noise opcodes

[GoogleCodeExporter]

Implement the noise related opcodes for procedural texturing. This is also our 
chance to apply 
any improvements to the old perlin style noise we are currently using.

There was some talk of calling noise functions via the RendererServices. Is 
this what we want? Or 
should OSL just provide a default implementations of these?

10/05/09 14:39:03 changed by lg 

I think they should definitely be done through RendererServices?. Many, if not 
most, renderers 
will probably want to use their own.

Orthogonal decisions: whether the base class of RendererServices? ought to 
provide a decent 
default implementation (I think yes, at least eventually), <edit>

10/06/09 17:22:25 changed by ckulla 

Implemented cellnoise() in r284. (Code review in RB483)

Perlin noise is next ...

10/07/09 16:16:44 changed by ckulla 

A question about pnoise(): it is currently specified that the period is passed 
as a float even 
though only integer arguments make sense. Why not specify the period to be an 
integer then? It 
feels like a leftover of the fact that RSL didn't have integers.

10/07/09 16:24:22 changed by lg 

It's surely a holdover from the int-less days. I am not averse to changing the 
spec to require 
integer periods if you guys think that would be better.

10/07/09 16:28:43 changed by ckulla 

The question is are we ever going to support a noise function that supports 
non-integer periods? 
If not, lets clarify the spec to require that ints be passed.

Next question: can a uniform value have derivatives?

10/07/09 16:38:25 changed by lg 

Now that's the question. I think it's certainly possible that some day we'll 
have a noise field that 
could have arbitrary period. OK, so then I vote that we keep the period as 
float, since it's only an 
artifact of our specific implementation that it must be an int. (And, BTW, we 
should just take the 
floor to convert it to an int.)

Uniform values always have derivative == 0. Did you mean integer values? We 
decided that 
integers don't have derivatives (since the deriv, mathematically, would be zero 
everywhere except 
the infinitesimal areas where it's the step function, at which point the 
derivative is undefined 
anyway).

10/07/09 16:41:17 changed by ckulla 

No I meant uniform values in general. Can you explain why a uniform float 
_must_ always have a 
0 derivative?

When we run a shader on a batch of 1 point - is there still a difference 
between varying and 
uniform?

10/07/09 16:47:07 changed by lg 

The definition of uniform is "has the same value everywhere on the surface." 
Thus, derivative is 
zero.

You can have varying values when shading only one point, yes, if it is a 
quantity that is expected 
to take on a different value at each point on the surface being shaded.

10/07/09 16:57:46 changed by ckulla 

Gotcha - I guess I was confused because you mentioned that sometimes varyings 
transparently 
get demoted to uniform and back up again. I guess the demotion step checks to 
see if the 
derivative is 0 (or not required)?

10/07/09 16:59:02 changed by lg 

It doesn't ever do it yet. :-) But yes, when it does, it would only be able to 
do this for vars that 
don't have derivs (most things).

10/07/09 17:17:51 changed by ckulla 

Derivative support for noise and snoise in r292 (code review: RB487)

Onto periodic noise ...

10/08/09 18:06:28 changed by ckulla 

Added pnoise and psnoise in r296 (code review: RB496)

10/08/09 18:11:25 changed by ckulla 

There is some discussion about the appearance of the noise function. We are 
worried about: 
repeating artifacts in the 1D case (too few gradients), exact range and 
standard deviation.

10/08/09 18:19:00 changed by ckulla 

Here is an implementation of simplex noise from the svea code base:

http://softboss/trac/software/browser/svea/trunk/Noise/export/Noise/Simplex.h

This has some nice properties over the classical perlin noise (even the 
improved variant). In 
Perlin's own words:

I've been developing a new approach. This method of implementing Noise conforms
better to the ideal Noise specification of [Perlin85]. While providing the same
general "look" as previous versions of Noise, it also:

  * provides a single uniform standard result on any platform

  * is visually isotropic, unlike the original algorithm

  * does not require significant table space to compute good pseudo-random gradients

  * can have an arbitrarily large extent for its repeating virtual tile at very low cost

  * does not require multiplies to evaluate gradient at surrounding grid vertices

  * does not produce visible grid artifacts

  * does not produce visible artifacts in the derivative

  * is cheaper to compute than is the original algorithm

  * allows for a direct analytic computation of derivative at reasonable cost

  * can be generalized to higher dimensions at relatively small computational expense.
Sounds pretty good to me.

10/08/09 18:29:14 changed by ckulla 

The first tricky question is: how do you do pnoise() with this technique?

10/12/09 16:53:42 changed by ckulla 

A bit extra normalization on the existing implementation (with some #if 0'd out 
code to compute 
it via random sampling) in r299 (review in RB498).

Original issue reported on code.google.com by rene.lim...@gmail.com on 11 Jan 2010 at 6:00

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Original comment by rene.lim...@gmail.com on 13 Jan 2010 at 1:13

• Added labels: Priority-Medium

[GoogleCodeExporter]

Noise routines added a long long time ago.

Original comment by larrygr...@gmail.com on 24 Feb 2011 at 5:58

• Changed state: Fixed