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