[vtk-developers] vtkMatrix4x4 and VisSimActor

[Mark Beall]

I think the best approach here is to have the transformation matrix
be null if the actor (actually Prop3D) is supposed to be in world 
coordinates, 
similar to the UserMatrix that's already there. This falls under the
category of "if you're not using it, you shouldn't have to pay for it".

mark


On 6/22/01 5:36 PM Simon Warfield (warfield at bwh.harvard.edu) wrote:

>On Fri, Jun 22, 2001 at 04:16:41PM -0400, obara wrote:
>> Hi Folks,
>> 
>> John Tourtellot's email on June 18,2001 stated :
>> 
>> >Issue 2: glMultMatrixd() is called by vtkOpenGLActor::Render(). In the 
>> >general case, this is needed to render the actor in the right place. In 
>> >our applications, however, the actors nearly always have an identity 
>> >matrix, making the glMultMatrixd() call unnecessary. (Mark Beall posted  
>> >this to the developers list on May 17, but there were no responses.) 
>> >
>> >Action: We added an "identity" flag to the vtkMatrix4x4 class to keep 
>> >track of its state. It's not ideal since the matrix elements in this 
>> >class are public (i.e., someone can change the matrix without the class, 
>> >or our identity flag, knowing about it). We also, of course, modified
>> >the 
>> >vtkOpenGLActor::Render() method to check the matrix identity flag before 
>> >calling glMultMatrixd(). 
>> 
>> This introduces a problem with the way that the matrix class is 
>> implemented.  The actual matrix of floats is public and therefore makes 
>> it impossible in general to track the state of the Matrix.  This is only 
>> a problem of course if the anyone directly manipulates the matrix and it 
>> seems (based on a quick grep of vtk's source) that some classes do 
>> directly manipulate the matrix's contents.
>> 
>> The main reason for testing if the matrix is an identity transform is to 
>> see if geometry needs to be transformed and in the case of an 
>> OpenGlActor, to see if a matrix needs to be pushed on the transformation 
>> stack.
>> 
>> There seems to be 2 possible approaches in getting around this efficiency 
>> issue:
>> 
>> 1. If the actual matrix part is protected, as a result the user can 
>> "tell" the matrix it is identity and if the matrix object is modified via 
>> its member functions then it could set its state not to be identity. 
>> 
>> 2. The alternative is to change Actor to have an member function that 
>> tells the actor it's coordinate system is the same as the world system 
>> (in this case it doesn't even create a transformation matrix at all) or 
>> that its defined in its own modeling coordinate system (internally it 
>> then can allocate a transformation matrix). 
>> 
>> The problem with 1 is that a bunch of code will not compile.  The problem 
>> with 2 is that a function asking for the transformation of the actor 
>> would need to see if they were given a null pointer which is not done 
>> (since currently it could never happen) - hence with option 2 we would 
>> have to deal with run-time errors.
>
>Some other ideas 
>
>3. Require the code that changes the public elements of the transform to
>  also change the isIdentityTransform flag to be the correct value
>
>4. The check for isIdentityTransform could be a function that looks at the 
>   matrix elements
>
>> Any ideas as to how we (the vtk community) should proceed ?
>
>I think option 1 is desirable because it will make it easy to get good
>performance.  Perhaps the change should be introduced in the event of a 
>major 
>vtk update ?
> 
>> Bob
>> 
>> 
>> Robert M. O'Bara
>> Senior Software Engineer
>> Simmetrix Inc.
>> 1223 Peoples Ave.
>> Troy, NY 12180
>> 
>> Lab: (518) 276-2867
>> Main Office: (518) 276-2729
>> 
>> 
>> _______________________________________________
>> vtk-developers mailing list
>> vtk-developers at public.kitware.com
>> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>-- 
>Simon
>
>_______________________________________________
>vtk-developers mailing list
>vtk-developers at public.kitware.com
>http://public.kitware.com/mailman/listinfo/vtk-developers