Skinning DQ blend weights

[koen-v]

Hello all,

I added support for the blend weights ( skinCluster.getBlendWeights(...) ) to the usd exporter from maya. Is there any appetite for a pull request for this?

Thanks,
Koen

[kxl-adsk]

Hi Koen,

As far as I'm aware, there is currently no support for dual quaternion in UsdSkel. Assuming this is still true, where do you write blend weight array to?

Thank you,
KxL

[koen-v]

Hello KxL,

I see the deformation code in usd skel as a sample implementation, much like how I see HdStorm as a sample implementation for a renderer. The fact that something is not supported in the sample implementation should not be a reason to exclude it from writing it to the usd in my book ( we write a lot of stuff hdstorm does not know how to deal with for example).

If you currently have these values authored in maya, export to usd and re-import, they are stripped. We use our own deformation code that does use this extra primvar. I store in under "skel:jointBlendWeights".

Thanks,
Koen

[dgovil]

While I think this would be interesting and useful as a long term addition, I also think having a non-standard implementation in Maya USD would cause issues in the USD ecosystem. This is something I think would best be handled as an internal chaser, with a schema proposal to Pixar first. Once that proposal has had buyoff, then I could see it being mainlined here (assuming there are no other concerns) Otherwise I'm concerned that we'll start seeing USD files with DQ that only work for a singular studios needs, while everyone else in the ecosystem will start getting USD files that are non standard, with no way to understand what to do with that data.

…

On Thu, May 13, 2021 at 6:57 AM Koen Vroeijenstijn ***@***.***> wrote: Hello KxL, I see the deformation code in usd skel as a sample implementation, much like how I see HdStorm as a sample implementation for a renderer. The fact that something is not supported in the sample implementation should not be a reason to exclude it from writing it to the usd in my book ( we write a lot of stuff hdstorm does not know how to deal with for example). If you currently have these values authored in maya, export to usd and re-import, they are stripped. We use our own deformation code that does use this extra primvar. I store in under "skel:jointBlendWeights". Thanks, Koen — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1413 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABB4XUVEIIJHI4VDBZAEH5DTNPLGHANCNFSM44Y56B4A> .

[koen-v]

That makes sense, but to be fair, that is true for nearly all primvars. ( not all consumers of the data will know what to do with all the data contained in a usd)

[ralphmeijerambassadors]

Getting back on this topic. I noticed in the usd documentation DQ now seems to be supported ( https://openusd.org/dev/api/group___usd_skel___skinning_utils.html#:~:text=Functions-,USDSKEL_API%20bool%C2%A0,points%20using%20linear%20blend%20skinning%20(LBS)%20or%20dual%20quaternion%20skinning%20(DQS).,-USDSKEL_API%20bool%C2%A0 ).

Also after exporting the skeleton to usd, in Houdini you can set the primvar:skel:skinningMethod to dualQuaternion. Is this something you can set in the export flags in Maya? We are currently on mayaUsd 0.27.0

Thanks in advance.

Ralph

[barbalt]

Hi @ralphmeijerambassadors,
Thank you for bringing this up.
This is not supported with our default exporter yet, but I'll share it with the team to be discussed.

In the meantime, it's possible to change the default exporter behavior by writing your own custom export behavior with a prim writer or export chaser.

Regards,

[barbalt]

I have a PR open to fix this here: #3886