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?

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".

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.

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.

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.