Spherical Terrain questions

Is planetary terrain on the backlog list of features?

I mean it would be an evolution of that:

1. terrain is used as usual, but have the curvature applied to them
2. we can manage neighbour on a surface rectangle/square grid, the surface control local curvature of the grid.
3. we can manage surface grid's neighbors to deal with pole.
4. the end data structure support a graph of neighbor of surface which contain grid which contain terrain. Ie we can compose arbitrary shape made of quad surface, which itself is divided in terrain grid cells.
5. the whole surface graph is checked against to know which surface to query and which terrain cell to display.

Workflow:
A. terrain are edited as usual, or created through code
B. terrain are assigned on a per surface basis, we can move reference on the grid to realized terrain, other are potentially created through code using a query or are simply vanilla terrain. Basically for each cells in the grid we render, we verify if there is a reference, else we use a script procedure to display the terrain, if no script is provided, vanilla terrain is displayed (potentially with random noise).
C. surface are deformed and stitch to create big volume. By code or by hand. Potentially using a starting shape (cubesphere) in which we can select and extrude surface to create more complex volumetric shape.

 

Last heard it's not.

But if you wanted to get this working within the next decade:

The Unity terrain system does bake out far (combined) maps so you'd be able to apply these to a spherified cube mesh for LODs and space, then when you enter the atmosphere, dissolve the LOD spherified cube mesh out and reveal the terrain. So really, what you are asking for is probably better like this. Better performance, better looking, and achievable with Unity now.

Real terrain that can be mapped to any shape (not just spheres - since people will be asking for asteroids and more):

What you are asking for is not a good idea for the following reasons you probably know:

• Seriously bad performance
• Require complete rewrite of terrain
• Require completely new collision
• Require all Unity systems including navmesh, to support sphere
• People might not want a perfect sphere...
• They probably want holes too...
• Then they'd want Unity's other systems to work with it... and all asset store tools

I think given the scales you are talking about, and the sheer amount of support engineering you'd need, it's not unreasonable to crossfade to terrain at a certain height.

 

I think it's an excellent topic, been researching it myself on and off over the years. That's where I am at re: using current terrain and relying on existing tools/features

 

Some form of terrain streaming like Google earth (with curved surface) would be great.

Also, does it support Continuous LOD (CLOD) like this?
http://casual-effects.blogspot.com/2014/04/fast-terrain-rendering-with-continuous.html

 

That wouldn't solve stitching between the cube face, you need an explicit structure.and there is a lot of problem into fitting what's essentially a flat displaced surface onto curvature (because it's not just a 'Y' displacement alone).

 

Yeah, I see what you mean. Here is quite nice tutorial how to get a sphere from cube:
https://catlikecoding.com/unity/tutorials/cube-sphere/

But then it would break the heightmap terrain standard when vertices are moved horizontally. But maybe this bending could be achieved by just adjusting it through shader on the top of the existing terrain shader?

 

That's why I proposed a difference between "surface" and "terrain" cells, the surface is the underlying implicit support, terrain still an heightmap. Using surface allow to generalize beyond sphere, because the problem remain the same for many topology (pole).

 

Hmm, I guess the next thing to this could be to allow moving heightmap vertices horizontally but keeping number of vertices the same in both x and z axis. This would allow to apply any curvature later, which would be just shifting vertices. I think this would solve both spherical terrain problem as well as possibility to have caves. However, this would break GetHeight, GetSteepness and many other functions. It wouldn't be possible to tabulate horizontal positions as horizontal cell sizes would not be the same. As a result, it would probably damage performance as instead of fast grid tabulation you would need to use nearest neighbour searches to find the closest cells from which to measure heights, slopes, etc. So I guess if going that way, probably both modes would need to exist, the existing standard heightmap with conserved horizontal cell sizes and the new adjustable cell sizes mode with new functions...

 

You would use the derivative of the surface like we do in shader.

 

That's correct. But before we can use a derivative, we need to find where the query point would be over the terrain. If cell sizes are the same, we can map indices through tabulation and access heightmap vertices through these indices, i.e.

Code (CSharp):

1. indexX = (int)((worldX - terrain.transform.position.x) / terrain.terrainData.size.x)*resolutionX

If every cell has different size, we can't use this estimation to find over which cell is the query point and need to use something else, i.e. neighbour finding, ray-casting, etc. Imagine we want to place a tree on the terrain. Random generator generates x and z coordinates. For y it would need to get a height from heightmap in order to place a tree in a correct position.

 

will be great for gamedev, if Unity team continue work on big spherical terrains support. Maybe in future releases...

 

Why not making a matrix of pyramids with a hexagone as a base, it can be easier to create many terrains with calculated rotations and positions of a dice. The pyramid is to use thalès when you want to create a hole in your sphere.
But... How can we do this ?