FW: vtkAssembly Woes

[Tom Radcliffe]

Gerald Dalley wrote:

> 
> 1) The render window interactors don't seem to be able to move the entire
> assembly around as a single unit.  For example, if I spin the main object
> while in actor-select mode, just the main object spins, but not the other
> objects in the assembly such as the point normals.  If I turn off the
> pickability on all of the actors in the assembly but leave the visibility on
> for the assembly as a whole, nothing is pickable.  What I'd really like to
> be able to do is only make certain actors in the assembly pickable, and then
> be able to control whether interactions modify just that one actor, or the
> entire assembly.
> 

This problem is due to the one you point out below -- you are
interacting with a copy of the main actor, not the main actor. 
BuildPaths creates a flat list of actors, so the parent/child
relationships no longer hold.  The way I've gotten around this is to
subclass vtkAssembly as described below, and then subclass
vtkInteractorStyleTrackball to use the additional information my
subclassed assembly provides to get at the real actor and interact with
it.  This still has problems when trying to interact with the parts of
an assembly rather than the main actor.

> 2) The much bigger problem for me is that I need to have the ability to read
> back the view transformations from the actors.  My application allows the
> user to manipulate the position and orientation of individual actors, then
> performs operations that are dependent on that information.  After digging
> through the source code with a debugger, I found out that vtkAssembly makes
> copies of the actors, and those copies are the actors accessed by the render
> window interactors.  I don't see a good, reliable way of getting at those
> actors programmatically without reverse-engineering BuildPaths or something
> like that.
> 

Reverse-engineering BuildPaths is possible (I did it) but not a good
solution.

These problems still exist in VTK 3.1.  You can subclass vtkAssembly and
over-ride BuildPaths to create a map between the copies and the real
actors -- this is kind of ugly because it just means copying BuildPaths
from the base class and adding a few lines to populate the map where
copies are made.  Then your interactor can look up the real actor in the
map and interact with it.  Because DeletePaths and UpdatePaths are not
virtual you have to keep track of the recursion depth by hand (that is,
with a member variable in the derived class) and clear the map whenever
you find BuildPaths being called at the top level.

There are further difficulties in that both interaction and path
building uses the user matrix of the actors, so if you interact with a
part of an assembly, the next time build paths is called your changes
will get wiped out unless you modify the interaction logic to use
SetPosition and RotateWXYZ rather than SetUserMatrix, but doing this
introduces further complications whose details I now thankfully only
vaguely remember -- something about the fact that you're interacting
with the copy in a potentially rotated and translated co-ordinate system
but the real actor is in an unrotated, untranslated one.

The code I've written to do all this is no longer very VTK-like (it
includes a completely non-VTK editor class to put all the funky logic in
a place where I could think about it without worrying about much of
anything to do with VTK) and has lots of external dependencies --
including the STL -- that make it a less than general solution.  I hope
this verbal description is helpful -- there may be better ways of doing
this.  I tried at one point to understand the logic of BuildPaths and
infer from the place of the copy in the paths what real actor it had
come from, but this was very painful to do and ultimately too fragile to
be of value, especially when using nested assemblies.

--Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: radcliffe.vcf
Type: text/x-vcard
Size: 364 bytes
Desc: Card for Tom Radcliffe
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20000518/6f117cc6/attachment-0001.vcf>