Controlling BSP Cuts

[Shmitz]

Is there a way to do this in UT? I hail from a Quake/Quake-based engine mapping background, and there was this nice, wonderful little thing called a Hint Brush, that, if you had some good understanding of how BSP worked and how the map got chopped up when it was compiled, you could use to control where the lines got drawn. This was a really good way to cut down on complexity and increase framerate, as well as fix any small glitches that may have resulted from too many poly's being drawn.

I'm making a UT map now, and in one area I can see where it looks like there's been a BSP cut made through a room on the XZ plane, which ends up making a couple strange BSP holes in the upper area, and just in general making the cuts up there a lot more complex than they need to be. I can't help but think (probably due to my Quake background) that if I could get it to make a cut on the XY plane somewhere in the middle of the room it would probably help things a bit, as it would only be the lower area getting chopped up (and currently there are no glitches in the lower area).

So is there any way to do this with UT? Or am I just going to have to start playing around with brush order?

I can probably work things out with the latter method anyway, but it would still be nice to know for the future if there's any UT counterpart to Quake's hint brushes.

Oh, and while I'm on the subject of Quake to UT analogs, is there anything like caulking in UT? And is it even needed?
(Caulking, for those not familiar with Quake, is essentially a surface flag that tells the engine "don't draw me", while still allowing it to, if desired, affect things physically, like an ICH, and make BSP cuts)

 

[Techno JF]

Ah, this is a good post to reply to.

There should be a BSP cut view that allows you to see the way the engine splits the polygons. I don't know exactly what key triggers it, but it's with the viewing modes like Textured, Dynamic Lighting, and Zones/Portals.

Also, you can work with the BSP cuts a little by checking out brush solidity. A solid brush makes normal BSP cuts, but an additive brush that has been made semisolid will only make cuts on other semisolid geometry. Note: semisolids are a very good way to limits BSP cuts, but you should be wary of the possible errors that can arise because of them. In particular, don't intersect or deintersect semisolid brushes, because they are essentially just a bunch of sheets with collision rather than fully solid brushes.

There is also a slider in the Build menu that can help out. The extremes say "Minimize Cuts" and "Balance Tree." Note: USE THIS ONLY AS A LAST RESORT! It is known for causing unpredictable things to happen when a level is rebuilt. The same goes for the Zone Portal slider.

As for the subject of ICH's, this is usually done with invisible semisolid brushes. It's seen quite often in the making of windows, where a sheet is used to make the glass. However, since a sheet has no collision, and ICH is built next to the brush. Note: I say next rather than around the sheet because there are issues that arise when semisolids and nonsolids touch. To check out ICH's and other such things, look in the "Add Special" menu on the toolbar.

If you need some form of generic invisible blocking, try a BlockAll, or one of the other blocking actors under the Keypoint class. The names will tell you what they have collision with.

 

[Shmitz]

Yeah, semisolids are a lot like "detail" brushes in the Quake mapping terminology.

However, I've discovered that UT seems to be pretty picky about having a lot of semisolids around

I've thought about stretching a zone portal sheet across the room, but I've read this can cause a performance hit, and unless I mess with the sliders and turn the second one all the way up to "portals cut all", there'd be no garauntee it would force the BSP cuts to happen the way I want.

My questions about invisibility actually stems from what I should have asked in the first place: Do hidden sides of semisolids still get drawn? (Like, as mentioned in another thread, the bottom of a crate.) If they do get drawn, is there some way to make them invisible so as to decrease the number of poly's getting drawn? This is what caulking was often used for in Quake on detail brushes. If hidden sides of semisolids don't get drawn, then that would make things much simpler

 

[Techno JF]

Actually, from what I understand about the Unreal Engine, hidden sides of any brush aren't drawn.

Let me clarify what I think you're asking, so you can correct me if you mean something else. I haven't done any mapping for Quake-engined games, so I don't know about that interface or set of mechanics.

In any case, two solid surfaces that touch each other (such as the crate on the floor) will influence how BSP cuts are made on those surfaces, because all of the nodes of those two surfaces will be taken into account. In particular, BSP cuts will be made around the area where the two sides touch, thus keeping the shared parts of those surfaces from being rendered at all.

With a solid touching a semisolid, there is a set of details that makes all the difference. The solid geometry is built by the engine first, and all cuts on it are made at that time. Then the semisolid geometry is added and cuts on it are made. However, since a semisolid is essentially made of sheets with collision, you could theoretically determine how either side of each sheet is rendered. In the case of the inside surfaces of semisolids, I think that the engine automatically foregoes rendering them.

(I remember seeing a good picture of this in action one time. I'll see if I can't find it again.)

So, to make a long story short, I really don't think that hidden sides are drawn.

Oh, in that slider, I think the "Minimize Cuts" causes fewer polys to be rendered by the same piece of geometry, but the "Balance Tree" makes the engine look harder at the geometry to see what polys are in view and what the engine shouldn't bother trying to render.

Zone portals and nonsolids are something else entirely. You are correct about large zone portals causing a performance hit. The engine doesn't like for people to look through large zone portals at other zones. It has a way of counteracting the performance boost that zoning a map provides. Also, nonsolid geometry has no effect whatsoever on how BSP cuts on solid architecture are made.

I hope I'm helping. These are some challenging questions you're asking, and it's just as much a learning experience for me.

Oh yeah, and check this thread out. It starts out on another topic, but has a bit of relevant information on this subject.

 

[Shmitz]

You're helping

While I'm starting to get a good idea of the differences between Quake's detail brushes and UT's semisolids, I'll give a little bit more info about detail brushes just to provide more background on where I'm coming from:

Detail brushes are handled, roughly, like a mesh (so far as my understanding of it goes). If it's in a node that the engine says you can see, every side of it gets rendered, even if a poly is inside a wall or another detail brush. Needless to say, this could potentially make detail brushes pretty useless, since the performance hit you could take from so many poly's would counteract any improvements from a simpler BSP tree. So, you have caulk. By making sides you will never see invisible, the engine knows not to render them. If UT does this automatically, this is a very nice thing.

Though, about that thread you linked, Chris Toth says this:

-They can't be used as trim. If the outer surface lines up with the solid surface it will be removed leaving the Solid surface there. (No effect)

I don't really understand this statement, unless he's talking about texture trim and not physical trim. If he is talking about texture trim, I can see this as an indication that indeed, if a semisolid face tries to share a plane with a solid face, it gets chopped off and not rendered.


One huge difference though between Q3 detail and UT semisolid: in Quake 3 pretty much any brush (additive, since all q3 brushes are additive) that does not significantly block the player's view from another area of the map should be detail, as most sides would get rendered anyway, and making it detail would simplify the bsp tree. This does not seem to be the case with semisolids, from what I've read and experienced thus far.

 

[Techno JF]

You're correct about texture trim, because I've actually done it myself. Semisolid and nonsolid surfaces that are made coplanar with solid ones are completely discarded.

For example, trying to make a picture on a wall by using a nonsolid sheet doesn't work (unless you put it in front of the wall rather than on it), but a semisolid cube that's 1 unit thick would work just fine (a solid cube would add 4 extra nodes to the BSP, which isn't pretty). The back surface of the semisolid wouldn't show up, and if there's a problem with the paper-thin sides, they can be made invisible in the surface properties, as an alternative.

I can see that there is quite a system of checks and balances for detail brushes in the Quake engine, and this has been a good refresher for me about semisolids in the Unreal engine, because a very different system of checks and balances seems to exist.

Well, I can also tell that you've picked this up faster than most people who are new to UnrealEd. CSG (Constructive Solid Geometry) can be quite conterintuitive until you've had a generous supply of experience with it.

Oh, three more things you might be interested in knowing. First, brush order can make a much bigger difference in the Unreal engine, particularly with reference to solidity. I have been told that the best thing to do after finishing a map is to 1) order all semisolids to Last, 2) order all zone portals and other nonsolids to Last, 3) order all movers to last in brush order, and 4) rebuild geometry again. This can help performance since the engine doesn't have to pick out each type of brush as it goes through the list.

Second, I've heard that editors like WorldCraft use separate engines to build maps. Part of what makes UnrealEd so much faster and easier to work with is that it actually uses the game's engine (rather than one of its own) for building and rendering.

Finally, there is a map for UT called DM-Falkenstein that was designed specifically for the purpose of stressing out the engine and the editor. It uses a lot of semisolids, and it breaks a number of other rules in general, such as exceeding the 30,000 poly limit. You might check it out for a little inspiration.

 

[Shmitz]

Cool, this has been a lot of help. I had thought about trying the reordering thing (with the insertion of one more step at the beginning: send most additive solids last, except any subtracted through). Which brings me to one last (I think) question:

Let's say you want to build a simple cube-shaped room with a square catwalk halfway up. Is it better to

a) use one 256 tall subtractive brush for the top, one 256 tall subtractive brush for the bottom, and one 32 tall subtractive brush to make a "hole" that the catwalk runs around, or

b) use one 512 tall subtractive brush for the entire room and four 32 tall additive brushes for the catwalk?

Or would both methods yield the same results?

And: Using the latter method, would it be a bad idea to make the catwalk semisolid?

 

[MachDelta]

The last one would be best IMHO. Your using less brushes, so there are less polys and nodes to render. And yes, it would be a good idea to make the catwalk semisolid.

Anywho, on with the technical stuff'n'stuff!

 

[MachDelta]

BTW, I wonder if anyone has ever tried the mythical task of making a map completely from subtractive brushes.... man that would be a pain.

 

[Techno JF]

I agree with MachDelta...on all three accounts. Neither one is really wrong, but the second of those methods would be less difficult.

Here's an additional idea. Instead of using four additive cube brushes, add a hollow cylinder with four sides. You might have to rotate it 45 degrees, but I think that it will help that you would be able to make the whole thing with a single brush. UnrealEd's default brushbuilders are quite versatile.

 

[Major-Lee-High]

AHh the war against bad bsp cuts......

almost like the unreal worlds veitnam war.... too many casualties!! SURRENDER!

They can be tammed though! Trial and error! Sometimes moving a vertex fixes it, sometimes adding a box or other objext on top of it helps.... very strange nme!

 

[tarquin]

Originally posted by Shmitz
a) use one 256 tall subtractive brush for the top, one 256 tall subtractive brush for the bottom, and one 32 tall subtractive brush to make a "hole" that the catwalk runs around, or

b) use one 512 tall subtractive brush for the entire room and four 32 tall additive brushes for the catwalk?

I'd actually go for method a)

reasons:
1. the hole can easily be moved at a later stage without scaling or vertex editing
2. with method b) the upper & lower room walls are single polys, & so are forced have the same texture. Lining it up nicely might prove difficult -- a 32 jump will cause problems with most patterned wall textures.
3. each room can be resized individually.
4. the floor and ceiling around teh hole is a single texture poly so no alignment problems there.

 

[tarquin]

Originally posted by TechnoArcher
add a hollow cylinder with four sides. You might have to rotate it 45 degrees, but I think that it will help that you would be able to make the whole thing with a single brush. UnrealEd's default brushbuilders are quite versatile.

:tup:
Indeed. Works great for trim around a hole. The corners are mitred for you too.
Use the 'Align to Side' option of the cylinder builder -- you don't need to rotate.