When implementing the particle info node i was considering to expose the particle rotation info as well. But cycles currently does not have any appropriate data type for quaternions or full transforms (matrices). IMO we should improve support for 3D vector math in shader nodes. While it may not be that important in most shader setups it is definitely needed for future particle nodes ;) So i'd like to have a consistent design throughout.
Using x-y-z axes could work and is perhaps the most intuitive. But if you want to do more complex vector math you'd still have to fiddle around with individual components and sine/cosine math nodes or be limited to the vector Mapping node (constant transform). Adding a quaternion socket data type (in addition to value, color, vector) would be the most efficient in terms of calculations afaik and would fit nicely in the SVM stack (4 floats), but it does not include scale which would need to be a separate object info output. It could be named "rotation socket" too, hiding the somewhat complex quaternion math, but it's still a bit abstract. Looking at the OSL language spec i noticed they have a "matrix" data type (4x4 homogeneous transform), which does not have an equivalent in Cycles yet (i.e. not usable in script node too). That would be the most generic way of handling rotation and scale and make it possible to add nodes for advanced vector math, e.g.: * transform vector x (input 1 matrix + 1 vector, output 1 transformed vector) * combine transform (input 2 matrices, output 1 matrix) * get loc/rot/scale from transform (input 1 transform, output loc vector, scale vector, rot depends on mode: euler or axis-angle) * create rotation from eulers, axis+angle, 2 vectors (rotation from vector a to b) If the math get too complex it may be preferable to use a script node, but with the help of group nodes i think a transform socket type could come in handy at times. On Thu, Jan 31, 2013 at 11:02 AM, Tobias Oelgarte <tobias.oelga...@googlemail.com> wrote: > I'm currently working on a eye shader that utilizes parallax mapping > [1], but to do it right (better) i would need to have access to local > axes of the object, so that i can transform vectors between local space > and world space. I can retain them from the normal and tangents (radial > x,y,z), but it are a lot of computations and the precession is not > really sufficient. I could add drivers as well, but that introduces > needless requirements. > > So I'm asking if we could expose the axes of the local coordinate system > in world space. We already have the origin of the shaded object in the > object info node. Having three additional not normalized vectors > (x-axis, y-axis, z-axis) would be nice. > > http://www.blendpolis.de/viewtopic.php?f=14&t=42940#p465811 > > Greetings from > Tobias Oelgarte > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers