Func_wall & Func_occulder clarification tutorial

[Voldro]

I decided to make this tutorial real quick to show the difference between the two and to clear things up. it is only 3 minutes long so won't waste too much of your guys's time lol.

http://martin.nsarmslab.com/clarification.rar

 

[SAJ]

Thanks for doing this, its very to the point and no-nonsense approach is very useful for demystifying hammer issues.
Having said that , two things strike me: firstly , its "occluder" not "occulder" as you were pronouncing it.
Secondly your technique of speaking "live" rather than from a pre-prepared script seems to cause you to break your sentances up in a hard to follow manner(in places).
Sorry to be a pain , but I only point this out because I think a series of these tuts would make invaluable reference material.

 

[RoyalEF]

The tut is fine, however I still would like to see better real world examples of appropriate use. I'm compiling right now so I can't play at the moment, but I would like to have see a regular old brush wall next to your three examples.

I guess I'm wondering why (and where) use a func_wall instead of a wall. I know all the old HL1 reasons. But it is the newer block brushes aspect that I'm curious about. I'm thinking a func wall acts like an "anti-window"? Meaning, where a normal wall might prevent brushes from being drawn(depending upon vis calculations fr the leaf), if the brush is within the "window" of a func_wall's shape it is hidden. I'm wondering if placing a func wall/occluder inside existing walls with windows would be good to prevent windows from showing too much of what is inside a building.

Occluder confuses me because the models pop in an out of existence and I'm wondering how that can be used with models popping out of thin air (as they do when you are moving about in the tut.

 

[sabre0001]

color messed up on my system but thanks for it - should help me in some way...

 

[RoyalEF]

Okay I had time to play with this and there is some confusion here.

Func_Wall was never an optimization and unless there is a Valve statement somewhere it was not meant to be. If Valve thinks it is then they have a serios performance bug.

I've attached the RMF I used to test this. I included triggers with messages but they don't work-maybe that isn't supported anymore.

Anyway, I constructed 7 open boxes. Put models and cylinders in each and then "closed" the open end with different things to test the frame rate effect for each item.I walked up to the closing brush and recorded fps (net_graph 3)

from LEFT to RIGHT with frame rates (higher is better)

OCCLUDER+FUNC_WALL - 200 (worst)
OCCLUDER - 280
FUNC_BRUSH - 220 (2nd worst)
FUNC_WALL - 220 (2nd worst)
FUNC_DETAIL - 270
WORLD BRUSH - 290 (best)
Open (no Brush) - 270s to 280s


Using a World Brush allows VIS to completley remove the items from the engine and you get the best possible frmae rates.

Func_Detail performs almost as good as being open, so it is close to having no rendering overhead (a good thing). Func_Detail optimization should benefit maps.

Occluder improves speed, better than open. The impact of not having to draw the models is clear. Funny though, the shadows of the radiators show even when the model doesn't.

FUNC_WALL & FUNC_BRUSH appear to be identical. They both worsen performance considerably, losing 50fps (18% of speed). These brushes were designed to take advantage of dynamic code, allowing interaction, visuals and motion. They are costly and create a load that clearly impacts speed--and always did. The fact that wireframe modes makes it look like it is not drawing objects is a technical misconception. Entities are probably overlaid on top of the rendered POV. SO entities will tend to sit on top of everything, hiding them, when in fact they are writing on top of the fully rendered world.

Occluders probably act as a filter for the queue of dynamic models. It just decides which models to skip. The entire static world is fully rendered before the engine gets to doing models.

End Result: Don't use FUNC_WALLs to "block" things. They don't and you take a hit over them being a regular wall. Use them only when you need the dynamic nature of rendering, movement or interaction.

However, Occluders are your friends--if you can figure out how to palce them.

Voldro, always good to see people contributing tutorials but what you're seeing in wireframe is not an optimization. There are other optimization entities out there I haven't figured out water_lod_control, func_lod, and isn't there the LOD fog somewhere or is that another game? Also I'm thinking occluders should be embedded in walls in tricky VIS spots. COmplex architecture sometimes bleeds big areas. Occluder could cut down the impact of VIS bleeding that can't be prevented otherwise.

 

[Limpet]

My results on a machine with p4 2.4Ghz and a Geforce4 420 mx w/ 64 mb (need a new card )

OCCLUDER+FUNC_WALL - 63
OCCLUDER - 90
FUNC_BRUSH - 66
FUNC_WALL - 60
FUNC_DETAIL - 47
WORLD BRUSH - 120
Open (no Brush) - 76

Looks like they tend to agree with RoyalEF

 

[RoyalEF]

FUNC_DETAIL - 47

Is that right or a typo? I know your FPS can vary dpeending upon your position in the box. I got a few odd readings, but used the most consistent numbers. Maybe if the boxes were deeper, narrower tunnels the numbers would get more consistent. Or it could have been a blip from outside HalfLife entirely.

 

[Limpet]

I went back to make sure and got pretty much the same results.
This time I'll list the ranges that I saw (or did my best to see)

OCCLUDER+FUNC_WALL - 76-77
OCCLUDER - 110-130 (weird)
FUNC_BRUSH - 47-49
FUNC_WALL - 59-62
FUNC_DETAIL - 66-68
WORLD BRUSH - 79-88
Open (no Brush) - 60-63

I had out the pistol and was doing my best to look forward as parallel to the ground as possible.

 

[Voldro]

Also depends on your system, also how you are using it. I use this when I have alot of things I need to block and alot of reflective surfaces like water and so on an so forth