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

21–30 of 44 posts

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

#21

Post by xandergos »

kelseyfrog wrote: post #20
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…

> in Infinite, Real-Time Terrain Generation My sincerest apologies. The submission disallowed the title in its entirety. It's generally unclear if the guidance for submitters favors omission or rewording. I take full responsibility for omitting those qualifiers.

No worries! It's worded fine as-is given the restrictions. Just wanted to clear up any misunderstandings.

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

#22

Post by xandergos »

noodletheworld wrote: post #17
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 irony of this paper is that the part that isn't geographic (towns, roads, fields, etc) which have non-random ordered structure are the parts that are most suitable for this approach.

Could be! I think maps are definitely the most interesting direction for future research to take.

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

#23

Post by stevefan1999 »

Not just this could improve Minecraft world generation (heh) but this could also have good use on 3D surface material generation as well, namely on the layering of different materials and generation using multi diffusions, if you look at the surface as a microscopic terrain

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

#24

Post by reactordev »

yunnpp wrote: post #19
reactordev wrote: post #10

Earlier quoted context omitted.

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…

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.

Which is what a sane terrain system would do. Just beyond the far plane you would load/gen the tile/chunk and as you got closer, increase the resolution/tessalation/etc. (or you start with high and each level away you skip vertices with a wider index march for a lower lod).

In any case, like I said, I welcome any new advances in this area. Overhang being the biggest issue with procedural gen quad terrain. Voxel doesn’t have that issue but then suffers from lack of fine detail.

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

#25

Post by daemonologist »

yunnpp wrote: post #19
reactordev wrote: post #10

Earlier quoted context omitted.

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…

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)

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

#27

Post by DonHopkins »

yunnpp wrote: post #19
reactordev wrote: post #10

Earlier quoted context omitted.

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…

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.

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

#28

Post by treyd »

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…

I think it's pretty neat that, in implementing this for the game, you wrote a terrain gen mod lets you call out to a server running as a separate process. I can't believe nobody had the thought of doing that before (to my knowledge), but it makes so much sense.

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

#29

Post by DonHopkins »

Imnimo wrote: post #3

I wonder what it would take to adapt a model like this to generate non-Earthlike terrain. For example, if you were using it to make planets without atmospheres and without water cycles, or planets like Io with rampant volcanism.

Since 1996, Ken Perlin has published a whole bunch of extremely cool Java applet demos on his web page, which he uses to teach his students at NYU and anyone who wanted to learn Java and computer graphics. One of his demos was a procedural planet generator!

I learned a lot from his papers and demo code, and based the design of The Sims character animation system on his Improv project.

https://mrl.cs.nyu.edu/~perlin/ (expired https cert)

https://web.archive.org/web/20001011065024/http://mrl.nyu.ed...

Here's a more recent blog post about a new one using WebGL, Dragon Planet:

https://blog.kenperlin.com/?p=12821

Here's another blog post about how he's been updating his classic Java applets by rewriting them in JavaScript:

https://blog.kenperlin.com/?p=27980

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

#30

Post by xandergos »

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.

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.
Post reply on HN