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@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org