Jump to content
  • Advertisement
Sign in to follow this  
meeshoo

Occlusion Culling - What algorithm to use?

This topic is 4872 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I've read some topics about this and now I'm confused. I saw that Dx9 has some queries for determining occlusions, but there are other techniques like cell-occlusion, octree occlusion, HOM (hierarchical occlusion maps) and so on. Which one is the best?

Share this post


Link to post
Share on other sites
Advertisement
This really depends on your needs for your project. You need to determine your requirements, and select the appropriate one. None of them is the "best".

Share this post


Link to post
Share on other sites
well, based on my requirements, since I don't have an octree scene representation and I don't have cell-portal base scenes, I can apply only two of them. The Queries and the HOM. From a tutorial here on GD I've seen that is a 3-pass rendering by using Direct3d queries and 2-pass rendering for HOM. However, HOM requires a lot of processing done by CPU. So I can't really tell which will be better and I can't afford the time to implement both and see which one is better.

Share this post


Link to post
Share on other sites
Hardware Occlusion Queries are asynchronous so may not return for a few frames.

HOM is effectively performed on a per-pixel level automatically by most modern Z buffer hardware (Hierarchical-Z etc).

Software HOM on a per-pixel or per-polygon basis is better suited to software rasterizers.


There is no better, and which type of higher level culling (not just HOM and occlusion queries) is "more appropriate" really does depend on a)what granularity of things you're trying to cull (sections of the world, whole models, groups of polygons, individual polygons, individual pixels), b)what you know about your world (indoor, outdoor, mixture, individual models, large scale, high polygon, low polygon, deformable, static), and c) what you know about how your scene changes over time (fast moving camera, static camera, fast moving objects, static objects, etc).

General rule of thumb though is to cull at the highest level possible to get the most bang-per-buck (e.g. cells/portals/antiportals, or octrees/BSPtrees etc).
The knowledge about your particular application should help direct your choices for lower level culling - for example with lots of fast moving things, a hardware occlusion query that takes a few frames to return might not be suitable unless you start accounting for object and camera velocities; camera cuts could screw hardware occlusion queries up even more.

Share this post


Link to post
Share on other sites
Quote:
Original post by S1CA
General rule of thumb though is to cull at the highest level possible to get the most bang-per-buck (e.g. cells/portals/antiportals, or octrees/BSPtrees etc).
The knowledge about your particular application should help direct your choices for lower level culling - for example with lots of fast moving things, a hardware occlusion query that takes a few frames to return might not be suitable unless you start accounting for object and camera velocities; camera cuts could screw hardware occlusion queries up even more.

Yea, I really don't recommend using occlusion queries for culling at all. After experimenting for a long time with them, their asynchornous nature was just too much to overcome. However, if you are really bent on using them, you can try the following optimizations:

(1) Combine with another scenegraph mechanism, like octrees or PVS. However, if you already have an octree or PVS in place, why not just rely soley on that? They are fast and produce an acceptable amount of overdraw, generally.

(2) Use an array of IDirect3DQuery9's. First, draw the bounding meshes of all the objects, and use a separate query for each. After all objects are drawn, go back and query the data. At this point, it should be ready, and you don't have to waste any CPU cycles in the while loop.

(3) Batch render all of the bounding meshes for the preliminary render. This will save many DrawIndexedPrimitive (DIP) calls.

(4) Use occlusion culling in an offline method, coupled with PVS. The occlusion tool will take the world, render all possible viewpoints, and export the PVS data. The engine will then load the PVS data, and use it accordingly. This is nice, because it's very accurate (you won't experience overdraw/underdraw), and it replaces some complicated offline algorithms. It should also be very flexible for both indoor and outdoor environments. However, this is a little complicated to implement in an article.

(5) Only test the objects that are above a certain triangle count. This is to make sure that actually rendering the full object is not faster than doing all of the occlusion stuff.

(6) Perform some kind of camera prediction, or enlarge your camera frustum, to avoid popping.

All in all, I think it's much easier (and faster) to just use other methods.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!