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

[Michael Halle]

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