Hi folks,

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.

The problem is, which coordinate transforms do I use?

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 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 ...

Thanks for any help,
	Mike Andrews.

Post a reply to this message

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

I just started to think, that maybe shader transformations do not apply
to warp at all and after tests this seems to be the case: I printed out
value of P and all transformations for it return same value. P's value
on input is in shader space. So it seems to be an explanation, why
transformations do not work correctly: direction vector Dir is in world
space, but P is in shader space and transformations from one space to
other do not work. 
One possibility is to calculate direction vector in POV-Ray beforehand
and supply to shader (note that translations should not be applied to
calculate vector transformation, only rotations and scales). But with
bigger number of objects it gets messy... 
Other option is to rewrite texture as 'true' surface shader.

I have to admit, that I'm not very much learned this warping code and
can't say right now, whether it is possible to make it working as normal
shaders (i.e. transformation matrices will be available). Time
permitting, I try to explore it better and improve shader support or
write better documentation for it.

Vahur

Post a reply to this message

Hi Vahur,

Thanks for your posts; I think they cleared up my thinking a little :-)

I've changed the transforms, taking into account that P (and Ng?) are in
shader coords already. This gave me 

    P2 = PP = P;

    if (Type == 0){
        Axis = normalize(vtransform("world", "shader", vector(Dir)));
    }
    else if (Type == 1){
        Axis = normalize(vector(PP - transform("world", "shader",
Dir)));
    }
    else if (Type == 2){
        Axis = normalize(vector(Ng));
    }

which seems to work as I expected for types 0 and 1.

Is there any way to pass normal (Ng) down to a shader in warp code that
actually is working on a true surface, rather than say in an isosurface
pigment or media density? I guess probably not ...

I've been thinking about a couple of other things I can try too: can you
get the colour of a point at another position, ie point(P + V) where V
is a given vector? Hmmm ...

Thanks again,
	Mike Andrews.


Vahur Krouverk wrote:
> 
> I just started to think, that maybe shader transformations do not apply
> to warp at all and after tests this seems to be the case: I printed out
> value of P and all transformations for it return same value. P's value
> on input is in shader space. So it seems to be an explanation, why
> transformations do not work correctly: direction vector Dir is in world
> space, but P is in shader space and transformations from one space to
> other do not work.
> One possibility is to calculate direction vector in POV-Ray beforehand
> and supply to shader (note that translations should not be applied to
> calculate vector transformation, only rotations and scales). But with
> bigger number of objects it gets messy...
> Other option is to rewrite texture as 'true' surface shader.
> 
> I have to admit, that I'm not very much learned this warping code and
> can't say right now, whether it is possible to make it working as normal
> shaders (i.e. transformation matrices will be available). Time
> permitting, I try to explore it better and improve shader support or
> write better documentation for it.
> 
> Vahur

Post a reply to this message

Michael Andrews wrote:
> 
> Hi Vahur,
> 
> Thanks for your posts; I think they cleared up my thinking a little :-)

Good!
 
> I've changed the transforms, taking into account that P (and Ng?) are in
> shader coords already. This gave me
> 
>     P2 = PP = P;
> 
>     if (Type == 0){
>         Axis = normalize(vtransform("world", "shader", vector(Dir)));
>     }
>     else if (Type == 1){
>         Axis = normalize(vector(PP - transform("world", "shader",
> Dir)));
>     }
>     else if (Type == 2){
>         Axis = normalize(vector(Ng));
>     }
> 
> which seems to work as I expected for types 0 and 1.

Hmm, as I wrote, transforms do not work for warp shader and this means,
that Axis is probably not expected one. But as long as it works and
produces expected output, it could be left as it is (I hope that in
future I can make it work).
 
> Is there any way to pass normal (Ng) down to a shader in warp code that
> actually is working on a true surface, rather than say in an isosurface
> pigment or media density? I guess probably not ...

Actually, already warp code misses intersection information (normal is
field in intersection structure). It is possible to pass down
intersection information to warp code and from it to shader, but this
requires probably quite big modifications in source code. I decided to
wait for version 3.5 of POV-Ray before making big source code changes to
avoid additional work with source update, although if this is not big
change and I get before v. 3.5 something releasable ready, then I could
include this feature as well.

> I've been thinking about a couple of other things I can try too: can you
> get the colour of a point at another position, ie point(P + V) where V
> is a given vector? Hmmm ...

Hmm, I'm not sure, that I follow this idea. Unless this point happens to
lay exactly in surface of object, there is no way to find color for
given point in space. And even if it lays on surface, then resulting
color will still depend from point of view for non-trivial textures
(reflections, diffuse etc. for given point change with camera position
changes).
But POVMan supports shader's function 
color trace(point from; vector dir) 
by tracing ray from given point in given direction and returning
resulting colour. Is this what you meant?

Vahur

Post a reply to this message