PixarAnimationStudios / OpenUSD

Universal Scene Description
http://www.openusd.org
Other
6k stars 1.18k forks source link

Specifying multiple SkelAnimations for UsdSkel #2246

Open dgovil opened 1 year ago

dgovil commented 1 year ago

It would be really awesome if UsdSkel could allow for specifying that multiple skel animations are associated with the current skel.

While UsdSkel does allow for containing multiple SkelAnimation prims, only a single rel is allowed to be bound via rel skel:animationSource. When traversing the USD stage, it's not possible to tell that SkelAnimations are associated with a given Skeleton, other than the single bound one.

However take a character that may have multiple animations that a runtime would want to switch between, like a Unity game. For example a character might have an idle, a walk and a run. The game engine would benefit from having access to all of these, and knowing it can associate them to this character on import.

Variants would not work here, since they'd recompose the stage, still resulting in a single bound animation. Another option would be treating all siblings of the animation source as alternative clips, however that's potentially inefficient, and places restrictions on where they have to be placed in the hierarchy (e.g you couldn't use Scopes to group them etc..., or share them between characters easily)

Expanding rel skel:animationSource to be an array would be a good solution, where the attribute would be able to enumerate all the animations that are associable with the current Skeleton. The current skel:animationSource could continue to point to the default animation to be used, and the combination of the two would be what should be taken by the engine.

Something like

rel[] skel:animationSources = [
    <./Idle>
    <./Walk>
    <./Run>
]

rel skel:animationSource = <./Idle>

It might also be beneficial to be able to point to a collections as well, in case multiple animations can be shared by multiple characters.

tallytalwar commented 1 year ago

Filed as internal issue #USD-7980

spiffmon commented 1 year ago

This makes sense, with a couple of caveats in what the expectation/thought around it is, I think.

  1. skel:animationSource is not the "default" animation, it is the animation, and that's important for animation as opposed to asset interchange
  2. Along those lines, it would be good to distinguish the other available options... in alot of media-related workflows, we have the concept of "alts" (alternatives). Something like skel:altAnimationSources might better convey the distinction
  3. Documentation-wise, just to clarify that "the engine" consuming these is a higher-level tool that may modify the scene (or its own internal representations) using the alternate animations. But it has no effect on the UsdSkel evaluation of the scene, by itself.
jesschimein commented 11 months ago

This relates to the Multiple Animation Support proposal posted on USD proposals: https://github.com/PixarAnimationStudios/OpenUSD-proposals/pull/11