[euleriancon]

I worked on something very similar for my master's degree.

The problem I could never solve was the speed, and from reading the paper it doesn't seem like they managed to solve that either.

In the end, for my work, and I expect for this work, it is only usable for pre generated terrains and in that case you are up against very mature ecosystems with a lot of tooling to manipulate and control terrain generation.

It'll be interesting to see of the authors follow up this paper with research into even stronger ability to condition and control terrain outputs.

[reactordev]

I came here to say this. My masters was on procedural generation. Perlin, fBm, etc. The things these noise functions have that an LLM doesn’t is speed. 1-D perlin is just a dozen or so multiplications with a couple random coefficients. The GPU can do 4-D Perlin all day long every frame taking up a 4096x4096x32 texture volume.

While I do like the erosion effects and all, having a few height texture brushes that have those features that you can multiply on the GPU is trivial. I still welcome these new approaches but like you said, it’s best for pre generation.

[yunnpp]

My masters was also on procedural generation. Now I wonder how many of us are out there.

At any rate, given that this paper divides the terrain in regions and apparently seeds each region deterministically, it looks like one could implement a look-ahead that spawns the generation on async compute in Vulkan and lets it cook as the camera flies about.

[anentropic]

I am curious - why would you want to keep generating the same perlin noise every frame? why not pre-generate the terrain?