[vtk-developers] fixing camera-tracking lights in vtk

[Lisa Sobierajski Avila]

Hello Michael,

I guess what I thought was that HEADLIGHT would be a type of light that 
would essentially ignore the position / focal point of the light and 
recompute it all the time. I think I need to look back through your 
explanations more carefully....

Lisa


At 11:06 AM 8/9/2000, Michael Halle wrote:

>Lisa wrote:
>
> > I still don't see the legacy problem - if you change the default behavior
> > of vtk to place one headlight in the list when no lights are in the
> > collection for the first render, then it should be OK for someone to get
> > this light and change its position. This may not function exactly the way
> > you want it to - but it didn't before either (if you set the position of
> > the first light, and you have an interactor, and lights follow the camera,
> > then as soon as you move the light position jumps) If you want to move the
> > light, it should not be a headlight, and therefore you should create it
> > yourself rather than relying on VTK to create it for you.
>
>The problem is that the code that moves the light moves it in world
>space.  If the light is a camera light, its position is defined in
>camera space (not exactly, but close enough). If the code sets the
>light's camera space position to be the world space location (instead
>of camera space location), the light won't be in the right place.  The
>point of adding the transformation matrix to the vtkLight is to be
>able to maintain the spatial relationship between the camera and the
>light explicitly.  For a CAMERA_LIGHT, the Position and FocalPoint are
>specified with respect to the camera in the CameraLight coordinate
>system, which I think is very natural.
>
> > Many of the examples that move the first light are simply doing it
> > because they move the camera and need to reposition the light. This
> > can be removed from most examples with your new implementation.
>
>Since such an update of Position and FocalPoint isn't benign, and code
>outside the VTK core might do it without knowing about the new light
>types, it's important to keep the simple code from doing damage.  It's
>not just extraneous code to remove.  That's why a copy of the light list,
>transformed into world coordinates for legacy code, will probably work
>fine.  (He says hopefully.)
>
> > BTW, I never liked the position / orientation / scale methods in prop
> > because I think they are difficult to understand and work with. So don't
> > take my criticism of your methods personally! :-) I suppose in Prop I 
> would
> > be happier is Position was called Tranlation, and Orientation was called
> > Rotation - with the implied understanding that you were specifying a 
> matrix
> > to be applied to the prop by specifying and x,y,z translation, and x,y,z
> > rotation and an x,y,z scale that are applied in fixed order. Then
> > GetPosition would return something different - the transformed location of
> > the origin. But I guess it is too late for such major changes... :-)
>
>Luckily, the user won't have to deal with the transformations on
>lights directly -- the transform is just the mechanism for changing
>the coordinate space of the light.
>
>Thanks for your ideas and help!
>
>
>                                                         --Mike