-
Notifications
You must be signed in to change notification settings - Fork 54
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
Comments
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. |
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! |
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. |
First of all, thanks for both OpenSimplex and OpenSimplex2! They're awesome.
Any news on this, or is will it not happen? (Also fine.) Would you mind explaining why it is faster? |
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. |
4D would be great as that's the one I'm using (and the math definitely goes over my head)
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! |
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 😁 |
Has this been done with the revamp? |
With everything except for the 4D 2S noise, yes. |
When I try to get noise using the 2D function, I get an out of range exception.
Here's my usage:
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.
The text was updated successfully, but these errors were encountered: