[yt-users] [Yt-dev] Broken volume rendering

[Matthew Turk]

Hi Rick,

I've committed and pushed a changeset that I think addresses this
issue in 1831bbe4afd1 in mercurial; I'll backport to svn shortly.
(Also, I recently updated my installation of Cython, which I think may
have turned off some performance-helping preprocessor directives by
default; I'm looking into this.)

You were right, it was in the calculation of the step, iv_dir, tdelta
and tmax variables, which are used for determining how a ray moves
across a subdivided volume (in this case, a homogenized brick
consisting of cells.)  I simply did a floating point check (which may
be unreliable) against 0.0, and if the vector component is zero it
initializes the tmax and tdelta to be very large and the step to be 1.
 I tried with step set to zero, but it introduced some issues with the
loop over cells never terminating, whereas this solution should not
cause any problems and should still allow the loop to terminate.

The black screens with zero component normal vectors are gone for me.
Let me know if you run into any more problems!

-Matt

On Sun, Aug 1, 2010 at 2:45 PM, Rick Wagner <rwagner at physics.ucsd.edu> wrote:
> Hi Matt,
>
> Thanks for tackling this, but I think there's still an edge case if any element of v_dir is 0. I can say for certain that having an element of the normal vector be 0 will produce this error repeatedly:
>
> Exception ZeroDivisionError: 'float division' in 'yt.amr_utils.PartitionedGrid.integrate_ray' ignored
>
> Looking into VolumeIntegrator.pyx, if step[3] is initialized to [0, 0, 0], that may take care of one need. However, I'm not clear enough on the code to suggest what else needs to change.
>
> I'm still working with this, since I'd like to add a rotate method to the camera that will spin it around the center of interest.
>
> --Rick
>
> On Jul 29, 2010, at 5:20 PM, Matthew Turk wrote:
>
>> Hi all,
>>
>> I broke volume rendering (via yt.extensions.volume_rendering) some
>> time ago, and I only just realized it today when some people were
>> getting corrupted images.  It took a while to come up because I
>> avoided re-generating the Cython/C code that actually conducts the
>> volume rendering; however, recently I updated this code and pushed it
>> to the repository, and that's when the errors started showing up.
>>
>> The exact error was in mercurial changeset 3007999e2518 (May 30),
>> which I merged into trunk in revision 1754 (June 24).  These dates are
>> not necessarily the dates at which the error showed up, however, as
>> the re-cythonization probably did not occur at those times.  The error
>> was in the optimization of division by the inverse of the vector
>> direction; the rays to cast were passed to partitioned bricks and to
>> avoid too much division of 64-bit floats, I changed it to be a
>> multiplication against the inverse.
>>
>> To calculate the inverse, I did something similar to this:
>>
>> for i in range(3):
>>    iv_dir[i] = 1.0/v_dir[0]
>>
>> The error, of course, being that I was dividing by v_dir[0] for all
>> three values.
>>
>> I identified this by using the hg bisect command, where I found a good
>> revision and a bad revision and it executed the necessary tests to
>> figure out where the code took a turn for the worse.  I've committed
>> fixes in hg changeset f0960f4f6bed, svn trunk r1804 and svn yt-1.7
>> r1805.
>>
>> I'm really sorry for the troubles, and I hope that it hasn't cost
>> anyone too much time.  There may still be some lingering bugs, so
>> please let me know if you run into any more bad images or difficulties
>> with the volume rendering.  You can get an updated yt by doing "yt
>> instinfo -u".
>>
>> -Matt
>> _______________________________________________
>> Yt-dev mailing list
>> Yt-dev at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
> _______________________________________________
> Yt-dev mailing list
> Yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>