Hacker News Reader

Comment by flohofwoe | Hacker News Reader

Very cool! A fairly popular terrain generation tool in gamedev which uses simulated erosion is World Creator: https://www.world-creator.com/

An additional (and tricky) requirement for procedural universe simulation games like Elite or No Man's Sky is that the terrain needs to be generated on the fly from a seed value, because there's not enough storage in the real world for pre-generated heightmaps in an infinite universe. Some additional notes how the presented algorithms deal with this requirement would be nice.

View on HN

I've always thought on-the-fly terrain generation for persistent worlds was a tricky approach, because once you ship the game and have player-created structures (bases, etc.), it's difficult to improve the algorithm. You're locked in, so to speak. As a game designer, you have three choices: call it done for the lifespan of the game; change it and disrupt the player base, maybe retconning with some kind of "apocalypse" event; or introduce algorithm versioning for new regions, meaning original areas will look more dated and simplistic as time goes on.

With instanced games like Minecraft, it's less of a problem, because players can choose when to move to a new world and get the advantages of new terrain algorithms.

Maybe not the end of the world (ha ha) but it's an interesting design issue and I'm curious how various teams will handle it.

You can use versioned seeds to have place for future versions of the generation algorithm.

As far as I understand Minecraft stores the chunks a player visits so that if the generation changes the chunks you've already visited stays, and it becomes an issue of solving boundaries. I don't know what Minecraft does there, but a plausible method would be to generate past the boundaries, and apply some merging process to make it mesh somewhat predictably if the generation changes.

An idea I'd love to see implemented (maybe someone has) is to apply a time element to the generator function where things change towards whatever the generator expects. E.g. new types of trees start growing, desert spreads or recedes etc.

You may want to then make player-placed blocks more resistant, but otherwise apply transformation functions to slowly migrate the terrain. You can apply that more aggressively to chunks the player rarely if ever visits. E.g. erode land that's too high. have trees grow etc. Some features then certainly will be noticeably "wrong" - e.g. a mountain suddenly growing - so maybe you make exceptions and just try to eat away at the differences you can plausibly change. Even if you can't change everything, you can at least try to use it to make things blend better. Couple it with running the old generator slightly further out from the user and you can mark those chunks as "unseen" and much more aggressively blend faster there.

The more finegrained info you store about what the player has actually seen, the more aggressively you can apply this.

> As far as I understand Minecraft stores the chunks a player visits so that if the generation changes the chunks you've already visited stays, and it becomes an issue of solving boundaries. I don't know what Minecraft does there...

Last time I've played in a world spanning multiple Minecraft versions, there were clear discontinuities (steep cliffs, minor water and lava floods) between areas that used different generators.

Obviously doesn't apply to infinite or "practically" infinite scenarios (like ED) I was under the impression that landscapes are generally not that costly in terms of storage.

AFAIK with systems like Unreal's landscape feature, the landscape is not stored to disk as meshes, instead the heightmap and layer masks (for terrain coloration) are stored as textures which are looked up at runtime in order to render the landscape.

Would assume this means its relatively lightweight to store large amounts of terrain to disk compared to storing it as textured meshes.

The only scenarios where this wouldn't be true is if your landscape texture is for example satellite imagery instead of a combination of texture samples blended together at runtime with masks. With Unreal Engine 5's Nanite there is also the the baked Hierarchical Level of Detail meshes which would add to the storage cost.

Notably landscape is excluded from Nanite since the path Epic wants to go down is to continue generating landscape mesh at runtime.

Would love to get some more insight into landscapes in general in game engines :)

Probably relevant to note that Minecraft stores the entire chunk once it's generated. (Of course it has to -- it's malleable.) And that's a lot more information than a height map and texture.

It looks like Star Citizen did something like procedural planet generation at different levels of detail depending on the camera. I'm assuming with a chosen, stable seed. And then a combination of randomly- and purposely-placed distribution of assets on the planet.

Star Citizen does the textures in Substance Designer, I would guess they're included in the game files and not regenerated at runtime.

I believe in addition to the terrain height/color maps, they generate textures that feed into object scattering so that rocks/trees/etc can be designed into the environments by the artists, but regenerated clientside to avoid needing to store millions of rock locations.

The low detail "from space" version used to be painted separately and then blend into the ground detail as you approach, but I believe the space view and the ground ecosystem mapping come off of the same map now.

EDIT: here's the video I'm remembering from https://www.youtube.com/watch?v=IfCc_aDNsAw

Whatever you think of the future prospects of the project, it's certainly technically interesting to keep an eye on

Ah, thank you. I had found the earlier 2016 video and information surrounding it, but failed to find this more recent information.

Depends on the scale. It might cost on the order of several MBs to store a km^2 at a moderate level of detail. For a small area that's relatively light, but becomes prohibitively large if you multiply by the hundreds of millions of square kilometers of a planetary surface...

Reply on news.ycombinator.com