Because i'm calculating the normal maps for each LOD chunk individually, and because different levels have different vertex densities, coarser levels are very dark compared to finer ones. When moving between them, a very visible pop occurs. And then there's the texture popping due to tiling. I googled and asked before but i can't find a solution. Do people not run into this problem??

[media]http:

Hmm yes i just realized the normals do look off:

I'm using the this method to calculate normals from heightmap. Here's my code:

// I have a chunk with a number of mChunkSamples vertices and a border vertices around the chunk to calculate normals at borders

Vertex* pV = pChunk->pVertices;

    int index = 0;
    D3DXVECTOR3 nor;

    for (int y = 1; y <= mChunkSamples; y++)
    {
        for (int x = 1; x <= mChunkSamples; x++)
        {
            float sx = pHeights[(x + 1) + mHeightSamples*y] - pHeights[(x - 1) + mHeightSamples*y];
            float sy = pHeights[x + mHeightSamples*(y+1)] - pHeights[x + mHeightSamples*(y-1)];

            nor.x = -sx * mVerticalScale;
            nor.y = 2;
            nor.z = sy * mVerticalScale;
            D3DXVec3Normalize(&nor, &nor);

            pV->nx = nor.x;
            pV->ny = nor.y;
            pV->nz = nor.z;
            pV++;
        }
    }

After doing the calculation myself (I take the whole research and duplicate literally :)), i found out that this:

nor.z = sy * mVerticalScale;

should be this:

nor.z = -sy * mVerticalScale;

Anyway, i think this looks correct:

The problem with popping is still there:

[media]http:

I would suggest you ensure all your normals are normalized (magnitude/length is 1) for all your LODs (which it looks like you are doing at the end).

Its also weird to me that you have your Y normal component hardcoded to 2 in all your normal calculations, this seems incorrect to me. Usually you calculate a normal using several data points (3 for a triangle for example) or a continuous function over the data points (which you are doing but your Y value is always hardcoded to 2).

The potential problem is when you normalize the end result, it is completely dependant on the X* mVerticalScales,Z * mVerticalScales. The larger they are the more it will reduce your hardcoded Y value of 2 when normalized. I have a feeling your mVerticalScales changes between your LODs which yeilds slightly different results for your normals after being normalized, which may be causing your undesired effect (as different LODs have incorrect and different Y normal values in the end).

My recommendation is to put in a correctly calculated Y value for your normals instead of hardcoding it to 2.

Yes i normalize my normals and mVerticalScale is constant for the entire terrain. The 2 is a result of the cross product. If you take two vectors crossing a vertex (top-bottom, right-left), and apply a cross product:

(x, z+1)

(x-1, z) Vertex (x,z) (x+1, z)

(x, z-1)

(0, sy, 2) x (2, sx, 0) = 2 * (-sx, 2, -sy)

Where the 2 in the vectors comes from the fact that the z+1 - z-1 = 2. Same for other vector.

Oh my god. Kill me now. I totally forgot about the xz scaling!!! You are absolutely right!

nor.y = 2 * pChunk->mScale;

Thanks :)