Jump to content
  • Advertisement
Sign in to follow this  
ehmdjii

frustum culling, how to decide when to put nodes back in to the scenegraph

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

hello, i just implemented view frustum culling so that scenegraph-nodes that lie outside the camera frustum are not rendered. now my problem is that when the camera changes these nodes should be checked again, and possible re-added into the scenegraph. now since there are a lot of nodes in the scene i can not check all the nodes each frame. i also tried checking them in another thread, but that leads to nodes popping in a bit too late, since the frustum-checking thread can be late. so what is the recommended way of checking non-rendering nodes for frustumculling? thanks a lot!

Share this post


Link to post
Share on other sites
Advertisement
The scene nodes usually contain bounding boxes (or spheres, etc.), and these boxes are organized into a hierarchy, i.e., the bounding box of a node contains all the bounding boxes of the child nodes. You can take advantage of this to perform hierarchical frustum culling.

The basic idea is that if a node's bounding box is not visible, then you know for sure that it's children are not visible as well, and so you don't need to check the children for visibility - you just discard the entire "branch" (node + all it's descendants) in one check! That way you don't need to check all the nodes each frame.

You can speed up collision detection and other spatial queries in a similar way.

About removing nodes from the scene graph - I'm not sure that's a good way to do it. I think the common way to do this is to add all visible nodes to a render queue. This queue can also be sorted according to some criteria, for example, opaque objects can be sorted by material for faster rendering while transparent objects need to be depth sorted back to front. For this reason, you typically have several render queues, each one holding a different "category" of objects (opaque, transparent, etc.). Of course, at the beginning of each frame the queues start out empty.

Share this post


Link to post
Share on other sites
thanks for your reply!

so if you create a new list of renderable objects every frame, that means that you also have to do the frustum-check for each object every frame, right?

that is actually what i want to avoid, since i have lots of objects.

thanks!

Share this post


Link to post
Share on other sites
Quote:
Original post by ehmdjii
so if you create a new list of renderable objects every frame, that means that you also have to do the frustum-check for each object every frame, right?


No. You traverse the scene graph, testing the bounding box of each node. If it's not visible, you discard the node and all it's child nodes. If it's visible, you recursively check each child node for visibility. I assume that the renderable objects are stored in the leaves (I think that that's usually how it works), so when you get to the leaves you check each object for visibility and add the visible ones to the render queue.

Notice that the above process does not check each object in the graph. If you have a node that has 100 children that are renderable objects and the node's bounding box is not visible, then you can reject all 100 objects in one check.

Share this post


Link to post
Share on other sites
thanks a lot!

i think my main problem is that i dont have this hierarchical setup. (or at least i have it, but dont make much use of it)
i have all the scenegraph nodes in one collection and that would mean i would need to check each of the nodes every frame, which is very costly.

i think i will need to redesign my scenegraph structure.

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.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!