[vtk-developers] bounds calculation in vtkActor

[Rusty Blue]

Changes and a test pushed to gerrit... (finally).  Without the changes, the
test result would have incorrectly set clipping planes.

Rusty

-----Original Message-----
From: Bill Lorensen [mailto:bill.lorensen at gmail.com] 
Sent: Thursday, October 28, 2010 12:18 AM
To: Aashish Chaudhary
Cc: Rusty Blue; vtk-developers at vtk.org
Subject: Re: [vtk-developers] bounds calculation in vtkActor

I would push both the changes and the test to gerrit.

Bill

On Wed, Oct 27, 2010 at 10:12 PM, Aashish Chaudhary
<aashish.chaudhary at kitware.com> wrote:
> Bill,
>
> On Wed, Oct 27, 2010 at 8:35 PM, Bill Lorensen <bill.lorensen at gmail.com>
wrote:
>
> What Rusty (in his reply) +
>
>> Rusty,
>>
>> I would think it should be consistent across ImageActor and Volume.
>
> I agree but I guess it would be nice to know if someone else ran into
> similar issues (yes / no). It is hard to imagine though but not
> impossible. When I worked on a project (8 months back with Rusty) I
> took control over the matrix multiplication and division by
> homogeneous coordinate and hence this problem never showed up.
>
>> I
>> also suggest you push it to Gerrit for code review. And you should
>> provide or modify a test to illustrate it.
>
> Would you prefer test to go to the Gerrit or  in the email thread?
>>
>> Bill
>>
>> On Wed, Oct 27, 2010 at 8:29 PM, Rusty Blue <rusty.blue at kitware.com>
wrote:
>>> Folks,
>>>
>>>
>>>
>>> We're setting the UserMatrix of an actor to... surprise, surprise...
>>> transform the actor.  Nothing exciting, right?
>>>
>>>
>>>
>>> Wrong, because the last row of our matrix is not the trivial [0 0 0 1].
>>> This is handled well enough in OpenGL, but the bounds calculation (in
>>> vtkActor::GetBounds()) is seriously wrong because it is doing a linear
>>> transformation of the bbox it gets from the mapper (Transform is a
>>> vtkLinearTransform):
>>>
>>>
>>>
>>>     fptr = bbox;
>>>
>>>     for (n = 0; n < 8; n++)
>>>
>>>       {
>>>
>>>       this->Transform->TransformPoint(fptr,fptr);
>>>
>>>       fptr += 3;
>>>
>>>       }
>>>
>>>
>>>
>>> The easiest fix I found for the issue was the following (force call to
>>> InternalTransformPoint of vtkHomogeneousTransform):
>>>
>>>
>>>
>>>     fptr = bbox;
>>>
>>>     this->Transform->Update();
>>>
>>>     for (n = 0; n < 8; n++)
>>>
>>>       {
>>>
>>>
>>>
this->Transform->vtkHomogeneousTransform::InternalTransformPoint(fptr,fptr);
>>>
>>>       fptr += 3;
>>>
>>>       }
>>>
>>>
>>>
>>> The change doesn't cause any tests to fail (for me)... and it seems like
a
>>> reasonable change (perhaps should be made in vtkImageActor and vtkVolume
as
>>> well?)... but I wanted to put it out there (before I committed and
pushed
>>> the change), because it is seriously likely that I'm not considering
some
>>> other special "situations", or perhaps the "right" way to fix this, or
????
>>>
>>>
>>>
>>> Rusty
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.vtk.org/mailman/listinfo/vtk-developers
>>>
>>>
>>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.vtk.org/mailman/listinfo/vtk-developers
>>
>>
>
>
>
> --
> | Aashish Chaudhary
> | R&D Engineer
> | Kitware Inc.
> | www.kitware.com
>