Software Occlusion Culling & Performance

[al2950]

I was looking at the possibility of adding software occlusion culling to Ogre 2.x, as a result I started looking at Intel's example of SOC found here;
http://software.intel.com/en-us/blogs/2 ... g-update-2

This then led me to the posts by Fabian Giesen on optimising this code. His blogs have been mentioned before in the Ogre forums but I would really recommend anyone interested in optimisations/performance to give his whole set of blog posts on this topic a read;
http://fgiesen.wordpress.com/2013/02/17 ... ing-index/

[drwbns]

Yeah, great example with articles. I read them all a few months back while looking into modern culling techniques. I think with Ogre 2.0, culling is supposed to be much better.

[al2950]

Yeah, great example with articles. I read them all a few months back while looking into modern culling techniques. I think with Ogre 2.0, culling is supposed to be much better.

Yes Frustum culling is much MUCH faster in 2.x, but it does not address occlusion culling which is needed for high detail city type environments, at least not yet

[scrawl]

Sounds interesting.
This would be a new scene manager, correct?

[al2950]

Sounds interesting.
This would be a new scene manager, correct?

Actually no. I would see it being an option culling method that can be optionally used. It would occur directly after frustrum culling. Integrating it would not be too much of a problem as far as I have looked. Although there is one fairly major issue (in terms of the Ogre pipeline), and that is firstly you need to mark what the occluders are and secondly you would normally get artists to create low poly occluders, I dont like this and I know it can be done automatically as Umbra have done it. It just a case of having a LOD system that will guarantee a conservative model. I dont know if the progressive mesh work by sajty could help.

[scrawl]

I'm not sure I like the idea then. Occlusion culling only makes sense in specific scenes, and as you said, it comes with a setup cost (occluder meshes), so only a fraction of users will actually use it, and it should be better off as a plugin / new scene manager then.

[al2950]

I'm not sure I like the idea then. Occlusion culling only makes sense in specific scenes, and as you said, it comes with a setup cost (occluder meshes), so only a fraction of users will actually use it, and it should be better off as a plugin / new scene manager then.

Fair enough, I am sure there is a way to make it modular

[AgentC]

For most efficiency the occlusion culling needs to be tied into the (hierarchical) frustum culling. If for example you're using an octree, you could be discarding entire octant hierarchies if their bounding box fails the test against the rasterized occluders. This would mean making two frustum queries, first collecting only the occluders, rasterizing them, then performing another frustum query with the help of the occlusion data. It may sound inefficient but in practice the octree traversal is the faster part and the actual occlusion tests the slower part.

Naturally such two-part setup does not spell good for modularity.

The gain achieved ultimately depends on how less efficient it would be to just to stuff all objects in the frustum to the GPU. With Ogre's current rendersystem implementation the overhead per draw call is huge, so the wins could be large, but that can be expected to go down with 2.0.