Open BBlayne opened 4 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.
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.
@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?
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.
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!
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:
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?
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.
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.