After some months of work, and a lot research on the web, I finally got a result (at last !). The first screenshot of the concept "planetary engine".
It's not very advanced, there is a lot to do. But I'm impatient, I can't wait to show them. So, let's go !
The first screen, in wireframe so you can see the structure of the procedural mesh.

Like in other implementation, the details of the terrain show themselves when the camera get closer to the ground.
I use a classical "Chuked lod" algorithm. It's just modified a little bit to handle a spherical terrain. Each chunks are computed separately in one of the four consumer threads. This allow the player to approach the planet smoothly, independently of the computational power of the computer (to a certain extent.).

Now, the player will not see it in wireframe, so here a screenshot of the planet :

You probably noticed some glitches in this image. This come from the method used to implement the normals computation.
To have a result faster, I just compute the normal of the current chunk, without taking in count the neighbors chunks. That's why you can see the "boundaries" of the chunk. This will be easy to fix.
But actually, I wonder if it would be better to use a normal map ?
The answer is probably yes. But I've never done that.

This is a closer look of the ground, you can see even better the glitches. There's also another bug, some "black pixels", some holes. Because between two different level of details, half of the vertices on the edges of the chunk of level n+1 aren't in the edge of the chunk of level n.
But this will be easily fixed with the "skirts" methods as explained in the chunked lod articles. Actually, there are already in the program, but I disabled them because of a little bug ;). Ah, the dev life.
If someone is interested of this project, I will probably write an article more detailed and more technical of this topic.
Thanks !
It's not very advanced, there is a lot to do. But I'm impatient, I can't wait to show them. So, let's go !
The first screen, in wireframe so you can see the structure of the procedural mesh.

Like in other implementation, the details of the terrain show themselves when the camera get closer to the ground.
I use a classical "Chuked lod" algorithm. It's just modified a little bit to handle a spherical terrain. Each chunks are computed separately in one of the four consumer threads. This allow the player to approach the planet smoothly, independently of the computational power of the computer (to a certain extent.).

Now, the player will not see it in wireframe, so here a screenshot of the planet :

You probably noticed some glitches in this image. This come from the method used to implement the normals computation.
To have a result faster, I just compute the normal of the current chunk, without taking in count the neighbors chunks. That's why you can see the "boundaries" of the chunk. This will be easy to fix.
But actually, I wonder if it would be better to use a normal map ?
The answer is probably yes. But I've never done that.

This is a closer look of the ground, you can see even better the glitches. There's also another bug, some "black pixels", some holes. Because between two different level of details, half of the vertices on the edges of the chunk of level n+1 aren't in the edge of the chunk of level n.
But this will be easily fixed with the "skirts" methods as explained in the chunked lod articles. Actually, there are already in the program, but I disabled them because of a little bug ;). Ah, the dev life.
If someone is interested of this project, I will probably write an article more detailed and more technical of this topic.
Thanks !
Create a custom theme





