Procedural planet, visible seams

Started by
6 comments, last by Ardan 9 years, 3 months ago

I am currently working in Unity to try to create a procedural planet for a game idea I have.

I've gone down the route of building 6 faces of a cube (from scratch, vertices, triangles...) and "spherifying" them into a grid-based sphere.

How ever I have seem to run into a small issue. The seams where these faces meet are quite visible and

I'm guessing that it has to do with the normals not being correctly calculated.

When the sphere has been generated it looks really good, but when I apply the noise to give the planet some terrain

features the seams become very noticeable.

Here is an image showing the seams when some noise has been applied.

eqr1u9.jpg

At first I thought that the problem was noise values not matching correctly. But if you look closely the vertices match each other.

At the moment the normals are calculated by Unity's mesh object using the built-in function


mesh.RecalculateNormals()

But I'm guessing that the normals are calculated in a way that doesn't work well with a spherical structure.

How should the normals be calculated? Should they be in the direction from planets center (0, 0, 0) to the vertex?

I'd really appreciate some insight into this issue.

Advertisement
How did you compute your noise? The standard solution to this type of problem is to use 3D noise evaluated at the points of the sphere. Then your particular tessellation shouldn't be very noticeable.

The noise is generated using LibNoise which has been ported to Unity and is used like this:


float noiseValue = noise.GetValue(vert.x, vert.y, vert.z)

On top of that I also add the planets radius and the noise amount:


float noiseValue = (float)(radius + noise.GetValue(p.x, p.y, p.z) * noiseAmount);
vert = vec * noiseValue;

I might be wrong, but I don't think that the problem lies with the noise, since the seams line up perfectly with each other and the "seam" only seems to be a lighting error of some sort.

9iv5sl.png

Here is what it looks like when looking at it close up. There is not gap between the tiles, only a difference in lighting.

The intersection looks pointy but is in fact not.

How does the render look with just the noise texture applied, with no height displacement on the sphere?

New game in progress: Project SeedWorld

My development blog: Electronic Meteor

Don't really know, I never create a noise texture, but instead just apply the values directly onto the sphere.

I'm not really sure how I would generate a texture from the noise. There is a GeneratePlanar function which can be used to create a texture, but I don't think it can be used with three dimensional noise.

If the vertices along the seams are unique for each cube face the RecalculateNormals method won't be able to get any information about the face on the other side of the seam and the shading will be discontinuous. To fix this you could make sure that there is only one vertex at each position along the seam and make sure your triangles on either side of a seam reference that vertex. Then the RecalculateNormals method should work correctly. You could also generate the normals yourself from the triangles, making sure to take into account triangles on both sides of your seams.

You might find this interesting: http://www.richardssoftware.net/Home/Post/60

He's creating a geodesic sphere which doesn't appear to have a problem with seams.

If the vertices along the seams are unique for each cube face the RecalculateNormals method won't be able to get any information about the face on the other side of the seam and the shading will be discontinuous. To fix this you could make sure that there is only one vertex at each position along the seam and make sure your triangles on either side of a seam reference that vertex. Then the RecalculateNormals method should work correctly. You could also generate the normals yourself from the triangles, making sure to take into account triangles on both sides of your seams.

The thing is, I'd really like the sphere to be made from 6 independent sides, that way I could easily implement a Chunked LOD using a QuadTree.

But maybe I could calculate the normals manually on the edges after I've generated every plane and can then check the joining sides about their vertex positions. Other than that I don't really know how I could possibly fix this.

This topic is closed to new replies.

Advertisement