🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Back to Graphics and GPU Programming

Procedural Landscape - Efficient Runtime Generation

PhillipHamlyn01 · 2023-09-09T08:34:34

I am a hobbiest developer and am doing a procedurally generated landscape. I want to share my general approach to see if it makes sense and to get any ideas on different ways to approach it. My current code does the following; I store heights at a frequency of 50m in a set of height files, then at runtime load them up and do a interpolation and inject some noise over the top to create a more naturlistic look. This gives me a detailed heightfield at any specific tile size. Alongside the low frequency height map I generate a texture coverage map at the same resolution based on noise plus biome information, plus the heighmap values (snow line. scarp etc). Again when I load this I use the probabilities held in the coverage map and resolve those into fractal parameters which give me a deailed coverage value at any specific tile size. Models on the landscape are provided with height positions at runtime via interpreting the detailed heightfield generated above. Models themselves (such as houses) can impact the heightmap, as can roads, rivers and other linear structures - and I generate a 'deformation map' overlay for both height and coverage, per tile at runtime and apply those to the first two steps to generate a finalized height and coverage set of data. My tiles are rendered from a fixed set of vertexes, with height coordinate picked up from the generated heightmap, and textured based on the coverage map. Each frame has around 120 tiles visible, with a pretty consitent triangle-to-pixel coverage depending on the view distance. This set of visible tiles is calculated on a background thread, and any missing tiles are picked up into a background “tile construction queue” Each frame may do two jobs - one rendering the existing landcape, and the second (depending on frame budget remaining) to pick up the construction of tiles from the ‘tile construction queue’ . I can 'afford' about 5 tile construction jobs per frame to keep around 40fps. I dont read back data to the CPU at runtime in general, although I do need to for one specific job where I generate random numbers of foliage models on a tile - but I push that to a frame-delay job and let multiple frames pass before reading it back to avoid GPU stall. My inability to construct more than 5 tiles per frame means that when the viewer hops into a new area it takes many frames to finally load an acceptible detail for them to view - until that point they are presented with low resolution tiles - it all looks a bit janky - nowhere near smooth and not at all convincing. Other than shunting a lot of the runtime construction of heightfields, coverage, deformation into a pre-stored set of (extremely large) data tiles, is there anything about this approach that can be improved ? Is doing procedural landscape tile-by-tile still a good approach, or do people use some other approach for this now ?

Graphics and GPU Programming Programming

Started by PhillipHamlyn01 September 05, 2023 10:45 AM

19 comments, last by JoeJ 9 months, 2 weeks ago

🎉 Celebrating 25 Years of GameDev.net! 🎉

Procedural Landscape - Efficient Runtime Generation

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

🎉 Celebrating 25 Years of GameDev.net! 🎉

Procedural Landscape - Efficient Runtime Generation

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines