Sorry your browser is not supported!

So I recently added a simple LOD system to speed up my terrain engine a bit. However, as is logic when one thinks about it, the edges won't match up perfectly when segments of different vertex resolutions are adjacent, thus resulting in gaps in the terrain.
I've thought of two possible ways to address this when I get home tonight and was wondering what you think about them / if there is any superior option I haven't thought of yet.

I use two sets of LOD meshes, each one at half the resolution of the higher one. So for example:
Main (top resolution) mesh: 64x64 tiles (actually 65x65 vertices for overlapping with the next segment mesh at the edges)
LOD 1: 32x32 tiles
LOD 2: 16x16 tiles

My plan is to either use linear interpolation to set the vertices of the higher resolution meshes to in-between values of the lowest resolution mesh. This should probably be fairly easy to accomplish, but might perhaps create blocky surfaces when up-close if the edges lie in a slope?

The other idea is to have even the lower resolution meshes have full (ie. 64x64) resolution along the edges. These kind of meshes would probably be more difficult to create through code than the constant rows*cols plains I currently have but should (I think?) allow for properly smooth edges.


Is any of these ideas better than the other, or do you know of yet some other approach?

Thanks for any suggestions,
Rudolpho

The interpolation method sounds decent to me. It won't look more blocky because it doesn't matter, you're only manipulating the vertices on the very edge and still effectively have 63x63 under your feet. This method might take a bit to program, but nothing that's impossible. And it will make your modeling life easier.

TheComet

There is a solution which will match them up perfectly, you will need to have access to index data.

You work your way around the edges of the higher lod mesh and change the index values around to lower the lod just on the edges.

It will then fit in perfectly with the lower lod mesh joined next to it. Note that you have the same amount of vertices but the triangle count is lowered by one for each square.



I am about to this exact thing for my plugin Dark Terrain, I did not want to but my current method of lowering the edges did not working too well


EDIT: So this is your second idea but the other way around, it's the way I would go since time spent on your first method may be wasted if it does not work too well

Thanks Matty, that looks interesting... however I'm using the individual vertices to set their height and am a bit at a loss trying to see how changing the triangle data would get around the issue... is it possible to just omit certain vertices from the index data (like the black one in your image)?
If you can give / link to a more in depth explanation of this solution that would be great

If your game is an FPS style game where you won't ever be very high above the terrain you can use this approach I came up with.

Basically you have 1 mesh with ever decreasing resolution. So maybe 16x16 squares in the middle of 1 unit size. Then 16x16 squares all around the outside of that with 2 unit size. So and so on. You then split these up into different meshes so you can process them all individually and cull ones off camera. The whole landscape moves with the camera, meaning you only need a finite number of meshes to create a theoretically infinite landscape.

For every 1 unit movement you update and move the middle mesh. For ever two units move you update the next layer and so on. The edges between the resolution steps are linked in a similar way to Matty H's diagram.

The benefit to this approach is far far less terrain snapping. With the approach you're using, an entire terrain section suddenly switches resolution making the entire ground move slightly. Plus you need meshes for every portion of the landscape. This requires fewer meshes and the landscape can be infinite. The down side is that it only really works when the camera is close to the ground.

My approach is best demonstrated in these vids ...

I like Fallout's terrain technique, but if you are like me then you have already mostly implemented it the other way.

I may be able to help with an algorithm which sorts the edges out, what commands do you use to create your terrain?

Also, how are your vertices and indices set out, I will need to check how I did mine, if we did them differently then the same algorithm will not work on both.

I thought it would be easier to create the LOD sections first and then alter the edges rather than do everything in one go, although this approach will be slightly slower.

Yes, I'd have to agree with Matty, my terrain system is already functional save for the edges with the LOD mesh switching. Your system is definitively interesting but I cannot undertake a complete rewrite at this moment; the system I have, blocky as it may be, should be enough for the game I'm planning anyway. Also I will have to have a somewhat functional demo done in a couple of weeks, so time is a bit tight. Thanks though, I'll definitively keep it in mind for later


@Matty H: at the moment I'm simply using Ian M's create object plane from Matrix1Utils 19. It lays the vertices out from top-left to lower right, row by row and I would guess (although I haven't had the chance to look it up yet) that the index data is also left to right, row by row in such a way:

where the first triangle is made up of a-b-c and the second a-c-d. So the rows are of two triangles / a quad at a time I suspect.

I have been doing some sketches on paper on the bus and have an idea of how it might be possible to achieve what I believe you mean.
Basically I would create the object as usual and read all the vertexdata to a buffer, I would then proceed to edit the index data like so (for a level 1 LOD mesh, the level 2 simply requires further stretching and the removal of more triangles in-between):
1) Find all triangles that contain the vertex "to be removed".
2) One of these triangles are "inverted" (replacing it's reference to the undesired vertex to the other "remaining" vertex on it's quad)
3) The second triangle also replaces its reference to the undesired vertex, this time to the one to the right (if we're assuming horizontal application on the topmost edge).
4) The third triangle is removed alltogether.
A new object is then created with the appropriate amount of vertices and indices and it's vertexdata will be set according to the old vertexdata and this modified index buffer.

As said, I haven't tried this yet, but I think I should be on the right track?
Still so, would be great to see your algorithm if you already have one

Finally, sorry if this doesn't make much sense, it's in the middle of the night here..

To update this, I eventually got it to work using Matty H's solution
If anybody was wondering then yes, it is indeed possible to have vertices that are not rendered at all / do not affect adjacent vertices by omitting them from the index buffer.

That's great. I started doing mine but it was more complicated than I expected

I will hopefully get time to finish it off soon.

You can have my source if you like, the top resolution (that, for me at least, has three vertices per four to be removed at a time) was quite tedious to work out the proper triangulation method for. I think I have 8 notebook papers with various sketches, each one which turned out to be wrong once I finally had it in code...

Thanks but it's ok, I am half way through doing it in GDK, I have not finished it since I'm not sure if I need it yet and there does not seem to be anyone waiting for it



Ha ha, I do too