Hi Folks,

I was playing with a macro to create area lights and hit a snag. One of the
parameters was a transform{} block to position the light and this seems to
be working wrong.

After some tinkering I came up with a fairly minimal scene that shows the
problem on my system, in that using a rotate and translate either directly
or in a transform{} block give different results in the Windows version of
3.6.1c.

Can someone confirm the problem or point out what I'm doing wrong? I find it
hard to believe that it is a bug in such a well used part of the code ...

Thanks,

Mike Andrews.

// --- Start of areaLightTransform.pov ---

// +w640 +h480 +a0.1
// Change useTransform to 'on' to see problem

#declare useTransform = off;

global_settings {
  assumed_gamma 1.0
  max_trace_level 50
  ambient_light 1
}

camera {
 up <0, 1, 0>
 right x*image_width/image_height
 location  <-1, 15, -25>
 angle     10
 look_at   0
}

plane {
  y, 0
  pigment { rgb 1 }
  finish { diffuse 1 ambient 0 brilliance 0.5 }
}

light_source {
  0, rgb 1
  area_light x,y, 2,2
  #if (useTransform)
    transform {rotate -90*x translate <0,2,0>}
  #else
    rotate -90*x translate <0,2,0>
  #end
}

#declare tBlack = texture {
  pigment { rgb 0 }
  finish { diffuse 0 ambient 0 }
}

cylinder { -y,0.3*y,0.02 translate < 0,0,-1> texture {tBlack} }
cylinder { -y,0.3*y,0.02 translate <-1,0,0>  texture {tBlack} }
cylinder { -y,0.3*y,0.02 translate < 0,0,0>  texture {tBlack} }
cylinder { -y,0.3*y,0.02 translate < 1,0,0>  texture {tBlack} }
cylinder { -y,0.3*y,0.02 translate < 0,0,1>  texture {tBlack} }

// --- End of areaLightTransform.pov ---

Post a reply to this message

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

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

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

Take a look at point.cpp. It seems that Transform_Light_Source() actually
does nothing special with area lights. Only Translate_Light_Source() does
not call Transform_Light_Source() (scale and rotate do), but does it
itself. I don't know how the area light sample points are stored exactly,
but that may be the cause.

Post a reply to this message

Hi Lucas,

Thanks for this, I think you've identified where the problem lies!

The lines

  MTransPoint (Light->Axis1,     Light->Axis1,     Trans);
  MTransPoint (Light->Axis2,     Light->Axis2,     Trans);

should deal with the area_light axes, but I think that they should use the
MTransDirection() function as the spotlight direction item does and not the
MTransPoint() function. I think that these functions differ in that
MTransPoint() incorporates a translate where MTransDirection() does not.

To check this I replaced the 'translate <0,2,0>' in my test code with

      matrix < 0, 0, 0,
               0, 0, 0,
               0, 0, 0,
               0, 2, 0>

and now the code produces identical, incorrect results whether or not a
transform{} block is used!

I think that this needs to be reported as a Bug in the core v3.6 code. I'm
not sure whether it has been carried over to v3.7 as that's timed out on my
PC.

Well, problem solved I think. Thanks those who have thought about this. Can
anyone think of a work around or is it a show-stopper for what I was trying
to achieve?

Mike Andrews.

Lukas Winter <web### [at] removeitgeloeschtnet> wrote:
> > 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
[snip]
> Take a look at point.cpp. It seems that Transform_Light_Source() actually
> does nothing special with area lights. Only Translate_Light_Source() does
> not call Transform_Light_Source() (scale and rotate do), but does it
> itself. I don't know how the area light sample points are stored exactly,
> but that may be the cause.

Post a reply to this message

"Mike Andrews" <nomail@nomail> wrote:
> Can anyone think of a work around or is it a show-stopper for what I was trying
> to achieve?

If your intention is to have something like:

#declare tr1 = transform {rotate -90*x translate <0,2,0>}

light_source { foo transform { tr1 } }

Then you can accomplish the same by using a macro rather than a declare:

#macro tr1() rotate -90*x translate <0,2,0> #end

light_source { foo tr1()  }

It's even shorter and reuses previous values just like in a declare. :)

Of course, a general matrix transform won't work while the bug isn't
corrected...

Post a reply to this message

Hi nemesis,

I'm writing a macro of the form

areaLight(_Colour,_Size,_subPanels,_Lights,_Transform)

that creates a visible light panel with the required characteristics.

I've actually figured out a generic work around given a declared transform.
Using vtransform from 'transforms.inc' you can split the translate out as
follows:

    #local _Translate = vtransform(x*0,_Transform);
    transform {_Transform translate -_Translate}
    translate _Translate

So I can finish writing the macro now :-)

Bye for now,

Mike Andrews.

"nemesis" <nam### [at] gmailcom> wrote:
> "Mike Andrews" <nomail@nomail> wrote:
> > Can anyone think of a work around or is it a show-stopper for what I was trying
> > to achieve?
>
> If your intention is to have something like:
>
> #declare tr1 = transform {rotate -90*x translate <0,2,0>}
>
> light_source { foo transform { tr1 } }
>
> Then you can accomplish the same by using a macro rather than a declare:
>
> #macro tr1() rotate -90*x translate <0,2,0> #end
>
> light_source { foo tr1()  }
>
> It's even shorter and reuses previous values just like in a declare. :)
>
> Of course, a general matrix transform won't work while the bug isn't
> corrected...

Post a reply to this message

Mike Andrews nous apporta ses lumieres en ce 03-05-2007 05:37:
> Hi Folks,
> 
> I was playing with a macro to create area lights and hit a snag. One of the
> parameters was a transform{} block to position the light and this seems to
> be working wrong.
> 
> After some tinkering I came up with a fairly minimal scene that shows the
> problem on my system, in that using a rotate and translate either directly
> or in a transform{} block give different results in the Windows version of
> 3.6.1c.
> 
> Can someone confirm the problem or point out what I'm doing wrong? I find it
> hard to believe that it is a bug in such a well used part of the code ...
> 
> Thanks,
> 
> Mike Andrews.
> 
> // --- Start of areaLightTransform.pov ---
> 
> // +w640 +h480 +a0.1
> // Change useTransform to 'on' to see problem
> 
> #declare useTransform = off;
> 
> global_settings {
>   assumed_gamma 1.0
>   max_trace_level 50
>   ambient_light 1
> }
> 
> camera {
>  up <0, 1, 0>
>  right x*image_width/image_height
>  location  <-1, 15, -25>
>  angle     10
>  look_at   0
> }
> 
> plane {
>   y, 0
>   pigment { rgb 1 }
>   finish { diffuse 1 ambient 0 brilliance 0.5 }
> }
> 
> light_source {
>   0, rgb 1
>   area_light x,y, 2,2
>   #if (useTransform)
>     transform {rotate -90*x translate <0,2,0>}
>   #else
>     rotate -90*x translate <0,2,0>
>   #end
> }
> 
> #declare tBlack = texture {
>   pigment { rgb 0 }
>   finish { diffuse 0 ambient 0 }
> }
> 
> cylinder { -y,0.3*y,0.02 translate < 0,0,-1> texture {tBlack} }
> cylinder { -y,0.3*y,0.02 translate <-1,0,0>  texture {tBlack} }
> cylinder { -y,0.3*y,0.02 translate < 0,0,0>  texture {tBlack} }
> cylinder { -y,0.3*y,0.02 translate < 1,0,0>  texture {tBlack} }
> cylinder { -y,0.3*y,0.02 translate < 0,0,1>  texture {tBlack} }
> 
> // --- End of areaLightTransform.pov ---
> 
> 
> 
> 
The transform aparently translate THEN rotate.
When you rotate your area_light, it stay in place but the plane of the aray does 
rotate and become horizontal, you then you translate it 2 unit straight up.

-- 
Alain
-------------------------------------------------
I can read your mind, and you should be ashamed of yourself.

Post a reply to this message

Mike Andrews schrieb:
> Hi Lucas,
> 
> Thanks for this, I think you've identified where the problem lies!
> 
> The lines
> 
>   MTransPoint (Light->Axis1,     Light->Axis1,     Trans);
>   MTransPoint (Light->Axis2,     Light->Axis2,     Trans);
> 

I have not checked the code myself but if these this is the way area 
lights are transformed this is indeed wrong.  You should post a bug report.

-- Christoph

Post a reply to this message

Hi Christoph,

Thanks, it's good to know that someone else thinks this is the problem code.

I've submitted a bug report to povray.bugreports, so we'll have to wait to
see if it gets past the moderator :-)

Bye for now,

Mike Andrews.

Christoph Hormann <chr### [at] gmxde> wrote:
> Mike Andrews schrieb:
> > Hi Lucas,
> >
> > Thanks for this, I think you've identified where the problem lies!
> >
> > The lines
> >
> >   MTransPoint (Light->Axis1,     Light->Axis1,     Trans);
> >   MTransPoint (Light->Axis2,     Light->Axis2,     Trans);
> >
>
> I have not checked the code myself but if these this is the way area
> lights are transformed this is indeed wrong.  You should post a bug report.
>
> -- Christoph

Post a reply to this message