7
\$\begingroup\$

Say I have an octree and at a certain level I store VBOs in that octree. I know the dimensions of of the nodes that own the vbo so I can do basic frustum culling. That works nicely because everything outside of the screen is never rendered.

However my world is quite big and I currently also draw things behind already drawn octrees. What would I use to not draw nodes that are occluded by other nodes and how would I go about that?

I saw some mentions of occlusion culling in the OpenGL superbible but I fail to see how I can utilize that when I don't have a clear distinction between occluders and occludees.

Improve this question
\$\endgroup\$
2
  • 1
    \$\begingroup\$ If the contents of a node don't necessarily completely fill a node then I can't see how you could use your octree for occlusion \$\endgroup\$ – CiscoIPPhone Nov 16 '10 at 1:21
  • \$\begingroup\$ You can use the octree contents as occluders, and the octree nodes as occludees. The aggregate pixel coverage of several partially filled nodes (i.e., partial in that it doesn't map to the full pixel footprint of the octree node cube) can easily form a large occluder, and this can block octree nodes that are further away from the camera. \$\endgroup\$ – Crowley9 Nov 16 '10 at 8:03
6
\$\begingroup\$

One of the features of the octree is that it allows you to render your octree nodes in front to back order. Just doing this will help performance a lot since it allows the graphics hardware's EarlyZ implementation to be more effective (you run fewer shaders, do less raster work, etc.)

The benefit of using occlusion queries to query the visibility of octree nodes is that it can save you from rendering occluded highly complex geometrical objects. The (opaque) objects in your scene are your occluders, and your octree nodes (and by implication, their contents) are occludees. As Samaursa said, it is really hard to get this right, so please check out this paper before trying it (stalls will kill performance if not treated carefully). Also, make sure that geometric complexity is actually your performance limiter otherwise you will likely be wasting your time.

Improve this answer
\$\endgroup\$
2
\$\begingroup\$

OpenGL natively does not support occlusion queries but you can use extensions such as ARB_occlusion_query. The link has a project and a nice PDF that explains how to use it. Be careful though, sometimes the occlusion queries end up to be more costly than simply drawing the geometry. This is especially true if you geometry is not very complex.

If you provide more information regarding your scene (screenshot), a better solution could be provided.

Improve this answer
\$\endgroup\$
0
\$\begingroup\$

I currently went just with ordering my vbos by distance to the camera. This seems to help the most. Unless I fail to understand occlusion queries it slows down my code and gives weird results instead of actually helping. So unless I see some more performance issues along the way, I stick with what I have.

Improve this answer
\$\endgroup\$
1
  • \$\begingroup\$ Good idea. :-) You may want to look into predicate occlusion queries (required for DX10 hardware, and I expect there is an OGL extension). The predication can help prevent stalls, removing a lot of the downside. Once again, the main motivation here is if you are rendering millions of triangles per frame. \$\endgroup\$ – Crowley9 Nov 18 '10 at 9:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.