Procedural planets with terrain

[creative-brain]

I would like to create procedural planets using HTerrain as all the functionality is already there, except the sphere shape of the terrain.

Would it be possible to alter the generation of the current flat terrain into 6 faces rotated to a particular directions to form a cube? Then it would be possible to inflate them as shown here. Maybe the inflation could be done more easily by using the sphere brush and simply elevate each face to form a full sphere. Then one could apply the noise on top of the "inflate brush" to generate random terrain shape or load predefined heightmap.

[Zylann]

I have thought about this, unfortunately, despite the idea being simple, this means modifying a TON of places in the plugin, if not ALL of them (from tool scripts to shaders) just to take spherification into account. Some places may even need a complete rewrite because spherical worlds can't do the same calculations as a planar world. Heightfield colliders also can't be used.

It's easy to make a generator script that makes a planet out of 6 planes (and if you need one, it's the fastest way instead of using this plugin), but hterrain does way more than this. It has editor authoring integration, with a wide range of variants and options that are ALL designed for a single, planar terrain. It means adding an entire additional workflow to stitch 6 nodes in a spherical topology and have all these tools being aware of that "mode", while even simple 2D stitching isn't yet implemented (and stitching is more than just moving two terrains next to each other).

None of this is particulary hard, just time-consuming and tricky to integrate on top of the existing functionality. Given the time I have to work on this, it's very unlikely to happen in the near future.

[creative-brain]

With a proper guidence I would be willing to invest my time to write a simple plugin based on yours. It should contain only basic functionality though. You wrote it shouldn't be particulary hard but maybe there's not that much of work on this afterall. Will you please guide me?

[Zylann]

From what I could gather in a few minutes:

• There must be 6 times the data found in HTerrainData accessible with an extra index. This is what would have to happen with a stitching system as well.

• 6 sets of mesh instances must be managed within one planet node using rotations instead of just one set of quads. They may also be centered rather than using lower corner as origin, because a planet is more convenient to manage if the center is at the core.

• LOD must account for a spherical shape, as this creates distortion between world space and terrain space.

• Collisions cannot use a HeightmapShape. Instead, a bunch of smaller trimesh concave shapes must be used, and due to how big this would be, they might have to be streamed.

• Sculpting downward may have a limit when reaching too close from the planet's center.

• Cell raycasting needs to be rewritten differently because they ray would now become a curve due to the distortion, and the current algorithm requires it to be straight. Might need to be approximated. This feature is required for the editor painting and sculpting tools because using colliders in realtime is too expensive.

• Painting and sculpting needs to account for stitching. When painting at a border, up to 3 sides need to be edited at once. But in general, stitching means any number of patches can be modified if they intersect with the brush.

• The baking of normalmaps needs to account for stitching when fetching neighboring pixels, to prevent seams from appearing in the final shading. This has other implications regarding the available resolutions, explained in https://github.com/Zylann/godot_heightmap_plugin/issues/12#issuecomment-606237713

• The builtin generator needs a different implementation using seamless 3D noise from a normalized vector, instead of 2D noise. Feature proposals like island mode no longer work here.

• Full-terrain operations such as importing, generating or baking maps must take multiple textures into account instead of one.

• All ground shaders (classic4, classic4lite, lowpoly, multisplat16, multiplat16lite) need to be rewritten to spherify the terrain and support rotation applied to their side of the planet.

• Grass script and grass shaders need to be changed to take spherification into account as well

• The importer can't expect a single heightmap anymore. It's unclear yet if 6-sided planets are a common format found in external world generators. Cubemaps may be expected. Importing a panorama could also work, however it will have to be converted and there will be distortion near the poles.

• The plugin must detect which topology is selected for the current terrain (plane or sphere) to adapt the logic used by every tool, unless this is done through a separate plugin. In which case, every tool will have to be re-implemented with a few differences, or just not implemented if not supported.

This is not a complete list, and it's very high-level, there is probably way more details to think about.