[vtkusers] RE: Multiple Renderers

[Sebastien BARRE]

At 4/29/2002 06:33 PM, Dean Inglis wrote:

>I am trying to use one RenderWindow with 4 Renderers: the goal is to show 3
>image plane widgets in one large viewport and 3 image plane outputs (not
>implmented yet) to an Actor2D/ImageMapper pair in each of the other 3
>viewports.  A similar pipeline might be an texture mapped image volume and 3
>Actor2D/ImageMapper pairs showing some slices from the volume.
>
>The problem seems to be that the widget

what do you mean by "the widget" ? Are you using Tk (i.e. vtkTkRenderWidget 
?), or just an ImagePlaneWidget inside a RenderWindow ?

>only knows about the interactor for
>the whole render window and not the specific renderer it should ideally be
>associated with.  Is there a way to set the widget/interactor to a specific
>renderer ?

The big picture is:

- a vtkRenderWindowInteractor (say, iren) is typically associated to a 
vtkRenderWindow (say, renWin).

- a vtkRenderWindowInteractor has special attributes that can be used to 
represent a GUI event in a generic way (through Set/GetEventPosition(), 
Set/GetControlKey(), Set/GetEventInformation(), etc)

- a concrete implementation of vtkRenderWindowInteractor (for example, 
vtkWin32RenderWindowInteractor) handles system-specific GUI events, 
represent them in a generic way by setting the attributes I mentioned 
above, then invoke the corresponding VTK event (for example, MouseMoveEvent).

- a vtkInteractorStyle (istyle) is associated to a 
vtkRenderWindowInteractor. By doing so (i.e. istyle->SetInteractor(iren)), 
it adds observer to the vtkRenderWindowInteractor so that it can 
intercept/listen/observe/receive/etc. some generic VTK events. For example, 
istyle will listen to MouseMoveEvent from iren. Once iren invokes a 
MouseMoveEvent, the isyle's callback is called 
(vtkInteractorStyle::ProcessEvents).

Inside that callback (a static func), two informations are know: 'rwi', the 
address of the object that invoked the event (here, iren), and 'self', the 
adress of the style (here, istyle).

At this point, the informations related to the event are retrieved through 
rwi, using GetEventPosition, GetControlKey, etc.

Now two things may occur:

- the style itself can invoke an event if it has observers for that event: 
in that way, you can override the behaviour of the style by intercepting 
the MouseMoveEvent.

- if there are no observers, it will call a default function, something 
like vtkInteractorStyle::OnMouseMove() in that case, a function that 
(again) you could have redefined in a subclass of a style. This function 
has parameters for the moment (ex: x, y, ctrl, shift), but I'm about to 
remove them, once again because the event informations should be retrieved 
where they are, i.e. at the interactor (rwi) level, not by duplicating 
(half of) the event infos inside the style (imho).

In most interactor styles, both ways lead to some piece of code that will 
initially try to find the *renderer* in which the event occured, by calling 
vtkInteractorStyle::FindPokedRenderer(x, y) (or FindPokedCamera(), that I'm 
about to remove also, so stick to the first one :). This will set the 
internal attribute CurrentRenderer. I guess you should check for it, and if 
it is not set, then there is probably a problem in the style (depending on 
its state).

Since there is no Get method for this one, I'll add one asap. Do *not* use 
CurrentCamera, CurrentLight, etc, I'm about to remove these also: these 
classes have grown organically by adding more and more duplicate state 
attributes, making the whole hierarchy difficult to maintain or grasp (to 
say the least). The only thing you need is CurrentRender, (which will leads 
you to the active camera, first light, etc.)

Does it help ?

--
Sebastien Barre