It crashes with 4K errors? 

has nothing to do with what Valgrind is reporting. I have looked at it, and most of the errors are within the libraries. It reports quite a bit of errors related to uninitialized variables, but these are usually due to how OpenGL works:

GLint textureId;
glGenTextures(&textureId, 1);

Valgrind will moan about this, but it's not actually in error. It's an easy fix to shut VG up, though:

GLint textureId = 0;
glGenTextures(&textureId, 1);

In any case - Valgrind won't help you finding the problem that you're seeing. That's not really a programming error but a flaw in how I set up the OpenGL context. I'll have to find a different way. 

LIBGL_ALWAYS_INDIRECT=1
should remove all false positives associated with opengl dma use.
which should actually make valgrind usable with such programs. 

just finished up recording the first in a series of TB tutorial videos (yes, you get to hear my basso gravelly northern english accent)... They're not properly finished yet (needs a bunch of tweaks etc) but suffice to say me and my friend had fun making them and definitely want to continue making them.
These are starting off at the lowest-entry point, intermediate and advanced mappers need not apply, literally the first vid is about installing quake, getting wads, downloading software etc and then working up to "my first room". 

Looking forward to seeing them! 

I'm in't Penrith. 

I'm not as north as you are, I'll give you one clue though...

"garlic bread is the future, I've tasted it!" 

Garlic....... BREAD?!?! 

Yep... My next map is a caravan for me mam. 

Can you try running TB from code blocks in the debugger? Strangely, it works for me that way on my VM. 

I have no idea how to do that, I'm not familiar with Codeblocks at all (nor with other IDEs, I use vim). 

 

Please update the sources and recompile, then run the editor (not from the IDE). It may fail on the first try, but it should work the second time. I have no idea why this is happening, but at least it now works on my VM and my MacBook Pro in Ubuntu 12.04. 

I did that. After that suggestion, I got it running on the third try. I experimented with this some more, and it seems to be random if it runs or crashes. But when I try enough times, I can get it to run.

It seems to crash when I press "V". This can be reproduced; this is the message:

(TrenchBroom:16513): Gtk-CRITICAL **: IA__gtk_window_resize: assertion `width > 0' failed
TrenchBroom: /home/jonas/TrenchBroom/Source/Renderer/Shader/ShaderProgram.cpp:155: bool TrenchBroom::Renderer::ShaderProgram::setUniformVariable(const String&, const TrenchBroom::Math::Vec3f&): Assertion `checkActive()' failed.
Afbrudt (SIGABRT)

Under "View -> Grid" I can select all grid sizes with the mouse at the same time (so they are all shown as toggled on with a hook in front).

When I click on "Snap to Grid", the 1 unit grid is displayed no matter what grid size I have selected.

Is there a key combo to snap a brush to the currently selected grid size? Shift-Ctrl-G doesn't do it and I can find nothing else in the Preferences.

Movement with WASD is jerky, there is a delay between button press and reaction and sometimes a stuttering effect to it. Rotating the camera stutters also. It won't accept multiple button inputs (eg W and A) at the same time (does nothing in such a case). I've tried all the different OpenGL Instancing settings.

Those are my initial findings, I'll give it some more time. 

I managed to enter vertex mode once, so that bug actually doesn't *always* happen. 

The vertex mode crash is usually fixed by setting the Instancing mode to "Force off" in the preferences. If that doesn't work for you, I'll have to investigate some more. Could you paste the stack trace for the crash at pastebin or something? The lines get truncated.

Movement is not implemented like in game ATM - there is no "fly through" mode yet. Pressing "A" actually just invokes the menu item for "Move Camera Forward", that's why you can't press multiple keys at once.

There is no command to snap a brush to grid size, "Snap to grid" toggles grid snapping. Rotation should be smooth - are you running a release or a debug build? 

Awesome, setting instancing to "force off" seems to prevent the crash indeed. So far, so good.

I was running a debug build. I'll try a release build.

I intend to also try this under Windows, so that I can form an opinion with the various bugs out of the picture.

I see about the movement.

At least I see an editor now, thanks for bearing with me. 

Sorry I didn't notice that.

http://pastebin.com/4878suLa 

The current build has serious problems with the menu on Linux. Menu items don't get disabled when they should (such as the Copy item when nothing is selected), leading to crashes when such menu items are invoked.

I'm trying to fix it, but I can't for the life of me find the cause. wxGTK behaves very differently from the other platforms. The current Windows version is much more stable. 

for the pastebin. Note that TB writes a log file at ~/TrenchBroom.log - could you try and find the lines it printed just before it crashed? I suspect that the problem comes from the driver not being able to compile a shader. 

It's actually a bug in Ubuntu: http://trac.wxwidgets.org/ticket/14302 Man, I hate this sometimes. 

Some more observations:

1. "Open recent" seems to do nothing.

2. Clicking "TrenchBroom Help" opens Firefox, but not the correct website.


Some problems I have while trying to quickly block out a room-and-corridor map:

1. Drawing new brushes with the mouse makes them appear "somewhere in space". I can't help but find Radiant's behaviour more intelligent, which is to make the newly created brush the same height as the previously selected one and place it on the same ground plane.

2. Having to press Alt (and everything that interferes with it on a Linux desktop) to be able to scale a brush in the Z direction. Again, Radiant allows you to resize brushes in all directions (in the 3D viewport) without any keypresses; the axis it chooses depends on your position relative to the brush and the mouse placement/movement. This seems quicker and more intuitive in Radiant.

3. I would appreciate (if a real 2D viewport is such a big no-no) to have at least an ortographic view toggle and keyboard shortcuts for top/side/front view like it is handled, for instance, in Blender. Example: When you press numpad 1 in Blender while in ortho view, you get a front view and the grid appears perpendicular to the camera. This (like the 2D view in other map editors) is helpful to check your mesh/brushes at a glance.

4. Movement through space is more intuitive in Radiant, because it is identical to the way you move ingame (with noclip). In this way, you don't need a camera orbit mode in Radiant, because you can practically circle-strafe around the object you want to examine. You can't beat WASD flythrough mode.

5. It is (in my opinion) easier to create a brush angled at exactly 45 degrees (or similar) in a 2D viewport, because that allows you to count the grid intersections to the side and to the top to arrive at the exact angle you want. In TrenchBroom, the grid is drawn on the brush itself; while you can do the counting, it is harder to do in TrenchBroom. This is another case where an orthographic top view with a grid shown in the entire viewport would really help. Note that while I could use a "helper brush" to allow me to do the counting, I'm one of those people who prefer to block out the walls first, not the floors.

6. I would appreciate a keyboard shortcut for "snap all selected brushes to the current grid" identical to Ctrl-G in Radiant. I just like to make damn sure that stuff is on grid.

Most of these problems relate to quick blocking out of buildings. I'll gladly believe that triangle terrain is easier to do in Trenchbroom, and that vertex editing is more comfortable (you pretty much have to use the clipper in Radiant to get the shape you want), but for blocking out angular geometry I find myself wanting to use Radiant.

I'll keep trying TB, though. 

1. "Open recent" seems to do nothing.

This is already fixed, but I haven't pushed the changes yet.

2. Clicking "TrenchBroom Help" opens Firefox, but not the correct website.

I'll look into it. Where is TB installed on your system? What permissions are set for the Resources directory?

1. Drawing new brushes with the mouse makes them appear "somewhere in space". I can't help but find Radiant's behaviour more intelligent, which is to make the newly created brush the same height as the previously selected one and place it on the same ground plane.

Brushes only appear "somewhere" if you don't start drawing them on some other surface. Once you have a couple brushes laid down, this becomes rather intuitive IMO.

2. Having to press Alt (and everything that interferes with it on a Linux desktop) to be able to scale a brush in the Z direction. Again, Radiant allows you to resize brushes in all directions (in the 3D viewport) without any keypresses; the axis it chooses depends on your position relative to the brush and the mouse placement/movement. This seems quicker and more intuitive in Radiant.

You can resize in any direction in TB by holding shift. Alt is only for moving things in the Z direction. I'm staying away from any kind of functionality that depends on the camera direction / position for all operations (exception resizing where it's implicit).

3. I would appreciate (if a real 2D viewport is such a big no-no) to have at least an ortographic view toggle and keyboard shortcuts for top/side/front view like it is handled, for instance, in Blender. Example: When you press numpad 1 in Blender while in ortho view, you get a front view and the grid appears perpendicular to the camera. This (like the 2D view in other map editors) is helpful to check your mesh/brushes at a glance.

Yeah, we've had this discussion already, and the gist if it is "no" ;-). What you're suggesting is basically a poor substitute for a 2D view. If you can't live without 2D views, this editor is not for you. That said, there seem to be plenty of people who, after getting used to how TB operates, don't mind the lack of 2D views.

4. Movement through space is more intuitive in Radiant, because it is identical to the way you move ingame (with noclip). In this way, you don't need a camera orbit mode in Radiant, because you can practically circle-strafe around the object you want to examine. You can't beat WASD flythrough mode.

I'm already working on a fly through mode which will also allow you to do editing much like how it works in the Sauerbraten editor.

5. It is (in my opinion) easier to create a brush angled at exactly 45 degrees (or similar) in a 2D viewport, because that allows you to count the grid intersections to the side and to the top to arrive at the exact angle you want. In TrenchBroom, the grid is drawn on the brush itself; while you can do the counting, it is harder to do in TrenchBroom. This is another case where an orthographic top view with a grid shown in the entire viewport would really help. Note that while I could use a "helper brush" to allow me to do the counting, I'm one of those people who prefer to block out the walls first, not the floors.

A positionable 3D grid is already planned for the next version. It will help in such situations.

6. I would appreciate a keyboard shortcut for "snap all selected brushes to the current grid" identical to Ctrl-G in Radiant. I just like to make damn sure that stuff is on grid.

What do you mean by "snap all selected brushes" - snap their vertices?

Most of these problems relate to quick blocking out of buildings. I'll gladly believe that triangle terrain is easier to do in Trenchbroom, and that vertex editing is more comfortable (you pretty much have to use the clipper in Radiant to get the shape you want), but for blocking out angular geometry I find myself wanting to use Radiant.

Yup, TB is weak in that department. I'm trying to address this with the positionable 3D grid and other features.

Thanks for your feedback! 

What do you mean by "snap all selected brushes" - snap their vertices?

Yep, snap them so all their vertices are on the currently selected grid.

Brushes only appear "somewhere" if you don't start drawing them on some other surface. Once you have a couple brushes laid down, this becomes rather intuitive IMO.

I noticed that the plane they appear on seems to be influenced by where you click on adjacent brushes, but I haven't managed to draw a new brush on the same ground plane as an adjacent brush.


More observations...

7. A shortcut to rotate any object by 90 degrees around the Z axis would be nice for e.g. monster placement. It is just faster than using an arbitrary rotation tool.

8. Rotating a brush horizontally to some arbitrary angle, then rotating it back (with snap to grid turned on) makes the brush go off grid with some coordinates now being floating point numbers. Thus it is pretty easy to create off-grid geometry, and that's where a "snap to grid" button would be useful.

9. Setting the angle of a func_door could be more comfortable if it was displayed in the 3D view.

10. Creating a key on an entity requires mouse clicking on the "Value" field after entering the key name; it would be faster to automatically move the cursor into the Value field after pressing Enter. Because as it is now, it requires you to reach for the mouse in between.

11. Creating a hollow box is harder in this 3D view than it is in a (Radiant) 2D viewport. I'm not talking about CSG Make Hollow, just building a box by hand. I like to box my maps during development, and I box large outdoor areas as well (put the pitchforks away, I know what I'm doing). I'm just saying it is hard to create a simple hollow box made from 6 brushes around the entire map with the 6 sides perfectly fitting, because drawing brushes (and navigating around the map, too) is klunky right now.

12. I find myself wanting to increase the movement speed of the WASD keys.

13. It would be good to have a method of axis-aligned movement; ie restrict moving a brush to the X or Y axis as well as the Z axis. Use case: Still trying to make a non-leaking large box.



Anyway, I'll quit for tonight.

I appreciate the idea of making a 3D-only editor, but IMHO this dogma introduces a couple of its own problems that would be very easily solved by such terrible things like a switchable 2D viewport or even a gizmo. It seems extremist to see the 3D viewport as the only good way to map.

It's not like I depend on the 2D viewports in a big way; I mainly use the 3D viewport in Radiant as well, which is definitely possible. I just think that for certain specific uses, a 2D view is very hard to beat.

More power to you, of course, it is your editor after all.