Terrain patch stitching preferences
Hi All,
I was wondering what everyone's preferences were, with regard to stitching together adjacent terrain patches to avoid T-junctions.
I'm currently doing the standard thing of geomipmapping on a regular grid of patches (6 grids that are connected and projected onto a sphere). If a patch has a lower LOD level than any of its 4 neighbours, it generates a connecting strip, for a seamless join. Blah. It was a little time-consuming to work out, but it looks OK.
The problem with this is that I've had to write a memory management scheme for the terrain vertex buffer. Eventually, the allocated regions in the buffer get fragmented and I have to compact it, which is a bit messy (because I have to rebuild all the index buffers for all the affected patches).
However, I've also experimented with a different approach, where each patch has a set resolution (17x17 vertices). If the patch screen-space error gets too high, it splits into 4 sub-patches (each also 17x17). I like it because it's conceptually neat, and I can have a far simpler free-list-based allocation scheme on top of the terrain vertex buffer. Maintaining the connecting strips between patches seems harder, though (not done it yet), as keeping track of neighbours in a quad-tree is not simple (or is it?).
So - does anyone have any thoughts on either of these schemes? Is there a third way that is better than both?
Thanks in advance,
Andy
I use a restricted quadtree and limit patch LOD differences to only one (1) level. This allows a simpler static index buffer to hold the 16 possible variations of the border triangles when a patch has a higher polygon density than its neighbor(s).
I use a different triangulation of the regular patches.
Another Post
Hope that helps.
I use a different triangulation of the regular patches.
Another Post
Hope that helps.
Hi Amadeus,
Thanks for that - very interesting.
I'm not too worried about constructing index buffers on the fly, though, so I might relax that constraint regarding neighbouring LOD levels. Might allow me to aggregate index buffers as well, to cut down on the number of dip calls.
Thanks for that - very interesting.
I'm not too worried about constructing index buffers on the fly, though, so I might relax that constraint regarding neighbouring LOD levels. Might allow me to aggregate index buffers as well, to cut down on the number of dip calls.
I'm too lazy to figure out some complicated stitching, so I draw "skirts" by duplicating the border vertices and offsetting them downwards. It's easy to code (and probably fast) too.
It sure isn't the technically correct thing to do, but it does hide the seams... for my eyes it's good enough. It certainly won't cope well with large cracks, but those shouldn't be there in the first place.
It sure isn't the technically correct thing to do, but it does hide the seams... for my eyes it's good enough. It certainly won't cope well with large cracks, but those shouldn't be there in the first place.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement