[vtk-developers] Logic Problem in vtkFixedPointVolumeRayCastMapper ?

[Randall Hand]

I've been looking into a problem in the vtkFixedPointVolumeRayCastMapper and
I've about exhausted my immediate expertise in the situation, so I present
it here in hopes that someone else can chime in (Lisa, are you reading
this?)

I'm rendering vtkImageData with the FixedPoint mapper, and seeing odd
problems along the zero-crossings when the data is presented in a
Perspective view direct-on to the user (or close to it).  The problem
doesn't manifest in Parallel/Orthographic views, and it's fairly difficult
to see.  The visual problem is black lines (black background in my case)
presented in the center of the data on the X & Y image axes, but not
completely through the data.  The part of the data closer to the viewer is
rendered properly, but the distant part is not rendered at all.

After alot of printfs, I've started to narrow down the problem.  In
vtkFixedPointVolumeRayCastMapper.cxx's "ComputeRayInfo" function, the
"numSteps" seems to be computed incorrectly.  Currently, you compute the
numSteps necessary along each of the 3 axis directions, and keep the
smallest number.  This works most of the time, except when the "direction"
component is near-0.  You have an "if" check for equal to zero, but when the
alignment is such that the "direction" becomes 1 or -1 (which is
infinitesimally close to zero once the Fixed-Point conversion is made), the
math seems to come out wrong.  In my dataset:

i=435, j=3, numSteps = 156
i=436, j=3, numSteps = 149
i=437, j=3, numSteps = 134
i=438, j=3, numSteps = 90
i=439, j=3, numSteps = 90
i=440, j=3, numSteps = 134
i=441, j=3, numSteps = 149
i=442, j=3, numSteps = 156
i=443, j=3, numSteps = 160
i=444, j=3, numSteps = 163
i=445, j=3, numSteps = 165

(generated with printf's I added to the code).  At the center of the image,
when i=438 & 439, you'll see the numSteps takes an unusual drop.  The same
happens when the j crosses the center of the image, because the Y component
of the direction drops to near-0.  The result is that the rays terminate
early, without fully passing through the volume.

Now, I can "alleviate" this problem by changing:
        if ( !(dir[stepLoop]&0x7fffffff ))
          {
          continue;
          }

to
        if ( (dir[stepLoop]&0x7fffffff ) < 10)
          {
          continue;
          }

But that doesn't really "solve" the problem.  I think that perhaps the
method used to compute "currSteps" needs to be changed, although I haven't
been able to find a method that seems to work any better.

Hopefully this can help someone find the cause of this problem.
-- 
----------------------------------------
Randall Hand
Visualization Scientist
ERDC MSRC-ITL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20070813/7fcff8f2/attachment.html>