[vtk-developers] camera lights modified

[Michael Halle]

Hey there,

I modified my design for cleaning up lights in vtk, based on comments
from the list.  Here's what I've done in my copy of the sources; I'd
appreciate further input on the changes and a couple of points.

I've added a flag on each light called LightType.  A can be of one of
three types:

HEADLIGHT - the position and focal point of the light are reset by
the renderer to be the current camera's position and focal point.
(This light corresponds to vtk's current default light.)

SCENE_LIGHT - the position and focal point of the light are taken
directly from the light, and transformed by the light's transformation
matrix if it is set.  The matrix is currently never set for scene
lights, so they are always in world space.  (This light is a standard
light in current vtk, provided LightFollowCamera is off.)

CAMERA_LIGHT - the position and focal point of the light are given in
a coordinate space where the camera is at (0, 0, 1), the focal point
is at (0, 0, 0), view distance is 1, and up is (0, 1, 0).  Every time
the scene is rendered, the light's transformation matrix is set to
correspond to the camera location of the renderer's current camera.

If vtkRenderer sees no light exists just before rendering, it creates
a default light of type HEADLIGHT.  The existing interactor code that
modifies the light's position and focal point is now redundant: it
does exactly the same thing to the default light that the renderer
does automatically.  For this default case, the change is backward
compatible.

Similarly, both headlights and scene lights (with no transform matrix)
should be rendered correctly by all code, except for one case.
Currently, if the user creates one light, and LightFollowsCamera is
set in the interactor, this light will move with the camera.  If the
user creates more lights, only the first one will be tracked by the
camera (and only if LightFollowCamera is on).  Under the new change,
whether the light tracks the camera or not is a property of the light.

Question 1: should a user-created new light by default be a headlight
or a scene light?

Question 2: does any existing code rely on the fact the first of the
user's light is a headlight and all lights afterward are scene lights?
This behavior doesn't really seem desirable or intuitive; I couldn't
imagine someone really wanting it.  It's possible that some tests
might fail, though.

To support camera lights and scene lights with transform matrices, existing
some code in vtk will have to be changed.  Essentially all calls to 
vtkLight::GetPosition() and vtkLight::GetFocalPoint() should become
vtkLight::GetTransformedPosition() and vtkLight::GetTransformedFocalPoint().
That change is backwards compatible: existing code still works, since
camera lights don't exist. Only when people start using camera lights
with unupdated code may lighting irregularities occur.  Since vtkLight
is already modified, the changes can happen now.

Sometimes, you'd like to share lights between renderers.  That still
works, and even better than it does now.  Say you have two renderers.
By default, the headlights and camera lights will track the cameras in
both renderers.  I think that's intuitive behavior.  Other times,
you'd like the lights to track only the camera in one renderer, and
have those lights appear in those world space positions in the other
renderer. (For example, in a virtual endoscopy application, a
headlight on the camera in the local view might be seen from the side
in the global view).  To get this effect, each renderer has a
LightFollowCamera flag.  If the flag is cleared, the renderer won't
touch its light's positions, focal points, or transforms.  In the
above example, the local view would have LightFollowCamera on, while
the global view would have it off (global view should be rendered
second).

In other words, camera tracking of light position has been pushed down
from the interactor down to the renderer (with a little help from the
camera and light).  Flags on the renderer and each light say how
tracking should happen.

Question 3: What should be done about LightFollowCamera on the
interactors?  Should it apply to all renderers using that interactor?
Should it set the LightFollowCamera flag on the just current renderer?
What if LightFollowCamera isn't explicitly set on the Interactor?
Should the current behavior be emulated, even though the existing
paradigm isn't very flexible?  Can it be ignored altogether, assuming
our default behavior is reasonable?

If we can agree on a workable approach, what's the best way to bring
the changes on line?

Thanks for your help.


							--Mike