View Full Version : Perlin Noise

05 May 2012, 04:09 PM
HI people.

Iīm programming a Perlin Noise generator.
Right now i have a big problem with the noise generator. It has to be a generator but not a random generator. That means, whenever you enter a number it gives you the same correspondant random , but always THE SAME.

Well. i got this from several websites. The rule is that these numbers must be primes:
float noise_function(int x)
x = x << 13;
float x2 = pow(x,x);
int t = ( x * (x * x * 60493 + 19990303) + 1376312589) & 0x7fffffff;
return 1.0 - ((float)t/1073741824.0);

Iīm supposed to give all X-axis values to this function, and it gives back a semi-random curve.
But it doesnīt , it obviously gives me a stairs-looking function. Like the one in the picture.

What the hell. As it is said here, it should be like this (first image).

Anybody know whatīs the problem?

06 June 2012, 07:51 AM
The most obvious thing is that your code isn't the same as the code at libnoise.

You have:
x << 13
and they have:
n >> 13.

You have (effectively):
newx = (oldx << 13) ^ (oldx <<13)
and they have (effectively):
newx = (oldx >> 13) ^ (oldx)

You have
x * x [pow(x,x)]
and they have
x bitwiseOR x [x^x]

You took
x^x ... and shoved it away to never use again
They took
(n>>13)^n ... and saved it back to n and used that in subsequent operations.

In short: you need to be told: different languages use different symbols for different things. The sample code is C++ so things like >> and ^ mayn't mean what you are familiar with. And you need to be more careful transcribing.

I don't know enough about the floating point formats and current compilers so you should check yourself that your using float where the sample code uses double isn't a problem. It looks like the return value is -1 .. 1 so you should be fine and just lose some fine grain that you probably weren't using anyway.

06 June 2012, 10:04 AM

You are right, the code in my sources is pseudocode. the problem is i donīt really get what they intend to do, so iīll have to figure it out...

But thanks for THAT!! it saves my day, i have just 4 days to finish this!

Iīll tell you if it worked.

06 June 2012, 10:45 AM
Now i realize how dumb i was. thanks :)
yeah. what a mess...

Now, what i ask is:

^ sometimes means POW, sometimes means Bitwise XOR. Considering the fact that i donīt really know what the funcion does, this makes it impossible. Iīll try different approaches. But well...

n >> 13 means shift left 13 bits (that means making it bigger, 13 times *2 right?)

Other pieces of code i found, they used << thatīs why i put it.

06 June 2012, 11:01 AM
At last!!

It works. I attach an image for you to see how deliciously random it is.

Thanks a lot gruhn! I was using Processing language for graphical artistic stuff. ^ xor existed, but wasnīt documented (O_o), but after adding these changes, i did it.

THANKS forever. You saved my day.

06 June 2012, 06:24 PM
Woo hoo, glad it worked.

Interesting that some examples had a left shift. I'd (completely and utterly) guess that would lead to aliasing in the output.

06 June 2012, 06:34 PM
Looking at your first sample I just remembered something irrelevant but possibly related...

Back in the day I wrote some BASICA code on a PC-AT for the 3 color CGA graphics. It was just supposed to fill the screen up with random colors in random locations. No memory what the actual code would be, but something like:

for i = 1 to 10000
x = random (0,320)
y = random (0,240)
c = random (0,3)
next i

At first it looked like it was working, but as the pixels started to fill in (this was back in the day, so 10,000 pixels was not instantaneous) it showed a diagonal stripe pattern of solid colors. If I threw in extra calls to random, the width and angle of the stripes changed. Evidence of a bad random number generator. What you have there is supposed to make noise... random numbers.

Not important, just interesting.

06 June 2012, 06:46 PM
> ^ sometimes means POW, sometimes means Bitwise XOR.

> n >> 13 means shift left 13 bits (that means making it bigger, 13 times *2 right?)

That's shift right because the arrows point to the right. Each shift is the same as a divide by two. So it's making it smaller: n / pow(2,13).

CGTalk Moderation
06 June 2012, 06:46 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.