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

[Lisa Sobierajski Avila]

Hello Michael,

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


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... :-)


Lisa



At 09:55 AM 8/9/2000, Michael Halle wrote:

>Lisa,
>
> > What if you have a transformation applied to a light, and you call
> > GetFocalPoint - do you get the focal point as it is set (before it is
> > transformed)? Is so, then transforming a light will break a bunch of 
> things
> > (notably all of volume rendering). I think we need to compare the 
> setting /
> > getting of the light  position / orientation information with that of the
> > prop - are they similar or will it confuse users?
>
>I followed the convention that if you Set a value like
>Position/FocalPoint, you should be able to Get the same value back.
>That's the same as setting a Prop3D's Position and setting its
>UserMatrix: Getting the Position doesn't return the transformed
>postion, since that would be confusing.  So, I think lights are
>consistent with Props.  I did add the convenience functions
>GetTransformedPosition and GetTransformedFocalPoint to help: the
>change could be made almost universally.
>
>However, I do agree that it would be much easier for backwards
>compatibility if Getting the Position and FocalPoint gave you the
>transformed coordinate.  Is there a way to resolve this problem?
>
> > Is it really necessary to break up the light collection into two? Can't
> > that functionality be achieved with a flag in the light? I think this 
> would
> > solve some of your problems.
>
>I think you're right.  The primary reason I did it was to deal with
>existing code that calls GetLights() and then sets the first light's
>position to the camera's position. If it does that to the
>camera-centric light, that's wrong behavior.  This problem is really
>sticky since each interactor had to reimplement the camera-tracking
>functionality, and none I've seen to what you really want to do.  Once
>it comes down to it, turning the first light in the list into a
>headlight without even seeing if it is on is fragile and arguably
>incorrect behavior.  It's really hard to fix the underlying lighting
>model while still allowing the existing code to function.
>
>Possible solution
>
>Okay, how about this.  vtkLight gets a flag like CAMERA_LIGHT,
>SCENE_LIGHT, and HEADLIGHT.  HEADLIGHT is the old behavior: always
>move the light to the camera position.  A "legacy" request to
>GetLights() returns a *copy* of the lights, transformed by whatever
>the light's matrix is, and with all lights set to be a SCENE_LIGHT.
>The renderer will take care of getting the camera's information,
>updating the lights, and copying them.  Existing code doesn't have to
>know about the transform, and CurrentLight's pesky behavior will be
>defeated because it is working on a copy.  If LightFollowCamera is set
>on the interactor, then all lights are assumed to be HEADLIGHTs when
>GetLights() is called.  The default light is a HEADLIGHT.
>
>GetLights() will have an optional new flag to return the real list of
>lights with their original CAMERA_LIGHT, SCENE_LIGHT, or HEADLIGHT
>flags and transforms intact.  That way, more sophisticated
>exporters/renderers will be able to know what kind of light a light is.
>
>With this change, the only incompatibility is that the legacy
>GetLights() returns a copy of the actual lights, so no changes can be
>made to the list.  I don't see any VTK code that uses that capability.
>
>Does that sound like a better plan?
>
>Thanks for your ideas!
>
>                                                         --Mike