POV-Ray : Newsgroups : povray.general : Problem with area lights and transform{}? : Re: Problem with area lights and transform{}? Server Time
4 May 2024 11:42:25 EDT (-0400)
  Re: Problem with area lights and transform{}?  
From: Mike Andrews
Date: 3 May 2007 11:15:01
Message: <web.4639fb211a0c1e53c717c9af0@news.povray.org>
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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.