Add Maya compatible "Bone Scale for Edit Bones" #38660

New Issue

Gaia Clary · 2014-02-16T16:30:54+01:00

Gaia Clary commented

2014-02-16 16:30:54 +01:00

I have a compatibility problem with Maya's bone system.

The problem is best explained as an example:
Here is a preview of a mesh (a simple human character actually)
before it gets imported to the target system:

This is obviously distorted... We could find the cause for the massive
distortion by now. It is a wrong (incompatible) generation of the
bind pose matrices in the Collada exporter from Blender.

The problem actually points to Maya where we can define a joint scale for rest pose:

It looks like this Joint scale actually defines a "neutral scale".
Translated to Blender that probably would mean:

When an edit bone has a scale <a,b,c> defined, then a mesh
binds to the rig undistorted only if the corresponding pose bone
also defines a scale <a,b,c>

Actually currently Blender does this already, but the "edit bone scale"
is fixed (implicitly assumed to be) <1,1,1>

Now my problem is this:

1.) Blender does not allow to define the "neutral scale" for edit bones.
It always assumes <1,1,1> But we have to provide the bone scales
without distorting the mesh.

2.) In Blender we have a scale for Pose bones. But this scale would
affect the mesh when it is bound to the rest pose. This implies when i
define a pose bone scale, then the mesh gets deformed also in rest pose
as soon as i bind it to the rig. this is not what i want.

Proposed solution:

Add a Bone scale property to the Edit Bones which is used as the "neutral scale in rest Pose". So when a mesh is bound to the rig, it does not get deformed when

  pose_bone_scale == edit_bone_scale

A less clean but doable alternative would be:

Add a Bone scale to the custom Bone properties.
Make the Collada exporter aware of this extra scale values and use this only for export (when the properties are available).

Maybe there are other ways to get this fixed. That's why i ask here how
this problem could possibly be fixed without adding a feature into
Blender and without need to create a new Collada exporter just to get
this issue fixed.

I have a compatibility problem with Maya's bone system. The problem is best explained as an example: Here is a preview of a mesh (a simple human character actually) before it gets imported to the target system: ![Image3.png](https://archive.blender.org/developer/F77531/Image3.png) This is obviously distorted... We could find the cause for the massive distortion by now. It is a wrong (incompatible) generation of the bind pose matrices in the Collada exporter from Blender. The problem actually points to Maya where we can define a joint scale for rest pose: ![Image2.png](https://archive.blender.org/developer/F77532/Image2.png) It looks like this Joint scale actually defines a "neutral scale". Translated to Blender that probably would mean: When an edit bone has a scale <a,b,c> defined, then a mesh binds to the rig undistorted only if the corresponding pose bone also defines a scale <a,b,c> Actually currently Blender does this already, but the "edit bone scale" is fixed (implicitly assumed to be) <1,1,1> Now my problem is this: 1.) Blender does not allow to define the "neutral scale" for edit bones. It always assumes <1,1,1> But we have to provide the bone scales without distorting the mesh. 2.) In Blender we have a scale for Pose bones. But this scale would affect the mesh when it is bound to the rest pose. This implies when i define a pose bone scale, then the mesh gets deformed also in rest pose as soon as i bind it to the rig. this is not what i want. **Proposed solution:** - Add a Bone scale property to the Edit Bones which is used as the "neutral scale in rest Pose". So when a mesh is bound to the rig, it does not get deformed when ``` pose_bone_scale == edit_bone_scale ``` A less clean but doable alternative would be: - Add a Bone scale to the custom Bone properties. - Make the Collada exporter aware of this extra scale values and use this only for export (when the properties are available). Maybe there are other ways to get this fixed. That's why i ask here how this problem could possibly be fixed without adding a feature into Blender and without need to create a new Collada exporter just to get this issue fixed.

Gaia Clary commented

2014-02-16 16:30:55 +01:00

Changed status to: 'Open'

Gaia Clary self-assigned this 2014-02-16 16:30:55 +01:00

Gaia Clary commented

2014-02-16 16:30:55 +01:00

Added subscriber: @GaiaClary

Brecht Van Lommel commented

2014-02-16 17:56:39 +01:00

Added subscriber: @brecht

Brecht Van Lommel commented

2014-02-16 17:56:39 +01:00

In principle it should not be necessary to add properties to export an armature correctly. For import I can imagine there is some Maya feature that Blender does not support, but for export it should be possible to assume the property has some default value in Blender. I don't understand why you would need to expose a property to the user when the user shouldn't have to edit it to get a correct export anyway?

For import it maybe be different, but it might even be possible to compensate for this without adding a new property, by removing this rest scale from all pose scale values, but it would be good to figure out export first.

I don't know the Maya system, so not sure what else to say at this point, but it seems to me that adding a new property doesn't address the issue.

In principle it should not be necessary to add properties to export an armature correctly. For import I can imagine there is some Maya feature that Blender does not support, but for export it should be possible to assume the property has some default value in Blender. I don't understand why you would need to expose a property to the user when the user shouldn't have to edit it to get a correct export anyway? For import it maybe be different, but it might even be possible to compensate for this without adding a new property, by removing this rest scale from all pose scale values, but it would be good to figure out export first. I don't know the Maya system, so not sure what else to say at this point, but it seems to me that adding a new property doesn't address the issue.

Gaia Clary commented

2014-02-16 19:23:39 +01:00

I have no idea how i could adress this without adding a new parameter. The problem as i understand it is this:

In Blender we have a Pose Bone matrix which defines a scale, a rotation and a location.

Now to make it easy assume:

the armature is in rest pose
the pose bone scale is <1,1,1>
the pose bone rotation is <0,0,0>

In other words: the bone pose matrix is:

  M0: blender's neutral rest pose matrix

Now i bind a mesh to this armature. All is well, the mesh binds undistorted.

unbind the mesh again.
set the pose bone scale to <0.1,0.1,0.1> and keep all the rest as it is.

Now the bone pose matrix is:

  M1: This matrix is no longer neutral regarding binding the mesh

0.1  0    0    0
0    0.1  0    0 
0    0    0.1  0
0    0    0    1

Now bind the mesh again. The bound mesh gets distorted because
of the pose bone scale. Until here all works as expected.
That is how blender works. All is well, no complains. All are happy.

Now Maya chimes in. It seems to be possible to define an arbitrary
bone pose matrix as the neutral matrix regarding the binding. So in Maya
we can tell that M1 is the neutral restpose matrix.

This is the essential feature that i propose. Once i have this neutral restpose matrix, i know how to proceed. Actually the export will "bake" the matrices all together into a final Bind pose Matrix. And that would fully solve my issue.

I have no idea how i could adress this without adding a new parameter. The problem as i understand it is this: In Blender we have a Pose Bone matrix which defines a scale, a rotation and a location. Now to make it easy assume: - the armature is in rest pose - the pose bone scale is <1,1,1> - the pose bone rotation is <0,0,0> In other words: the bone pose matrix is: ``` M0: blender's neutral rest pose matrix ``` 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 Now i bind a mesh to this armature. All is well, the mesh binds undistorted. - unbind the mesh again. - set the pose bone scale to <0.1,0.1,0.1> and keep all the rest as it is. Now the bone pose matrix is: ``` M1: This matrix is no longer neutral regarding binding the mesh ``` 0.1 0 0 0 0 0.1 0 0 0 0 0.1 0 0 0 0 1 Now bind the mesh again. The bound mesh gets distorted because of the pose bone scale. Until here all works as expected. That is how blender works. All is well, no complains. All are happy. Now Maya chimes in. It seems to be possible to define an arbitrary bone pose matrix as the neutral matrix regarding the binding. So in Maya we can tell that M1 is the neutral restpose matrix. This is the essential feature that i propose. Once i have this neutral restpose matrix, i know how to proceed. Actually the export will "bake" the matrices all together into a final Bind pose Matrix. And that would fully solve my issue.

Antonis Ryakiotakis commented

2014-02-16 20:53:52 +01:00

Added subscriber: @Psy-Fi

Antonis Ryakiotakis commented

2014-02-16 20:53:52 +01:00

I still can't understand the workflow issue here: Is this a blender to Maya export or the inverse? There is a solution to both without introducing extra variables. Of course if you do ping-ponging between the two software you may get some issues.

Gaia Clary commented

2014-02-16 21:49:22 +01:00

It is not about ping pong between maya and blender. The problem is that Second Life's character was based on a rig made with Maya. The SecondLife Importer assumes that exactly the original Maya rig is used. And it assumes to get the data as Collada file.

Because of this the import of a rigged mesh into SL not even requires the skeleton to be present in the Collada file. It just assumes all is compatible to their standard skeleton. So we have to give the SL importer exactly what it expects to get.

Since the neutral rest pose matrix in Blender is the identity matrix, and in Maya it is customizable, the Blender exporter can not create the data like it would be exported from Maya. So we have a nasty compatibility problem.

Does that explain better what the problem is ?

Here is the corresponding thread in the Second Life Forums:

http://community.secondlife.com/t5/Mesh/Problems-with-Blender-and-Fitted-mesh-blend/td-p/2487943

However, i still am very unsure about how to fix this with blender's collada exporter. It may well be that there is a simple solution to this and i just overlook it. But i have no idea how to step further.

The only other alternative i see is to extract our own collada exporter (from the Avastar-Addon) into a separate Blender addon. But that would be the "last rescue" imo. Actually getting this solved in Blender would allow us to entirely drop our own exporter in favor of the Blender exporter. So this would help a lot.

It is not about ping pong between maya and blender. The problem is that Second Life's character was based on a rig made with Maya. The SecondLife Importer assumes that exactly the original Maya rig is used. And it assumes to get the data as Collada file. Because of this the import of a rigged mesh into SL not even requires the skeleton to be present in the Collada file. It just assumes all is compatible to their standard skeleton. So we have to give the SL importer exactly what it expects to get. Since the neutral rest pose matrix in Blender is the identity matrix, and in Maya it is customizable, the Blender exporter can not create the data like it would be exported from Maya. So we have a nasty compatibility problem. Does that explain better what the problem is ? Here is the corresponding thread in the Second Life Forums: http://community.secondlife.com/t5/Mesh/Problems-with-Blender-and-Fitted-mesh-blend/td-p/2487943 However, i still am very unsure about how to fix this with blender's collada exporter. It may well be that there is a simple solution to this and i just overlook it. But i have no idea how to step further. The only other alternative i see is to extract our own collada exporter (from the Avastar-Addon) into a separate Blender addon. But that would be the "last rescue" imo. Actually getting this solved in Blender would allow us to entirely drop our own exporter in favor of the Blender exporter. So this would help a lot.

Gaia Clary commented

2014-02-19 14:05:53 +01:00

fe5e1dd adds support for the Maya Restpose matrix as follows:

The following (custom-) properties will be used if the option "import to Second Life" is enabled:

  restpose_scale_x (default = 1.0)
  restpose_scale_y (default = 1.0)
  restpose_scale_z (default = 1.0)
  
  restpose_rot_x (default = 0.0)
  restpose_rot_y (default = 0.0)
  restpose_rot_z (default = 0.0)
  
  restpose_loc_x (default = 0.0)
  restpose_loc_y (default = 0.0)
  restpose_loc_z (default = 0.0)

This addition was implemented to support Second Life import of "Fitted Mesh"

fe5e1dd adds support for the Maya Restpose matrix as follows: The following (custom-) properties will be used if the option "import to Second Life" is enabled: ``` restpose_scale_x (default = 1.0) restpose_scale_y (default = 1.0) restpose_scale_z (default = 1.0) restpose_rot_x (default = 0.0) restpose_rot_y (default = 0.0) restpose_rot_z (default = 0.0) restpose_loc_x (default = 0.0) restpose_loc_y (default = 0.0) restpose_loc_z (default = 0.0) ``` This addition was implemented to support Second Life import of "Fitted Mesh"

Gaia Clary commented

2014-02-19 14:08:16 +01:00

Changed status from 'Open' to: 'Resolved'

Gaia Clary closed this issue

2014-02-19 14:08:16 +01:00

J.R.I.B. commented

2014-03-18 18:52:30 +01:00

Added subscriber: @faerietree

J.R.I.B. commented

2014-03-18 18:52:50 +01:00

Removed subscriber: @faerietree

J.R.I.B. commented

2014-03-18 19:18:14 +01:00

Added subscriber: @faerietree

J.R.I.B. commented

2014-03-18 19:18:14 +01:00

Hey GaiaClary, thanks for the effort.dude.blend

Do you think you could add the scale for a 3DS Max rig too now that there is a way specify different rest pose scale values?

Tried with export setting as you said to OpenSim/SecondLife, but it turned into:

(WOW !! at least prop points positions work suddenly with opensim export setting. Note that rotation can be due to my empties' rotation! So I have to check it ... the problem related to this topic is rather the distortion).

Without OpenSim it looks like:

The value our rig seems to have is .17 - though I'm not all an expert and it's just the value that I found for the scale in the attached blend. :/ Is it possible to add a custom input for the rig's scale on import. Or am I getting it wrong?

Here I hopefully soon will get more info from our artists:
http://www.wildfiregames.com/forum/index.php?showtopic=15552&page=21#entry287140

Hey GaiaClary, thanks for the effort.[dude.blend](https://archive.blender.org/developer/F81747/dude.blend) Do you think you could add the scale for a 3DS Max rig too now that there is a way specify different rest pose scale values? Tried with export setting as you said to OpenSim/SecondLife, but it turned into: ![dude-all_props-position_fixed_after_blender_start_then_export_with_OpenSim-strange_but_cool.gif](https://archive.blender.org/developer/F81753/dude-all_props-position_fixed_after_blender_start_then_export_with_OpenSim-strange_but_cool.gif) (WOW !! **at least prop points positions work** suddenly with opensim export setting. Note that rotation can be due to my empties' rotation! So I have to check it ... the problem related to this topic is rather the distortion). Without OpenSim it looks like: ![dude-stepping.gif](https://archive.blender.org/developer/F81748/dude-stepping.gif) The value our rig seems to have is .17 - though I'm not all an expert and it's just the value that I found for the scale in the attached blend. :/ Is it possible to add a custom input for the rig's scale on import. Or am I getting it wrong? Here I hopefully soon will get more info from our artists: http://www.wildfiregames.com/forum/index.php?showtopic=15552&page=21#entry287140

DragonWhisperer commented

2014-06-30 00:36:57 +02:00

(Migrated from localhost:3001)

Added subscriber: @DragonWhisperer

DragonWhisperer commented

2014-06-30 00:36:57 +02:00

(Migrated from localhost:3001)

I'm still getting crazy distortions, even with Blender 2.7 and 2.71. If I alter the location of even a single bone in edit mode [rest pose] and export a mesh with only the bone layer that has the m* bones [mTorso, mChest, etc.] the imported armature has joints going all over.

I am thinking that the blender exporter is not handling rest pose properties correctly, the SL uploader is not. Here are a few observations...

In the .dae created by the Blender exporter, under the section tag "<float_array id="Avatar_headMesh-skin-bind_poses-array" count="384">", all of the x, y, z positions iterated there are negatives of the values displayed for those bones in Blender. Now, since Avastar creates instances of the Avastar avatar mesh and armature facing the -y axis, rotating everything by 180 degrees to face +y accounts for this in regards to x and y, but not for z. All the default bone positions should retain +z values, yes?

Both .dae files created [one using the Blender exporter, the other using Avastar's v1.1 beta] have <bind_shape_matrix>1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1</bind_shape_matrix> included. However, the 4x4 matrix for the bones are different.

Example:

mHead - via Blender

1 0 0 0
0 1 0 -0.02477991
0 0 1 -1.682703
0 0 0 1

mHead - via Avastar

1.08108 0 0 0.026789
0 1.08108 0 0
0 0 1.08108 -1.81914
0 0 0 1

The Avastar .dae has the x and y values transposed for all mBones [not sure how the fitted mesh deform bones are handled yet], which would be valid if the armature data is rotated 90 degrees around the z axis. The latest SL .blend avatar includes a custom property called fbx_pre_rotation with the values [-90.0, -0.0, 0.0]. All other bones have values [0.0, 0.0, 0.0]. That looks like a rotation around the x axis. I would have suspected a z value. Perhaps this is why some people see their meshes appear horizontal for a brief moment upon rezzing in-world. I don't understand the need for an x rotation here.

The scale values...why do we need them? If our armature's rest pose is our identity pose, I see no reason for including scalars with that bone matrix. [note - these scalar values result in new x, y, z bone locations that scale in relation to the point (0.0, 0.0, 0.0). I foolishly assume that my armature origin is the center/pivot for the scaling]. Why define the x, y, z of a bone, then add scalars to each to move the bone elsewhere? Seems to me an identity matrix should have discreet values only. In the Avastar .dae example for mHead above, the scalar values are included in its 4x4 matrix and the x, y, z location included are values to which the scalar has already been applied, which explains why each example has different x, y, z values. Unless the SL uploader or something in the SL code uses that scaling data to reverse the scaling to extract the correct bone location, why include the scalars?

In a nutshell, moving a bone in edit mode [rest position] seems like the way to define its identity pose. However, it appears one now needs to alter the custom properties to synch with bone changes. With all the rotations and scalings happening at different stages of the whole process, figuring out what values to use is unnecessarily difficult if not unnecessary at all.

How bone roll needs to be handled is another related topic which I won't go into now.

I'm still getting crazy distortions, even with Blender 2.7 and 2.71. If I alter the location of even a single bone in edit mode [rest pose] and export a mesh with only the bone layer that has the m* bones [mTorso, mChest, etc.] the imported armature has joints going all over. I am thinking that the blender exporter is not handling rest pose properties correctly, the SL uploader is not. Here are a few observations... In the .dae created by the Blender exporter, under the section tag "<float_array id="Avatar_headMesh-skin-bind_poses-array" count="384">", all of the x, y, z positions iterated there are negatives of the values displayed for those bones in Blender. Now, since Avastar creates instances of the Avastar avatar mesh and armature facing the -y axis, rotating everything by 180 degrees to face +y accounts for this in regards to x and y, but not for z. All the default bone positions should retain +z values, yes? Both .dae files created [one using the Blender exporter, the other using Avastar's v1.1 beta] have <bind_shape_matrix>1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1</bind_shape_matrix> included. However, the 4x4 matrix for the bones are different. Example: mHead - via Blender 1 0 0 0 0 1 0 -0.02477991 0 0 1 -1.682703 0 0 0 1 mHead - via Avastar 1.08108 0 0 0.026789 0 1.08108 0 0 0 0 1.08108 -1.81914 0 0 0 1 The Avastar .dae has the x and y values transposed for all mBones [not sure how the fitted mesh deform bones are handled yet], which would be valid if the armature data is rotated 90 degrees around the z axis. The latest SL .blend avatar includes a custom property called fbx_pre_rotation with the values [-90.0, -0.0, 0.0]. All other bones have values [0.0, 0.0, 0.0]. That looks like a rotation around the x axis. I would have suspected a z value. Perhaps this is why some people see their meshes appear horizontal for a brief moment upon rezzing in-world. I don't understand the need for an x rotation here. The scale values...why do we need them? If our armature's rest pose is our identity pose, I see no reason for including scalars with that bone matrix. [note - these scalar values result in new x, y, z bone locations that scale in relation to the point (0.0, 0.0, 0.0). I foolishly assume that my armature origin is the center/pivot for the scaling]. Why define the x, y, z of a bone, then add scalars to each to move the bone elsewhere? Seems to me an identity matrix should have discreet values only. In the Avastar .dae example for mHead above, the scalar values are included in its 4x4 matrix and the x, y, z location included are values to which the scalar has already been applied, which explains why each example has different x, y, z values. Unless the SL uploader or something in the SL code uses that scaling data to reverse the scaling to extract the correct bone location, why include the scalars? In a nutshell, moving a bone in edit mode [rest position] seems like the way to define its identity pose. However, it appears one now needs to alter the custom properties to synch with bone changes. With all the rotations and scalings happening at different stages of the whole process, figuring out what values to use is unnecessarily difficult if not unnecessary at all. How bone roll needs to be handled is another related topic which I won't go into now.

Sign in to join this conversation.

5 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#38660

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Add Maya compatible "Bone Scale for Edit Bones" #38660