Jump to content
  • Advertisement
Sign in to follow this  
FeverGames

OpenGL true occlusion culling

This topic is 3170 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 need to know wether an object is visible or not. Since we have some issues with openGL and hardware occlusion queries and the support of prev. video cards, I decided to propose another way, and see if this is doable. Maybe I am missing something, or maybe my methods would suck, please give me some feedback! First we render the whole scene to the backbuffer and depthbuffer, without the objects to test. Second we use the depthbuffer from the main scene, use a render target texture, and render all the objects to identify with a color code that can reproduce a number once read back. Third we scale down the rendertexture to a small size. This will remove all "little visible" objects but maintain most very visible once, say we scale with a factor of 4 Forth we read back all the pixels from the scaled down texture and identify the visible objects. How does this sound?

Share this post


Link to post
Share on other sites
Advertisement
That requires you to synch up the CPU and GPU, so you'll create a large stall...

Some new console games are actually using a software renderer to rasterize a low-resolution depth buffer, and then do all the occlusion tests on the CPU to avoid the stall ;)

Share this post


Link to post
Share on other sites
Do you have any idea if this is more productive than causing that stall? It seems logic to reuse the original depthbuffer, but i get your point about transfering the data...

Share this post


Link to post
Share on other sites
Is your scene static? Perhaps you can precompute occlusion information into a scene partitioning structure like a BSP or octree then you don't have to do this in real time.

Share this post


Link to post
Share on other sites
not fully perse, my intentions are to calculate visibility within dynamic scenes as fast as possible, but most games at this moment have most of their content static

Share this post


Link to post
Share on other sites
Hardware occlusion culling isn't used by lots of games, and it definitely shouldn't be the only method of occlusion-culling used.

There's an article on gamasutra (can't find it at the moment) and probably some here on Gamedev too, which describe "occluders" or "occlusion volumes".

Basically, you define a convex polygonal shape for large objects in your scene. You then find the edges of this shape and use them to project an occlusion frustum out into the scene. You can then test the bounding-boxes of small objects on the CPU to see if they lie inside any of these frustums -- if they do, they're hidden.

You should probably also look into sector/portal systems. Portals can be culled using the same method as above (test the portal's BB against occluders, if hidden, don't traverse into the sector linked by the portal).

Share this post


Link to post
Share on other sites
just to be sure, before i go into depth of research, this does result in knowing if an objects visiblity is not disturbed by other objects right?

Share this post


Link to post
Share on other sites
before you start with occlusion culling, you shall identify what you want to achive.

occlusion culling is not to make something faster, it's rather to load-balance work. you will have more costs on one side and less on another, the goal is to save time in average by utilizing underutilized resources.

e.g.
-you have damn expensive pixelshaders, in this case your goal #1 is to cull pixels. This could be accomplished by a z-prepass.
-you are vertex limited. in this case your idea is not that bad, you could use the ID-rendertarget in a 2nd pass and identify the visible IDs. resolve them into an ID-buffer (1d texture either set to 0 or 1) and the first instruction in the vertexshader would check the ID and either reject the wohle vertex (dynamic branching) or execute the whole shader (like comple FFT for water or 8weight skinning for some 50k character).
-you are drawcall bound, in this case u need an earlier stage to cull, maybe a software rasterizer or even some artist set anti-portals (which are damn simple to implement) would help already.

sometimes some middleware could help :)

Share this post


Link to post
Share on other sites
Quote:

You should probably also look into sector/portal systems. Portals can be culled using the same method as above (test the portal's BB against occluders, if hidden, don't traverse into the sector linked by the portal).


I would advise against using portals for the following reasons:

1. the are limited to indoor environments

2. you cannot classify where you are in the world without keeping track of every single sector you are in and testing whether you intersects a portal or not every time you move. (you also need to pair yourself with an initial sector) (this goes for all objects, not just the player). You *could* use a BSP tree to classify where you are (like in doom3) but anything involving a bsp is hellish work.

3. portal culling is done in world space, image-space methods should be used as they address the actual problem of occlusion on a raster grid rather than be specific to triangular meshes. e.g. In an image space method - dynamic particles could also be used as occluders.

Share this post


Link to post
Share on other sites
Quote:

2. you cannot classify where you are in the world without keeping track of every single sector you are in and testing whether you intersects a portal or not every time you move. (you also need to pair yourself with an initial sector) (this goes for all objects, not just the player). You *could* use a BSP tree to classify where you are (like in doom3) but anything involving a bsp is hellish work.
that depends on the rooms. if you have room geometry as well, it's fairly easy to check where you're in, and you can assume that "indoor" scene do have those "rooms". in cryengine it seems to be a simple n-gone.

Quote:

3. portal culling is done in world space, image-space methods should be used as they address the actual problem of occlusion on a raster grid rather than be specific to triangular meshes. e.g. In an image space method - dynamic particles could also be used as occluders.


imagespace doesn't strictly imply that a raster grid is used. doing portalculling in imagespace reduces the work to simple 2d-vector-math (rect-rect clipping).

I think a big advantage and at the same time disadvantage is that you need humans to set it up. so they need to be skilled in setting them in the most performant way. portals to cull empty rooms are useless, but also missing portals can be a big performance hit.

but I think the OP was anyway asking for something for dynamic scene, that makes PVS and portals kinda obsolete.

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!