[Bf-committers] Cycles: Exposing local axes through object info node?
lukas.toenne at gmail.com
Thu Jan 31 11:42:59 CET 2013
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.oelgarte at googlemail.com> wrote:
> I'm currently working on a eye shader that utilizes parallax mapping
> , 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.
> Greetings from
> Tobias Oelgarte
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers