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.
I'm trying to make something along the lines of KSP (until I get bored or give up) and planet-scale terrain rendering is one major piece of the puzzle. At first it can seem daunting, but compared to creating a fictitious solar system from scratch, it is "basically" just a data visualization problem, since digital elevation models covering ≈99% of Earth (and significant portions of the Moon and Mars) are publicly available.
Godot doesn't have any explicit support for Wayland. The "linuxbsd" platform is implemented using classic X11 protocols (it doesn't even use a toolkit like GTK or Qt). Compatibility is handled by XWayland. I haven't had any problems though, aside from a bug I managed to fix about a year ago which caused dialog windows in the editor to arbitrarily minimize themselves.
There is a lot of commercial interest in ensuring X11 applications work on Wayland with high performance. This is what keeps the majority of the SteamOS game library working on modern Linux desktops. The pressure was even high enough to force Nvidia to come around.
I think there's initial wayland support as of recently (https://github.com/godotengine/godot/pull/57025).
Doing terrain of the whole earth is neat. I wonder if it will be easier than the process for using OpenStreetMap vector data which has to be split into tiles. Although at least OSM data is all one dataset (one file even). Not sure if there's a single earth heightmap? And you have to stitch together the triangles somehow I assume.
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.