Sign in to follow this  
lcriver

how to handle crack in chunk lod arithmetic?

Recommended Posts

hi, i am studying chunk lod arithmetic recently,but i don't understand how to handle crack using the arithmetic.who can tell me the detail method how to handle crack? thanks very much!

Share this post


Link to post
Share on other sites
If I remember correctly Ulrich Thatcher uses a "skirt" for each chunk. That means you simply render a border (or wall) around each chunk where the border's upper part is aligned to the terrain chunk geometry. The only thing you have to think about is how "deep" into the terrain this border should be rendered so you won't see any cracks - making the borders too big will have a bad impact on your fill rate.

Hope that makes sense and helps you ...

Share this post


Link to post
Share on other sites
Filling up cracks between lod chunks greatly depends on how you have generated your chunks in the first place, and what type of LOD algorithm you are using.

Skirting is a valid technique, but the joints are obvious, and lighting/texturing can make this more apparent.

Filling cracks is made much easier if the chunk can predict where the verts will be when the lod level changes. For example, I have used geo-mipmapping. In this technique, you are guarenteed 2^n polys (where n is the lod level), and as the polys are evenly distributed, you can guarentee that if you are up against a chunk with lod level (n), the points will be at a given position (p).

Using this, you can alter the indices/vertices of the higher level chunk to match up with the lower level, so the verts line up at position (p).

If you are using a more random distribution of points in the chunk, you may need to traverse the edge of the adjacent patch, picking out the points you want to line up with.

Of course, using this method means you are decreasing the number of poly's in the higher lod level chunk, but it shouldn't effect you too much.

You can of course go along the route of increasing the poly count of the lower level patch to line up with the adjacent chunk, but that is something I have never done.

I hope that gives you a few pointers
Spree

Share this post


Link to post
Share on other sites
lcriver,

In the chunks in your Chunked LOD implementation, are you using an irregular triangle mesh like shown in Thatcher Ulrich's paper? Or are you using a regular grid of triangles

If you are using a regular grid of triangles in your chunks, take a look at my journal to see how I did it. In my implementation, neighboring chunks that differ by one LOD still have T-junctions, but you can add degenerate triangles at these T-junctions to remove them.

[Edited by - jasjas on March 14, 2006 11:05:29 AM]

Share this post


Link to post
Share on other sites
Quote:
Original post by SpreeTree
Skirting is a valid technique, but the joints are obvious, and lighting/texturing can make this more apparent.


Not entirely true. Skirts are obvious if they are too tall, but as ChunkedLOD uses a screenspace error metric (IIRC) you can be sure they'll never be bigger than your maximum error value. Keep it small and they should be very hard to see.

Also, I found that texturing and lighting actually made it harder to spot my skirts. I used the same normal and tex coord as the edge vertex directly above each skirt vertex. Again, this relies on the visible part of the skirts being quite short.

Share this post


Link to post
Share on other sites
Quote:
Original post by mrbastard
Not entirely true. Skirts are obvious if they are too tall, but as ChunkedLOD uses a screenspace error metric (IIRC) you can be sure they'll never be bigger than your maximum error value. Keep it small and they should be very hard to see.

Also, I found that texturing and lighting actually made it harder to spot my skirts. I used the same normal and tex coord as the edge vertex directly above each skirt vertex. Again, this relies on the visible part of the skirts being quite short.


Good points especially with regards to using the screen space error distance as your skirt length. I still think you will get 'prettier' results from using different methods though.

One area this will not work is if you have distance modifiers to your screenspace error distances. When using Geo-MipMapping, I tend to add a minimum distance, which means that all chunks will decrese in detail past a certain point (it's usually quite high, and in most cases not used). In this case, using the distance metric as the skirt length may still lead to cracks

Spree

Share this post


Link to post
Share on other sites
Quote:
Original post by SpreeTree
I still think you will get 'prettier' results from using different methods though.
It depends on your datasets and on the decimation algorithm you use. In hindsight I was quite lucky that skirts worked well with my GMM terrain. GMM's hurried approach to decimation makes a screenspace error metric (and thus skirts) hard to use unless you have nothing but smooth rolling landscape. I'd guess that's why you added your distance modifier - it's hard to acheive high framerates with GMM using a screen space error metric. The decimation scheme is just too undirected, with no regard for how much error would be caused by removing a face.

As it goes, I'm working on another GMM implementation using multiple index lists for crack fixing. Part of the spec for this one is that static objects on the terrain (houses etc) must be seamless with the terrain mesh. Skirts would really suck at covering that up, so as I'd be messing with indices anyway, I'm going to do the same for LOD crack fixing.

Share this post


Link to post
Share on other sites
Why it can use skirt to deal with those cracks? i don't understand the method yet.
please give me a detailed answers.i know i can solve cracks by increasing or decreasing
triangle numbers at junction.

remarks:my english is poor,please forgive me.

thanks


my msn: jiangliuchang@hotmail.com
welcome to add me and discuss the problem.

Share this post


Link to post
Share on other sites
Quote:
Original post by mrbastard
I'd guess that's why you added your distance modifier - it's hard to acheive high framerates with GMM using a screen space error metric. The decimation scheme is just too undirected, with no regard for how much error would be caused by removing a face.


My terrain is generated on the fly using Perlin and other noise functions, which means sometimes the terrain is quite hilly, and in cases like that geo-mipmapping is generally not the best fit.

I would have patches that were so far out, yet still have the highest LOD that I was rendering a stupid number of tri's. The distance modifier just tries to avoid that, with the obvious cost of popping in the far distance.

Quote:
Original post by mrbastard
As it goes, I'm working on another GMM implementation using multiple index lists for crack fixing. Part of the spec for this one is that static objects on the terrain (houses etc) must be seamless with the terrain mesh. Skirts would really suck at covering that up, so as I'd be messing with indices anyway, I'm going to do the same for LOD crack fixing.


I took the approach that occasionally locking and updating the index buffer is not that bad, so my approach involves having one index buffer per LOD, and the indices on the edges of the patch are updated on the fly as needed.

As changes in patches do not occur every frame, the impact of the log is pretty negligable.

Spree

Share this post


Link to post
Share on other sites
Quote:
Original post by SpreeTree
in cases like that geo-mipmapping is generally not the best fit.

I would have patches that were so far out, yet still have the highest LOD that I was rendering a stupid number of tri's.

Exactly the problem I had. GMM just doesn't generate good enough low detail patches for screen space error to be predictable.

Quote:
Original post by SpreeTree
I took the approach that occasionally locking and updating the index buffer is not that bad, so my approach involves having one index buffer per LOD, and the indices on the edges of the patch are updated on the fly as needed.


Yeah that's what I'm doing now, though I'm thinking about just generating all possible combinations, shouldn't take up that much memory. I was quite happy when I did my skirts that they meant the indices could remain constant, but I don't think it was that major a speed-up.

Quote:
Original post by lcriver
Why it can use skirt to deal with those cracks? i don't understand the method yet.


The best source of info is the original paper - look towards the bottom of the page for the pdf. For a less accurate but maybe more conversational explaination, check my posting history. I tend to bang on about skirts a fair bit.

Share this post


Link to post
Share on other sites

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