Plans for the new vtk*Transform classes

[David Gobbi]

Jeez, I kinda put my foot into my mouth at the end there and
didn't realize until a few minutes after the post had been sent.
What I meant is that I consider the pure math literature to 
be the ultimate authority on these nitty-gritty details.

 - 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, David Gobbi wrote:

> 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
> > 
> 
>