   Simplex noise artefacts?
  In my continuing saga with procedural generation and planets, I have come across an odd bug in almost all publicly available implementations of Perlin's Simplex noise.As you can see in the following image (click to enlarge), simplex noise is fine in the positive quadrants of the sphere, but in the negative quadrants it develops grid-like artefacts. These exist when one or more coordinates are negative, but are most pronounced when all coordinates are negative.For the image I use fractal Brownian motion to combine several layers of simplex noise, as the artefacts are most apparent at high frequencies. I also used 3D noise, but the same artefacts are apparent with 2D noise.This simplex noise was generated using Stefan Gustavson's implementation (http://staffwww.itn.liu.se/~stegu/aqsis/aqsis-newnoise/), but the problem seems to exist with almost all implementations I have access to - the notable exception being Gustavson's own GLSL implementation.I am not entirely comfortable with the intricacies of the implementations (particularly Perlin's own), but similar artefacts occur in many types of noise - including Ysaneya's fast computed noise, and Gustavson's GLSL implementation of simplex noise, if I disable wrapping in the lookup tables.As far as I can tell, the logic is identical in Gustavson's C and GLSL implementations, but clearly one works and the other doesn't...Is there some implementation detail I am overlooking? I could probably get by with offsetting all my coordinates to be positive, but this is hardly ideal, and the fact that some implementations don't suffer from this suggests it isn't inherent.   
  Well, that turned out to be horrifyingly simple, and I should have picked up on it as soon as I noticed the wrapping on the GLSL lookup textures.As is, the C code uses the % operator to wrap indices into the lookup table. Unfortunately, I (and the various implementors) neglected to account for the fact that modulo preserves sign, yielding negative indices into the lookup table.A simple check for negative indices solves this problem nicely, but my CPU based noise generation still doesn't match my GPU based noise - a property I unfortunately require. Time to go unwind those lookup tables to find the difference...   ;  Think it might have to do with your CPU having a different floating point unit than your GPU?   ;Quote:Original post by Atrix256Think it might have to do with your CPU having a different floating point unit than your GPU?I am sure that will cause small differences (GPU is lower precision), but not the big differences I am experiencing. It appears that Gustavson used completely different permutation table lookups for the GLSL version - and I don't seem to have found the right combination yet.Porting GLSL code back to C is not entirely straightforward. [wink]   