Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Chaucer

chunked lod

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

It''s my understanding after reading the chunked lod paper by thatcher ulrich that it works like this: In the preprocessing stage, first, the index buffers are created to hold all the indices to the vertices in the ENTIRE map such that there is a very low resolution. This will cause give a blocky look. second, the terrain is split in the same manner as a quadtree such that each quad is a higher resolution and so on until the highest resolution is reached. Therefore, in the preprocessing, there will be a number of static meshes or static index buffers that represent each of these meshes from the low detail map of the entire terrain, to the high detail maps of smaller pieces of the terrain. now...if preprocessing is all correct... in the rendering stage, the lowest detail mesh is drawn first? followed by higher detail meshes if they are within the viewing frustum? This is what I don''t get. If this is the way it works, wouldn''t the blockier mesh show through the higher detail mesh when it comes to hills? It seems that the slope on the lower detail mesh would look like a ramp where the higher detail might be a cliff. Can anyone help me figure this out? Thanks!

Share this post


Link to post
Share on other sites
Advertisement
maybe i missed something, but i thought the point was to render only the resolution you need. stacking them would be wasteful, cause artefacts and sounds like a horrible idea. thats just the drawback of it. you wont get ridiculously small 2-triangle chunks, but you loose flexibility. if one part of a "node" requires higher lod you have to use that higher lod for all parts. you cant just render them all in low res and then put the high res part on top.

Share this post


Link to post
Share on other sites
In a nutshell, here is the algorithm:

If the resolution of the mesh is good enough, draw the mesh. Otherwise, draw 4 higher resolution sub-meshes instead. Do this recursively.

Share this post


Link to post
Share on other sites
My point is that IF you want to render the lowest resolution, the mesh covers the entire terrain, therefore it will show up through the high resolution meshes.

Or should I just be creating a bunch of high and low resolution meshes of the same size and render what''s needed?

Share this post


Link to post
Share on other sites
If I recall rightly, the main difference between chunked LOD and others is that chunked LOD generates discrete vertex and index lists for each chunk at each LOD. This what makes it so scaleable - if index lists operate on the same vertex lists throughout (as in geomipmapping etc), at some point you will be storing a full high resolution mesh worth of vertices when only a small portion of a low detail version of that mesh is needed. Obviously you could experiment with how many levels can use the same vertex list easily and take it into account in your preprocess to save mem / storage, but YMMV (post here if you do though, I''d be interested in any results!)

afaik, you''re meant to generate the small low res chunks to avoid the problem you''re talking about, but it would be possible to just generate index lists for the smaller low res chunks. This would affect batching for the graphics card as the batches would be really small, but then there should never be more than a few of them off in the distance...

At the end of the day it''s mainly down to you to decide your minimum chunk size and live with it ;~)

Share this post


Link to post
Share on other sites
Ok, so instead of what I posted before, where in preprocessing a low detail chunk is created for the entire terrain, then 4 higher detail chunks are created, etc...

I would create a low and high detail chunk at every level?

It seems that would take much more memory and preprocessing time.


The picture on the front of the paper is what leads me to believe the low resolution chunk is created for the entire terrain, and the higher resolutions are split into smaller chunks. But using this method generates the problem I was stating before where if you draw the lowest resolution chunk,it will cover over all the higher resolution chunks.


Or is the lowest resolution chunk ever supposed to be drawn?

The reason I see the lowest resolution chunk drawn first is because in a quadtree, you start at the lowest resolution and recurse down.

In this situation, are the highest resolution chunks drawn first and then lower resolutions drawn later?

Share this post


Link to post
Share on other sites

As JohnBolton says, if you render a given higher-res LOD chunk you don''t render the lower-res parent chunk that ''contains'' the higher-res one, since as is mentioned the two would overlap and look nasty.

In the update stage, the lowest-res chunk (root of the quadtree) is tested first, but probably not actually rendered. If a given chunk is considered to be too low-res, the ENTIRE mesh for that chunk is turned off. Instead the four higher-res meshes of the subchunks (which together occupy the same terrain area as the original parent chunk) are rendered. This is done recursively as was mentioned, of course.

So typically the top low-res mesh is never rendered, as LOD requirements will usually have you rendering higher-res subchunks instead. This is kind of a waste because when a high-res chunk mesh is rendered all the lower-res chunk meshes are taking up memory but not being used for rendering. I suppose you could extend the out-of-core loading/unloading to work both above and below the rendered chunks, but that sounds like a formula for a really messy algorithm.

Share this post


Link to post
Share on other sites
Thank you very much. For some reason, after reading the last post, it''s seems to make sense.

So then I wouldn''t need small low res chunks, but instead, for the height of the tree, the root of the tree is the lowest res, where the bottom of the tree is the highest res.

If I decide not to render the low res, I instead move to the next level and determine whether to recurse on EACH chunk. *Only when I stop recursing, do I render a chunk.*

Therefore, it will most likely look like there will be 3 chunks rendered at the 2nd level and the 4th chunk will be recursed down into higher resolution chunks.

Share this post


Link to post
Share on other sites
So if the above works correctly, how would you implement terrain self-shadowing?

Would you create a lightmap for every chunk?

Then if the lightsource moved, you''d have to recreate the lightmap?

thanks!

Share this post


Link to post
Share on other sites
depending on your hardware. you can use one big lightmap for the whole terrain or one big normalmap and do it "per pixel". shadows aren''t as easy (though it helps if your sun just "happens" to cleanly move along one of the axes).

Share this post


Link to post
Share on other sites

  • 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!