Jump to content
  • Advertisement
Sign in to follow this  
rpreller

View Frustum Culling using Quadtree

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

Hey. I'm writing a view frustum culler using a quadtree, somewhat easily extendable to use octrees. Before I fully write it, I was wondering if I could get some feedback from people who've written them and what I can expect in terms of run time. Of course, the culler should be benefitting me overall or there's no point in using it. I wanted to know of any simple techniques in term of runtime. I'm seeking a framerate of about 80 using my level of detail engine. If the view test that checks the frustum against the quadtree is being called 80 times a second, I picture this as being somewhat wasteful. Does anyone find a problem with calling it maybe only 10 times a second, and possibly testing a slightly-larger-than-it-really-is view frustum against the quadtree?

Share this post


Link to post
Share on other sites
Advertisement
frustum tests against a quadtree aren't that big of a performance bottle neck (in my programs at least) since the cpu tears through that stuff. I think if you don't check every time you render the object you are going to get some serious artifacts. No matter how big you make the 'slightly-larger-than-it-really-is' frustum, you will always be able to swing the camera around fast enough to see areas that are culled. And using a larger frustum will cull less objects. So I don't think it will be worth it, although the only way to know for sure is to implement both methods and compare.

By the way, an fps of 80 is only 12.5ms per frame, which is being stingy. You can use almost three times that (33ms) and still have silky smooth movement.

Share this post


Link to post
Share on other sites
I wouldn't got a 10hz forced update - as jamesw said, that'll probably introduce artefacts unless you're very careful.

Consider two things:

1. Lazy evaluation - only update the PVS when something changes. That is, dont rebuild your PVS each frame, only do it when an object or camera moves.

2. Delta evaluation - considering human reaction times, animation/movement speeds the frame-to-frame movement is probably minimal. You could consider doing a partial/rough check of the last frame's PVS to see if anything substantial has changed. For example, only look at the border/edge nodes and see if they're still valid.

In my experience, the actual API overhead (potentially large number of draw calls) was far more of a problem. The CPU/algorithm side was rarely the bottleneck.

hth
Jack

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!