Anyone looking at this?<br><br>Also, I believe I found a typo bug in vtkFixedPointVolumeRayCastMapper.cxx.  Line 1982 reads:<br><br>    if ( diff[1] >= diff[0] && diff[1] >= diff[2] && rayDirection[2])

<br><br clear="all">But I'm pretty sure it should be:<br><br>    if ( diff[1] >= diff[0] && diff[1] >= diff[2] && rayDirection[1])<br><br>(Wrong rayDirection Index).<br><br>-- <br>----------------------------------------

<br>Randall Hand <br>Visualization Scientist<br>ERDC MSRC-ITL

<br><br><div><span class="gmail_quote">On 8/13/07, <b class="gmail_sendername">Randall Hand</b> <<a href="mailto:randall.hand@gmail.com">randall.hand@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

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.

<br><br>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:

<br><br><div style="margin-left: 40px;">i=435, j=3, numSteps = 156<br>i=436, j=3, numSteps = 149<br>i=437, j=3, numSteps = 134<br>i=438, j=3, numSteps = 90<br>i=439, j=3, numSteps = 90<br>i=440, j=3, numSteps = 134<br>i=441, j=3, numSteps = 149

<br>i=442, j=3, numSteps = 156<br>i=443, j=3, numSteps = 160<br>i=444, j=3, numSteps = 163<br>i=445, j=3, numSteps = 165<br></div><br clear="all">(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.  

<br><br>Now, I can "alleviate" this problem by changing:<br>        if ( !(dir[stepLoop]&0x7fffffff ))<br>          {<br>          continue;<br>          }<br><br>to <br>        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.

<br><br>Hopefully this can help someone find the cause of this problem.<br><span class="sg">-- <br>----------------------------------------<br>Randall Hand <br>Visualization Scientist<br>ERDC MSRC-ITL

</span></blockquote></div><br>