Planets

Creating a square section of artificial terrain was just a warm-up!
Today, I'd like to show you what happens if we apply the same logic to a sphere.

First of all, our input height matrix will have different dimensions. In case of the square, it was just a 2x2 matrix. A "minimal" sphere can be defined by eight vertices: two poles and two circles with three vertices each, as such:

The interpolation logic remains the same, except for a few details: when interpolating between a pole and a circle, a new minimal (three vertices) circle will be created. For example, if we had to run one iteration on the minimal sphere, we would start by interpolating new heights for the existing two circles then we would interpolate new circles between the the existing circles and the poles. Here's a visual explanation:

Contrary to what happened with the square section, not every row in the "matrix" has the same length. It means that, sometimes, new rows have to be interpolated from two rows of different length: for example between a pole and a circle. In this case, not all vertices are used to interpolate a new row but that's OK because the height information contained in these vertices is indirectly present in the used vertices through previous interpolations.

Let's see how a planet would look like after a few more iterations:

You can notice that the terrain looks quite detailed and realistic around the equator but, near the poles, it looks smeared, giving the planet a cotton candy look. This is due to the way our algorithm functions. Because heights are interpolated inside each circle and between circles, height information propagates mostly in two directions: longitudinally and latitudinally, but that's not the issue.

The problem is anisotropy, in other words, uneven resolution. If we counted the number of vertices on each circle and divided it by the circle's length for this particular example, we would find out that it varies between roughly 0.3 and 0.7. This longitudinal resolution tends to be higher around the equator and lower near the poles. What's more, the latitudinal resolution at the prime meridian is even higher and equals around 1.2. To solve this problem, we could increase longitudinal resolution to match the latitudinal one as it's the maximum. This can be simply accomplished by interpolating heights for circles that have insufficient resolution.

Let's see how the planet looks like after adding the densification step at the end of each iteration:

Much better! The total number of triangles tripled, but the resolution is very even which adds a lot of realism to the planet. Of course it's not completely uniform because sometimes the number of vertices is doubles for two consecutive circles but that's just a drawback of using this algorithm.

Finally, I'd like to show you a couple of worlds generated with more realistic height maps:

In case you didn't notice, these two planets are supposed to look like Earth and Venus.

Remember, none of this uses any textures, only colors. Imagine how amazing these models could have looked like if we used textures instead! But for now, I have other priorities.

By the way, 10 iterations and 100 million triangles is a lot. With the current structure of my algorithm, I cannot go beyond that without running out of memory. I'm not an expert but I'm sure there are many ways to improve that. However, it is not my focus right now.

The rendering uses about 5 GB of memory and the computation takes only 7 minutes on a modern computer. The FPS drops to about 18. Naturally, if I was looking at the planet from the point of view of a person standing on its surface, I would only need to render a fraction of all the triangles and I could further improve performance by using levels of detail (LODs).

Anyway, that's all for now.