[Bf-committers] Cycles: Exposing local axes through object info node?

[Tobias Oelgarte]

That is a nice outline, but i also have to assume that implementing it 
would take a lot of time. But till then the user has no true way to do 
anything in that direction, even if he implements the functionality 
using vectors instead of matrices.

Having the three vectors is an easy way to transform between Cartesian 
coordinate systems. Multiplying global vectors with the axes gives the 
local vectors, multiplying local vectors with the transposed axes gives 
global coordinates and so on. Something very simple i can't do at the 
moment, because deriving the axes itself is very expensive, limited and 
not very precise with the currently available data.


Am 31.01.2013 11:42, schrieb Lukas Tönne:
> 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
>> [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 at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>