Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Terrain Diffusion: A Diffusion-Based Successor to Perlin Noise

arxiv.org

Post reply on HN
Print view View original

31–40 of 44 posts

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

#31

Post by DonHopkins »

lawlessone wrote: post #13
euleriancon wrote: post #11

Earlier quoted context omitted.

In practice you can use 2d generation on spheres with simple UV mapping techniques. Your pixel height becomes distance from the sphere origin.

Will it not get all bunched up near the poles though? and maybe have seam where the ends of the tiles meet? edit: Perlin noise and similar noise functions can be sampled in 3d which sorta fixes the issues i mention , and higher dimensions but i am not sure how that would be used.

Yes, you can use a 3d Perlin noise field and sample it on the surface of the sphere, to get seamless texture without any anomalies at the poles or projection distortion. That applies to any 3d shape, not just spheres -- it's like carving a solid block of marble. And use 4d Perlin noise to animate it!

It's easy to add any number of dimensions to Perlin noise to control any other parameters (like generating rocks or plants, or modulating biomes and properties like moisture across the surface of the planet, etc).

Each dimension has its own scale, rotation, and intensity (a transform into texture space), and for any dimension you typically combine multiple harmonics and amplitudes of Perlin noise to generate textures with different scales of detail.

The art is picking and tuning those scales and intensities -- you'd want grass density to vary faster than moisture, but larger moist regions to have more grass, dry regions are grassless, etc.

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

#32

Post by yunnpp »

DonHopkins wrote: post #27
yunnpp wrote: post #19

Earlier quoted context omitted.

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.

Now days there are a whole lot of people procedurally generating their masters degrees, but that's a different thing entirely.

lol, this got me good.

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

#33

Post by treyd »

noodletheworld wrote: post #9

Mm. This paper makes it hard to understand what they've done. For example: > MultiDiffusion remains confined to bounded domains: all windows must lie within a fixed finite canvas, limiting its applicability to unbounded worlds or continuously streamed environments. > We introduce InfiniteDiffusion, an extension of MultiDiffusion that lifts this constraint. By reformulating the sampling process to operate over an effe…

They built a system that can be trained on real-world data so it can output more real-world-like data. It's much more sophisticated than what you could hand-tune with Perlin noise and can have coherent terrain features across multiple scales which are harder to do in classical Perlin noise.

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

#34

Post by tonyarkles »

daemonologist wrote: post #25
yunnpp wrote: post #19

Earlier quoted context omitted.

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.

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!

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

#35

Post by MindSpunk »

xandergos wrote: post #30
lawlessone wrote: post #13

Earlier quoted context omitted.

Will it not get all bunched up near the poles though? and maybe have seam where the ends of the tiles meet? edit: Perlin noise and similar noise functions can be sampled in 3d which sorta fixes the issues i mention , and higher dimensions but i am not sure how that would be used.

I've thought about this before, and I think there is some way you could find to do it. For example, you could generate on the mercator projection of the world, and then un-project. But the mercator distorts horizontal length approaching the poles. I think it would be complex to implement, but you could use larger windows closer to the poles to negate this.

You're still going to run into problems with mercator because under mercator the poles project to infinity, so you'd need an infinitely large texture or you special-case the poles. Many renderers do this so it is viable!

There isn't a zero tradeoff 2D solution, it's all just variations on the "squaring the circle" problem. An octahedral projection would be a lot better as there are no singularities and no infinities, but you still have non linear distortion. Real-time rendering with such a height map would still be a challenge as an octahedral projection relies on texture sampler wrapping modes, however for any real world dataset you can't make a hardware texture big enough (even virtual) to sample from. You'd have to do software texture sampling.

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

#36

Post by semi-extrinsic »

xandergos wrote: post #14

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…

The paper is cool, and this is not a criticism, but Fig. 4 gives strong "draw the rest of the owl" vibes.

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

#37

Post by liamzebedee »

I wonder if you could use this to generate the fractal terrain by the ocean like in Sydney. We already have "artificial reefs". We have built beauty in the build environment (architecture), some in the natural environment (gardens, forests), but comparatively less when it comes to the ocean.

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

#38

Post by sieste »

xandergos wrote: post #14

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?

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

#39

Post by Fraterkes »

I’m not sure if I understand the usecase: for a lot of generated worlds (of eg games) you don’t just want downsampled “realistic” topology, you want specific stylization and fine-grained artistic control. For those cases this is worse than “raw” noise. If all you wanted was to generate plausible, earth-like maps, Gemini, or Gpt would do a comparable job (with more control Id wager)

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

#40

Post by anentropic »

reactordev wrote: post #10
euleriancon wrote: post #6

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…

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 t…

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