PDA

View Full Version : who's using occlusion testing



zed
10-23-2008, 05:08 PM
Just a straw poll on whos using it, to try and improve performance,
Ive been for years, but are now thinking of dropping it.

during usage
A/ performance is improved in the average + best case senerios
B/ performance is worse in the worse case senerio

the reason being is
Now ultimately WRT framerate, average+maximum are no where as near as important as the minimum framerate.
Is my reasoning sound?

Jan
10-23-2008, 05:59 PM
I do. In the scenario i use it for (a city scene) it decreases performance when one looks over the whole city. This i can detect easily (camera outside the octree) and disable it.

When one walks through the streets, occlusion culling gives a speed-increase of up to 30%.

In our case i think OC does make sense.

Either one is looking over the entire city, then we have high polygon count, but we can disable many shader effects, reduce LOD, etc. to get good performance (and disable OC too).

Or one is in the streets, close to buildings, here we can use OC to reduce the number of polygons considerably and thus use the processing power to enable quite expensive effects (especially conemap parallax mapping).

So, we don't use it as THE optimization to get good performance, but rather as A optimization for a special case.

Note that we do not have any kind of sectors/portals, so we can only cull geometry by the whole view-frustum, not by a restricted subset, which is possible in many other scenarios.

Jan.

LangFox
10-24-2008, 02:18 AM
Will Early-Z do the same function of OC? I heared that for pixels the depth test is done before the fragment process. If so, we can use simpler vertex and fragment shader to do depth rending first.

Jackis
10-24-2008, 02:38 AM
Recently we decided to stop using OC because of moving to deferred shading. But before it, in our multipass forward renderer, it was quite comfortable to use OQ result just from drawing actual geometry in first passes. Our use cases are planar terrain views, so OC are made for trees, plants and so on. Average gain was about 10-15%, sometimes getting to 35%-40%. Worst case was looking from the top, just as expected, and as Jan said, it's very easy to test for this case and disable OC tests.

LangFox,
Sometimes it's easier to draw simple bounds with much less vertices, and use it as OC colume. You remark is right, yes, but for EarlyZ you need to pass actual geometry and so on, and you said about 2 passes: laying down depth first, then draw with full shading. It has a big disadvantage of throughputting all the geometry twice. And if you are vertex-limited, that is not an option (as for me).

Jan
10-24-2008, 05:49 AM
We also do a z-only pass for geometry in the first 50 meters (because only those pixels get the high quality shading). Surprisingly it is very very rare, that this increases speed, only when we are standing in a section of the world, where our rendering is completely back-to-front (due to how our octree works), it prevents a noticable speed decreas.

Jan.

Keith Z. Leonard
10-24-2008, 11:00 AM
It is certainly a matter of the environments in your game/3d app. If you are making a game with a good amount of indoor areas, OC is pretty important to get highly detailed areas. It's obviously going to do less in terrain games, as there is less opportunity for things to be occluded.

LangFox, OC is not equivalent to early Z. In early Z, you have to issue the draw calls for those objects that are not seen, and you have to execute the vertex program for those verts, and the fragments have to be setup. With OC you know ahead of time that you don't even want to render the occluded objects.

Ysaneya
10-24-2008, 04:22 PM
I'm working with geometry-crowded environments with simple shaders, and as expected OC does wonders. It often gives a performance boost of x3-x4. I'd definitely wouldn't like to see it being dropped.

In addition, there is AFAIK no mechanism to perform fences that work on ATI cards; on those cards I'm emulating that feature by creating an empty query. If OC was dropped I'd have no fallback solution.

Y.

zed
10-24-2008, 10:46 PM
So quite a few ppl are,
The problem with occlusion testing (to get correct results) is u need to do the following

A/ lay down depth pass (from front to back)
B/ lay down another depth pass with occlusion testing
C/ read occlusion results
D/ draw the shaded visable meshes

(u could also combine B+D though its a tossup whether or not this is faster)

without occlusion testing u can start straight away with D

sure it depends on the scene, eg the city or indoor scenes are ideal candidates for occlusion but
At the moment im doing a scene like Jackis's (on a terrain), I think Ill give it a go without + see what happens

Brolingstanz
10-25-2008, 06:01 AM
It'd be tough to leverage predication for your typical terrain (relatively flat, camera free to move anywhere), just not enough constraints. But if you had towering canyon walls or sprawling underground chasms and caves, well then you'd have an outdoor dungeon of sorts...

Keith Z. Leonard
10-27-2008, 08:27 AM
What you really meant to ask would be "is anyone using occlusion query". There are many occlusion culling algorithms that are not based on Occlusion query.

Also, there are more efficient ways of doing the query than what you have stated. You can create a hierarchy for your scene and query large chunks of the scene as you are laying down the depth pass, just don't resolve your queries until end of frame, and use those results for the next frame of rendering.

Jackis
10-27-2008, 11:18 AM
And one more thing to mention - there is also such a good feature as conditional rendering.

zed
10-28-2008, 06:32 PM
Also, there are more efficient ways of doing the query than what you have stated.
yes there are faster methods, but they will give inaccurate results, ie things will be reported as visible when they are not + (if u use the previous frames depth) reported as invisible when they are (which is worse)

conditional_renderer looks good but no go on my nv4x