LODding Terrain for 3D in Godot
- Edited
I certainly get it, no worries. I mean, we'd obviously need some deeper C++ understanding here that I did not mention. Nevertheless, if you like to dive in, there you go. Have fun :-)
Here is an open source C++ project and they have a "Procedural terrain generator". Might be interesting.
No worries !
- Edited
Refactoring. Pls. stand by :-/
Am currently simplifying the conversions between raster space, the space represented by the raster of the spacial data structure which are basically integers for the positions in heightmap textures, and world space, which is the usual floating point stuff one deals with in any 3d application.
Before there was the possibility to extend a terrain in all directions, but that lead to conversion problems I could not really wrap my brain around. Si si, somos aficionados ...
So, in future I will start any quad tree's raster at 0,0,0 and extend it out to max, which is limited to power of 2 sizes. That makes things considerably easier, also when I think of presenting everything to people who probably just want to slab in a bunch of textures and expect it to just work.
Since I also have a new home to build, this may all take a bit longer.
Lesson learnt: Do not say it will be done until it is done.
- Edited
The last overworking got me one step forward. That's from the rim of the canyon where I stood :-)
Never mind the flat shading. Shown is one terrain tile made from a 16bit heightmap 4096*4096 pixels, but it works well up to a tile size of the maximum the graphics card can digest. My test data is SRTM (Shuttle Radar Topographic Mission) data, shown is a part of the Himalaya, distance between two posts is about 90m. Purposefully exaggerated to better show the boxes that cover the terrain for view frustum selection.
The white lines are bounding box of the whole tile, the light blue ones are all the boxes of each node of the spatial data structure, the coloured ones are the per frame selected lod levels as seen from camera position.
Sending two 0s away gives us:
with the bounding boxes of the lod levels.
A close-up of a valley gives an impression of what the terrain lod is planned for (no planetary curvature yet, or any sophisticated shading, that's future music for now):
- Edited
So, the base algorithm is finally working.
https://github.com/BaronVerde/cdlod
Tagging @Haystack , whenever you like.
A 4k heightmap texture comes with it. Ask me if you want a 16k texture, or search SRTM 90m data download, select the region you want, choose ARC ASCII as format, and see my other rep srtm-converter for how to generate .png tiles from the SRTM ASCII data. Also, try noise textures you may have somewhere. Eventually tweak the HEIGHT_FACTOR in settings.h.
Loading of a large heightmaps takes a few seconds, though that's going to change. Please mark the b* and krams directories under src as exclude from compile or you get multiple definition errors. These are just backups from working states.
It is only a single heightmap texture for now, and only flat vertex shading. No cosmetics. If you use an own heightmap, make sure it is 16bit-grayscale png of power-of-2, edit RASTER_MIN and MAX values in src/applications/cdlod/settings.h, and add a .bb text-file next to the heightmap texture. Look into src/renderer/renderer.cpp and change the filename there. Don't add .png. Attention, though there is a vector defined there, only one texture is loaded.
Next steps:
Comb the code. There are quite a few implicit conversions I must get rid off. - done -
Texture compression. - scrubbed, using half floats and uint16_t -
Parametrize and correctly calculate raster-to-world sizes and distances. My poor brain ...
Abstract texture types and bit depths and quite generally heightmap sources.
Build a data structure for heightmaps, and load/unload them asynchronously.
Render relative to eye. That means an own terrain camera.
Then: try to get it into the Godot scene tree.
Then proper texturing, rendering, evtl. cascaded shadow maps that fit the lod levels and ranges, collisions, placing of game objects.
Need a beer.
- Edited
Effect of a resolution multiplier that equally divides the space between two heightmap posts and thus "fakes" a higher resolution than there actually is. It is just a linear interpolation. Considerably improves visual experience (look at the detail in the distance), raises number of triangles rendered, and adversely affects performance :-/
4*resolution multiplier, 11 million triangles per frame, frame rate drop from around 5000/s to 1000/s compared to the other screenshots which are from the same heightmap.
- Edited
Pixophir Considerably improves visual experience ... and adversely affects performance :-/
Look, sometimes it's worth it, ok?
1ms vs 0.2ms is not a big deal.
Certainly. Specifically comes in handy when using procedurally generated maps from noise or fractals. And there are other methods to control the density in a distance. Otoh, proper shading isn't yet done, nor shadows. So, it will not stay that comfortable.
But of course, having a higher resolution heightmap right from the start would be best. The resolution in the example is also not exactly game-friendly, it is around 90m between posts. A small thorpe or village would just be a speck from that perspective.
Have also experimented with different methods to calculate the normals, which is done on the fly in the vertex shader so I don't have to do normal maps for the terrain. Will offer several methods further down, to control better the "crispyness" of the image.
Huge work. Unfortunately, all the landscape generators do not take into account the principle of the formation of rivers. Rivers are not just irregularities filled with water. Until hydrodynamics in terrain formation is implemented, even the best generators will only be able to automatically create a lunar landscape. Or require a lot of manual revision.
- Edited
Thanks :-) Yeah, my stuff it just a renderer for heightmap images that stem from elsewhere. I will do an interface that people can use to adapt their own heightmaps.
But there is quite some work on modelling of drainage systems. Look at this, for instance:
https://hal.archives-ouvertes.fr/hal-01339224/document
Update:
OpenGL built-in texture compression for heightmap (RGTC) is scrubbed. Too lossy.
Pixophir But there is quite some work on modelling of drainage systems. Look at this, for instance:
https://hal.archives-ouvertes.fr/hal-01339224/document
This is excellent work! But as far as I understand, it remained at the level of the concept and did not get any practical questioning. And that's too sad.
They have an implementation, they write.
And there's more work out there. I believe Outerra has made something similar. And I have read papers in which they try to mimic plate tectonics. Don't have the time to gather the information again.
Bit I'd say the algorithm in the above paper could be implemented right away.