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

[Michael Halle]

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