Detail Brushes vs. No-Touch Geometry
by Scott Doerrfeld · in Torque Game Engine · 11/01/2006 (6:37 am) · 15 replies
So I have read about two methods to prevent a brush from splitting the surface of another brush:
1) Make one of the brushes a "detail" brush.
2) Shift the brushes slightly so they are not touching.
I have a room with a LOT of chair legs going into the floor, so I have to implement one of these methods. Does anyone know which method is better for performance? I am somewhat suspect that having tons of detail brushes could be bad for performance, but I may be wrong.
1) Make one of the brushes a "detail" brush.
2) Shift the brushes slightly so they are not touching.
I have a room with a LOT of chair legs going into the floor, so I have to implement one of these methods. Does anyone know which method is better for performance? I am somewhat suspect that having tons of detail brushes could be bad for performance, but I may be wrong.
About the author
#2
It is my assessment so far that using more detail brushes results in a slighly lower framerate, even with much fewer surfaces. Check out these results:
Method 1 - Detail Brushes (for chair legs)
- Total brushes: 624
+ structural: 442
+ detail: 180
+ portal: 2
- Number of zones: 2
- Number of surfaces: 3653
Highest Framerate: 110 fps
Method 2 - No-Touch Geometry (chair legs slightly raised off ground)
- Total brushes: 624
+ structural: 622
+ detail: 0
+ portal: 2
- Number of zones: 2
- Number of surfaces: 4248
Highest Framerate: 115 fps
The map with 4248 surfaces/no detail brushes performed BETTER than the map with 3653 surfaces/detail brushes. (The extra surfaces come from the fact that I didn't separate the chair legs from the chair seat --- so there was some surface splitting going on.) So it seems one can conclude that the fewer detail brushes, the better!
11/01/2006 (8:36 am)
FYI...It is my assessment so far that using more detail brushes results in a slighly lower framerate, even with much fewer surfaces. Check out these results:
Method 1 - Detail Brushes (for chair legs)
- Total brushes: 624
+ structural: 442
+ detail: 180
+ portal: 2
- Number of zones: 2
- Number of surfaces: 3653
Highest Framerate: 110 fps
Method 2 - No-Touch Geometry (chair legs slightly raised off ground)
- Total brushes: 624
+ structural: 622
+ detail: 0
+ portal: 2
- Number of zones: 2
- Number of surfaces: 4248
Highest Framerate: 115 fps
The map with 4248 surfaces/no detail brushes performed BETTER than the map with 3653 surfaces/detail brushes. (The extra surfaces come from the fact that I didn't separate the chair legs from the chair seat --- so there was some surface splitting going on.) So it seems one can conclude that the fewer detail brushes, the better!
#3
Detail brusehs are technicaly for other uses.
11/01/2006 (9:42 am)
Best solution is to make them not touch.Detail brusehs are technicaly for other uses.
#4
Explain? His example sounds like exactly for what detail brushes are made.
I don't know why they would make for lower performance, though.
11/01/2006 (1:00 pm)
Allyn, Explain? His example sounds like exactly for what detail brushes are made.
I don't know why they would make for lower performance, though.
#5
11/01/2006 (1:56 pm)
I agree. What other purposes do you need a detail brush for? 
#6
11/01/2006 (3:53 pm)
I'm not exactly sure; but I believe detail brushes are not added into the BSP tree the same way as the split surfaces. If that's true, then the performance will not be as optimal. 
#7
I've had huge problems with my map due to not using detail brushes. Using TGE 1.4 with TLK it caused TGE to crash when lighting the mission and even in game at random times.
See This post.
Detailed Brushes will save your sanity.
DTS models are probably better. I've been forcing myself to learn 3DSmax due to the trauma I experienced trying to find and solve this problem!
11/01/2006 (5:26 pm)
A Cautionary Tale...I've had huge problems with my map due to not using detail brushes. Using TGE 1.4 with TLK it caused TGE to crash when lighting the mission and even in game at random times.
See This post.
Detailed Brushes will save your sanity.
DTS models are probably better. I've been forcing myself to learn 3DSmax due to the trauma I experienced trying to find and solve this problem!
#8
But I am still wondering --- say I have a room with 500 chairs (like an auditorium or something). Let's assume 2 legs per chair so that's 1,000 legs.
Is it better for performance to have 1,000 detail brushes, or raise the chair legs up off the floor by a hair?
11/03/2006 (10:01 am)
The link you posted, ChrisG, tells us that very narrow brushes should probably be made detail brushes. Thanks, that's useful to know.But I am still wondering --- say I have a room with 500 chairs (like an auditorium or something). Let's assume 2 legs per chair so that's 1,000 legs.
Is it better for performance to have 1,000 detail brushes, or raise the chair legs up off the floor by a hair?
#9
Technically, they are used for things that you don't really care about, such as rails, torch holders on walls, clocks on walls, bricks that poke out of walls ETC...
The difference of using a detail brush , our using a very small gap are large. The detail brush will still divide your geometry, such as a chair leg snapped to the floor, the exporter will split (most times) the surface of the floor on export, creating more splits. While the item is not calculated for visibility checks, it doesn't mean that the object, or the object it touches won't be split.
Using a gap however, includes in the visibility check, but will not split the surfaces its snapped to, because they don't touch.
My full recommendation is , since the object in question is a chair, set the chair to detail (so its not calculated in the visibility check, as it shouldn't ) AND have a very small gap between its legs and the floor, so it doesn't once again divide your floor, increasing polygon count.
So, two things. setting the chair objects (as a whole) to Detail will make them not used in the visibility check (+ performance) and using a small gap will not split surfaces it touches ( + performance).
Hope that helps.
Disclaimer: My explanation is from the days of the quake / doom and subsequent engines. This may not hold 100% true because the BSP implementation varies between engines, and the Torque system, specifically MapTOdif is an unknown standard. It unlimitedly depends on how the exporter decides to do things. I already know that it dosn't support Hint brushes (to my knowledge) so, it may not react as i suspect.
EDIT Italics = Incorrect. After further research about detail brushes it seems i was incorrect about them.
Assuming they are implemented basically the same as other engines, They don't split your geometry.
And another on the subject.
11/03/2006 (11:28 am)
Quote:Entity Description
A brush entity that does not retain any actual entity data after a compile, making it similar to a world brush. It is solid (unless materials specify otherwise) and blocks light just like a normal world brush. However, unlike a world brush, a func_detail does not block visibility. Therefore it does not contribute to visibility calculations and does not divide the BSP tree. Thus, they are ideal for optimizing "visual detail" brushes that do not significantly block the player's line-of-sight (like debris, fences, or even small buildings) and complicated brushwork (like stairs, columns and angled brushes).
Technically, they are used for things that you don't really care about, such as rails, torch holders on walls, clocks on walls, bricks that poke out of walls ETC...
The difference of using a detail brush , our using a very small gap are large. The detail brush will still divide your geometry, such as a chair leg snapped to the floor, the exporter will split (most times) the surface of the floor on export, creating more splits. While the item is not calculated for visibility checks, it doesn't mean that the object, or the object it touches won't be split.
Using a gap however, includes in the visibility check, but will not split the surfaces its snapped to, because they don't touch.
My full recommendation is , since the object in question is a chair, set the chair to detail (so its not calculated in the visibility check, as it shouldn't ) AND have a very small gap between its legs and the floor, so it doesn't once again divide your floor, increasing polygon count.
So, two things. setting the chair objects (as a whole) to Detail will make them not used in the visibility check (+ performance) and using a small gap will not split surfaces it touches ( + performance).
Hope that helps.
Disclaimer: My explanation is from the days of the quake / doom and subsequent engines. This may not hold 100% true because the BSP implementation varies between engines, and the Torque system, specifically MapTOdif is an unknown standard. It unlimitedly depends on how the exporter decides to do things. I already know that it dosn't support Hint brushes (to my knowledge) so, it may not react as i suspect.
EDIT Italics = Incorrect. After further research about detail brushes it seems i was incorrect about them.
Assuming they are implemented basically the same as other engines, They don't split your geometry.
And another on the subject.
#10
That's interesting because my observations using the setInteriorRenderMode command (not sure of spelling of the actual command) show that the detail brushes do not divide the geometry, which is why I used them in the first place.
I'm not quite sure what you mean by that. The detail brush is rendered if the zone it is in is rendered. Are you saying it will still render if the zone isn't rendered? I don't think that's the case.
My guess would be that there is additional overhead for using any detail brushes. And, in this case, using them just for the chairs might not be enough to compensate for it, or the chairs might be too complex to be used efficiently as detail brushes.
It's also possible that the different versions of Map2Dif could affect the results.
In any case I think the only rule is, "Your milage may vary."
FYI for anyone who doesn't know about it, check out this link for how to use setInteriorRenderMode.
11/03/2006 (12:41 pm)
Quote:The difference of using a detail brush , our using a very small gap are large. The detail brush will still divide your geometry, such as a chair leg snapped to the floor, the exporter will split (most times) the surface of the floor on export, creating more splits.
That's interesting because my observations using the setInteriorRenderMode command (not sure of spelling of the actual command) show that the detail brushes do not divide the geometry, which is why I used them in the first place.
Quote:While the item is not calculated for visibility checks, it doesn't mean that the object, or the object it touches won't be split.
I'm not quite sure what you mean by that. The detail brush is rendered if the zone it is in is rendered. Are you saying it will still render if the zone isn't rendered? I don't think that's the case.
My guess would be that there is additional overhead for using any detail brushes. And, in this case, using them just for the chairs might not be enough to compensate for it, or the chairs might be too complex to be used efficiently as detail brushes.
It's also possible that the different versions of Map2Dif could affect the results.
In any case I think the only rule is, "Your milage may vary."
FYI for anyone who doesn't know about it, check out this link for how to use setInteriorRenderMode.
#11
1. Detail brushed do not split the other brushes it touches. Normal world brushes will.
2. Detail brushes do not add to the visibility checks.
3. Detail brushes do not block rendering, and can not be used for zone making.
Chairs should most likely, in the numbers you talk about, should be DTS objects.
11/03/2006 (12:47 pm)
No. Read my last statement and the articles i posted.1. Detail brushed do not split the other brushes it touches. Normal world brushes will.
2. Detail brushes do not add to the visibility checks.
3. Detail brushes do not block rendering, and can not be used for zone making.
Chairs should most likely, in the numbers you talk about, should be DTS objects.
#12
Sorry. Missed the Edit.
My main points were that you can observe splitting using setInteriorRenderMode and that I have no idea what Torque supports in terms of visibility other than zones.
@Scott
Personally, I too would use a DTS for a chair. For large numbers of chairs, I would think you would need some sort of batch renderer like in TGEA or a large DTS or a custom batch renderer for TGE.
11/03/2006 (1:25 pm)
@Allyn Sorry. Missed the Edit.
My main points were that you can observe splitting using setInteriorRenderMode and that I have no idea what Torque supports in terms of visibility other than zones.
@Scott
Personally, I too would use a DTS for a chair. For large numbers of chairs, I would think you would need some sort of batch renderer like in TGEA or a large DTS or a custom batch renderer for TGE.
#13
Why would you need that stuff for a DTS?
Just make one, with LOD, and Mipmaped textures.... and place them in the DIF, using the torque editor?
But then again, if 1000's is the number you need, you may wish to rethink your design, depending on the complexity of your chairs + Avatars + interior + distance you wish to be able to view, im not sure with out serious optimization, and very carefully created art assets, that any engine would be able to support your needs.
what are you doing?
11/03/2006 (2:05 pm)
The visibility check i'm refering to is done on map compilation, AKA exporting using maptodif. Its also the point at witch the exporter decides to split things, based on visibility checks.Why would you need that stuff for a DTS?
Just make one, with LOD, and Mipmaped textures.... and place them in the DIF, using the torque editor?
But then again, if 1000's is the number you need, you may wish to rethink your design, depending on the complexity of your chairs + Avatars + interior + distance you wish to be able to view, im not sure with out serious optimization, and very carefully created art assets, that any engine would be able to support your needs.
what are you doing?
#14
11/03/2006 (2:23 pm)
I'm pretty sure detail brushes do not split.
#15
There are two reasons I can think of not to go with DTS for this scenario:
1) I won't get the same quality of lighting/shadows (using TLK).
2) Even if I tried to to get good lighting, that would require some pretty accurate collision meshes for the chairs. Not to mention, I have noticed that when you enable "DTS Objects" for a light with TLK, it lights DTS models dynamically EVEN IF the light is static. I imagine these things hurt performance.
Honestly I can't imagine using DTS for any of the furniture in a room if you want good lighting/shadows. Take the TSE Car Demo, for example. The lighting in that scene is among the most spectacular I've seen with the Torque engine. If you examine the scene you will see that nearly all the objects in the room (crates, barrels, crane, pipes, cables) are all part of the DIF.
11/04/2006 (12:07 am)
Actually I have an auditorium space with about 400 chairs (800 chair legs) and it runs pretty decent. Grant it, the chairs aren't very complex.There are two reasons I can think of not to go with DTS for this scenario:
1) I won't get the same quality of lighting/shadows (using TLK).
2) Even if I tried to to get good lighting, that would require some pretty accurate collision meshes for the chairs. Not to mention, I have noticed that when you enable "DTS Objects" for a light with TLK, it lights DTS models dynamically EVEN IF the light is static. I imagine these things hurt performance.
Honestly I can't imagine using DTS for any of the furniture in a room if you want good lighting/shadows. Take the TSE Car Demo, for example. The lighting in that scene is among the most spectacular I've seen with the Torque engine. If you examine the scene you will see that nearly all the objects in the room (crates, barrels, crane, pipes, cables) are all part of the DIF.
Torque 3D Owner Eric Forhan