skel:animationSource relationship directly on the Skeleton prim

Community USD
1

Hi everyone,

We’ve recently ran into some USD like this:

#usda 1.0

def SkelRoot "Model"
{
    def Skeleton "Skel" ( apiSchemas = ["SkelBindingAPI"] )
    {
        rel skel:animationSource = </Anim>

        ...
    }

    def Mesh "Arm" ( apiSchemas = ["SkelBindingAPI"] )
    {
        rel skel:skeleton = </Model/Skel>

        ...
    }
}

def SkelAnimation "Anim" {
    ...
}

(full USD sample with the same structure here: blend_arm.usda (3.1 KB))

Now, according to the Binding Skeletons part of the documentation, this should not animate. You can deduce this from the examples, and also from this statement:

a skel:animationSource binding is not considered to have any effect until the next skel:skeleton binding at or beneath the binding location in namespace.

In the USD above, the rel skel:animationSource cannot inherit down to where rel skel:skeleton is, so I think it shouldn’t animate, right?

And yet, it does animate in usdview… and in fact if you construct an AnimQuery for that skeleton, it will be valid and point at the “Anim” prim. Additionally, the setup shown at the top of this doc page has the same pattern, suggesting this is supported.

My question is, is having the skel:animationSource directly on the Skeleton something that is meant to work, even though it disagrees with the documentation, or is it perhaps something that is being “phased out” and not recommended? We’re just investigating whether we should support this pattern in our importer or not.

Thanks!

2

With the caveat that I am not the expert… I think the documentation is a little misleading, and that the behavior you are seeing is intentional - I think the idea was that it gave you a way to easily attach a “default” animation for all users of the skeleton.

If it is, as I suspect, an intentional behavior, I would hope that, if you did bind an animation as per the docs on the agent that also binds the skeleton, that the animation specified from the agent would “win” over the one attached to the Skeleton. If that’s not the case, I’d think that is highly problematic.

Could you try that and report back?

3

Hi Spiff,

I’ve tweaked the previous file to have a setup as you described, like this:

def SkelRoot "Model"
{
    def Skeleton "Skel" ( apiSchemas = ["SkelBindingAPI"] )
    {
        rel skel:animationSource = </NoAnim>
        ...
    }

    def Mesh "Arm" ( apiSchemas = ["SkelBindingAPI"] )
    {
        rel skel:animationSource = </SomeAnim>
        rel skel:skeleton = </Model/Skel>
        ...
    }
}

def SkelAnimation "NoAnim" {
    uniform token[] joints = ["Shoulder/Elbow"]

    float3[] translations = [(0,0,2)]
    quatf[] rotations.timeSamples = {
        0: [(1,0,0,0)]
    }
    half3[] scales = [(1,1,1)]
}

def SkelAnimation "SomeAnim" {
    uniform token[] joints = ["Shoulder/Elbow"]

    float3[] translations = [(0,0,2)]
    quatf[] rotations.timeSamples = {
        5: [(1,0,0,0)],
        10: [(0.7071, 0.7071, 0, 0)]
    }
    half3[] scales = [(1,1,1)]
}

Unfortunately it seems that the binding on the skeleton wins over the binding on the Mesh, and we get no animation on usdview. If we flip the bindings to have the skeleton point at SomeAnim and the Mesh point at NoAnim, we get animation :frowning:

Here is a complete file with that setup.

blend_arm_two_anim_sources.usda (3.3 KB)

1 Like
4

Thanks, @coelhodaniel . Would you file an Issue on GitHub with your repro? I can’t promise when we might get to it, but that seems to me like not-useful behavior.

Also curious to hear other opinions in the community about whether an anim binding on a Skeleton should ever be considered.

1 Like
5

Posted issue Inconsistency regarding skel:animationSource relationship directly on the Skeleton prim · Issue #3532 · PixarAnimationStudios/OpenUSD · GitHub