Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Don't forget to read Tuesday's email newsletter for your chance to win a free copy of Construct 2!


Imprecision

Member Since 08 Mar 2012
Offline Last Active Oct 23 2013 01:23 PM

#5102402 Vertex Normals In A QuadTree Terrain

Posted by Imprecision on 18 October 2013 - 07:32 AM

I finally managed it to get my terrain stitching working on a globe with six quadtrees.

I used a index system similiar to this one http://img406.imageshack.us/img406/2153/screen4ya3.png.

Everything looks fine so far (no cracks, no shifted heightdata), except for the lighting. The vertex normals on the edges are sh*t.

 

See the image below:

shitnormals0lp68.png

 

Is there any way how to calculate/interpolate the edges, so they have the same normal?

One of the problems that I cant "fix in my head" are the differences between LODs

I cant just copy the vertices of my neighbor because maybe its larger or smaller than me:

ddtrkkil.png

Node (1) needs the vertex data (red and green slice) from node (2), (3) and (4)  to calculate correct normals. This means data from these nodes must be extracted (slice) and some of it must be skipped (because node (1) has a lower resolution) by the difference of the specific neighbor depth. This is complicated, but not that much.

 

The other way around is giving me headache. Node (2) needs the border vertex slice from (1) (the blue one). The problem is, that it just needs a specific "range" of the slice, so it needs to determine what exact position it (2) has compared to the border of the node (1) and calculate the index of the first vertex to extract. WTF?!

 

 

Next problem with this is, the 3D aspect. I have different behavior when my neighbors are on other sides of the node:

f4333nntb7abt.png

 

For Node (4) I need three slices to get correct normals for the north and west edge. One from (5) one from (6) and the last vertex for the corner from Node (1). When I have the same situation with the neighbors beeing on anthoder side, i just have 2 slices, because I don't have a corner at all. 

 

-

 

Even if i would have a super algorithm that calculates how much shifted a smaller node to a bigger node is handling different sides of the cube... there must be another way. I found 1000 topics of neighbor finding and crack fixing problems for quadtrees. But not a single one who has problems with vertex normals.

 

This makes me suspicious that I make something fundamentally wrong.

 

Btw. here is the code how I calc the normals:

 private static Vector3d[] create(Vector3d[] vertices, int[] indices) {
            // Prefilling result
            int vertLength = vertices.Length;
            Vector3d[] result = new Vector3d[vertLength];
            for (int i = 0; i < vertLength; i++) {
                result[i] = Vector3d.Zero;
            }

            // Calculating normals
            int length = (int)(indices.Length / 3);
            for (int i = 0; i < length; i++) {
                Vector3d v1 = vertices[indices[i * 3]];
                Vector3d v2 = vertices[indices[i * 3 + 1]];
                Vector3d v3 = vertices[indices[i * 3 + 2]];

                Vector3d ab = v1 - v2;
                Vector3d ac = v1 - v3;

                Vector3d vCross;
                Vector3d.Cross(ref ab, ref ac, out vCross);

                result[indices[i * 3]] += vCross;
                result[indices[i * 3 + 1]] += vCross;
                result[indices[i * 3 + 2]] += vCross;
            }

            // Normalize
            for (int i = 0; i < vertLength; i++) {
                result[i].Normalize();
            }

            return result;
        }



PARTNERS