• Advertisement
Sign in to follow this  

Terrain LOD light pops?

This topic is 1660 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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:

[/media]

Edited by Waaayoff

Share this post


Link to post
Share on other sites
Advertisement
Your lighting looks off. I don't know if that's a normal or lighting equation issue but something isn't right. This could be why the transitions between LODs is so odd and inconsistent. I personally would address this issue first and foremost.

ETA: It looks like the lower LODs are the problem but I may be wrong as the issue could be more fundamental. Edited by GeneralQuery

Share this post


Link to post
Share on other sites

Hmm yes i just realized the normals do look off:

 

9kll.png

 

 

 

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++;
        }
    }
Edited by Waaayoff

Share this post


Link to post
Share on other sites

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:

 

x4hq.png

 

The problem with popping is still there:

 

[media]http:

[/media]

Share this post


Link to post
Share on other sites

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.

Edited by BLG

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

 

nor.y = 2 * pChunk->mScale;

 

Thanks :)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement