<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hi,</div><div><br></div><div>I've run into the same problem as described in <a href="http://public.kitware.com/pipermail/vtk-developers/2007-August/004678.html">http://vtk.org/Bug/view.php?id=5519</a> and <a href="http://vtk.org/Bug/view.php?id=5519">http://public.kitware.com/pipermail/vtk-developers/2007-August/004678.html</a> while testing convergence properties of the VTK fixed point volume rendering. Essentially, the images generated should converge to a pre-defined ground-truth (under some conditions) at the right speed. However, it did not converged. Below I describe the problem and also a possible solution for this problem. i've compiled Paraview 3.12.0 on Linux.</div><div><br></div><div>I tried to apply the patch suggested in <a href="http://public.kitware.com/pipermail/vtk-developers/2007-August/004678.html">http://vtk.org/Bug/view.php?id=5519</a> but it segfaulted my code (I need to check why). However, I do not think that the problem is the computation of numSteps or that the values of dir[i] are too close to zero. I think the problem is the rounding during conversion from float to fixed-point precision. When dir[i] approaches to zero (for i = {0, 1, 2}), the conversion from float to fixed-point precision may double the value of dir[i]. This is because the conversion is done as:</div><div><br></div><div>new_dir[i] = dir[i] * VTKKW_FP_SCALE + 0.5</div><div><br></div><div>The '+ 0.5', used for rounding, will make values of new_dir[0] to be 1 when it should have been 0. Suppose that dir[i] == 1.5E-5. Then, new_dir[i] == 1, because 0.5 is added. As a result, if one recovers dir[i] one gets 3.0E-5, which doubles the size on the i-direction. Hence the number of steps required to traverse the volume diminishes in 1/2 (in this example). See <a href="http://dl.dropbox.com/u/4483810/before.png">http://dl.dropbox.com/u/4483810/before.png</a> for an example of the problem.</div><div>By simply removing the '+ 0.5' part, the image is fixed and the black lines no longer appears. Also, in my tests I observed the rendered image converged to the right image, at the right speed. See <a href="http://dl.dropbox.com/u/4483810/after.png">http://dl.dropbox.com/u/4483810/after.png</a> for an example obtained after the fixing it.</div><div><br></div><div>In my tests, I have only changed the method:</div><div><br></div><div>inline unsigned int vtkFixedPointVolumeRayCastMapper::ToFixedPointDirection( float dir ).</div><div><br></div><div>I did not change the overloaded version (because it is not used):</div><div><br></div><div>inline void vtkFixedPointVolumeRayCastMapper::ToFixedPointDirection( float in[3], unsigned int out[3] ) </div><div><br></div><div><br></div><div>Best,</div><div>
<div>-- tiago</div><div><br></div><br class="Apple-interchange-newline">
</div>
</body></html>