Jump to content
  • Advertisement
Sign in to follow this  

Screenspace Occlusion Culling

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

So I'm working on a terrain renderer, and I need to get occlusion culling up and running. I have had a few ideas, that failed due to their glitchy nature, I was working on implementing the occlusion volume method described here: http://www.flipcode.com/archives/Simple_Terrain_Occlusion_Culling-Vystoc_VerY_Simple_Terrain_Occlusion_Culling.shtml This seemed rather complicated, and I believe would probably be more efficient if I were using a quad-tree approach, which I'm not. I had an idea yesterday, and it goes like this: -Figure all the patches that are within the FOV -Sort them into a binary tree based on their distance to the camera -To render, walk the binary tree front to back -For each patch in the tree, create a bounding rectangle to compare against the occlusion buffer (more on this in a second). If it's not occluded entirely, draw it. -Then create a new rectangle from the smallest boundaries of the patch in screenspace (eg: a rectangle that is as large as possible, while still not exceeding the actual geometry of the patch onscreen) and add it to the occlusion buffer. Now the goal here is to build a list of rectangles in screenspace that represent drawn area, like a z-buffer, and ideally there'd be a way to blob them together into fewer rectangles so that each patch bounding rectangle isn't being checked against a ton of occlusion buffer rectangles. Then each patch we are trying to draw, just make sure its bounding rectangle isn't entirely covered by the rectangles in the occlusion buffer. The slowest thing I imagine that would be happening here is using something like gluProject to get the screen coordinates of the various extremity vertices of a patch. Each patch would call gluProject 8 times I believe, but I can't remember if it was gluProject or gluUnProject that was slow. Feedback ? Anyone ? Thanks

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!