Problem with diamond-square algorithm

[David Makin]

I took a little time to learn perlin noise, but I'm a little disappointed.
Hopefully I'm doing something wrong, but perlin looks much worse than d-s.
The artifacts are pretty clear with most settings I put it on.

Any tips? Maybe try a random generator that isn't the default one?
If so, what might be a good one to use with real-time in mind?
Edit: Just tried the "multiply with carry" method and didn't see a difference so I don't think randomness is creating artifacts.

Go to the UF formula database:
http://formulas.ultrafractal.com/
Use the browse option to find Damien Jones' colouring formula, dmj.ucl, and in that take a look at his Fractional Brownian Motion formula (dmj-fBm). Then either in UF or using your own implementation try the following settings for the user parameters:

Offset (0,0)
Scale 0.6
Rotation 0
Scale step 0.6
Rotation step 43
Octaves 8
Exponent 1.9

And from the basic coordinates as input (e.g. in UF using mt.ufm:pixel as the fractal formula) you should get something like this:


http://www.fractalforums.com/index.php?action=gallery;sa=view;id=9026

[xenodreambuie]

I took a little time to learn perlin noise, but I'm a little disappointed.
Hopefully I'm doing something wrong, but perlin looks much worse than d-s.

This is a 2d slice of 3d noise.
The artifacts are pretty clear with most settings I put it on.

Any tips? Maybe try a random generator that isn't the default one?
If so, what might be a good one to use with real-time in mind?
Edit: Just tried the "multiply with carry" method and didn't see a difference so I don't think randomness is creating artifacts.

For the Perlin noise, it looks like you're using the old version with the S-curve 3x² - 2x³, which is not continuous in the second derivative. That produces the slight creasing at peaks and troughs. Instead, change the blending function to x*x*x*(x*(6*x-15)+10).

When adding octaves of Perlin noise, you also want to add some big offsets to the position to avoid correlations near the origin.

If you're using the standard hash table method for Perlin noise, it doesn't use many random numbers so the generator isn't important.

For a good generator, I used to use Mersenne Twister and had no problems with it, but switched to complementary multiply with carry. Make sure it's a full CMWC, not just MWC. To pass the lottery standard tests, as well as being suitable for high resolution chaos game fractals, it's not enough to have a long period and low correlations. It's also necessary to produce all possible sequences of a given length somewhere in the cycle. George Marsaglia's CMWC generators do this, and are simpler than Mersenne Twister and more flexible for seeding or customizing.

[Syntopia]

If you want to try with GPU acceleration, you could try McEwan's noise functions: http://www.lighthouse3d.com/2011/03/noise-for-glsl/

I did some tests a few months ago, and was able to do some 4D Perlin-like noise ray marching in real-time:
<a href="http://vimeo.com/moogaloop.swf?clip_id=28424494&amp;server=vimeo.com&amp;fullscreen=1&amp;show_title=1&amp;show_byline=1&amp;show_portrait=0&amp;color=01AAEA" target="_blank">http://vimeo.com/moogaloop.swf?clip_id=28424494&amp;server=vimeo.com&amp;fullscreen=1&amp;show_title=1&amp;show_byline=1&amp;show_portrait=0&amp;color=01AAEA</a>

Notice, that it doesn't look even remotely like a landscape (only two different scales of noise were used). You probably need to combine many scales to get something landscape-like.

[kronikel]

@ David
Very nice results but I'm not familiar with that type of code and it looks like it might be over my head

@ Xeno
I believe the hash table method is where you have the array of 0-255 in random order?
I'm using a different method which I found here - http://www.gutgames.com/post/Perlin-Noise.aspx
I just used common sense / analogy to make it 3D
I don't notice anything that looks like "3x2 - 2x3" though
Maybe this would be a better approach? http://lotsacode.wordpress.com/2010/02/24/perlin-noise-in-c/

@ Syntopia
GPU noise would be ideal for me, but as of now I don't know how to do anything on GPU

[kronikel]

I implemented the hash table version and I guess that was my only problem.
Very smooth (only 3 octaves) but looks great =)

Only down side is I'll have to figure out how to add the parameters I had in my first code such as frequency, amplitude, number of octaves, etc.

And here it is on my planet -

3 fps =/ but at this point I have no optimization at all other than a clunky LOD algorithm I made up in one day.
And it's at about 200,000 vertices
But it's coming along and I owe some thanks to the people here who have helped me out

[xenodreambuie]

@ Xeno
I believe the hash table method is where you have the array of 0-255 in random order?
I'm using a different method which I found here - http://www.gutgames.com/post/Perlin-Noise.aspx
I just used common sense / analogy to make it 3D
I don't notice anything that looks like "3x2 - 2x3" though
Maybe this would be a better approach? http://lotsacode.wordpress.com/2010/02/24/perlin-noise-in-c/

The first link there is not "Perlin" noise. It's a poor interpolation between random values. This type is generally called "value" noise, and even with better interpolation, has visible axis alignment. (I wouldn't recommend his method for cellular noise either - sqrts in a nearest neighbour search!)

The second link is the standard (original) Perlin algorithm, with the hashed array. Specifically, it's Perlin gradient noise, because it calculates random gradient values at each lattice point, and the result is less axis aligned than value noise. You can also modify (or add a function) to produce Perlin value noise by just interpolating the values instead of the gradients.

The smoothing function at the bottom is as I mentioned, x * x * (3 - 2 * x); this is the part that you can improve with the fifth order polynomial. The difference is more visible in 3d than 2d.

[kronikel]

Here is a comparison of two different methods

The one with the blue dot is cosine interpolation and the fifth order polynomial,
the other frame is linear interpolation and the regular order polynomial.
It seems to give it more distinct features.
I haven't seen the effects it has in 3D though.
The blue dot frame costs about 5-10% more time.
I'll have to see 3D before I can tell if it's worth it.

Edit:
After messing with it a bit it looks like linear interpolation actually looks better and the fifth order polynomial looks better.
Also with 3D noise, if you add the octave you are on to your z coordinate for each octave iteration it looks a bit better and reduces some of the repetition.

[xenodreambuie]

Here is a comparison of two different methods

The one with the blue dot is cosine interpolation and the fifth order polynomial,
the other frame is linear interpolation and the regular order polynomial.

What you want is linear interpolation and smooth with the fifth degree. This gives the smoothest curve for a single octave. It's noticeable on either a 3d surface or a 1d plot.

[Syntopia]

A small test with the GPU Ashima-noise functions: Nine different scales of noise added together for a 2D heightmap, and still realtime (GPU raytracing with no polygons).

Two different noise functions are shown.

[David Makin]

Nice !
Am just trying to find time to do something similar, but also to try an alternative method that I think will be a lot faster (in shader fragments but is a lot slower in UF).

[David Makin]

Was just trawling my old posts to cross-reference something in the current LRIFS thread and came across this which is (I think) relevant here:

http://www.fractalforums.com/programming/linearising-a-normal-distribution-%28for-the-math-geeks%29/msg13802/#msg13802

[setec]

kronikel, solution is to extend terrain with virtual space as show on the attached picture;
blue - virtual space (no need to allocate mem for it)
red - resulting terrain
green - seed poles

use for blue height function where result is avg of seed poles + random deviation based on roughness