Red_Fist wrote:Overlapped subtracts, add brushes sticking out of subtracts
Both of which cause 0 problem are are perfectly normal methods.
As long as the brushes themselves are not bad.
As Ferali said, it's a question of moderation (and in this case, of local complexity).
fudgonaut wrote:So I want to dig deeper into this. I think it's an important point to illustrate - and I mean literally illustrate. Has anyone ever done a visual tutorial/explanation/example of how to avoid pitfalls with (concave/convex) shapes?
This is not as important an issue as you seem to think.
Shapes are not the issue, we're talking about polygons.
A brush can be concave, it can be a torus with a literal hole in the middle. But concave surfaces will have to be divided into several convex ones. This is usually achieved by the engine itself through BSP cuts, but sometimes, it will mess up and you'll see weird things like surfaces ghosting around. You can test this in a few seconds by creating a cylinder and moving one of the vertices inside the brush to create a Pacman-like shape.
The top surface is in red and as you can see, it's concave. I highlighted the perimeter of the surface and you can see a bit of this polygon is ghosting outside its limits. Because the engine tries to stretch a surface between all these vertices and at some point, it cannot do so without going outside the edges of the poly.
So what if you intersect it? Well the engine removes this problem by dividing Pacman into two polygons.
Victory! The top surface is divided now and you can see the two resulting coplanar surfaces are now convex, no more ghost polygons!
Except as you can see, there's this ugly thing now: the new line that divides the polygon ends in the middle of an edge, creating both a vertex off the grid and a T-junction (where a vertex is in the middle of an edge, in a sort of T shape). T-junctions are not as deadly in Unreal as in Quake, but it's bad form and it will still foster geometry problems. Off-the-grid vertices are always bad.
So my 10 surfaces cylinder in a cube doesn't have problems, but when you're messing with objects which have tons of polygons and vertices in an environment which is already complex, this becomes a concern.
fudgonaut wrote:
By working with Additive brushes in a negative space, my goal above was to gain greater control over pre-defining where splits/vertices were added - instead of letting Ued try to decide for me. As someone new to the editor, to me the resulting brush looks pretty clean.
Subtractive brush work the same as additives, There's not really much more control over the splits in my opinion, but if you find it easier, go for it, this is not an issue at all.
fudgonaut wrote:
Is this approach flawed? Is the brush problematic? OR, is it not a matter of the brush being problematic, but a matter of subtracting this brush shape that is problematic?
Your brush is fine because it's relatively simple: it's just a bunch of square polygons with on-grid vertices and plane or 45° surfaces and everything looks convex. I don't understand what you mean about subtracting though, subtracting does not cause more problems than adding brushes and they work exactly.
However, looking at the brush you end up with you can see the seeds of what I talked about earlier.
In cyan, all your nice T-junctions and the nice cuts the engine added.
In this case it's fine because your brush is simple and doesn't cause problem and without these new edges, the BSP cuts would probably have been similar to these actual edges. But obviously, you now have much less control: you can't move things around as easily if you want to modify the brush and if one of these cuts goes bad, then you have to change the whole thing instead of moving just a few things a couple units away. You can't convert small details from it into semi-solids either.
Same in your previous screenshot about intersecting the catwalks: I jump up and down about it not because the result you have is directly bad, (it looks fine, mostly, although there are a lot of cuts on the eastern end) but it's a slippery slope.
Basically, this is a very simple structure and so it doesn't really matters if you keep it into several separate polygons or in a single molded intersect.
But now imagine how surreal things would go if you were to intersect something like this:
Really, intersecting/deintersecting is mostly a bad habit. It will not be a sure recipe for disaster and there are cases where you need them (mostly to create big complex movers in a single brush). But I and probably everyone here has seen dozens of maps with huge complex intersects wreaking havoc because they were used in a retarded way. The less you use them, the better. Unreal has stable enough geometry that you can make full maps without needing them. My advice is to keep intersects to where you can't avoid them.
For the record,
here's an Unreal/UT99 map with exactly 1 intersect which is a mover.
(And oh noes tons of add brushes sticking out and overlapping subtracts, how can we fight the 0 geometrical errors!)
You must construct additional pylons.