• Advertisement

Archived

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

chunked lod

This topic is 5102 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
The total size of the data can be much larger when using LODs, but since much of the terrain being rendered is at low resolution, the amount of data in use is much smaller than without LODs.

Chunks covering an area of terrain all share the same lightmap. Lightmaps look much better than gouraud shading because the lighting stays the same even though the mesh changes. With gouraud shading, the lighting can change noticably as vertexes are added and removed. The drawbacks to lightmaps are that they are static and can be very large.

Share this post


Link to post
Share on other sites
quote:
Original post by JohnBolton
With gouraud shading, the lighting can change noticably as vertexes are added and removed.

No. If you interpolate vertices'' positions as the detail level changes, you can just as easily interpolate their colors so the gouraud shading will always be smooth. It''s very easy.

Lightmaps can still be used for the highest resolutions, which is good since you can then do things like have trees cast shadows on the world.

~CGameProgrammer( );

Screenshots of your games or desktop captures -- Upload up to four 1600x1200 screenshots of your projects, registration optional. View all existing ones in the archives..

Share this post


Link to post
Share on other sites
quote:
Original post by CGameProgrammer
No. If you interpolate vertices'' positions as the detail level changes, you can just as easily interpolate their colors so the gouraud shading will always be smooth. It''s very easy.



there''s a limit to what geomorphing can do to hide the transitions. for example i still dont know if i want to see a hill "grow" out of nowhere or just have it pop into view. both effects can destroy the illusions and look just plain wrong. a hill disappearing and changing color from brown to green still wont look too great.

quote:

Lightmaps can still be used for the highest resolutions, which is good since you can then do things like have trees cast shadows on the world.


*confused* the one thing where lightmaps are pointless is the highest resolution where vertex colors would have the exact same result (given that the lightmap and heightmap have the same resolution). keeping that high resolution for textures on parts with low lod is the whole point of not using vertex colors for that.

Share this post


Link to post
Share on other sites
Triangles are pretty large even at the highest resolution, usually. Lightmaps therefore offer more precise lighting for things like shadows.

As for how noticeable ROAM is, if it''s well-implemented, the morphing is usually hard to see and too subtle to notice, and the same goes for color changes (which are only shading changes, besides... so green fading to darker green, for example).

Anyway ROAM is what I''ll be using for my current project but it''s not implemented yet. (I have done it in a much older engine though, with the color changes.)

~CGameProgrammer( );

Screenshots of your games or desktop captures -- Upload up to four 1600x1200 screenshots of your projects, registration optional. View all existing ones in the archives..

Share this post


Link to post
Share on other sites
If I use one big lightmap for the terrain, wouldn''t it take too long to recreate the lightmap when the sun moves?

How would a normal map work with the sun moving?

Share this post


Link to post
Share on other sites
The sun moves very slowly (unless you''re doing some sort of accelerated time effect or something like that). You can update the lightmap over several frames. So this is not much of a problem.

Michael K.,
Co-designer and Graphics Programmer of "The Keepers"



We come in peace... surrender or die!

Share this post


Link to post
Share on other sites
Wouldn''t that give a popping effect, unless the lightmaps did a cross fade?

Maybe it would be better to create them all in preprocessing stage, although that would also lead to LONG load times.

Share this post


Link to post
Share on other sites
If for example your sun makes a complete circle in 6 minutes, it would only move one degree every second. One degree is barely noticable, if at all, and yet a second is plenty of time to generate a new lightmap afaik. You can even swap lightmaps after a larger amount of degrees without it being very noticable. Try it - chances are you won''t need a cross fade. But even if you will, it''s not very hard to do.

Michael K.,
Co-designer and Graphics Programmer of "The Keepers"



We come in peace... surrender or die!

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
What do you think about this :
- generate 2 lightmaps, one for sunset/dawnset, one for full-lighting at midday (sorry for my english)
- use those 2 lightmaps to generate via linear/cubic interpolation the one that will be used. This technique should be a lot faster than dynamic generation

Share this post


Link to post
Share on other sites

  • Advertisement