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. 

TB will have groups for that purpose. You will then be able to hide and lock such groups. 

In WC they're called 'visgroups'. 

 

 

I've been using TyrUtils and Txqbsp.exe as a work around if I need to find a leak. I can't see the point of mapping without func_detail now.

TB can make some really wild brushes to the point that it's hard to tell if there valid. Simple is better. Make a few simple brushes instead of one complex monster. An option is create the complex brush and fill it in with simple ones to make the same shape then delete the complex one.

You can also make up prefab brush groups. As long as there good and on grid you can mash them up to create varied terrain.

IMO creating valid error free terrain has been the hardest thing to learn in Quake editing. 

That pointfile bug sucks, I'll get to work on that. 

Well, getting proper vis blocking is tricky as well - lots of maps are made without any at all and have infinite vis times. Detail brushes should help this some as well now though. But for the want of a few dogleg corridors or a doughnut, we've probably not seen many maps that the author(s) gave up on.

Sleepwalker, I'm going to start using trenchbroom exclusively now, so should be able to provide some more valid contributions in the coming weeks :) 

I'm also looking for another tester if you're interested. 

I'm already signed up on github, but haven't been active.