Michael Andrews wrote:
> 
> Hi folks,
>
Hi!
I'm not quite sure, that I understand your problem completely, but I try
to answer questions.
 
> I'm writing a shader for use with POVMan. The output colour is designed
> to be used in a type 0 displacement warp. At the moment it seems to be
> working at the origin, is scaling and rotating, but goes wrong when I
> try to translate it.

Hmm, what happens (what goes wrong), if you translate it? I tried to
translate and it seemed to work?

> 
> The problem is, which coordinate transforms do I use?
>
POVMan supports currently 3 different color spaces: 
1. 'world' space.
2. 'current'
This is 'initial' coordinate space, input parameters (P, N, Ng etc.) are
given in this coordinate system. For different RenderMan implementations
it is different (PRMan uses camera space, BMRT world space), so actually
one should not assume, that this is equal to some specific space (in
POVMan this is equal to 'world' space). This means, that if e.g. one
wants to use world space for calculations, then transformation should be
applied to keep shader implementation-independent.
2. 'shader'
This is texturing space. Generally calculations are performed in this
space, so if texture transformations are performed, then they will
affect calculated texture. 

You use in shader also 'object' space, but currently it is not supported
(as well as other spaces: camera, screen, raster, NDC). I intend to
implement in future some other spaces too, but right now identity matrix
is used for transformations to/from these spaces, so they have no
effect. 

There is question in shader:
Do I need to use different transforms for the different types?
Answer is: 'Yes', in transformations one should take into account, which
types are transformed: points should be transformed with transform,
vectors with vtransform and normals with ntransform. Additionally,
POVMan does not register, in which space given variable is calculated,
so it is up to shader writer to ensure, that required conversions are
performed.

> The shader produces a 'swirl' effect in the displacement warp, with the
> local axis of rotation defined in one of three ways.
> 
> I can not seem to get the right coordinate transforms for the axis and I
> have no idea which transform to use for the colour output.
I'm not sure, that there is need to transform color output at all:
simple difference and conversion to color would suffice. If you
transform, then e.g. texture rotation will affect result twice: once,
when you calculate coordinates in shader space and secondly, when you do
difference transform for color calculation. I can't think out (with this
heat here:-), what will be the result, but I don't think, that it would
be very intuitive. (In posted shader this transformation does nothing
actually, as it uses object space, but this space has no effect
currently, as explained above).

> I'm posting an image on p.b.i and the shader and a scene file to
> p.b.s-f, so if any shader writers out there could have a look at it and
> make any suggestions ...

As I said, I'm not sure, what is the problem and what should be expected
outcome. But I suggest to use initial space transformation from
'current' to 'shader' space (for calculation expressions of variables
P2, PP, Axis) and remove final transformation. If this does not help,
then I'm ready to answer to additional questions (but I will be in
vacation for 2 weeks from this weekend, so try to ask them before
Saturday, otherwise I might be unavailable).

Additional note: shader is used for warp calculation and this means,
that only subset of built-in variables is available for shaders (see
documentation for 'non-object pigment definitions' in 'POV-Ray specific
notes' chapter.) This will mean, that 2nd swirl type (where type==2)
will not work, as normal Ng is not provided (it contains undefined
value). If you want to use surface normal for swirl calculation, then
I'm afraid, that you should calculate whole pigment in shader.

Vahur

Post a reply to this message