Live editing of a clipset in SkelAnimation

[dkurek-mvfx]

Description of Issue

I'm trying to create a sequence of skeletal animations and display it with a Hydra delegate at runtime. To do so I created a SkelAnimation prim with a clipset in a stage, then added a clip. Unfortunately, the animation is not playing and the skeleton remains in a rest pose (animationSource is correctly set in the skeleton).

• After saving and reloading the stage, the animation plays correctly.
• Re-setting rel skel:animationSource at runtime fixes the issue.

Steps to Reproduce

Sample scene: skel-anim-issue.zip

• Add a clipset (or edit it: add/remove a clip) to a SkelAnimation prim at runtime with c++ API.

The following video shows the steps (and a workaround: "refreshing" rel skel:animationSource) in usdtweak: skel-anim-clipset-issue.webm

System Information (OS, Hardware)

• Hardware: Apple M3 Pro
• OS: macOS Sonoma 14.6.1

Package Versions

USD 24.05

[jesschimein]

Filed as internal issue #USD-10070

[spiffmon]

Huh, so this is actually an "easier" problem to address than what I thought you were having. I'm kind of surprised that applying/removing a clipSet does not trigger stage-level invalidation on the prim(s) on which it is applied, although there is one subtle thing to work out in pulling that off.

The harder problem is going to be: once you have clips applied, making live changes to those clips and having the affected scene description get invalidated.

Thanks for reporting!

[kikaxa]

Im pretty sure it does trigger the invalidation of the prims(and subprims) involved, but not of the any relationships targeting said prims..?

[kikaxa]

i think this problem might be related, as they both concern UsdSkel.. https://github.com/PixarAnimationStudios/OpenUSD/issues/2654

[spiffmon]

Thank you, @kikaxa . So for several reasons, it's not practical for UsdStage itself to propagate invalidation through relationships and connections - even in the "forwards" direction, and here we're talking about the more challenging "backwards" direction. Instead, that is the responsibility of higher-level clients that can be more selective about which dependencies are important to it.

In this case that's UsdImaging's Skel adaptor; we are about to begin work on the Hydra 2.0 implementation of UsdSkel, adn the good news is that dependencies like this are much easier to track in the new architecture, so we should definitely be able to address this there.