Plans for the new vtk*Transform classes

David Gobbi dgobbi at irus.rri.on.ca
Tue Apr 18 12:12:09 EDT 2000


Hi Jim,

I'm quite confident that the code for the normals is correct, and
the behaviour is the same as before.
So, we come down to the different ways to interpret vectors.  Here are
the three that I considered while writing the code.

1) A vector represents a point at infinity, i.e. represented by a
   homogenous coordinate with w=0.  Implicitly by the fact that it
   is a homogenous coordinate, the 'length' of this vector is unimportant
   because homogenous coordinates can be arbitrarily scaled.
   This is not what we want in VTK -- if people want to represent points
   at infinity, then they should stick with homogenous coordinates to
   guarantee that the math is done right.  Such an interpretation cannot
   be used with non-perspective nonlinear tranfsormations because such
   transformations are almost always local, not global.
   My code works for these vectors only under linear transformations.

2) A vector represents the (x,y,z) displacement between two points.
   In nonlinear transformations (this includes perspective), you 
   need to know where one of the points is in order to do the
   transformation.  This is a valid interpretation of a vector
   (as far as I know) but since you need to know one of the points
   anyway, why not just transform the two points and then subtract
   them afterwards?
   My code works for these vectors only under linear transformations.

3) Finally, a vector can represent the magnitude & direction of 
   an infinitesimal displacement, i.e. a derivative.  Again,
   in nonlinear (inc. perspective) transformations you need to
   associate a point with the vector in order to tranform it.
   I feel that this is the most 'pure' definition of vector,
   so this is the one I chose. 

I never thought of treating a vector as a tangent, but such
an interpretation implies that it is perpendicular to a normal,
both before and after.  This doesn't fit into the above 
categorizations -- I'll have to work through it to understand
the implications.  But the interpretation of a vector as a
tangent seems more contrived than the three interpretations above.

Most VTK users only work with linear transformations, and they
won't have to concern themselves with interpretation so much.
As developers, however, we _do_ need to worry about this stuff.

If someone is willing to dig up references that either support or
conflict with what I've done, that would be great.  Computer
graphics texts are probably not the most appropriate here...
good, solid math texts are more likely to get it right.

 - David

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

On Tue, 18 Apr 2000, Miller, James V (CRD) wrote:

> Matt was just looking through the new transform code and brought to my attention that I was not quite
> accurate in my previous message.  The normals in the new transform code are being handled properly in
> terms of using the transpose of the inverse matrix.  However, vectors are now being multiplied by the
> upper 3x3 whereas before they were transformed by the transpose of the inverse.
> 
> So we do have a difference between how vtk handles transforming vectors now and how it used to
> transform vectors.  Does anyone know if we are doing it correctly now? Or were we doing it correctly
> before?  I can see an argument for only using the transpose of the inverse for the normals since
> normals must remain perpendicular to some surface.  Vectors would not have this additional
> constraint.  Does this jive with your understanding?  If so, then the new transform code is fine and
> we can move onto the new changes that David wants to pursue. (I still want a new test that will make
> sure normals and vectors are transformed properly, whatever "properly" is).
> 
> Jim
> 
> -----Original Message-----
> From: Miller, James V (CRD) 
> Sent: Tuesday, April 18, 2000 8:12 AM
> To: 'David Gobbi'; vtk-developers at public.kitware.com
> Subject: RE: Plans for the new vtk*Transform classes 
> 
> 
> Before we get too far down this path, I noticed yesterday that the new transformation code is not
> transforming vectors and normals the way vtk used to.  The current code in vtkLinearTransform simply
> multiples a vector or normal by the upper 3x3 portion of the 4x4 matrix.
> 
> vtk used to multiple vectors and normals by the transpose of the inverse of the 4x4 matrix.  This
> technique is described in Graphics Gems Volume 1, page 541. The discussion has to do with normal
> vectors needing to transformed by the transpose of the inverse of the matrix that is used to
> transform the tangent vectors.
> 
> (I have not looked at whether an equivalent methodology is possible with the general transform
> classes.)
> 
> So things have changed in vtk and I am disappointed that none of our tests were able to pick this up.
> So we need a new test and we need to determine whether the new code needs to be brought back in line
> with the old code.
> 
> Jim
> 
> -----Original Message-----
> From: David Gobbi [mailto:dgobbi at irus.rri.on.ca]
> Sent: Monday, April 17, 2000 11:37 PM
> To: vtk-developers at public.kitware.com
> Subject: Plans for the new vtk*Transform classes 
> 
> 
> Hi all,
> 
> As people have probably noticed, I've been doing a fair bit of
> work adding new geometrical transformation code to VTK.  My goal
> is to eventually replace much of the existing 4x4 matrix code
> in the VTK classes (particularly the Camera, Prop3D, Renderer,
> and Picker) so that it uses the new transform classes.
> 
> So, since this is going to change VTK quite a bit, it's probably a good
> idea if I explain why I want to do it.  Here are the reasons.
> 
> 1) It will drastically simplify many core VTK classes.  If anyone
>    wants an example, just yesterday I removed over 250 lines of
>    code from vtkCamera -- almost 1/4 of the file.  The calculations
>    that used to be done in these 250 lines of code is now done
>    by 5 methods in vtkProjectionTransform that total 130 lines of code.
> 
> 2) Efficiency - by pipelining transforms, it is possible to guarantee
>    that they are only updated when they have to be (most VTK methods
>    will re-generate transforms each time they are requested).  It is
>    hard to say what real impact this will have on rendering speed, though.
> 
> 3) To make it easier to move between the various coordinate systems in
>    VTK.  Wouldn't it to be nice, for example, to be able to transform
>    a point from world coordinates to mapper coordinates just by doing
>  
>    actor->GetTransform()->GetInverse()->TransformPoint(worldXYZ,dataXYZ)
> 
>    or to be able to move a whole bunch of display coords to world coords
>    using
> 
>    transform = renderer->GetDisplayToWorldTransform()
>    transform->TransformPoint(point0,point0)
>    transform->TransformPoint(point1,point1)
>    ...
> 
> 4) To make new things possible in VTK.  For example, imagine that you
>    want to write a flight simulator in VTK, and have to set up a spot
>    plane.  Well, you could write a vtkFollowerTransform that will 'follow'
>    its input vtkTransform but will incorporate damping factors and the
>    like to make it 'follow' the lead plane just like a real spot plane
>    would.  This requires that A) you can get a pipelined transform from
>    a vtkActor, which is currently not possible, and B) that the
>    'spot-plane' vtkActor has a SetUserTransform() method that can accept
>    a pipelined transform.  (Note: every single one of the transforms in
>    the vtkGeneralTransform heirarchy is a 'pipelined' transform, that part
>    of the work is already done).
> 
> 5) Closely linked to (4), it will make VTK much easier to use and much
>    more featureful for real-time animation.  My area of expertise is
>    real-time guidance for neurosurgery, and just about everything I do
>    involves a dynamically changing scene rather than static visualization.
>    And VTK is _very close_ to being an ideal package for dynamic
>    visualization.
> 
> 6) Finally, for myself, I would like to become intimately familiar with
>    VTK internals.  This is partly due the fact that I plan to continue
>    using VTK to develop surgical guidance applications for some years to
>    come, and am pretty darn sure that there are still a number of 
>    significant bugs left in VTK.  The nightly regression testing is all
>    well and good, but many bugs that aren't caught by regression tests
>    stick out like a sore thumb when you read through the code.
> 
> 
> Now, one big problem is the changes required, especially if they are to
> be done right, are pretty massive.  As far as I can see, though, it should
> be possible to implement them without breaking compatibility.  So, is
> anyone interested in helping out?  In particular I would be greatful if
> someone was willing to write tcl regression tests for any new features
> (e.g. the vtkProjectionTransform could use one) or to modify existing
> vtk classes and examples to use the new transform classes and methods.
> Or someone could help with the required core changes to vtkProp3D,
> vtkRenderer etc.  but I'd have to warn such a person that I'm an
> extreme nitpicker when it comes to code and even more so when it comes
> to design.
> 
> Opinions are welcome.  I'll step off my soapbox now.
> 
>  - David
> 
> --
>   David Gobbi, MSc                    dgobbi at irus.rri.on.ca
>   Advanced Imaging Research Group
>   Robarts Research Institute, University of Western Ontario
> 




More information about the vtk-developers mailing list