[Bf-python] Object matrix writable?

[Jonathan Merritt]

>
>
>On Mon, May 26, 2003 at 12:26:32PM +1000, Jonathan Merritt wrote:
>  
>
>>The matrix also currently has an _intrinsically_ different meaning to 
>>the translation and rotation components which you can read and set on an 
>>object.  Try parenting an object to another and then animate both of 
>>them.  The child object's translation and rotation are measured 
>>_relative_ to the parent object, but its transformation matrix is 
>>(apparently - I have deduced this only by trial and error) always 
>>relative to world space.  
>>    
>>
>
>Is matrix really relative to 3D world, not to parent? Does Loc, Rot and Size
>need to be calculated from new Matrix (It isn't trivial calculation!)?
>  
>

The mathematics of evaluating the Loc, Rot and Size from the matrix are 
trivial provided that the matrix only implements these transform types.  
However, I believe you'll get inconsistent results if the matrix is 
unusual in some way; for example if it's a skew or perspective matrix.  
I haven't really thought that through.

In the hypothetical situation where the transform matrices are writable, 
then problems could arise because of this.  If, for example, a script 
sets a matrix as a perspective matrix then how is Blender meant to 
interpret that when Blender itself cannot apply a perspective transform 
to object space coordinates (it can only do rigid body transforms + 
scaling)?  Blender could hypothetically somehow calculate a Loc, Rot and 
Size, but these three components _won't_ be equivalent to the matrix 
that the script originally set.  The fundamental issue is that a 4x4 
homogeneous transformation matrix can represent a _wider set_ of 
transforms than Blender itself allows a user to edit with the GUI.  It's 
not just an issue of converting between the two, since the 
transformation matrix is a superset of Blender's allowed transforms.  
Minimally, you would have to provide checking that the matrix set by the 
script is not one that exceeds Blender's object space transform 
capabilities.

The second problem is that if you have a parented object and you change 
its transformation matrix (which is in world space), then at what stage 
in the object heirarchy should the appropriate changes to Loc, Rot and 
Size be made?  If the transformation matrices of all objects in a 
heirarchy were simply concatenated (ie: expressed relative to the 
parent), then the new matrix could be considered to apply only to the 
child, which would be equivalent to world-space coordinates for an 
unparented object.  However, as it stands, the transformation matrix of 
an object is it's absolute position, in world space, _after_ all the 
parent transforms have been applied.

What I'd propose (IMHO!!! - I'm not an expert) is to change the 
semantics to the following:
  1. Maintain Loc, Rot and Size relative to the parent; this just "makes 
sense" to me.
  2. Have a read-write transformation matrix for an object which is 
relative to its parent.  The "setting" code for this matrix calculates 
Loc, Rot and Size and spits out a warning if the matrix specified 
expresses a badly-non-rigid-body transform (since the results won't be 
as expected).  (NB: There is definitely a word for a 
badly-non-rigid-body transform; we need a mathematician!!! - I can ask 
on the Aqsis mailing lists if nobody else steps up)
  3. Provide a method, for render export scripts and the like, which 
calculates the world-space transform for an object, by contatenating all 
the transforms in an object's heirarchy together (fast and easy - it's 
just matrix multiplication).  This matrix is read-only.

These changes would promote a stricter view of the object tranformation 
heirarchy than currently exists.

What does everyone think?

Jonathan Merritt.