This is fantastic, I’ve been sitting here half the day thinking about using noise to generate terrain but feeling too brain dead to actually research how to implement it. Then I remembered this thread and have it producing nice patterns in 10 minutes without having to use any brain power 
@KdotJPG – or anyone else that understands these legal issues:
If your “open” implementation makes use of a geometrical “Simplex” for generating gradient noise uses of 3D or more, what exactly is it that you’ve done that puts this out of the reach of Ken Perlin’s patent?
This is an honest question, not an attempt to shoot anything down. I don’t have much knowledge of how patent law works in this situation. How is your implementation any more or less restricted than what Gustavson coded?
I’m assuming Simplexes are involved, since they are part of the title of the project.
Here’s my non-lawyer take on it: If you read the patent claims: http://www.google.com/patents/US6867776:
Claim #1 talks about the hardware-implementation-optimized gradient generator. Most software implementations of Simplex Noise don’t use this anyway, and OpenSimplex Noise certainly doesn’t.
Claim #2(&3&4) talk about using (x’,y’,z’)=(x+s,y+s,z+s) where s=(x+y+z)/3 to transform the input (render space) coordinate onto a simplical grid, with the intention to make all of the “path-simplices” approximately regular. OpenSimplex Noise (in 3D) uses s=-(x+y+z)/6 to transform the input point to a point on the Simplectic honeycomb lattice so that the simplices bounding the (hyper)cubes at (0,0,…,0) and (1,1,…,1) work out to be regular. It then mathematically works out that s=(x+y+z)/3 is needed for the inverse transform, but that’s performing a different (and opposite) function.
Claim #5(&6) are specific to the path-simplex lattice. Simplex Noise divides the (squashed) n-dimensional (hyper)cube into n! simplices based on ordered edge traversals, whereas OpenSimplex Noise divides the (stretched) n-dimensional (hyper)cube into n polytopes (simplices, rectified simplices, birectified simplices, etc.) based on the separation (hyper)planes at integer values of (x’+y’+z’+…). In 3D this works out to six approximately-regular “path simplices” per cube for Simplex Noise, and two regular tetrahedra plus one regular octahedron per cube for OpenSimplex Noise.
The other interesting point is that, if you read all of the claims, none of them appear to apply to the 2D analogue of Simplex noise so long as it uses a gradient generator separate from the one described in claim #1. The skew function in Claim #2 only applies to 3D, and #5 explicitly refers to n>=3. Also, both Simplex Noise and OpenSimplex Noise generalize to different orientations of the equilateral triangle tiling in 2D.
And none of the patent claims speak about using surflets / “spherically symmetric kernels” to generate the “images with texture that do not have visible grid artifacts,” which is probably the biggest similarity between the two algorithms.
TL;DR it’s not doing the same thing.
The patent claim is very nice. It narrow and its intention is targeting same results everywhere and primarily hardware implementations. So pretty much only CG houses with specialized hardware…unless GPU IHVs decide to make native ops. Much ado about nothing.
Indeed, I wouldn’t bat an eyelid if I were to implement the original simplex noise somewhere inside a game to make some clouds or terrain or whatnot.
Cas 
Very pretty, DarkCart!
Thanks. Just fooling around with it, then that popped up. Well done.