Downloaded a sample DEM tile from the NASA SRTM dataset, scaled it down to 1024x1024, and used it to control the height of a 1024x1024 grid of vertices. I am kind of new at this, but 2,093,050 is definitely a new personal record for number of triangles put on the screen... by a LOT. The normal generation needs a bit of work, but it is not too far off. Doesn't make sense to waste too much time getting it nailed down for a proof of concept.
Show
Before I start messing around with LOD algorithms, I need to get my hands on the entire dataset and figure out a pipeline to pre-process it in QGIS.
Oh shit, you're right! It looks like they're rolling it out for 4.3, so I haven't tried it yet, but I'm looking forward to it.
The closest thing to a (free, publicly available) whole-earth heightmap is the ASTER GDEM dataset. Like the SRTM dataset, it comes in the form of one degree latitude by one degree longitude GeoTIFF tiles. This raw data is simply too much to integrate or ship with a game. The SRTM data takes up 73 GB compressed (assuming I got all of it). The ASTER data, covering more of the Earth at the same resolution, likely takes up more.
This data needs to be processed before it can be used in a game. Typically this is done using GIS software to integrate data from various sources, as well as manage features other than elevation (like water coverage, land classes, etc). There is a lot of interesting information about this in the FlightGear wiki, documenting their long transition to what they call "World Scenery 3.0." They are doing a lot more advanced stuff though, like integrating OSM features like streets, bridges, buildings, and landmarks, as well as landclass data from various datasets. I am just trying to build a heightmap at this stage.
Their approach is also rather different. They use a quad-tree structure to load in pre-built meshes at various LODs, and switch to an orbital renderer above a certain altitude. Kerbal Space Program does something similar, but they use 6 quad-trees representing faces of a cube and project them onto a sphere. They still use an alternate rendering mechanism in orbit which scales the planet down to 1/6000 size to overcome floating rounding errors.
What I'm trying to do is use a Geometry Clipmap approach instead, where all the height data is stored in textures and realized by the vertex shader. Geometry clipmaps are commonly used in modern large scale open-world games like Witcher 3 or Tears of the Kingdom. The trick is generating an LOD mesh where each vertex lines up exactly with a sample in the texture. This is done mostly using flat, rectangular worlds, but a few algorithms exist to adapt this method to spherical worlds. One thesis explains a method using octahedral geometry, abstracting each pair of triangles into a rectangle (though it's actually a rhombus), and another paper expands this concept to icosahedrons.
At this stage of the game, I think the use of tessellation shaders could go a long way towards optimization, but Godot doesn't support them, and they are a relatively new feature found only in modern desktop GPUs.
Very cool. It's interesting how many ways of implementing terrain there are. The height maps definitely have the disadvantage of not being able to represent overhangs and stuff though. I assume that stuff has to be added in using a different mechanism. It definitely makes sense that Witcher 3 used that because it has very plain and hilly terrain. But that would work well for data that is already a heightmap like satellite terrain data.
Yeah, I believe the way this is done is by creating holes in the heightmap (for caves) and positioning conventional 3D assets manually to match up with them (for caves or simple overhangs in general). In theory you should be able to encode holes right in the heightmap texture by encoding them as NaN, INT_MAX, or something along those lines, but a vertex shader is only capable of moving vertices, not deleting them. Like generating geometry, discarding geometry apparently requires the use of a tessellation shader, though some hacks can potentially be achieved in the vertex shader - e.g. swapping pairs of vertices to reverse the winding order of their triangles and trigger back-face culling. The trick is figuring out how to do that while avoiding conditional branches, which apparently ruin performance. Fortunately this isn't my problem.