[yt-users] Volume rendering rotation

[Matthew Turk]

Hi Stella,

This is a dirty little secret of the volume rendering that I'm working
on fixing -- I really, really hope to roll this new set of code out
tonight or tomorrow for production.  It should dramatically improve
the user experience, and hopefully get rid of some of the things like
this that are annoying and counterintuitive!

The box for volume rendering -- as you note -- can be characterized by
three vectors and a center.  Right now, only the center and the
'normal' vector can be specified by the user; this is a throwback to
the original code that did oblique slices, the CuttingPlane -- when it
was written, the idea was to specify only the normal vector, so that
it'd be defined in that manner, so that for instance things like "cut
along the L_vec" would be easier.  The code to do, reproduced here, is
on line 849 of yt/lagos/BaseDataTypes.py:

        self._norm_vec = normal/na.sqrt(na.dot(normal,normal))
        self._d = -1.0 * na.dot(self._norm_vec, self.center)
        # First we try all three, see which has the best result:
        vecs = na.identity(3)
        _t = na.cross(self._norm_vec, vecs).sum(axis=1)
        ax = _t.argmax()
        self._x_vec = na.cross(vecs[ax,:], self._norm_vec).ravel()
        self._x_vec /= na.sqrt(na.dot(self._x_vec, self._x_vec))
        self._y_vec = na.cross(self._norm_vec, self._x_vec).ravel()
        self._y_vec /= na.sqrt(na.dot(self._y_vec, self._y_vec))

So what it does is normalize the normal vector, then take the cross
product of the normal vector with all three of the axes.  Whichever
has the biggest cross-product is then crossed with the normal vector
again and used as the X-vector.  Then these two are crossed to get the
Y-vector.

I've prepared a new version that will allow for the "north" or "up"
vector to be specified; I'll commit the changes as soon as I can.  The
reason I have hesitated is that they also changed the C-code (to allow
for differing aspect ratios, for instance) which requires a
recompilation, and the direct_ray_cast function will probably be going
away replaced with a much nicer one.

But -- as a stopgap, I've gone ahead and allowed you to specify the
x_vec and y_vec.  I don't know if this will end up making things worse
or better, but you should be able to calculate them and rotate them by
the same mechanism as the L vector.  To get a starting set,

cp = pf.h.cutting(L, center)
xv0 = cp._x_vec
yv0 = cp._y_vec

then you can do your volume rendering, rotate the L_vec, x_vec, y_vec
identically, and specify "x_vec =" and "y_vec =" in your argument
list.

Hope that helps!

-Matt

On Thu, Feb 25, 2010 at 12:45 PM, Stella Offner <soffner at cfa.harvard.edu> wrote:
> Hi,
>
> I am generating volume renderings using a direct_ray_cast call. If I set L =
> [na.sin(2*na.pi*frame/rotframes),na.cos(2*na.pi*frame/rotframes), 0.0] (like
> Sam's python movie script) so that the consecutive images revolve, after 30
> degrees of rotation the "up" vector of the output image suddenly rotates 90
> degrees. The problem seems to be independent of the z coordinate of L. Is
> there something strange happening in the normalization of L within
> direct_ray_cast or am I missing something basic? I can rotate the png files
> back to the correct orientation before stringing them together but that is
> annoying.
>
> Thanks,
> Stella
> _______________________________________________
> yt-users mailing list
> yt-users at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>