Best way to handle maya's ability to have different joint bindPoses per skin?

[pmolodo]

So, when debugging a skeletal animation that didn't export to USD correctly, I found that maya DOESN'T use the dagPose node that's connected to the skinCluster.bindPose attribute - which is what maya-usd reads when exporting.

Instead, it seems it's using the data in the skinCluster.bindPreMatrix attribute.

First - can anyone at Autodesk confirm that this is indeed how the skinCluster works? (And, if so, what is the dagPose > skinCluster.bindPose used for?)

Secondly - if so, we should switch the exporter to reading from skinCluster.bindPreMatrix, instead of the dagPose.

Lastly - we have a question of how to deal with maya skinClusters that share the same skeleton, but have different bind poses... since in USD, the skeleton bind pose is a property on the skeleton, not the skinned object.

This was actually already a potential problem, but if our real-world example is any indication, it seems like it may become a more frequent issue if we switch to using the bindPreMatrix.

The options I can think of are:

• Ignore/Warn/Error
• Export a duplicate skeleton for clusters that use different bind poses
• Try to get Pixar to add the ability for the SkelBindingAPI to override the default bindTransforms specified on the skeleton. You could argue that there's a certain precedent for allowing overrides in the fact that they're already able to selectively reorder and prune the joints themselves... so why not make them able to alter the bindTransforms as well?

[williamkrick]

Yes, skinCluster.bindPreMatrix is what is used as the bind pose for the skin cluster. This attribute is set by the skinCluster command when an influence is added to the skin cluster, and after that the value doesn't change. I don't see a way for changes to the dagPose to modify skinCluster.bindPreMatrix, and all the deformation algorithms use bindPreMatrix as an input (vs. looking at the dagPose). You could modify skinCluster.bindPreMatrix directly with setAttr or a connection, I believe all the code is in place for that to work correctly.

From the point of view of what is actually happening right now, it looks like the dagPose could be removed and everything in Maya would keep on working in exactly the same way.

In the near term, having the export code ready from skinCluster.bindPreMatrix would be better because that's the data Maya is actually using.

Longer term we will have to think more carefully about how we represent the bind pose in Maya and if that is something we should change, or if we'd like to instead add more flexibility to USD and allow the bindTransforms to be overridden. If we added an attribute to skinCluster that allows you to choose the source of the bind pose, either the bindPreMatrix or bindPose, would that be enough to solve the problem of consistent bind poses for USD? If we did that you would be able to share one dagPose node for all skin clusters for a given skeleton, and then I believe the export would be simplified? But you'd still have to manage all those bindPose nodes and that workflow is probably not very developed.

I like the other solution of USD is able to override bindTransforms in a useful way. That adds more flexibility and doesn't increase the complexity on the Maya side.

[pmolodo]

Yes, skinCluster.bindPreMatrix is what is used as the bind pose for the skin cluster. This attribute is set by the skinCluster command when an influence is added to the skin cluster, and after that the value doesn't change. I don't see a way for changes to the dagPose to modify skinCluster.bindPreMatrix, and all the deformation algorithms use bindPreMatrix as an input (vs. looking at the dagPose). You could modify skinCluster.bindPreMatrix directly with setAttr or a connection, I believe all the code is in place for that to work correctly.

From the point of view of what is actually happening right now, it looks like the dagPose could be removed and everything in Maya would keep on working in exactly the same way.

Ah, thanks for the explanation (and confirmation) of how maya is working!

In the near term, having the export code ready from skinCluster.bindPreMatrix would be better because that's the data Maya is actually using.

Makes sense - that should be a relatively easy change.

Longer term we will have to think more carefully about how we represent the bind pose in Maya and if that is something we should change, or if we'd like to instead add more flexibility to USD and allow the bindTransforms to be overridden. If we added an attribute to skinCluster that allows you to choose the source of the bind pose, either the bindPreMatrix or bindPose, would that be enough to solve the problem of consistent bind poses for USD? If we did that you would be able to share one dagPose node for all skin clusters for a given skeleton, and then I believe the export would be simplified? But you'd still have to manage all those bindPose nodes and that workflow is probably not very developed.

I don't think that adding a means to switch between bindPreMatrix or bindPose fixes the consistency issue for USD. The consistency problem lies with the fact that, regardless of whether the bindPose is read from skinCluster.bindPose or skinCluster.bindPreMatrix, they're both still properties on the skin cluster, and therefore can vary per skinCluster.

The way USD works would be analogous to if NEITHER of those attributes existed in maya, and it instead we always had to get skeleton bindPose data from the joint.bindPose attributes.

I like the other solution of USD is able to override bindTransforms in a useful way. That adds more flexibility and doesn't increase the complexity on the Maya side.

Long term, I agree, that's definitely the ideal solution. However, the problem with the "Try to get Pixar to add the ability for the SkelBindingAPI to override the default bindTransforms" approach is that there's no guarantee we can get Pixar to buy in, and even if they do, it will be a while before it gets into main USD tree, then released... and then we would have to wait for all previous versions drop out of the list of supported USD versions before we could rely on it.

So - shorter term, I think we'll have to go with one of the other approaches - ie, either Ignore/Warn/Error if we detect different bindPoses for the same joints, or Export a duplicate skeleton for clusters that use different bind poses .

My vote would be to Error by default if we find conflicting bindPoses for the same skeleton, perhaps with an option to Ignore. It's the simplest solution, both in terms of ease of implementing, and least ripple effects to worry about.

[williamkrick]

I think the right approach is to switch over to using the pre bind matrix and error or warn when there are conflicting bind poses. I've also raised the issue of the bindPose attribute with Maya's animation team, they'll think it over and figure out what the right path forward for skinCluster is, including changes to the docs to make it clear how everything works.

We're not focused on UsdSkel export right now, so we won't be able to devote any resources to fix this in the near term. With that said we will keep track of this until we do turn our attention to UsdSkel export, or if you pick this up we can help with more feedback, code reviews & testing.