[Bf-committers] Some questions/suggestions for "motion toolkit" and "iksolver"...

[Ton Roosendaal]

Hi Herman,

We don't have an active maintainer or 'owner' for the math modules you  
describe below. Since you seem to understand all of it well, this could  
be a nice job for you and your team. :)

All of the issues below I think you should just be able to implement or  
work on, of course being aware it's important that old functionality  
remains working... the moto lib is being used heavily in the game  
engine for example.

About matrices; Blender uses an ordering that gives easy float pointer  
access to the vector component of the 4x4 matrix; this is a convention  
being used in OpenGL too. I always forget if that's called row or  
collumn major. :)
When Solid/Moto was added I recall the developer used the other  
ordering for matrices. Also python APIs haven't been checked on  
consistancy yet.

-Ton-



> - in "moto", I miss a class like "MT_RotMatrix3x3", which would
>   specialise MT_Matrix3x3 for the case of rotation matrices. The only
>   real differences would be:
>     - a MT_RotMatrix3x3 must always be orthogonal
>     - it has a very easy inverse: just the transpose. (Instead of the
>       explicit inverse by Cramer's rule that is used now.)
>   There _is_ already such an efficient thing for 4x4 matrices:
>   "MT_Transform", where the efficient inverse is implemented, but it
>   still calls the efficient inverse of its 3x3 rotation part.
>   Maybe I miss some historical reason why the MT_RotMatrix3x3 has never
>   been introduced explicitly, but it seems odd for a roboticist :-)
>
> - I would add things like "MT_Screw", "MT_Twist", "MT_Wrench" for 6D
>   rigid body motion; these are the physical things that Jacobian
>   matrices (see IKSOLVER) of armatures work with: each column of a
>   Jacobian matrix represents the end-point velocity ("twist")  
> generated by
>   the joint corresponding to that column; and vice versa, any 6D force
>   ("wrench") applied to the end-point is transformed by the transpose
>   Jacobian into torques at the joint level.
>
> - can't we remove the dependency on TNT? (TNT namespace occurs
>   explicitly in some of the moto code.) Possibly just by other  
> namespace
>   ("MN" or so, for "Matrix Numerics") that can wrap many numerical
>   libraries that one wants to use. It's not a priority, but TNT is a
>   dead project...
>
> - in the "iksolver", I would suggest to work with the physical  
> ("twist")
>   Jacobian instead of with the matrix of partial derivatives: the
>   physical Jacobian has nicer properties and is easier to calculate
>   iteratively. No derivatives must be calculated explicitly, which  
> gives
>   large efficiency gains for complex structures. Our goal is to extend
>   the solver to cope with "humanoid"-like armatures, including the  
> dynamic
>   properties; and to contribute more general IK routines than the one
>   implemented now (e.g., damped pseudo-inverse, redundancy resolution
>   based on the real mass distribution, etc.)
>
> - I would also introduce revolute, prismatic and helical joints in the
>   armatures, because doing everything with the current spherical joints
>   requires too often constraints to be added to the chain, and that
>   reduces efficiency and numerical accuracy of the iksolver.
>
> - it seems that the moto library stores transformations as follows:
>    | Xx  Yx  Zx  Px |
>    | Xy  Yy  Zy  Py |
>    | Xz  Yz  Zz  Pz |
>    | 0   0   0   1  |
>   but the Python code that we use in the Gameengine prints out the
>   transpose of this... Am I overlooking or misinterpreting something,  
> or
>   is there really a difference in storing transforms and rotation  
> matrices?
>
> Herman
> --  
>   K.U.Leuven, Mechanical Engineering, Robotics Research Group
> <http://people.mech.kuleuven.ac.be/~bruyninc> Tel: +32 16 322480
> _______________________________________________
> Bf-committers mailing list
> Bf-committers@blender.org
> http://www.blender.org/mailman/listinfo/bf-committers
>
>
------------------------------------------------------------------------ 
--
Ton Roosendaal  Blender Foundation ton@blender.org  
http://www.blender.org