FW: vtkAssembly Woes

[Will Schroeder]

Hi Folks-

Picking has been heavily reworked...a generous customer paid for the work and has contributed them back to the community. These will be checked in shortly (I'm hoping next week). The copy of actors has been eliminated, UserMatrix is no longer trounced on, BuildPaths, etc. makes much more sense now. Pick information includes a fully qualified path (in the sense of an assembly) and the transformations associated with each node in the path.

I've been a little reluctant to check them in sooner because there are some pretty big changes (over 60 files involved including several new classes). I'll accelerate the check-in process if I know that I can depend on some volunteers to help debug and test the stuff.

Will

At 09:33 AM 5/18/00 -0400, Tom Radcliffe wrote:


>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

--------------------------------------------------------------------
This is the private VTK discussion list. Please keep messages on-topic.
Check the FAQ at: <http://public.kitware.com/cgi-bin/vtkfaq>
To UNSUBSCRIBE, send message body containing "unsubscribe vtkusers" to
<majordomo at public.kitware.com>. For help, send message body containing
"info vtkusers" to the same address.
--------------------------------------------------------------------