Random Chitchat 2020-2024

[Greaper88]

fixed it. typically used for signature blocks, but eh

[tigerw]

There are multiple caches in the worldgen - biome cache, height cache, composition cache. Getting rid of them would be unwise, they save a LOT of work. For example the biome cache measured more than 90 % cache hit rate during startup world generation - that means ~10x speedup just thanks to the cache.

If I remember correctly, the terrain height is used in trees generator to see if the trunk and branches (all log blocks, in fact) intersect the terrain, if not, the tree is not generated; for this to work, it needs to see into the neighboring chunk as well (bent acacia trees' trunks and branches may go off-chunk). So no, it can't be removed, otherwise you end up with tree parts on chunk borders that generate in one chunk but don't generate in the other chunk. Can you imagine how long this took to actually get right?

If you want to threadpool the worldgen, you need to make the caches thread-safe and share them among all the threads / tasks.

That's a very helpful explanation, thank you.

I did some testing and after villages and trees are commented out the only thing that hits a cache is apparently height generation, reading 3x3 chunks' worth of biome data. This is to smooth out height transitions between biomes, right? Reminds me of the lighting thread, that also has a 9:1 read amplification when calculating one chunk xD

Do you think it would be, theoretically, feasible to generate the terrain first, say with suitably tuned 3D noise, and afterwards retroactively apply biomes based on the terrain height, a temperature map, and a humidity map? This way we can sidestep needing to smooth out height.

[tigerw]

Also for trees, I think it's even desirable for them to intersect and cut through terrain; they've had hundreds of years to do it, after all Then trees also wouldn't need to depend on other chunks' data.



Image source DevianTart

[tigerw]

The Generator.html article did mention the "generate terrain first" strategy as how the natural world does it, but didn't go into detail on why the inverse "biome-first, then apply terrain" approach was chosen.

[NiLSPACE]

I assume the tree generator still requires the height of adjacent chunks because if a branch goes outwards to another chunk it needs to know the height where the tree started.

[tigerw]

That is a good point, I guess if using terrain-first generation it could do a noise query at one point in the other chunk to figure out height.

[xoft]

Calculating biomes from terrain is incredibly hard.

Why are you so obsessed with getting rid of the caches? Just make them thread-safe, it will be fine.

[tigerw]

With independent chunks doing anything with them is embarrassingly parallel, but with a cache, barring just putting a big mutex on any access, a more fine-grained locking strategy would need finesse to get right. Even then, reading from it/writing to it won't be free.

Anyway, just some discussion about hypotheticals. Why is biome calculation from terrain super hard? Maybe even with humidity + temp data we don't have rich enough information to distinguish every biome supported?

[xoft]

How would you even go about calculating the biome from terrain? I assume by "terrain" you mean just the heightmap, or possibly shapemap (solid vs air in 3D), probably not the composition, because how would you compose without biome info?

I suspect you'd want to calculate at least slope from the height, which means calculating differences between neighboring heights, which means you need to calculate the terrain height for neighboring chunks in order to be able to calculate the slope at the edge of the chunk. And you're back to 9:1 amplification, but this time you're calculating terrain ahead of the biomes.

[NiLSPACE]

That is a good point, I guess if using terrain-first generation it could do a noise query at one point in the other chunk to figure out height.

Keep in mind we're not generating the height anymore but the shape. From that shape the height is retrieved. I believe the shape is actually generated much smaller and later upscaled to fit an entire chunk, so you might have to generate the entire shape of adjacent chunks.