#329 Space on point parameter default values

[Matthias Baas]

The space on a default value for a point parameter doesn't seem to be taken into account properly.
The attached example demonstrates the problem.

The scene contains three disks at positions (0,0,0), (1,0,0) and (0,0.7,0) (the latter is not 0,1,0 so that the disk can be seen properly).
The camera space differs from world space by (0,0,1).

The shader that is applied to the disks displays some points as colors. The points are the origins of the world space, object space and camera space.
The shader divides the disk into three "layers". The center is the camera space, the middle ring is the world space and the outer ring is the object space. Each ring is again divided into three sections that show the points from three sources:

• An single input parameter
• An array input parameter
• A local variable

(have a look at the shader, then I hope the description makes sense)

In the rendered image, the disks should all have a black center (as apparently, Aqsis is shading in camera space). The middle ring should always be pure blue because the origin of the world space as seen in camera space is (0,0,1). The outer ring should be colored with the position of the disk, so the middle disk should be blue, the right disk magenta and the top disk cyan (not pure cyan though).
The sections of the rings should not be visible because all three points that are used for shading a ring should be the same. This is where Aqsis fails. The points that are passed as parameters are as if they were described in world space instead of object space. Only the local variable is correct which means only the top right third of the rings is correct and the rest appears in blue.

I don't know if it's related or not but aqsltell also reports all spaces as "current" which obviously is not correct.

• Matthias -

[Matthias Baas]

[Chris Foster]

The problem here seems to be that the shader initialization code is run at the time that RiSurface() is called, and the renderer doesn't have access to the object(s) which will be shaded at that time - therefore it can't possibly know what the correct "object" --> "current" space transformation is.

There seems to be two alternatives:
* Disallow object-specific stuff for shader default arguments - in this case the aqsl should throw an error I guess.
* Postpone the evaluation of shader default argument lists until the object is known.
Some research on the way that other renderman renderers handle this would be worthwhile before we choose one of these options...

In some ways this seems to be related to bug 1846441 ("Crash with simple (malformed?) shader"), since they both revolve around the way in which the initialization segment of the code is run.

The problem with aqsltell isn't related to this. The aqsltell problem is just because "current" is incorrectly hardcoded in libslxargs as the space associated with all vector-like shader arguments. This may be because it's difficult to extract the correct default space when getting the shaderVM to run the initialization code segment.

~Chris.