Open dgovil opened 1 year ago
Filed as internal issue #USD-7980
This makes sense, with a couple of caveats in what the expectation/thought around it is, I think.
skel:altAnimationSources
might better convey the distinctionThis relates to the Multiple Animation Support proposal posted on USD proposals: https://github.com/PixarAnimationStudios/OpenUSD-proposals/pull/11
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
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.