search

ashima / webgl-noise

Procedural Noise Shader Routines compatible with WebGL
MIT License
2.8k stars 302 forks source link

Ugly artifacts in 2d simplex #11

Closed EntityB closed 9 years ago

EntityB commented 9 years ago

Im experimencing some ugly artifacts in 2d simplex. It seems that pattern repeat itself faster then in 289.

I experimenced it with iPad (iPad 2 mini I think).

Could anyone point where the problem could be?

stegu commented 9 years ago

I can't replicate the bug. If it persists, please submit the entire shader so I can test it.

I notice that you are doing bump mapping from noise. Simplex noise has a distinct advantage over regular noise in that it is a sum of easily differentiable terms, and its analytic derivative can be computed easily with a low order polynomial. For a 2D version of simplex noise in GLSL with an analytic derivative, have a look at the "flow noise" in this demo:

http://www.itn.liu.se/~stegu/gpunoise/

I have not made a GLSL version of 3D noise with analytic derivatives, but the differentiation is quite straightforward and follows the same pattern as for 2D noise, only with one more term and one more dimension for each term. Last time I tested it, the speedup compared to computing a finite difference approximation is around 2x for 2D noise and slightly more for 3D noise.

/Stefan

On Fri, Dec 12, 2014 at 6:24 PM, EntityB notifications@github.com wrote:

It is possible that problem with 3d simplex was fixed before and I just had old implementation.

— Reply to this email directly or view it on GitHub https://github.com/ashima/webgl-noise/issues/11#issuecomment-66804549.

stegu commented 9 years ago

After looking at the code that generated the artifacts, I think the problem is with using "precision mediump float" instead of "precision highp float". Some platforms choose a 16-bit floating point representation for "mediump", and that will cause problems with the permutation polynomials even quite close to the origin.

EntityB commented 9 years ago

Thank you, everything is working with "precision highp float"!

EntityB commented 9 years ago

Recent events force me to ask, would be possible to reimplement this noise with precision mediump float?

stegu commented 9 years ago

The problem here is that for compatibility with older versions of GLSL and with WebGL, the permutations are done by integer math with floating point variables.

I see no way to make the permutation polynomial method work with a 16-bit floating point representation. The permutation set would then have to be very small to keep the numbers in the range where the integers N and N+1 map to different representations, and the periodic artifacts from using such a small set of gradients would most probably be too strong to be acceptable.

If texture bandwidth is not a problem, I would recommend using the texture-based lookup table for the permutations, as demonstrated by the older version of noise which I link to on the wiki page in the section "Other noise implementations". The texture-heavy version is generally not as fast on mobile platforms, but on desktop GPUs it can actually be about twice as fast as the pure computational version.