KdotJPG / OpenSimplex2

Successors to OpenSimplex Noise, plus updated OpenSimplex.
Creative Commons Zero v1.0 Universal
559 stars 53 forks source link

IndexOutOfRangeException using 2D Simplex Noise #3

Open BBlayne opened 4 years ago

BBlayne commented 4 years ago

When I try to get noise using the 2D function, I get an out of range exception.

Here's my usage:

        float max = 0.0f;
        float min = 0.0f;
        float sum = 0.0f;

        float frequency = scale;
        float amplitude = 1.0f;
        float x = xin;
        float y = yin;
        for (int i = 0; i < octaves; i++)
        {            
            x = x * frequency;
            y = y * frequency;
            float v = (float)noiseGenerator.Noise2(x, y);
            sum += v * amplitude;
            max += amplitude;
            min -= amplitude;

            frequency *= lacunarity;
            amplitude *= persistance;
        }

        return (sum - min) / (max - min);

In particular when "scale" is at sizes at around 20 or so or higher.

e: The issue also occurs if I attempt to use Classic Simplex Noise.

KdotJPG commented 3 years ago

Interesting. Is this the OpenSimplex2F or OpenSimplex2S noise? I do plan on completely replacing the implementations of 2D and 3D in both, with faster non-lookup-table based versions soon. 4D will follow after. That should resolve any issues like this in addition.

BBlayne commented 3 years ago

I'm unfortunately not sure as I moved on to a different Simplex noise library (FastNoise iirc?), my guess is probably 2F because it was first in the list and probably the first one I clicked on and didn't explore the other. But that's good to hear though and I hope I helped!

KdotJPG commented 3 years ago

Oh - in that case I suggest using FastNoiseLite. Its simplex has better gradient tables than original FastNoise, so it doesn't have as many diagonal patterns. https://github.com/Auburn/FastNoise/tree/FastNoiseLite

It's actually the lib that uses the faster OpenSimplex2(S) implementations that I've been working on. No Java port yet, but from the looks of it you're using C# anyway I think.

CreamyCookie commented 3 years ago

@KdotJPG

First of all, thanks for both OpenSimplex and OpenSimplex2! They're awesome.

I do plan on completely replacing the implementations of 2D and 3D in both, with faster non-lookup-table based versions soon. 4D will follow after. That should resolve any issues like this in addition.

Any news on this, or is will it not happen? (Also fine.)

Would you mind explaining why it is faster?

KdotJPG commented 3 years ago

Wow I didn't realize it was that long ago that I made that comment! I started it finally. Non-final updated OpenSimplex2S C# here: https://github.com/KdotJPG/Noise-Extras/blob/master/alternative_implementations/OpenSimplex2S_Stateless.cs

Has the 2D and 3D versions, not 4D yet. Part of why I think they're faster is that they directly mimick the lookup table scheme, but without the overhead of the table and all the reference lookups. I also think the branches are easy to predict because the conditions can evaluate the same for many successive noise evaluations.

I don't think you'll see any index errors with it either. There are no array lookups to traverse the noise structure or compute the hash, and the gradient vector index lookup is tightly limited by a bitmask.

CreamyCookie commented 3 years ago

not 4D yet

4D would be great as that's the one I'm using (and the math definitely goes over my head)

I think they're faster is that they directly mimick the lookup table scheme, but without the overhead of the table and all the reference lookups. I also think the branches are easy to predict because the conditions can evaluate the same for many successive noise evaluations.

That makes a lot of sense. I guess I thought (naively) that in this case you can tradeoff memory (lookup table) for performance, but obviously that's often not true, because it doesn't fit into the cache and/or, as you mentioned, branch predictions can be really fast in certain cases.

Thanks for explaining and the update!

lmas commented 3 years ago

I guess I thought (naively) that in this case you can tradeoff memory (lookup table) for performance

Huh I was thinking the exact same thing. It's sad though, the code is so lean and clean when using the lookup table and makes it easier to port it to another language :grin:

CreamyCookie commented 1 year ago

Interesting. Is this the OpenSimplex2F or OpenSimplex2S noise? I do plan on completely replacing the implementations of 2D and 3D in both, with faster non-lookup-table based versions soon. 4D will follow after. That should resolve any issues like this in addition.

Has this been done with the revamp?

KdotJPG commented 7 months ago

Interesting. Is this the OpenSimplex2F or OpenSimplex2S noise? I do plan on completely replacing the implementations of 2D and 3D in both, with faster non-lookup-table based versions soon. 4D will follow after. That should resolve any issues like this in addition.

Has this been done with the revamp?

With everything except for the 4D 2S noise, yes.