Terrain crack prevention.

Started by
3 comments, last by DirectXFreak 19 years, 3 months ago
Greetings, I am in the process of creating a terrain engine. I have reached the point in development where I need to implement crack prevention for LOD patches (the method I'm using is Geomipmapping). I have thought up a method of doing it, however, and I would like some feedback. First off, the terrain is organized in patches where each LOD has its own index buffer. I was thinking that in order to fix the cracks, I would create extra index buffers for the right and left, top and bottom sides. So, I would create the main index buffer like this: '+' = vertex that is left out 'O' = indexed vertex

  + + + + + + + + +
  + O O O O O O O +
  + O O O O O O O +
  + O O O O O O O +
  + O O O O O O O +
  + O O O O O O O +
  + O O O O O O O +
  + O O O O O O O +
  + + + + + + + + + 
Then for each LOD, there are separate index buffers created for the left and right side like this:

  O + + + + + + + O
  + O + + + + + O +
  O O + + + + + O O
  + O + + + + + O +
  O O + + + + + O O
  + O + + + + + O +
  O O + + + + + O O
  + O + + + + + O +
  O + + + + + + + O 
so the engine would create three of these index buffers, one for each possibility, right, left, or none. Then for the top/bottom the engine would create 3 more index buffers per LOD the same way as the right/left ones, only rotated at a 90 degree angle. I created it this way because rather than switch the index buffer 5 times per patch, it would switch only 3 times. So my question is this: is this an good way to do it? I hope I haven't confused you, this is about the extent of my grasp on this subject. Thoughtful replies would be helpful.
--m_nPostCount++
Advertisement
I didn't quite follow that last bit, but I think you're on the right track.

An article that details a fairly straightforward approach to this problem is called 'Terrain LOD Using Interlocking Tiles' (or something like that) - it's in one of the first Grame Programming Gems books.

A problem it addresses is that in a naive 'edge stitching' implementation, even if the patch is at a uniform LOD, 5 API calls will be made - one for the interior, and one for each edge.

At the expense of memory consumption, a workaround for this is to store every combination of interior/edges with matching LODs at each LOD. Then, only the edges that 'don't match' are filled in with separate rendering calls.

Anyway, it's a little much to explain in one post, although conceptually it's pretty simple. Just ask if you have more questions. Although again I didn't completely get what you were saying, it sounds like you're moving in that direction anyway.
Yeah, that's basically what I had in mind. The reason I chose to render all four sides in two calls rather than four is that I figured it would be a good balance between memory consumption and render calls. Do you think I should just go for having one render call for all four edges? The result would be lots of memory consumption as you said, but would it be worth it?
--m_nPostCount++
Quote:The result would be lots of memory consumption as you said, but would it be worth it?


Short answer - I don't know. There are too many variables regarding your platform, API, cache issues, etc. to be able to say which approach would perform better. Render pipeline optimization isn't an area I've spent much time on, though, so maybe someone else will be able to provide better input.
Alright, I'll just try it out. :-D
Thanks for the replies; you've been a great help.
--m_nPostCount++

This topic is closed to new replies.

Advertisement