|
|
Hi Warp,
Thanks for the reply.
I just tested your theory by adding a matrix<> block the light, both inside
and out of the transform as before. I used
matrix < 1.5, 0,-0.25,
0.5, 1, 0,
0, 0, 1,
0, 0, 0>
before the scale and rotate, which is a shear/scale/rotate mix, and the
light seems to cope with this fine outside of the transform{} block.
Can anyone tell me where in the source code a light_source actually applies
a transform block? I tried following through from 'parse.cpp' where
Transform_Object ((OBJECT *)Object, Parse_Transform(&Local_Trans));
is called. This is defined in 'objects.cpp' where
Transform(Object,Trans);
is called. Transform() is a macro declared in 'frame.h' as
#define Transform(x,y) ((*((x)->Methods->Transform_Method)) (x,y))
but I can not figure out where Transform_Method() is declared for a
light_source object ...
Any other thoughts welcomed,
Mike Andrews.
Warp <war### [at] tagpovrayorg> wrote:
> I can't know the exact reason for this, but this is my educated guess:
>
> A 'transform' identifier probably uses internally a transformation
> matrix, and when you apply a matrix transformation to the light, the area
> light ignores it because the transformation matrix might transform it in
> ways which make it invalid (ie. not rectangular). Direct 'translate' and
> 'rotate' commands are "optimized" so that they are applied to the area
> light appropriately.
>
> If this is the case, there may be two possible solutions (both of which
> require enhancing the source code of povray):
>
> 1) When applying a matrix transfomration to the area light, check if it
> will keep the area light rectangular, and if so, apply it, else don't (and
> issue a warning).
>
> 2) Enhance the 'transform' identifier so that it internally knows what
> types of transforms have been added to it, so these can be easily checked
> or applied separately as needed.
>
> --
> - Warp
Post a reply to this message
|
|