Hi Guys! Been a while! My project sees constant changes, and it really helps that I learned to stick to stuff.

That said, I often see myself rewriting a module or replacing it with others. Feels clean.

I've tried to grasp the principle of Geoclipmapping. Following various articles, but mostly the one from GPU gems 2 (see, I even used the colours :P) I get that all the vertices should move relative to the camera movement,

and thus represent static points in the world. While I'm mostly successful at this, the "rings" that represent the overlap between the detail levels

cause me some headaches. (They're the ones on the picture which fades to a darker colour on the inside)

[attachment=18917:geoclipmaps.png]

I've done it so that these rings will snap to the same points where the outer vertices on the ring within are. That means that these in-between rings

scale a bit, and that the quads in the corners have issues snapping to the inside.

The individual rings are each offset with eye.xy modulo size (where size is the size of an individual quad in that ring) - when I look at these isolated,
they move seamlessly, so I think I got those right. But I can't wrap my head around how the ones on the inside can stay without being distorted a bit. And how to do the corners at all.

Any feedback or hints highly appreciated! :D

Have a good weekend,

So you're talking about doing the degenerate triangles that marry the LOD levels, right? I'm not sure why you say that "these in-between rings scale a bit". They shouldn't scale at all. The way I did it was to create the rings as static vertex buffers that use the Y vertex component to represent the LOD level they were a part of. So each triangle is comprised of two vertices from the inner LOD and one from the outer; the inner ones have a Y component of 0 and the outer ones have a Y component of 1. This lets me pick which LOD texture to fetch the height from in the vertex shader.

So you're talking about doing the degenerate triangles that marry the LOD levels, right? I'm not sure why you say that "these in-between rings scale a bit". They shouldn't scale at all. The way I did it was to create the rings as static vertex buffers that use the Y vertex component to represent the LOD level they were a part of. So each triangle is comprised of two vertices from the inner LOD and one from the outer; the inner ones have a Y component of 0 and the outer ones have a Y component of 1. This lets me pick which LOD texture to fetch the height from in the vertex shader.

Hi Funkymunky! Thanks for responding. Yes - those are the ones I'm talking about.

The way you do it, do these triangles that connect the two LOD levels maintain size, and therefore overlap either the inner LOD area, or the outer one, as the camera pans across the landscape?

Because with how I do it, letting the innermost slide to a max of 0.25 (as the innermost quads are 0.25 in width and height), and letting the next layers slide by 0.5, 1.0 etc in each direction, there is at most a gap or an overlap between two LOD levels of the inner quad size. And this means that the gaps are often narrower.

But I see your point. Just as how I've mapped it down, there's still something I need to figure out....

Huh. - Could it be that I'm fitting the inner part of the coarser LOD to the finer? This means having fewer vertices to move around than if I used the outermost
triangles of the finer LOD level...

I keep my LOD value for the vertices in the texcoords, but it seems we do just about the same thing with regards to picking the applicable level.

Actually I mis-spoke. I meant to say that I use two vertices from the Outer LOD and one from the inner. The whole point of them is to get rid of the T-Junction by drawing a triangle there.

I'm still not understanding what you mean when you say that your layers "slide". In my implementation, the LOD levels move in discrete steps, such that one pixel always corresponds to one vertex. As you fly about the scene, the levels in the grid only move (and shift around with the L shaped strip scheme) when the camera has moved far enough within the LOD level.

So the degenerates stay at the same exact place as you move until the camera passes a threshold, and the LOD levels shift, and the degenerates also shift to accommodate the new boundaries.

Ah, the only thing I meant by slide was the movement relative to the eye, before the modulo bit resets the positions of the vertices. I see how that was a weird term to use.

I've read so much and re-coded so much of this that I think I need to take a break. All this talk about grids is weird, when they are not really complete.

I somehow fail to comprehend why I should use an odd number of cells in the "grids". Also, is it supposed to be the innermost grid that's 2^n -1, or the surrounding ones?

Anyways, thanks for trying to help out. I thought I got it, but it appears that I didn't really do it how it's supposed to be done. And now I'm sorta stubborn to learn the "right" way. :)

the movement relative to the eye, before the modulo bit resets the positions of the vertices

The modulo should be the only thing moving the vertices. As far as movement relative to the eye, aside from the standard ModelViewProjection matrix work, nothing should be translating relative to the eye. The camera moves, and the vertices only change position when the modulus changes.

The grid cells need to be odd because each level of detail has twice the number of vertices as the next level, and they need to line up. Like this:

That inner level has 4 vertices along its edge. See how that hits the middle of a quad in the next LOD? By extending it to 5 vertices, the LOD edges always line up.

All grids are 2^n - 1. The reason for this number is that it's generally preferred for textures to have dimensions that are a power of two (2^n), but since odd numbers are required, the vertices only sample from 255 of the 256 pixels available.

Don't get discouraged!

(EDIT)

Look at this video:

Pay attention to the outer levels as the camera moves. See how they only "move" when the camera has moved far enough for the modulus to index the next pixel? They don't slide around with every change in eye position.

I'm back! Thanks Funkymunky, that did in fact help. I ended up understanding it, but before I sat down to rewrite some things,
I discovered that I would eventually have to deal with a patented approach, a Geoclipmaps apparently is.

So I went back to sort of a compromise. I do classic LOD chunks now, but baked into a single mesh, where every verex has its fp LOD value set as one of its attributes.

The cool thing about this is that i can use euclidean distances rather than manhattan or chessboard distances, and that I get a seamless result, as I lerp the LOD values downward towards the next chunk (which requires it's sample LOD to match its mesh density or be coarser.)

I now have

[attachment=19009:standardlod.png]

... And I'm now at the point where I'm actually considering applying a modulo equal to the highest density -quads, rather than using modulo of a chunk size. (here, the chunk size is constant, only the density changes)

This causes obvious but smooth vertex scaling in the distance, which I actually like. Viewing with the wireframe on also makes it more obvious.

I think I've managed to do a fair settlement, but you're welcome to input on the approach, of course! :)