DIF Splitting Brushes?
by Max · in Torque Game Engine · 07/27/2008 (11:34 am) · 12 replies
Hello everyone.
I have a question about how DIF exporters split brushes. I've looked through the TDN and have performed a search, but the documentation is not clear about it.
Judging from this TDN article: http://tdn.garagegames.com/wiki/DIF/greater_than_256_surfaces_on_an_interior_hull
It would appear that brushes are only split when they are intersecting other brushes.
But say I have an interior with NO intersecting brushes, but many of the vertices are sharing a position. Are any brushes split into more polygons than as I modeled?
For the sake of clarity, here are two diagrams.

The red and the blue brushes are intersecting. I understand that this would cause the brushes to split into non-intersecting brushes, but create more faces.

The red and blue brushes are NOT intersecting, but do have faces touching. Will this cause any more splitting?
Thanks!
I have a question about how DIF exporters split brushes. I've looked through the TDN and have performed a search, but the documentation is not clear about it.
Judging from this TDN article: http://tdn.garagegames.com/wiki/DIF/greater_than_256_surfaces_on_an_interior_hull
It would appear that brushes are only split when they are intersecting other brushes.
But say I have an interior with NO intersecting brushes, but many of the vertices are sharing a position. Are any brushes split into more polygons than as I modeled?
For the sake of clarity, here are two diagrams.

The red and the blue brushes are intersecting. I understand that this would cause the brushes to split into non-intersecting brushes, but create more faces.

The red and blue brushes are NOT intersecting, but do have faces touching. Will this cause any more splitting?
Thanks!
About the author
#2
What are the negative effects of disabling Hidden Surface Removal?
Also, besides preventing the brushes from being split, what else do detail brushes do? Do they still have collisions, and will it effect the lighting in any way?
Thanks again.
07/28/2008 (7:07 am)
Thanks John.What are the negative effects of disabling Hidden Surface Removal?
Also, besides preventing the brushes from being split, what else do detail brushes do? Do they still have collisions, and will it effect the lighting in any way?
Thanks again.
#3
There are situations where turning off HSR can resolve problems with dropped faces, but 99% of the time you'll want it enabled.
Detail brushes look and act like structural brushes in-game. The only major difference is how they split geometry in your DIF. They have the same collision and lighting characteristics as structural brushes.
Zones and portals depend on structural brushes to figure out where things are, though, so all of the walls enclosing your zones or surrounding your portal brushes should be structural.
Detail brushes are good for -- well, for details! They're perfect for columns, arches, railings, stairs, and architectural widgets that aren't key structural parts of a building, and would otherwise break up the brushes around them.
07/28/2008 (2:38 pm)
You should leave HSR enabled whenever possible. Without the HSR pass, your engine will waste valuable time rendering faces that are never seen by the player, which adds up fast on a large, complex level. You can also get "z-fighting" artifacts, where two overlapping faces flicker and strobe (usually with diagonal stripes) as the engine tries to draw them both.There are situations where turning off HSR can resolve problems with dropped faces, but 99% of the time you'll want it enabled.
Detail brushes look and act like structural brushes in-game. The only major difference is how they split geometry in your DIF. They have the same collision and lighting characteristics as structural brushes.
Zones and portals depend on structural brushes to figure out where things are, though, so all of the walls enclosing your zones or surrounding your portal brushes should be structural.
Detail brushes are good for -- well, for details! They're perfect for columns, arches, railings, stairs, and architectural widgets that aren't key structural parts of a building, and would otherwise break up the brushes around them.
#4
07/28/2008 (2:51 pm)
Detail brushes are exactly the same as normal brushes in every way, except that can't be used to identify portaled areas, while structural brushes can. This is why structure brushes split the faces they touch, something to do with dividing it so it can register portals (I don't know the exact mechanics, just that it does it) so use detail brushes on anything that isn't a wall, floor, or ceiling that you need to contain a portaled area. So if you have one very large room with 2 doors, portaled off on each side; and many walls and subrooms inside the main room which you will not be portaling, each of those subrooms can be built with detail brushes (even though it seems like a structural component to the building)
#5
Now I know why my previous bases and structures made such a big hit on the frame rate. It also looks like I'll have to change the way I model. I've always gone out of my way to make sure vertices lined up perfectly, faces always touched exactly, be never overlapped.
I guess this was all a kind of pointless effort when I could just turn a lot of those detailed shapes into detail brushes.
Thank you all very much, you've been a huge help.
07/28/2008 (4:20 pm)
Wow, thanks for the swift responses. Very good ones at that.Now I know why my previous bases and structures made such a big hit on the frame rate. It also looks like I'll have to change the way I model. I've always gone out of my way to make sure vertices lined up perfectly, faces always touched exactly, be never overlapped.
I guess this was all a kind of pointless effort when I could just turn a lot of those detailed shapes into detail brushes.
Thank you all very much, you've been a huge help.
#6
One strategy you can try is to let your brushes overlap, but use the CSG Subtract operation to remove the overlapping portions. So, you could line your brushes up like your first example, then select the red brush and perform a CSG Subtract. The overlapping end of the blue brush is zapped out of existence, and the remainder is a perfect fit.
-- JohnDopp
07/28/2008 (4:58 pm)
Well, overlapping brushes are considered bad form, and it can lead to problems. And detail brushes won't solve all your woes.One strategy you can try is to let your brushes overlap, but use the CSG Subtract operation to remove the overlapping portions. So, you could line your brushes up like your first example, then select the red brush and perform a CSG Subtract. The overlapping end of the blue brush is zapped out of existence, and the remainder is a perfect fit.
-- JohnDopp
#7
07/29/2008 (6:53 am)
I find as long as you keep lining up the brushes with the grid, as long as you aren't working on a shape too small (like tiny railings or something) it is pretty easy to keep everything from intersecting. @John, I think it's actually the selected brush that does the removing, not get's pieces removed from it.
#8
07/29/2008 (2:36 pm)
Right-o, that's what I said. =D
#9
07/29/2008 (3:40 pm)
If you do disable HSR, using the null texture on those faces will clean up the z-fighting issue. It's also a good idea to use the null texture for the non visible faces of detail brushes. Hidden faces for detail brushes aren't automatically removed like they are for structural brushes. There are options for it in Constructor though.
#10
@John:
07/29/2008 (3:59 pm)
@Maxwell:Quote:Now I know why my previous bases and structures made such a big hit on the frame rate.A hit on performance is most likely the result of a A) An inadequately portalized DIF, B) The lack of additional Levels of Detail, C) Excessive detail brush usage (since they cannot be culled via the BSP process), or D) all of the above.
@John:
Quote:Well, overlapping brushes are considered bad form, and it can lead to problems...Considered bad form? LOL! Maybe if you don't know what you're doing! =) There's nothing inherently "bad" about brushes overlapping. It's the application of overlapping brushes that can lead to problems. But used correctly, they can be extremely useful; for example, for sealing the outside of a level or to avoid duplicating brushes unnecessarily. In fact, the only problems I can immediately think of right now with overlapping brushes is where they either result in co-planar faces or where they visibly fragment a large flat surface, making the surface's light map look like crap. [Edit: And even a non-overlapping brush will fragment the surface if it's flush with the surface and not a detail brush.]
Quote:One strategy you can try is to let your brushes overlap, but use the CSG Subtract operation to remove the overlapping portions. So, you could line your brushes up like your first example, then select the red brush and perform a CSG Subtract. The overlapping end of the blue brush is zapped out of existence, and the remainder is a perfect fit.If this gives you some sort of peace of mind, then great. But it's pretty much a complete waste of your time, since this process is already performed automatically by the map exporter for all structural brushes. And it's a waste of time for detail brushes as well, unless you have an extreme number of detail brushes inside or interpenetrating into structural brushes, in which case, you need to re-think your level design anyway.
#11
I was under the impression that overlapping structural brushes led to larger DIFs, possible performance issues, and lightmap issues. If I've been misinformed, excuuuuuuse me! Perhaps it was just the geometry being split that led to that iffy DIF info.
Anyone else want to chime in on this issue? I'd love to see a consensus on the matter.
-- JohnDopp
07/29/2008 (4:57 pm)
@Kevin: I never, ever claimed to know what I was doing. =DI was under the impression that overlapping structural brushes led to larger DIFs, possible performance issues, and lightmap issues. If I've been misinformed, excuuuuuuse me! Perhaps it was just the geometry being split that led to that iffy DIF info.
Anyone else want to chime in on this issue? I'd love to see a consensus on the matter.
-- JohnDopp
#12
Like I mentioned before, any overlap is automagically dealt with in the exporter -- any overlap/interpentration is culled and is not exported to the DIF. The key thing to note, however, is the face splitting which occurs, which generates more polygons, which can, of course, affect performance. (And fuxxor light maps, but that's mostly a visual snafu than a performance one.) But, like I also noted, brushes do not have to overlap to split faces, they only have to be touching. This is where detail brushes come in handy. BUT (yes, another one), excessive detail brush usage can also create performance issues, because detail brushes are never culled from the DIF, even when overlapping or inside other brushes; thus all polys for detail brushes are rendered, whether visible or not. (Sans back-faces, of course.) It's something of a balancing act between using detail brushes as much as possible to avoid any face splitting, yet not over-using them.
I tend to completely avoid using detail brushes initially, then I go back and start converting structural brushes to detail brushes where needed.
Also, unless the player is always inside the interior, you really should create at least a couple LOD versions of the interior; this affects performance more than anything.
07/31/2008 (12:39 pm)
@John: Heh. =)Like I mentioned before, any overlap is automagically dealt with in the exporter -- any overlap/interpentration is culled and is not exported to the DIF. The key thing to note, however, is the face splitting which occurs, which generates more polygons, which can, of course, affect performance. (And fuxxor light maps, but that's mostly a visual snafu than a performance one.) But, like I also noted, brushes do not have to overlap to split faces, they only have to be touching. This is where detail brushes come in handy. BUT (yes, another one), excessive detail brush usage can also create performance issues, because detail brushes are never culled from the DIF, even when overlapping or inside other brushes; thus all polys for detail brushes are rendered, whether visible or not. (Sans back-faces, of course.) It's something of a balancing act between using detail brushes as much as possible to avoid any face splitting, yet not over-using them.
I tend to completely avoid using detail brushes initially, then I go back and start converting structural brushes to detail brushes where needed.
Also, unless the player is always inside the interior, you really should create at least a couple LOD versions of the interior; this affects performance more than anything.
Torque Owner John Doppler Schiff
The brushes do not necessarily have to intersect to be split; the surfaces only need to be touching.
In your second example, Hidden Surface Removal will split the brushes.
Turning off HSR (not a great solution), or making the blue brush a Detail Brush will prevent the geometry from being split.
Hope that helps!
-- John