It's a bit of a learned art. I struggled at first to make good shapes with the vertex editor, but once you catch on to the fact that the directions you can pull properly in are affected by your camera angle it becomes a bit easier to use. Trying to push at a severe angle to the camera produces wacky results where the vert just shoots off into the distance...

I will definitely say that building curves is very painful, and primitive support would be appreciated... 

I have been struggling with same thing.. I personally would like to figure out what is going on in every view.

TB[Version 2] has orthogonal view also.. but only reason why those are useful/fast is when using precise steps, and working on basic layouts of your map (but that is just my opinion.

If there is going to be multiple layers of rooms on top of each other everything will get messy and hard to navigate through these orthogonal view.

You can group/put in different layers your entities and brushes, and try to organize your used space. For example layers: "Top Floor" "Mid Floor" etc. but even though TB support using those.. it is really time consuming and not always worth of effort.

In the end you just need slowly get used to what ever feels better for you.. or maybe using other editor for different uses.. I use J.A.C.K and TB together. For example I love J.A.C.K features that can create arches, cylinders and all kind of basic shapes, but everything else I do basically in TB. 

I really should give J.A.C.K. a try for those primitives, I've made some pretty awful circles in TB... 

Yeah TB totally is not for those kind of primitives... hopefully in the future there will some features for those even. 

@Pritchard I didn't say it's the best, I said it's the most intuitive. I also added "that I've ever tried". Of course, other editors probably have stronger points, but they're also much more complex to handle for n00bs. Never tried J.A.C.K. but I tried editors like WC and Radiant back in the day, was put off by their complexity and never got past one blocky empty room. With TB I could build stuff from the get-go in the 3D view without having to memorize the full readme first. That's intuitiveness at its finest IMHO. That said, I'm right here with you regarding primitives. Has anyone made a feature request for those on Github?

@NewHouse You can easily make cylinders in TB with the intersect feature: build a cube, duplicate, rotate, intersect. Rinse and repeat.

@Sevin Study the help file. There are keyboard shortcuts that will make your life much easier, like locking the editing along one axis to prevent the kind of weird behavior you were talking about. 

Yes, TB is very shortcut-focused. I read the readme while I missed around. You can lock movement to one axis only when you've already begun moving, and most of the time it would start on the wrong axis. I don't want to have to keep jiggling my camera so I can get the vertex moving in the right direction. Plus, moving the cam so I can get on the right axis often has the consequence of making it impossible to see where I'm going, so I end up bouncing back and forth between moving my camera and moving the vertices. It's not intuitive to me, but I can see how setting up basic brushwork on the 32+ grid could be greatly streamlined using TB. Maybe using TB for alphas/whiteboxes and then Radiant/WC for betas and later would be a good practice. 

You must be first one ever suggesting something like that.. it doesn't come to my mind at all, because I always though rotating in TB wasn't that trustworthy. And especially when trying to make stylished simplified cylinders that method is trying to achieve more realistic look? 

Like this? https://drive.google.com/file/d/0BwxYkKdSD855N0lNUlViYUQ1Rm8/view?usp=sharing 

The only CSG operation that I trust is merge. as far as I'm concerned, subtract and intersect are black magic not to be messed with...
It always takes me at least like, 3-4 tries to get subtract to work ;-; 

Getting kind of off topic, but speaking of CSG: why does HL have a CSG build program but Quake doesn't? What does CSG do that BSP doesn't? 

@NewHouse Yes, like this, but without forgetting to intersect your brushes so that no cubes remain... ;) I made pretty nice 24-sided columns in my first test map using this method with the default 15-degree rotation. I'm sure I'm not the first one to think of that. What do you mean by "not that trustworthy"?

@Pritchard According to the doc, CSG subtract and intersect are more reliable in TB than in other editors. The only time I used subtract so far was to make an 8-sided tube with two of those cylinders and it worked like a charm on the first try. 

By trustworthy I mean specific cases where geometry was very complex, then something like that didn't worked back then.. but maybe when working on simplier shapes.. I just have couple bad experiences about it back then, I know there has been a lot of updates etc. but what can you do. Your mind just says stay away from areas that have causes you problems even earlier.

For example I was trying to create almos realistic tree by using these merge, subtract and intersect and it totally broke the geometry, but that was maybe just back then. 

Indeed, a tree is far more complex than a cylinder! A cylinder is only a convex brush, so it has little chance of breaking geometry on its own. 

Sevin: I couldn't reliably pull edges/vertices in the direction I wanted and would spend over a minute shaping just one of the four brushes for half of the arch I would need to adequately match the curvature of the texture. It just seems like complicated geometry would be difficult to work with in TB.

I agree that an arch / primitive builder is sorely missing from TB, and it is very high on my list of todos. I would however be interested to hear why it's so hard to move the vertices where you want in TB. I suppose you have figured out that you always move things around on the XY plane, and can switch to vertical movement along the Z axis by holding the ALT key?

Pritchard: the directions you can pull properly in are affected by your camera angle

That's not true at all. In fact, I have made it a point to avoid doing this. The camera angle should not affect how your actions (mouse movements) are interpreted. The fact that vertices shoot off into infinity if you're looking at things at a shallow angle is a direct result of that, it's impossible to avoid. What's the alternative, disable one movement direction when the camera angle is shallow? Which one? At what angle? I toyed with that, and it sucked.

The truth is that using only the 3D view is not as useful as I had originally envisioned. That's why I added the 2D views. If you need better precision, use those.

Sevin: You can lock movement to one axis only when you've already begun moving, and most of the time it would start on the wrong axis.

I don't understand. You can select the axis yourself, it's the one you have moved the farthest distance on. Why is that difficult to handle? I'm asking out of genuine interest - maybe I can improve it?

Sevin: I end up bouncing back and forth between moving my camera and moving the vertices.

But that's how you work in a 3D view. I am not an avid user of 3D modeling tools, but I would think that having to move the camera around a lot is necessary in those tools also. I urge you to read up about and use the camera's orbit mode (hold alt and drag with right mouse button). It makes adjusting the camera angle so much easier because you can control the point of rotation yourself and therefore control what the camera is focused on.

Pritchard: The only CSG operation that I trust is merge. as far as I'm concerned, subtract and intersect are black magic not to be messed with...

Why? As long as your geometry is clean and as long as you're not doing anything crazy, CSG subtract should give you much better results in TB than in other editors. Of course, all within the limits of brush-based geometry that doesn't support CSG in the first place. You have to remember that CSG is always an emulation with geometry that's based on convex polyhedra.

Newhouse: For example I was trying to create almos realistic tree by using these merge, subtract and intersect and it totally broke the geometry, but that was maybe just back then.

For the reasons I gave above, this is a really bad idea, as you have realized by now ;-) 

One of the things that always gets me with TB's workflow, and no, I don't have any better ideas, is the priority in which brushes are treated. I feel like half the time it's random which brush an operation "chooses". I think it cuts the second brush out of the first brush when I subtract, but for some reason it just doesn't seem natural to me and instead I end up with the brush I wanted to use to cut floating in empty space.

Same with right clicking to move brushes into different groups or entities; I don't think I realised that's how it works until recently. I would try selecting both brushes and then right clicking to use the option, thinking that it didn't matter where I clicked, and that somehow the tool would decide which entity to make the brush a child of based on the order I selected them in (Almost a valid criticism here: Subtract depends on the order of selection, adding brushes to entities does not, a fix would be to put CSG in the right click menu (a bad idea??)). In any case, that basically meant me fumbling around with deselecting, reselecting and all that until i got lucky and happened to right click on the right thing.

And well, before this thread and that circle demonstration I don't think I really understood what intersect did; I mean, I know what the word means, and it seems obvious now, but still... I should really spend an afternoon with the manual.

Merge is nice because it doesn't matter what order you select brushes in or any of that mumbo-jumbo. It just sticks them together, resolving concave gaps in a sensible way that I can understand.

And on vertex movement:
I see where you're coming from, and why there's no easy way around it, but it does still feel out of place to me having a vertex shoot off uncontrollably. I'm not really saying you should fix it, like you say it's just an issue with a 3D camera viewpoint in general.



So yeah, my complaints are basically all just grumblings of a guy who never had to deal with vertices, selection order or CSG in previous editors and is still trying to understand them for the first time...

This has been your daily dose of Pritchard confesses his idiocy� 

I should really spend an afternoon with the manual.

Yes you should. That said, I agree that user actions should depend on as little context as possible. For example, as you noticed, CSG subtract depends on the history of user selections, but the details are arbitrary. Is the first selected brush the minuend or the subtrahend? Even I don't remember, but then I'm not a user.

Fortunately, CSG subtraction is the only action where this is the case. I did it this way because I felt like all other options weren't any better, and this was the least amount of work for me.

If you have concrete ideas on how to make things simpler, let me know on github or over in the TB thread. 

However, I found vertex manipulation to be extremely finicky, though I may just need more experience with the controls.

I've developed the habit of using the arrow keys + page up/down to avoid too much mouse movement. Quite like it that way, esp with alt + arrow keys for rotation. Combine that with number keys for grid density.

I find myself wanting those operations in 2D editors now, esp rotation, it really sticks to muscle memory.

One thing that bugs me about mousing verts is that it seems to decide on the plane in viewspace while it does it in worldspace for brushes. I would prefer the latter to be the standard behavior everywhere, less thinking involved, smaller brain volume required.

(hoping these things have fixes and Sleepwalkr yells at me to RTFM) 

it seems to decide on the plane in viewspace while it does it in worldspace for brushes

Both behave in the same way. Which version are you using? 

TrenchBroom 2.0.0 Beta Build 31439f2 RelWithDebInfo

I'll check the latest dev build to see if I have the problem there. 

I posted some suggestions to improve the axis lock system in the TB thread. 

I'll try to explain, as someone who is most at home with the Worldcraft/Hammer series..

I'll use the 2D view exclusively to create the basic outline of a structure e.g. floor plans. At this early stage, the 2D view is clean and uncluttered and it's easy to see what is going on.

At a more advanced stage, such as in your screenshot, the 3D view takes over. I fly around in it, select brushes in it, adjust textures in it. The 2D view still helps for complicated brushwork, and because Hammer highlights any selected brushes in bright red, they stand out well against the 2D view background clutter. Even so, if I'm resizing a brush or doing vertex manipulation my eyeballs will probably be flicking between the 2D and 3D views to see the results.

In a nutshell, I don't try to make sense of the huge mess of 2D geometry in one go, only the parts being worked on in the moment. Hiding stuff also helps, probably all editors have a way to do this (in Hammer it's visgroups). Having the 3D view open at the same time helps me confirm I'm doing what I think I'm doing. Finally, if I've been working on a given area for some time, building it up from basic brushes, I get to know by heart what each coloured box in the 2D view corresponds to anyway. This is a lot different to opening up someone else's project and trying to make sense of it all for the first time. 

Auto visgroups are another great addition to the Source Hammer. I use auto visgroups all the time to help clean up the 2D views and make what I'm looking at in the 3D view easier to see. That's one of several things I miss from the Source Hammer to Quake/GoldSrc Hammer derivatives. 

I always found quark's handling of 2d view clutter to be elegant. The 2d views are locked together (linked zoom and pan) so the area they are looking at is a cube, and any brushes outside of that cube are drawn greyed out. 

Who let the quark kid in here?