A downside to using more detail brushes?

Kritanu

L1: Registered
Jun 26, 2008
4
0
I've been learning everything I can about mapping, and I've noticed something. When I make a basic layout, just floors and walls and such, I notice in the game that the wireframe shows everything splitting into a ton of extra polygons.

I went through and made most everything into detail brushes, with nodraw on the unseen surfaces, and nodraw world brushes just behind them. In game, there appears to be much less polygons made. The only visible world brushes I make now are the ones I need for good vis leafs.

However I notice in a lot of other maps, this isn't done. Is there a reason I don't know about why detail brushes aren't used more?
 

Spike

L10: Glamorous Member
Feb 13, 2008
716
82
You should read some optimization tutorials. Search on google or in the tf2maps section. Thay'll help you a lot.
 

Kritanu

L1: Registered
Jun 26, 2008
4
0
Yeah, I have - I've been reading a lot of stuff for the last couple days. Posting here is a bit of a last resort for me.

I know detail brushes are normally used for geometry that "sits on top" of your world brushes, especially angled stuff, but not normally the floors and walls themselves.

Turning the walls and floors into detail brushes seems to cut down on polygons a lot and I can't find anything anywhere saying why this is a bad idea.

I put nodraw world brushes behind the details to keep from leaking and keep the vis good, kind of like what you might do with displacements.

I'm just worried I might be doing something horrible to my map, but it's making the map run a lot smoother on my weenie computer and I don't see anything bad happening off the bat.
 
Last edited:

teddyruxpin

Sr. Hygiene Technician
Mar 24, 2008
83
26
The main thing you will see when you use a func_detail for a wall or floor is the light bleeding around the edges. This is a known side effect of a using these brush types and is mentioned in some of the tuturials. You can test this yourself by making a box and then making it hollow and a detail brush clip inside of it with no clip and you will see some light bleeding in around the edges or the colors of that brush getting a bit distorted as if they had more light on them then other areas.

On some maps this is a non issue and will be quickly overlooked on others where you have fancy lighting it can stand out like a sore thumb. That and the game engine will also assume you can see through the wall and render everything behind hit which will kill your ingame FPS.

-Teddy
 
Last edited:

Nineaxis

Quack Doctor
aa
May 19, 2008
1,767
2,820
Why most maps have lots of visportals? Most people are stupid and don't optimize their maps. That's the simple answer.

If I'm reading this right, you're turning your world geometry into func_details? Probably don't want to do that. It'd the same thing if you turn them into details and put nodraw behind them as if you didn't func_detail.

Read:
http://developer.valvesoftware.com/wiki/Visleafs
http://developer.valvesoftware.com/wiki/Hint_brush
http://developer.valvesoftware.com/wiki/Areaportal

They'll help you understand how Visibility/Vvis works and what you should be doing.
 

Kritanu

L1: Registered
Jun 26, 2008
4
0
Aah, the lighting thing I didn't know about. The cut down on polys still seems to be worth it though, I don't see any very bad bleeding.. I do see some though, I didn't know why that was happening.

And yeah, I feel like I've got my visibility set up clean, I'm happy with that stuff. Nothing is a detail brush that needs to be blocking visibility.
 

Sgt Frag

L14: Epic Member
May 20, 2008
1,443
710
Really no reason to double the work there.

Hammer doesn't have a hard time with polys. That's not the major concern, the concern is that you don't have a million vis_leafs. That's why all small details should be func_details. Not to save polys but to save vis_leafs.

If you hide all details(basically everything except worldspawn brushes) your map should look pretty simple anyway. It would basically be an interconnecting series of cubes. So making them func_details and placing cubes behind them for vis doesn't make much sense really.

If your world spawn is creating too many polys then it is to complex and you need to make more func_details.

Also, your vis_leafs will be smaller if using the world spawn than if you use brushes around worldspawn. So they will block more vis_leafs sooner.
 

Tigger

L2: Junior Member
Mar 29, 2008
72
8
One thing you should know about func_detail is the engine can decide to not render them on low framerate systems. Essential items like walls, general roof pieces, things people can hide behind, surfaces to walk on, etc probably should not be func_detail for that reason.

Another thing about func_detail is it doesn't cast shadows properly. So brushes you want to block light, create shadow pools, shouldn't be func_detail.

Anything that isn't essential to the gameplay? Sure, func_detail it. But if you want to make sure something is rendered from a distance don't put it in a func_detail.
 

Spacemonkeynz

L5: Dapper Member
Jan 31, 2008
234
52
One thing you should know about func_detail is the engine can decide to not render them on low framerate systems. Essential items like walls, general roof pieces, things people can hide behind, surfaces to walk on, etc probably should not be func_detail for that reason.

Another thing about func_detail is it doesn't cast shadows properly. So brushes you want to block light, create shadow pools, shouldn't be func_detail.

Anything that isn't essential to the gameplay? Sure, func_detail it. But if you want to make sure something is rendered from a distance don't put it in a func_detail.

Are you sure?

There are setting in the func_detail which set it to when it will be enabled, it default to max and min dx levels, so it should show all the time.

You have to func_detail stuff which is essential to the gameplay. Otherwise you get too many visportals. Entire buildings in valve maps, things all cover, bridges are all func_detail, and they are right in the middle of the gameplay.
 

Bonafide

L6: Sharp Member
Mar 18, 2008
313
25
there is no point making a floor a func_detail just to then put a nodraw brush behind it to block a possible leak. Its just increasing the work load
 

shpladoink

L3: Member
Dec 19, 2007
108
6
I was wondering about this when I noticed the wooden ceiling beams in the decompiled 2fort were not func_detail brushes. Actually, a lot of the small brushes in that map that I assumed would be ideal candidates for func_detail are just regular brushes. I suppose the only reason for this would be the light bleed that was mentioned.
 

grazr

Old Man Mutant Ninja Turtle
aa
Mar 4, 2008
5,441
3,814
Another thing about func_detail is it doesn't cast shadows properly. So brushes you want to block light, create shadow pools, shouldn't be func_detail.

Anything that isn't essential to the gameplay? Sure, func_detail it. But if you want to make sure something is rendered from a distance don't put it in a func_detail.

func_details don't have a fade out option, they will be rendered as long as your system believes it can see it. If you're having shadow problems you should probably decrease your lightmap scale on the underlying brush face. I've not had any issues regarding func_details and dodgy shadows. The fact that you are having shadow problems with func_details is probably just a coincidence, because your func_details are also small geometry, which react badly to faces with large lightmaps.
 

Tigger

L2: Junior Member
Mar 29, 2008
72
8
I don't believe the map designer has the option of fade out for func_details. If the engine's frame rate is low, it will start to cull out optional geometry. By specifying something as func_detail, you are telling the engine this is optional geometry.
 

YM

LVL100 YM
aa
Dec 5, 2007
7,135
6,056
There are a whole load of func_lod brushes in goldrush (most noticably the horizontal beams holding the large uprights on the wooden walls together) they aren't treated like normal brushes by vis and then fade out and stop being rendered after the distance you tell them to.
You can even tell them to be solid or not.

Really handy, I might have to turn some of my func_details from hoodoo into these.
 

Spacemonkeynz

L5: Dapper Member
Jan 31, 2008
234
52
I don't believe the map designer has the option of fade out for func_details. If the engine's frame rate is low, it will start to cull out optional geometry. By specifying something as func_detail, you are telling the engine this is optional geometry.

I doubt it, Looking at TC_hydro with 'func_detail's disabled, it doesn't look much like hydro anymore.

If it were possible to have func_detail not render on low end systems, they would be many cases where brushes which would normally hide players, would not render. Which means the lower end users would be able to see other players when they should not be.

That's simply not the case.


func_detail was two fields called 'mindxlevel' and 'maxdxlevel', which default to 'lowest' and 'highest'.

Changing these values, for example, increasing the 'mindxlevel' would cause the 'func_detail' to not render on lower end systems, so in that case it is optional geometry, and would be useful for something that won't affect the players view.

However leaving the dxlevels at their default will ensure that the func_detail will always render.
 

Tigger

L2: Junior Member
Mar 29, 2008
72
8
If it were possible to have func_detail not render on low end systems, they would be many cases where brushes which would normally hide players, would not render. Which means the lower end users would be able to see other players when they should not be.

That's simply not the case.


Quote from the Valve Wiki: Note: In some cases, surfaces on very thin (about 2 units thick) func_details has been known to disappear at certain distances. A workaround for this is to make the entity a func_brush instead. It is advised to instead use a larger brush or world brush rather than a func_brush, which is networked.

So I stand corrected about the disappearing. The way you control it is by making the func_detail large enough.