Live data from Hacker News

Terrain Diffusion: A Diffusion-Based Successor to Perlin Noise

arxiv.org

41–44 of 44 posts

Re: Terrain Diffusion: A Diffusion-Based Successor to Perlin Noise

#41

Hi everyone, I wrote this paper. Cool to see it has been posted here already. I want to clarify some points on things other people have mentioned: - This architecture is not as fast as Perlin noise. IMO it is unlikely we will see any significant improvement on Perlin noise without a significant increase in compute, at least for most applications. Nonetheless, this system is not too slow for real-time use. In the Mine…

1) A system that needs _seconds per tile_ is not suitable for real-time anything imo.

The irony is that you explicitly posited your thing as a successor to Perlin noise when in fact, it's just a system that hallucinates detail on top of Perlin (feature) noise. This is dishonest paper bait and the kind of AI hubris that will piss off veterans in the scene.

2) I'm also disappointed that nowhere is there any mention of Rune Johansen's LayerGen which is the pre-AI tech that is the real precedent here.

Every time I see a paper from someone trying to apply AI to classic graphics tech, it seems they haven't done the proper literature study and just cite other AI papers. It seems they also haven't talked to anyone who knows the literature either. https://runevision.com/tech/layerprocgen/

3) >The top level input is perlin noise because it is genuinely the best tool for generating terrain at continental scale

This is a non-sense statement. I don't know what you are thinking here at all, except maybe that you are mistakenly using "Perlin" as a group noun for an entire style of functions.

Perlin has all sorts of well-known issues, from the overall "sameyness" (due to the mandatory zero-crossings and consistent grid size) as well as the vertical symmetry which fails to mimic erosion. Using it as the input to a feature vector isn't going to change that at all.

The idea of using plate tectonics is much better, but, vastly _different_ from what you have done. And btw, every plate tectonics simulation that I've seen does not look convincing. If you treat it as a simple transport problem, the result just looks like a Civilization 1 map. But if you want to treat it seriously, then the tectonics have to be the source of all your elevation changes, and not just some AI hallucination on top afterwards. The features would all have to make sense.

Your abstract states that classic terrains are "fundamentally limited in coherence"... but even to my non-geologist eye, your generated heightmaps seem incredibly blobby and uncanny. This makes me think that a real geologist would immediately spot all sorts of things that don't make any sense. For example, if you added water and rivers to the terrain, would it work, or would you end up with non-sense loops and Escher-like watersheds?

(mostly I'm disappointed that the level of expertise in AI tech is so low that all these things have to be pointed out instead of being things you already knew)

Re: Terrain Diffusion: A Diffusion-Based Successor to Perlin Noise

#42

Earlier quoted context omitted.

I think it's catnip for programmers, myself included. (See also: boids, path traced renderers, fluid simulations, old fashioned "generative"/plotter art, etc. - stuff with cool visual output)

Boids is so satisfying!

Boids, Game of Life, Genetic Algorithms, Pixel Shaders...

All so satisfying to play with.

One of my favorites was when I was sure I was right about the Monty Hall problem, so I decided to write a simulator, and my fingers typed the code... and then my brain had to read it, and realize I was wrong. It was hilarious. I knew how to code the solution better than I could reason about it. I didn't even need to run the program.

Re: Terrain Diffusion: A Diffusion-Based Successor to Perlin Noise

#43
post #41

Hi everyone, I wrote this paper. Cool to see it has been posted here already. I want to clarify some points on things other people have mentioned: - This architecture is not as fast as Perlin noise. IMO it is unlikely we will see any significant improvement on Perlin noise without a significant increase in compute, at least for most applications. Nonetheless, this system is not too slow for real-time use. In the Mine…

1) A system that needs _seconds per tile_ is not suitable for real-time anything imo. The irony is that you explicitly posited your thing as a successor to Perlin noise when in fact, it's just a system that hallucinates detail on top of Perlin (feature) noise. This is dishonest paper bait and the kind of AI hubris that will piss off veterans in the scene. 2) I'm also disappointed that nowhere is there any mention of…

> And btw, every plate tectonics simulation that I've seen does not look convincing.

It's an amazing problem! I haven't spent much time on it - maybe 20-30 hours spread out over several years - but it _is_ something I come back to from time to time. And it usually ends up with me sitting there, staring at my laptop screen, thinking, "but what if I... no, crap. Or if we... well... no..."

TBH it's one of the things that excites me, because it makes it clear how far we still have to go in terms of figuring out these planet-scale physical processes, simulating them, deriving any meaningful conclusions, etc. Still so much to learn!

Re: Terrain Diffusion: A Diffusion-Based Successor to Perlin Noise

#44
post #38

Hi everyone, I wrote this paper. Cool to see it has been posted here already. I want to clarify some points on things other people have mentioned: - This architecture is not as fast as Perlin noise. IMO it is unlikely we will see any significant improvement on Perlin noise without a significant increase in compute, at least for most applications. Nonetheless, this system is not too slow for real-time use. In the Mine…

Cool work, congratulations. Why did you put "real-time" in the title though when generation takes > 7 seconds?

The author points out that the sheer scale of what you generate in that 7 seconds is so vast that you’ll have plenty of time to generate the next tile even when moving at extreme speeds. So your only problem is the first tile, which you can pre compute at the very beginning.

Latency vs Throughput

Post reply on HN