[vtk-developers] Re: Logic Problem in vtkFixedPointVolumeRayCastMapper ?

[Randall Hand]

Anyone looking at this?

Also, I believe I found a typo bug in vtkFixedPointVolumeRayCastMapper.cxx.
Line 1982 reads:

    if ( diff[1] >= diff[0] && diff[1] >= diff[2] && rayDirection[2])

But I'm pretty sure it should be:

    if ( diff[1] >= diff[0] && diff[1] >= diff[2] && rayDirection[1])

(Wrong rayDirection Index).

-- 
----------------------------------------
Randall Hand
Visualization Scientist
ERDC MSRC-ITL

On 8/13/07, Randall Hand <randall.hand at gmail.com> wrote:
>
> 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/20070815/8cdbae62/attachment.html>