PoseBone.matrix is nothing I've seen at all. Over a month I'm trying to get my scripts from Blender 2.4 to the new API.

There were other problems, like inability to assign matrices from file to EditBones for some reason, but you could at least generate bone head, tail and roll and assign those instead (heavy math).

But I still can't get my animation importer working.
What's the deal with PoseBone.matrix? In Blender 2.4 API there were two matrices: one in local space, one in armature space.

But the new PoseBone.matrix is neither! It's not a local matrix:


Position isn't local, it's global.

But rotation

Code:

<Euler (x=1.5708, y=-0.7854, z=-0.0000), order='XYZ'>

is.

So what is this "object space" that the API says PoseBone.matrix is in?

I'm trying to assign my armature-space matrices to a hierarchial armature and I can't get them right.

I tried decomposing the matrices I have, undoing parent rotations then recomposing the matrix again before setting it as "PoseBone.matrix".
It just doesn't work.

Code:

oldmatrix = myMatrix loc, rot, scale = oldmatrix.decompose() #rot = rot * pose.bones[bonename].parent.rotation_quaternion.conjugated() for i in pose.bones[bonename].parent_recursive:    rot = rot * i.conjugated() newmatrix = rot.to_matrix().to_4x4() newmatrix[0][3] = loc.x newmatrix[1][3] = loc.y newmatrix[2][3] = loc.z pose.bones[bonename].matrix = newmatrix

object space sounds much like space relative to the container object

container object: bpy.data.objects['Armature']

actual armature: bpy.data.objects['Armature'].data, which is equal to bpy.data.armatures['Armature']

so the Armature object appears to be the space which the Armature is relative to.

The object can have translation, rotation and scale. But if everything is set to identity matrix, it shouldn't have no impact on the Armature object space.
_________________
I'm sitting, waiting, wishing, building Blender in superstition...

Well that's weird, whats the point in having PoseBones relative to the object containing the Armature?
Either way its at (0,0,0).

Still doesn't explain why rotations are relative to parent bones, but locations are not.

And just undoing parent rotations doesn't fix it for me...

There's more strangeness here than that...

ddos wrote:

Still doesn't explain why rotations are relative to parent bones, but locations are not.

I think they are all relative to the Object space.

Using a similar setup, and modifying your script to :

Code:

import bpy  armobj = bpy.context.scene.objects.active armature = armobj.data pose = armobj.pose print(" -"*10) for bone in pose.bones:     print(bone.matrix.decompose()[0])     print(bone.matrix.decompose()[1].to_euler())

gives the output:

- - - - - - - - - -
#0
No rotations in Pose Mode
- - - - - - - - - -
<Vector (0.0000, 0.0000, 0.0000)>
<Euler (x=1.5708, y=-0.0000, z=0.0000), order='XYZ'>
<Vector (0.0000, 0.0000, 1.1863)>
<Euler (x=1.5718, y=-0.0000, z=0.0000), order='XYZ'>
<Vector (0.0000, -0.0012, 2.3894)>
<Euler (x=1.5718, y=-0.0000, z=0.0000), order='XYZ'>
- - - - - - - - - -
#1
bottom one only, rotated 45 degrees
- - - - - - - - - -
<Vector (0.0000, 0.0000, 0.0000)>
<Euler (x=1.5708, y=-0.7854, z=0.0000), order='XYZ'>
<Vector (-0.8388, 0.0000, 0.8388)>
<Euler (x=1.5718, y=-0.7854, z=0.0000), order='XYZ'>
<Vector (-1.6896, -0.0012, 1.6896)>
<Euler (x=1.5718, y=-0.7854, z=0.0000), order='XYZ'>
- - - - - - - - - -
#2
middle one only, rotated 45 degrees
- - - - - - - - - -
<Vector (0.0000, 0.0000, 0.0000)>
<Euler (x=1.5708, y=-0.0000, z=0.0000), order='XYZ'>
<Vector (0.0000, 0.0000, 1.1863)>
<Euler (x=1.5708, y=-0.7854, z=0.0000), order='XYZ'>
<Vector (-0.8507, 0.0000, 2.0370)>
<Euler (x=1.5708, y=-0.7854, z=0.0000), order='XYZ'>

If it was relative to the parent then the child bones in #1 should be y=-0 as in #0
same goes for #2