Procedural generated terrains for large planets

News & General Discussion
1

I see there are a lot of thing about procedural generated terrains for planets but I have a question about a certain solution to this.

say you have a very large planet, like Jupiter. Rendering that whole planet at once with a cube that has a many subdivisions would be very memory heavy, right? Is there anything wrong with following the idea of infinite terrain generation but having a fixed amount of terrain chunks and wrapping back to the beginning chunks when the user reaches the end?

For example,

You have 9 chunks:
(0,0),(0,1),(0,2),(1,0),(1,1),(1,2),(2,0),(2,1),(2,2)

Say you walk diagonally from (0,0) to (2,2) displaying only 4 chunks at a time in any direction. Ex. User is on 0,0 facing north-east so chunks (0,0)(1,0)(1,1)(0,1) are rendered. Once the user reaches (2,2) the chunks that’s would be rendered are (2,2)(0,0)(1,0)(0,1)

This would simulate the effect of walking around a planet complete if a full loop with flat land only rendering what the player needs to see correct?

Are there limitations to this though? Am I thinking this through correctly?

2

The only limitation is whether that realistically approximates a planet’s surface.

3

The other problem is that there is no way to map the planet from orbit. So you will have to rely on a transition and some design rules (ie only land at set point depending on angle) and hide the geography.

Anyway it’s a problem I’m tackling, the thing is you need to render a proxy planet for distance and project a typical LOD terrain just below the ship relative to the center of the planet (ie just like typical flat terrain when you gain altitude) that you would tesselate and LOD as the ship goes close to it. No matter the size of the planet the footprint would remain the same (like infinite flat terrain, it’s only a fixed radius around the avatar)

Now depending on your planet model you will have to deal with seam and pole. Typical solution is to use a quadsphere (or inflated cube) with a specific projection to reduce area distortion(something with square root). This method is preferred because it’s easy to find which face is hovered using simple math and have simple coordinate in that face (ie the planet is the equivalent of 6 fixed size planes depending on the size of the planet).

Now the problem is transitioning between the seam (between cube faces, coordinate reference shift) and poles, but I haven’t fully resolve that for myself! Look at No man’s sky team gdc talk for further details about how they solve it for themselves (and hit google to find some other attempts).

4

Cubes are bad for planet rendering. Hexagons will work much better for surface subdivision.

5

Until you implement them and fail harder, all sort of mapping has been tested already, they all similar problem because you can’t mathematically solve isotropic direction on a curve space. Cube give you the most comfort and convenience and is compatible with usual way of doing map.

Now if you are a genius coder, anything goes, go for it!