Sign in to follow this  

Updating terrain lod and rendering a terrain quadtree

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

What is the best way to update a quadtree for lod, and render it? Should I go through the quadtree once for updating and then again for rendering, or is it best to have a flag be sent in the update and during render, I just have to go through my Quadtree and just look for anything with a flag set to true and render that? Currently my quadtree ends at the size of my terrain patches, should I make a new quadtree and fill it with objects, or use the same quadtree, but just make it go smaller?

Share this post


Link to post
Share on other sites
I'm currently having it this way.

During render, I check if a chunk is in the frustum.
If it is, a "IsVisible" bool gets true else "IsVisible" = false.

each game object has a parent chunk, and if that chunk is !IsVisible, then the object doesn't get drawn either :)


To answer your question: Don't loop through the terrain twice, simply update it as you go. :)

Share this post


Link to post
Share on other sites
I found this article most useful when setting up my quadtree and frustum culling.

The optimisations he suggests do in fact make a difference so it is well worth trying them out [smile]

With regards to the boolean isVisible. I personally use an integer equal to the frame number. So if I find a node to be within the frustum, I set it's frame integer equal to the current frame counter. Then, when looping through to determine lods and then again to render. I have a check for if(node.frame == frameCounter) etc.
The benefits of this were outlined in a flipcode thread a while ago but I cant find the link [wink] I just find it to be a lot more robust than a boolean yes/no and definately helps during debugging. I then reset to frame counter back to 0 after it reaches a certain value.

Regards,
ViLiO

Share this post


Link to post
Share on other sites
you could also put a pointer to every visible node into a special "renderqueue" (i.e. a vector or list).
this way you only have to traverse the scenegraph only once and have the added benefit that you can now easily sort your renderable objects (to minimize state-changes and back-to-front rendering for translucent objects)

Share this post


Link to post
Share on other sites

This topic is 4307 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this