Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IndexOutOfRangeException using 2D Simplex Noise #3

Open
BBlayne opened this issue Sep 4, 2020 · 9 comments
Open

IndexOutOfRangeException using 2D Simplex Noise #3

BBlayne opened this issue Sep 4, 2020 · 9 comments

Comments

@BBlayne
Copy link

BBlayne commented Sep 4, 2020

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
Copy link
Owner

KdotJPG commented Sep 11, 2020

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
Copy link
Author

BBlayne commented Sep 11, 2020

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
Copy link
Owner

KdotJPG commented Sep 11, 2020

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
Copy link

@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
Copy link
Owner

KdotJPG commented May 3, 2021

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
Copy link

CreamyCookie commented May 3, 2021

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
Copy link

lmas commented May 11, 2021

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 😁

@CreamyCookie
Copy link

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
Copy link
Owner

KdotJPG commented Feb 3, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants