appendixA.html, appendixF.html, index.html, section01.html, section02.html, section03.html, section04.html, section05.html, section06.html, section07.html, section08.html, section09.html, section10.html, section11.html, section12.html, section13.html, section14.html, section15.html, section16.html
There is no support for using general expressions to specify defaults for shader parameters. The parameter defaults may only be written in one of the following ways:
/* An explicit constant. */
color param0 = color (0,1,.75);
/* A point in a specified space. */
point param1 = point "shader" (0,1,2);
/* A float value specified in degrees using the radians() function. */
float param2 = radians(30);
Functions may not contain any illuminance, illuminate or solar statements.
Functions may not access any global variables or shader parameters (unless these are passed in explicitly as arguments to the function).
Functions (and also illuminance, illuminate and solar statements) may not use any built-ins which explicitly or implicitly use derivatives. These are: Du(), Dv(), Deriv(), area(), calculatenormal(), texture(), environment(), bump() and shadow().
The extensions void and output are supported but may be omitted for backwards compatibility.
To support functions which update their parameters, parameters are copied back into the passed arguments, at the end of the call. This makes it a bad idea to pass the same variable as more than one parameter if any of those parameters is used as an output parameter. Such use is not currently supported.
For example with the definition:
void add(point x, point y, point z) {
x = y + z;
}
Consider the usage:
add(v0, v1, v2); /* OK */
add(v0, v0, v1); /* not OK */
add(v1, v0, v0); /* OK */
The problem in the second case is that v0 may end up with the final value of x or the value of y. In the third case there is no ambiguity. (y and z both contain the value of v0 at the end of the execution of add().)
Last modified: Wed May 31 09:34:26 BST 2000