[vtk-developers] vtkLODProp3D and vtkProp3D:SetUserTransform ? (+ GetActors bug ?)

David Gobbi dgobbi at irus.rri.on.ca
Mon Jul 17 16:52:52 EDT 2000


Just a few quick notes about vtkProp3D::SetUserTransform():

1) It almost certainly needs some minor repairs since the Assembly
   changes, in terms of MTime checks

2) Right now, both the UserTransform and the UserMatrix contribute to
   the final Prop3D Matrix.  THIS WILL CHANGE.  For simplicity, the
   UserMatrix and UserTransform should both refer to the same
   transformation, i.e. GetUserMatrix() and
   GetUserTransform()->GetMatrix() will return the same address.
   I've discussed this with Will, I'm sure that most people will agree
   that there is no need for the two to be separate.  I already have the
   details worked out, I just have to write the code.

3) I'll make the changes sometime over the next three weeks -- I promise.
   (or sooner, if I'm pushed).

Finally, to answer the unavoidable question of 'why do we need a 
UserTransform anyway?':

1) To connect actors to a vtkAbstractTransform-type pipeline.
   The vtk*Transform pipeline has some things in common with 
   the Assembly mechanism, but is much more general: you can
   chain a series of transforms together, but unlike assemblies,
   you can use the final transform anywhere (i.e. to transform
   vtkPolyData, on a vtkImplicitFunction, to resample vtkImageData,
   anywhere that there is a SetTransform method to hook into).  Also,
   the transforms that you chain together do not
   necessarily have to be 4x4 matrix transformations, they can be
   thin plate splines or whatever you wish.  Of course, type checking
   is used to ensure that you don't use a thin plate spline etc. transform
   on a vtkProp3D.

2) Take a look at the definition of 'transform' vs. 'matrix'
    Transform - maps one coordinate system to another
    Matrix    - a 4x4 array of numbers (which can describe a transform)
   Really, the users should be permitted to ignore 4x4 matrices in nearly 
   all cases -- they must be part of the implementation, but 
   the highest-level portions of the VTK interface should probably
   avoid them.

Also, I'm hoping to provide a GetTransform method for vtkProp3D as
well (to complement or replace GetMatrix).  This transform would be
pipelined, i.e. it would automatically update whenever the actor
moved without it being necessary to call GetTransform() again.  This
would allow you, for example, to take an actor's transform and feed it
into a vtkImplicitFunction used to clip data.  The transform pipeline
would take care of all updates.

There are a massive number of changes that I would like to make to VTK
over the next year, but it will be a few more months before I dig in
again.  Partly due to lack of time, but mainly to give people time to
become familiar with the changes I have already made.  

 - David

--
  David Gobbi, MSc                    dgobbi at irus.rri.on.ca
  Advanced Imaging Research Group
  Robarts Research Institute, University of Western Ontario

On Mon, 17 Jul 2000, Sebastien BARRE wrote:

> I found the bug Lisa (see below).
> Maybe will David Gobbi tell us more about what to do with the Transform 
> modification time.
> 
> >During a render, the current matrix of the LODProp3D is pushed down onto 
> >the selected LOD:
> >
> >   // Push the matrix down into the selected LOD
> >   vtkProp3D *p = this->LODs[this->SelectedLODIndex].Prop3D;
> >   if ( p->GetMTime() < this->GetMTime() )
> >     {
> >     this->GetMatrix( p->GetUserMatrix() );
> >     }
> 
> I see
> 
> >When you call this->GetMatrix() does this include the transform's matrix 
> >as well?
> 
> Yes it is, BUT when you do...
> 
>    if ( p->GetMTime() < this->GetMTime() )
> 
> ...it does not guarantee that 'this' has been modified when you have 
> modified its UserTransform. I've just checked that out : if you modify the 
> user transform, the GetMTime remains the same, therefore the matrix is not 
> pushed down, and the transformation is not reflected.
> 
> If the cost of the matrix copy is small, then maybe should we remove the 
> test. If not, introduce a new one managing the MTime of the UserTransform...
> 
> >I specifically avoided adding any access methods to the internally created 
> >props so that users could not modify them in any way.
> 
> I understand, but what about the "power users" ? :) I mean, there is a lot 
> of black magic behind the LODProp3D, creating actors, volumes and so on is 
> not a small thing, there is a lot of case when one usually customize the 
> actors, or just want access to them. Hence, I think an access method would 
> be nice. But these are just my 2 cents.
> 
> Thanks for your help
> 
> Sebastien
> 
> _______________________________________________
> vtk-developers mailing list
> vtk-developers at public.kitware.com
> http://public.kitware.com/mailman/listinfo/vtk-developers
> 





More information about the vtk-developers mailing list