Coherent noise algorithms are a popular choice for procedural texturing and procedural terrain generation. There’s Perlin Noise, which has grid artificts, and there’s Simplex Noise, which is patented (for 3D+ implementations), so here’s something new!
Blog Post: http://uniblock.tumblr.com/
I see you “Unlicensed” it, that’s nice. Was my main concern when I saw it on reddit.
I do have question though, do you know if this runs afoul of the branch predictor?
That seems like a lot of branching and I expect it would be fairly random given that it’s noise… I might investigate if I have time.
Most if not all of the conditionals are geometry-based. Conditionals are used to figure out where you are on the lattice and figure out a small superset of the possible vertex contributions (i.e. points within one edge-length of the input point), math is done on each vertex to compute its distance away, another conditional is used to confirm whether or not that point does actually contribute, then if it does more math is done and a final value is added to a total.
EDIT: i.e., no matter what “seed” you’re using, the branches will happen the same way. The “seed” just determines what happens in the last math step (gradient selection at the vertex, extrapolation, and multiplication by the distance-based attenuation).
Table lookups are not your friend.
thanks for sharing!
this one generates really nice patterns. compared to regular Gustavson’s simplex noise it
top : simplex, bottom : opensimplex
Why isn’t the OP medal-slapped?! :point:
This is technically impressive, produces seriously high quality output, and above all: is usable for a lot of projects.
That it’s somewhat slower than simplex noise, yet faster (allegedly) than perlin noise, is only a mere inconvenience for the performance junkies.
Just what I have been looking for!
OP: I took a quick peek at the output of a single sample and it appears like there’s a bug…perhaps the output isn’t full range. Visually it looks like a lightweight blur has been applied.
My 2011 reference implementation which is twice as fast, equal usable and patent free (assuming you don’t flip the switch) has a grand total of zero. Potentially useful things often don’t get bombarded with medals as I’m sure you’re aware. Stefan Gustavson’s version from 2005 is likewise patent free and equally usable. BTW as far as patent’s are concerned this one is nice as it only claims an exact formulation. So this whole patent free thing is much ado about nothing.
But performance is quite important for this kind of noise. It needs to be fast enough to not require build-time generation. If you need build-time generation then you might was well kick it up a notch to a non-realtime noise generator.
And the Lord Hath spoken: “Thou shalt Slap him with Medals!”.
And Lo and Behold, he was Slappeth with many Medals.
is it this : have http://www.java-gaming.org/topics/simplex-noise-3d/23962/view.html ?
just curious, do you have a newer version of it somewhere ? it is almost as fast as stefan gustavson’s (http://staffwww.itn.liu.se/~stegu/simplexnoise/simplexnoise.pdf) version, easier to read but generates slightly more repeating patterns (due to hashing ?).
A newer version is here: https://github.com/roquendm/JGO-Grabbag/blob/master/src/roquen/pg/noise/SimplexNoise3D.java
Flipping to the more expensive hash removes some defects, but this is intended to be example code not really production ready. I really need to add a note about the patent to the source. There’s all kinds of choices about hashes depending on use-case.
thanks 
that one get’s even closer to the reference (speedwise with [icode]simpleHash[/icode]). very impressive considering there are no LUT’s involved.
In case someone is interested, here is a stripped-down 2D version of Gustavson’s SimplexNoise implementation that is relatively readable. Performance is quite OK, although I do not have any benchmarking. Also, this uses a fast pseudo-random number generator, but you could use any other random generator as well.
Edit: put the code in the pastebin:
http://pastebin.java-gaming.org/fa70a2c870418
I tried converting all the doubles to floats in Gustavson’s version a couple weeks ago, and found no measurable performance difference. Maybe this says more about my benchmarking ability than the code.
This is the first I’ve heard of patents being an issue with the Simplex algorithm. I have an app with a background graphic where 2D cirrus clouds are floating by, making use of 3D translation. I’m wondering if this use requires any sort of payment. Right now I’m just acknowledging Gustavson, as he requests in his code.
Roquen makes a very good point about performance being relevant. At this point, I’m calling the Simplex graphic effect a “placeholder” because it uses over twice the amount of cpu of the main program, e.g., a usage level of 15% jumps to 45% when I turn on this skin animation. So, I’m glad for the reminder, and will be giving Roquen’s a try again.
Roquen: marketing and pitching is an art. (Just finishing reading Jane Bussman’s “A Journey into the Dark Heart of Nameless Unspeakable Evil”–Hilarious, with many insights into how the world works. I recommend it to all JGO’ers.)
OP: I just turned up a multiply factor and started to see results in line with my expectations, so I think the problem with your code is that it’s isn’t returning full range.
Gustavson’s version from the paper is out of date, at least the last time I looked at the paper, check the code: http://webstaff.itn.liu.se/~stegu/simplexnoise/
I use singles because doubles don’t bring anything to the table. On intel the time to issue and latency of single and double add/mul are the same so without reading/writing they should be the same. Who knows embedded devices might take off sometime in the future which don’t use intel desktop/mobile CPUs.
Makes sense. I think the bottom graphic looks a little “faded” compared to the top, which had me wondering if the new version wasn’t reaching the same extremes in range.
I didn’t know that the difference between floats and doubles are not so much in calculations, but in pipeline. Thanks for that! That is also in line with what I experienced.
singles and doubles only have the same latency numbers for the most basic operations, so divide will differ etc…add,mul,fabs…the super basics are the same.
output range test of 65000 samples normalized to 0.0 … 1.0 :
value noise : 0.012 - 0.988 reference simplex : 0.013 - 0.986 roquen's simplex : 0.018 - 0.985 open simplex : [b]0.038 - 0.959[/b]
slightly off.
BTW I went ahead and updated the code to include 2D and 4D implementations alongside the 3D implementation, as well as tweaked the gradient set that’s being used for the 3D implementation.
thanks alot again! ;D
output range after 80000 samples :
2D : 0.068 - 0.932 3D : 0.060 - 0.932 4D : 0.060 - 0.935
nicely in range.
a bit of comparison :
4D, top : opensimplex, bottom Gustavson’s
4D false color, top : opensimplex, bottom Gustavson’s
4D false color + FBM, top : opensimplex, bottom Gustavson’s
colors could be better i know but we can see opensimplex’s patterns are much better.
