- Düzenlendi
Unity Timeline for Skeleton Mecanim, how?
Hello folks,
Currently,
The stock Unity timeline Spine mixer behavior works great for skeleton animations in the timeline for both editor playback and at runtime.
What kind of modifications would need to be made to the SpineAnimationStateMixerBehaviour script(s) in order for the Skeleton Mecanim game object to work in the same manner (both in Play mode and editor mode scrubbing)?
I assume another set of mixer and track behaviors for a different kind of skeleton renderer.
SkeletonAnimation seems to use AnimationState to perform duties that Unity mecanim has built-in.
What's the spineMecanim equivalent to:
Glad you like the SkeletonAnimation Timeline integration, thanks for your kind words.
As you have correctly stated, SkeletonMecanim leaves the animation state and transition logic to Mecanim.
Regarding the equivalents to AnimationState.Update() and .Apply():
Each frame SkeletonMecanim gets the current state from the Animator as can be seen in the method SkeletonMecanim.GetStateUpdatesFromAnimator().
Each animation of the clips received is then manually applied to the skeleton with the received clip and layer weights, as can be seen here.
I'm afraid what still needs to be solved though is that the Skeleton's Mecanim animation clips can be placed in the Timeline so that they override the current Mecanim state. However I must admit that it's been some time since I last investigated the encountered problems for a SkeletonMecanim Timeline solution, so I might be wrong there.
If I'm understanding correctly, sounds like the weighted mecanim clips need to be returned to Unity Timeline mixer? Is this on the right track?
Also, would I need to be setting up custom mix settings on the SkeletonData asset for it to work?
It depends on what exactly you mean by "mecanim clips need to be returned to". I would say that the MixerBehaviour needs to receive the Spine Mecanim clips (of type AnimationClip, the Mecanim clips are generated here) that the Timeline is currently moving its "progress bar" over. Or as an alternative, instead of adding the Mecanim AnimationClips, you could use the animation reference assets used with SkeletonAnimation.
Whatever the actual clips are that are placed in a Timeline, the MixerBehaviour will receive this from a Playable, as can be seen here. From this object you can then get the respective animation that needs to be played, and update the SkeletonMecanim.Skeleton accordingly, by applying each one of the weighted animations on it.
In little quickie test scripts, if editor-scrubbing uses a normalized time of 0 only makes the first frame show up and seems not to continue. However, when a similar script is applied to a Unity created anim and mecanim, it works as expected... (I can move a cube around on some quick anims managed by a simple mecanim and only when normalizedTime progressed). This script does not work with Spine's skeletonMecanim though.
Executes in edit mode...
Can confirm the correct information and clips are reached in the mecanim graph.
To make things more interesting, and hopefully I'm wrong about this, seems (in the editor mode with respects to mecanim) the default mecanim values get reset to their defaults every editor frame. So guessing that's why we'd need to tell it what state and what time it needs every update. For a normal cube animated in editor time, it only animates when the normalizedTime parameter continues to increase.
What's missing for the mecanimSkeleton to update through a whole animation at editor time? This logic would then be planted in the timeline mixer behavior.
Thanks for posting your insights.
I'm afraid I cannot completely follow how your above findings are related to the Timeline mixer though. For Timeline playback or scrubbing to work, I would assume you will need the animation clips coming from the Timeline tracks, overriding any animations that the Animator component currently has active in it's animation states. Thus you would not want to set a state at the Animator or need to call playableGraph.Evaluate() on it, but instead stop/override everything with the Timeline track animation frame. I would assume that what needs to be done is applying the clip animation frame to the Skeleton, and ensuring that normal Mecanim playback does not interfere with (or override) the Timeline clips.
holymolar yazdıWhat's missing for the mecanimSkeleton to update through a whole animation at editor time?
Just to make sure I do not misunderstand you there: in case you mean updating according to Editor deltaTime - you would not want this, you want to play back the current Timeline clips at the playback position (normalized time). This will ensure both the Play button as well as scrubbing works.
Please let me know if I misunderstood you or if any of my above assumptions are wrong.
Harald yazdıI'm afraid I cannot completely follow how your above findings are related to the Timeline mixer though
The script above is to localize and test the mechanics needed to run skeletonMecanim from editor mode without adding more code like timeline. The skeletonMecanim doesn't seem to work in timeline (editor time) even though the playable graph that it uses seems to be updated.
Harald yazdıyou would not want this, you want to play back the current Timeline clips at the playback position (normalized time)
Progressing through the timeline, would want to control the animations through the data (triggers, ints, floats, etc) so the Timeline clip might consist of shifting data to the mechanim so the result might be idle->attack#33->idle in the clip where attack#33 might have been caused by a player pressing a key. The normal uninteracted timeline clip would just be idle. Mecanim seems ideal for this purpose.
And the reason for using timeline instead of a programmatic loop allows a series of interactive cutscenes (designer made timelines) that utilize the same characters seamlessly. The designers need to be able to test their cutscenes or part of the cutscenes in the editor (scrubbing bacwards and forwards and playing through specific parts). Its as much about the content making tool as it is about the resulting gameplay.
holymolar yazdıThe script above is to localize and test the mechanics needed to run skeletonMecanim from editor mode without adding more code like timeline. The skeletonMecanim doesn't seem to work in timeline (editor time) even though the playable graph that it uses seems to be updated.
Thanks for the clarification. This is not the standard way of how to use Timeline with Mecanim animation clips, but I can see what you are trying to accomplish.
I would not recommend to try executing the whole Mecanim logic in the Editor when not in play mode though, as it has not been designed for it - it may work, but be prepared to receive slightly different results when executing it in play mode vs outside play mode.
Is there an example of skeletonMecanim working in editor time?
Unfortunately there is no example, for the same reason mentioned above.