[vtkusers] Re: bug in vtkVolume's user matrix vs zbuffer resolution

[Lisa S. Avila]

Hello Alex,

One other thing to note is that the transfer functions are not independent 
of scale. The scalar opacity function indicates how much opacity is 
accumulated per unit length. Scaling your volume by 0.1 means that you need 
to adjust this table accordingly.

Lisa

At 11:05 AM 6/18/2001, Lisa S. Avila wrote:
>Hello Alex,
>
>I believe the comment stating that the sample distance is in voxel 
>coordinates is out-of-date. When Actor and Volume merged (quite a long 
>time ago) the Volume obtained a UserMatrix and 3 component scaling, and 
>the sampling distance changed to world distance. So, if you scale your 
>volume by 0.1 you should do the same to your sampling distance.
>
>One limitation (this is true of Actors and Volumes) is that non-uniform 
>scaling is not handled correctly for gradient calculation. For correct 
>rendering, change the aspect of the volume in the ImageData rather than 
>the Volume.
>
>Lisa
>
>
>
>
>At 10:57 AM 6/18/2001, alext at win.tue.nl wrote:
>
>
>
>>   Hello all,
>>
>>   I have stumbled on a very unexpected behavior of the vtkVolume's transform
>>with respect to the vtkVolumeRayCastMapper. Basically, I took one of VTK's
>>example (e.g. volProt) and added a user-matrix to the vtkVolume that did
>>nothing but scaled the volume uniformly to e.g. 0.1 times the initial size.
>>Then I used the vtkVolumeRayCastMapper to volume render the volume.
>>Surprisingly, the z resolution of the image was extremely bad. The noticed
>>effect is very similar to subsampling the volume along the rays or setting
>>the camera's clipping range incorrectly such that not all the zbuffer's
>>precision is used.
>>   It looks to me that this is a bug in VTK. I tried other transforms on the
>>vtkVolume, such as rotations and translations, and all went ok. But scaling
>>the volume, namely with a scale factor < 1, seems to destroy the sampling
>>precision along the rays of the raycaster.
>>
>>   I thought first that I had to adjust the SampleDistance member of the
>>vtkVolumeRayCastMapper, i.e. to make it smaller because the volume is now
>>smaller. However, it didn't help mcuh to improve the rendering quality -
>>moreover, the vtkVolumeRayCastMapper.h file states that this distance is in
>>volume coordinates, so it should be insensitive to scaling of the volume.
>>Then I thought I should adjust the camera clipping range differently.
>>However, when printing the bounding-box based computation of the camera
>>clipping range of vtkRenderer::ResetCameraClippingRange(), I saw that the
>>clipping range is correctly computed to take into account the smaller
>>volume.
>>
>>   Has anyone notices these rendering artifacts when scaling a vtkVolume with
>>a factor < 1? Is there any way to cope with such volumes? I can't increase
>>the scaling factor of vtkVolume really, since my application passes it
>>together with other transform info in a SetUserMatrix() call - so I have to
>>stick with a sclaed vtkVolume.
>>
>>   Any help is very welcome,
>>
>>   Alex Telea
>>
>>-----------------------------------------------------------------
>>  Dr. Alexandru C. Telea      | Technische Universiteit Eindhoven
>>                              |
>>  E-mail   : alext at win.tue.nl | Dept. of Mathematics and
>>  Office   :  HG 7.71         | Computer Science
>>  Tel.     : +31 40 247 5008  | PO Box 513
>>  Secretary: +31 40 247 4416  | 5600 MB Eindhoven
>>  Fax      : +31 40 246 8508  | The Netherlands
>>                              |
>>  URL      : http://www.win.tue.nl/math/an/alext
>>-----------------------------------------------------------------
>>
>
>
>_______________________________________________
>This is the private VTK discussion list. Please keep messages on-topic. 
>Check the FAQ at: <http://public.kitware.com/cgi-bin/vtkfaq>
>Follow this link to subscribe/unsubscribe:
>http://public.kitware.com/mailman/listinfo/vtkusers