Jump to content
  • Advertisement
Sign in to follow this  
Kyall

Devil in the details (Occlusion Test/Culling)

This topic is 2610 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

Occlusion testing is querying the GPU by rendering a simple shape representing an object (with color write channels and depth writing disabled) to get an estimate on whether the object is hidden behind an occluding object.

My questions are:

- Is there really much of a performance difference with modern GPUs in rendering 12 vs 100 tris. If it's super fast for a GPU to render anything less than a few hundred polygons I could use geometry instead of just a box for the occlusion querying, which would return less false positives.

- Same as above but with mobile platforms, my guess is that the iPhone isn't exactly powerful enough to do any occlusion testing except with a bounding box.

- Is the performance hit of using blocky, rigid skinned shapes that follow the animated bones to represent the components of a characters body to query the occlusion too expensive to justify anything other than just testing by bounding box ?

- I've read up a fair bit on occlusion querying, with different objects, and what I can think of right now is that I'll have to cut terrain maps up and box the segments for occlusion culling, either automatically or manually, is there a good algorithm I should know about when it comes to occluding terrain elements that are behind other terrain elements that doesn't require slicing the map up?

Share this post


Link to post
Share on other sites
Advertisement
If you can use the query shape for an entire house, neighbourhood or city behind a mountain, you would gain a lot on it.
Single items should have distance adaptive detail level so that the number of triangles at an average distance is the same as a query shape.

Share this post


Link to post
Share on other sites
- Is there really much of a performance difference with modern GPUs in rendering 12 vs 100 tris. If it's super fast for a GPU to render anything less than a few hundred polygons I could use geometry instead of just a box for the occlusion querying, which would return less false positives.
GPUs tend to have a "minimum triangle count" in practice, due to them being heavily pipelined. At some point you'll find that rendering [font="Courier New"]n-1[/font] triangles is the same speed as rendering [font="Courier New"]n[/font] triangles. Same goes for rendering pixels -- it may be that drawing 100 pixels takes just as long as drawing 400, due to pipeline bubbles. This of course varies greatly from GPU to GPU, and is also affected by the complexity of the shaders in use.
Occlusion testing is querying the GPU by rendering a simple shape representing an object[/quote]To be a pedant, GPU occlusion queries are one possible tool that you can use to implement the general idea of occlusion testing. They're not always the best tool, and are a fairly brute force solution to the problem.
I'll have to cut terrain maps up and box the segments for occlusion culling, either automatically or manually, is there a good algorithm I should know about when it comes to occluding terrain elements that are behind other terrain elements that doesn't require slicing the map up?[/quote]Regarding automation, Nick Darnell has some good research on automatic generation of occlusion meshes on his blog.

In games where the world is static (i.e. you're not blowing up mountains), a common solution is to instead use some kind of precomputed visibility technique, often resulting in a PVS. These precomputed techniques often make use of automatic slicing algorithms, such as BSP.

Share this post


Link to post
Share on other sites
[color="#a0522d"]@dawoodoz[color="#a0522d"]: Thanks dude

[color="#a0522d"]@hodgman: Thanks for the tip on PVS, I'm currently working on embedding an octree into my level format because of your tip. I know it's not a PVS, but I think a PVS might be more than I can handle. I'm gonna go with aabb to the octree, but the octree doesn't have to be axis aligned, only it's nodes to it, and I'll just transform the camera/frustum into the local space of the octree, gives artists some freedom without compromising speed, also going to do the octree bounding boxes as one long data array where each node has the number of child nodes (grandchildren, etc. included in the count) so that I just iterate over it, and if I get an excluded object, iterator += childCount

As for more occlusion stuff, would using the same octree to exclude children that have an excluded parent be more expensive than just testing the occlusion of the child elements, because of the pixel draw cost?
And considering the draw cost should I set the octree occlusion up to be a factor of estimated screen space of a node, say 200 pixels?
Obviously if a leaf was previously visible I'll just be querying it's actual render. The problem I see with that though is that if I have 8 levels under a visible node, and each frame I'm only testing the occlusion tree one depth lower, it's going to take 8 frames for the leaves to show up. To prevent that I would have to occlude test all the way down to the leaves, or just render the leaves as normal (query at the same time) when the (-8 levels) node becomes visible until I have better information about what children are visible so I can decide to exclude them or not.
All of this leads to rendering more geometry than brute force occlusion testing where a parent node is visible, even if the leaves aren't, but the benefit of only rendering 12 triangles for the entire tree under an occluded node.

The solution is obviously what hodgman said with the PVS system, but I fear that may be more than I can handle, in any case where a PVS system is different from a spherical geometric constraint that contains non occluded nodes to render within arcs to deal with the direction being faced as the data read from the disk, and where the camera's dynamic sphere is generated using a combination of the surrounding nearest spheres.

EDIT: I'm gonna leave all that nonsense I wrote in there so as not to double post but I thought about reversing my idea and I think the reverse would be a good PVS system, where each object has a simple spherical map, where each of the points of the sphere makes up an arc value that has a distance to the camera under which the object is definitely visible, and then I can do the PVS from the node to the camera location. It won't occlude 100% of cases, but it should work pretty well, and using something between a sphere and a cube shape as the data storage for the distances, and storing those points as a tree, should work pretty well.

I'll use voxels and ray tests in the intermediate application that builds the visible probability set, AND I can put a V.P.S (visible probability sphere) along the octree so that I can get occlusion probability on a branch by branch basis. Only when I get down to the leaves that are definitely visible, or too likely to be visible to ignore, do I need to do an occlusion query.

Also don't have to worry about the distance calculation for the node-camera either, since I have to do that when I z-sort the elements for rendering anyways, I'll just keep a view-depth variable handy

Anyone got any advice on that (from edit onwards) ?

Also, double thanks Hodgman

EDIT2: Scratch that, it only works in orthographic view and with spheres.... But I think PVS from the node to be rendered is some how the way to go just 'cause it allows me to put the occlusion into a nice tree structure.... Just have to figure out how to do it without using too much data, and having it work, was thinking about the sphere thing but using quantum field theory to generate a probability of the behind object being visible, but that's still only half a solution.... Needs moar work. I'll post if I come up with something worth while.

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!