Khronos Public Bugzilla
Bug 384 - noise* is not specified and implemented in a useful fashion
Summary: noise* is not specified and implemented in a useful fashion
Alias: None
Product: OpenGL
Classification: Unclassified
Component: API Specification (show other bugs)
Version: GLSL 4.10
Hardware: All All
: P3 normal
Target Milestone: ---
Assignee: johnk
QA Contact:
Depends on:
Reported: 2010-11-25 16:05 PST by Florian Bösch
Modified: 2013-09-15 10:54 PDT (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Florian Bösch 2010-11-25 16:05:12 PST
The family of noise functions (noise1, noise2, noise3, noise4) are specified in their statistical behavior in the GLSL specification in chapter 8.11

Typical use cases of noise include procedural materials, landscapes etc.

It is desirable to able to reproduce the same numerical value for an invocation of the noise function when the same input argument is provided. For example noise1(0.5) == 0.123 no matter on what hardware and driver from which vendor. This is desirable because it broadens the usefulness of the noise function to the creation of procedural content, for which it would be primarily intended. It would be very counter intuitive if the same input (save files, level descriptions etc.) produce different results for different users when this was not intended by the application developer.

Randi J. Rost notes in his book "OpenGL Shading Language" in chapter 15.3 on noise that I quote: "A user-defined function can also provide matching behavior on every platform, whereas the built-in noise function cannot (at least not until all graphics hardware developers support the noise function in exactly the same way.)"

I take exceptions with these three issues that I see:

1) The statistical definition of noise from the spec chapter 8.11 does not specify the algorithm. Therefore a variety of varying implementations is bound to emerge, which reduces the usefulness of the noise functions for their intended purpose.

2) Most vendors choose to implement the specification by returning 0, which violates I quote "Values returned by the following noise functions give the
appearance of randomness" as well as "and cover at least the range [-0.6, 0.6], with a Gaussian-like distribution" and "They typically give different results under translation."

3) Some vendors have started to support the noise function, which makes issue #1 more urgent, as a fragmentation of implementations will reduce the usefulness of this specification to actual use cases.
Comment 1 Florian Bösch 2010-11-25 16:26:23 PST
The intend of this bug report is to broaden the potential usefulness of the noise family of functions in a case where a more precise specification can provide more value.

If the purpose of the specification is to target specific special cases of noise function usage like "per user different content" then I don't think it belongs into the specification nor into any implementations by vendors.

If the special use-case of "per user" or "per invocation" or "per machine" or "per driver" different content is desired, it can easily be provided by translating the input value by a desired random offset passed in as a uniform to the shader. However if the specification is implemented as the special use case it shapes up to be right now, no more generic usecase can possibly be derived from it, forcing everybody to implement their own noise functions despite a potentially useful default implementation.

This would be regrettable as it would be possible for vendors to provide faster noise implementations of noise then could be provided by user implementations.
Comment 2 Jon Leech 2010-11-29 16:59:50 PST
Hi Florian,
I've passed this on to the ARB for discussion. I wouldn't expect a quick
answer. but it is on our radar now. Thanks!
Comment 3 johnk 2013-09-15 10:53:59 PDT
The ARB has decided to officially deprecate the noise*() functions and define that their return value is 0.  These changes should appear in the next available revision of the GLSL 4.4 specificiation.

Note that deprecation means identified for reduced support and possible future removal.  It does not mean they have been removed.