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. 

I used this on my speedmap, getting all kinds of crazy problems when I try to compile it. Is using this more or less prone to microleaks? It seems I can't use snap vertices and snap to grid to fix these problems.
Map is here if you're interested -

http://depositfiles.com/files/sgiknj9nk

compiled with treeq (tyr's wont let me compile beyond the bsp stage for some reason) 

I sent an email with that map. Loaded into Hammer and again the bad brushes could not be loaded. After I plugged the holes no leaks.
I added func_detail the map layout was a vis killer.

Link below works to compile.
I have found it to create bad pointfiles but everything else seems to work.

http://disenchant.net/files/utils/snapshot/tyrutils-0.7-42-gbb02e6d-win32.zip

Maybe you could use Hammer to filter out bad brushes. Trenchbroom's rules for bad brushes seem loose. 

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.

Look at Edit > Actions when brushes or entities are selected.

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.

That's pretty much unavoidable, but you can of course always use undo.

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

I agree that the angle indicators are flimsy right now. I'll improve their visibility.

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.</a>

Can't do it right now due to a limitation in wxWidgets, but it will be fixed as soon as wxWidgets 2.9.5 is released. Although I think you can move to the next field with TAB right now.

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.

Also being worked on.

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.

I agree with that. The reason why I'm trying avoid 2D views is that I want to find out how far I can push the 3D only approach. If it turns out that, even with things like a moveable grid, it is not possible to do certain tasks comfortably at all, then I'll reconsider 2D views. 

 

I'll take a look! 

The bad pointfiles are the reason why I'm resorting to using TreeQ, the only problem with that is I am playing a lottery game with brushes. I'm trying to avoid using Hammer if possible. I think maybe was that I had used the "force plane integers" on this map which really I only need vertex integers (probably).

As for it being a vis killer, I think this is going to be my curse as I used to make very open/large Unreal maps. Also I didn't really plan it properly because it's a speedmap. I think I will probably avoid terrain for speedmaps in the future.. 

The option to use integer plane points mostly exists for backward compatibility with older compilers. It will not avoid problems with brushes and might even produce more microleaks.

You need to get a feeling for what brush shapes are "safe" and what aren't. I haven't looked at the map you posted above, but here are some general rules:

- fewer faces on a brush are better
- very big and very small brushes can cause problems
- integer vertex coordinates can help, but cannot always be guaranteed due to rounding errors or lack of precision when integer vertex coordinates are enabled

Everyone feel free to add to that list. 

I used the speedmap to experiment with something that I haven't used yet. I think this backs up my thoughts quite well though, and it's clear to me that the compilers and the editors aren't really designed to do the things I want to do with terrain.
I have a few more experiments to do with terrain but I doubt they'll be as nice as what I've tried to do so far. 

Keep in mind how old Quake is. If you want to get crazy, maybe make maps for something more modern. Doing crazy crap in Quake is a challenge for people rather than the preferred platform. :) 

might be right - speedmaps are good places to experiment with that kind of stuff though. 

While I do encourage experimentation, I suggest you stick with trisoup or even prisms. The fewer vertices a face has, the better. The fewer faces a brush has, the better - ergo prisms are optimal. 

Like Wedges<Pyramids<tetrahedrons? 

has the brush geometry always need to have some thickness?
I.e like not using two edges to seal the map from void
(and avoid bsp holes)?
Not getting it... 

Yeah my next attempt at terrain will be some kind of trisoup/prism thing, but the work involved for this is hefty (and unlike cubes it's not as good for sealing off back faces). I really can't wait until you implement a floor lofter style tool, or have some kind of easy way of grouping brushes together for manipulation (or have a layer system).
It's still early days yet and I guess I'm still learning. 

What do you mean by that?

mfx: Ask me on wednesday when we have some paper in front of us ;-) 

or Worldcraft. You can make "layers", just throw brushes into the layer and you make them visible or invisible. I thought this was a feature you may look at adding some time down the line. It's probably more useful if you have 2d views though.