- Modifié
Animation Snapping
I've just now switched from Mecanim to SpineAnimation and am not sure if this is something I'm doing wrong, is because of the beta Spine Unity 3.2 runtime, or other..
If you use trackEntry = spineAnimationState.SetAnimation(0, "Attack_1H, false) and leave it there for a solid second and then play a looping Idle animation like spineAnimationState.SetAnimation(0, "Idle_1H, true).. should it not blend from the end of the current animation into the Idle? Right now it's snapping straight to the Idle start pose/frames.
This all worked 100% perfectly in SpineAnimator with Mecanim even on the beta 3.2 runtime.
The bones are definitely in use in both animations and default mixing of .2 is in place, and I even tried adding a specific blend for the attack to idle transition and it had no effect.
Unrelated I'm also now getting a bunch of spam that I didn't get in SpineAnimator. Switching to the native runtime I assumed would be more stable, so I'm obviously doing something "wrong."
ArgumentNullException: Argument cannot be null.
Parameter name: attachmentName cannot be null.
Did you mean SkeletonAnimation?
SkeletonAnimation's AnimationState does crossfading in a different way than Mecanim.
AnimationState doesn't blend from "nothing" though. The current version only crossfades/mixes between a previous and a next animation.
After an Animation finishes playing, the trackEntry is removed from the internal queue. So if the animation finished playing, and THEN you play a new animation, no mixing happens. This is how AnimationState behaves in all the runtimes.
There's a new version of AnimationState coming after Spine 3.3 (coming soon). I'm not sure but I think this may be in the list of things to address.
I'm not sure what your log means. Looks like you're making some calls to SetAttachment maybe? And passing an empty/null string?
Yes SkeletonAnimation
None of the error has any code from any of my scripts, so it was hard to determine what is going on. Could it possibly be that my animator has created some animations that hide or don't use some attachments and it is throwing errors? That would be odd to identify and I wouldn't think it should throw errors in those instances.
This is super confusing because it's even happening when going from Walk to Idle or Walk to Run and basically any animation transition.
ArgumentNullException: Argument cannot be null.
Parameter name: attachmentName cannot be null.
Spine.Skeleton.GetAttachment (Int32 slotIndex, System.String attachmentName) (at Assets/spine-csharp/Skeleton.cs:262)
Spine.Unity.SkeletonExtensions.SetSlotAttachmentToSetupPose (Spine.Skeleton skeleton, Int32 slotIndex) (at Assets/spine-unity/SkeletonExtensions.cs:154)
Spine.Unity.SkeletonExtensions.SetToSetupPose (Timeline timeline, Spine.Skeleton skeleton) (at Assets/spine-unity/SkeletonExtensions.cs:190)
Spine.Unity.SkeletonExtensions.SetKeyedItemsToSetupPose (Spine.Animation animation, Spine.Skeleton skeleton) (at Assets/spine-unity/SkeletonExtensions.cs:162)
Spine.AnimationState.Apply (Spine.Skeleton skeleton) (at Assets/spine-csharp/AnimationState.cs:159)
Spine.Unity.SkeletonAnimation.Update (Single deltaTime) (at Assets/spine-unity/SkeletonAnimation.cs:175)
Spine.Unity.SkeletonAnimation.Update () (at Assets/spine-unity/SkeletonAnimation.cs:165)
Something to add is it spams this 5-7 times when simply going from one animation to another. I even changed my FSM to always transition at 80% into an animation so that it never just "stopped" on an animation and it is still doing it. No idea why a SetUpToPose is being fired.
Edit #2: I loaded up an older revision of our main character which was based off Spine 3.1.08 and wiped spine-csharp and unity from my assets and downloaded the latest official one and everything is 100% smooth now with no errors. There is still the snap but your explanation makes sense.
Edit #3: Pharan, also.. not sure the usage case and maybe we're just weird.. but it is very beneficial in a fighting game like ours to allow pausing at the end of an attack animation so that it can flow into another at the last minute instead of queuing up an attack half way through.
What we do is basically allow hitting attack 50% to 100% into the animation, but since you are forced to initiate another animation before the attack ends, I just changed the FSM to always transition at 85%. In Mecanim I was able to manually tell it what animations to blend and did it at 100% with a 25% blend, but with SkeletonAnimation I don't see any way to do that.
What would be really great is it always knew the last animation played and blended to the next animation. Is that not what most people would desire instead of an odd snapping or are we just doing crazy stuff over here? lol :whew:
I think you were using the unofficial modified AnimationState.cs before. That's the only version that calls SetKeyedItemsToSetupPose. That was since updated, but it also doesn't handle the case you needed. When you nuked your spine-csharp, you started using the official one.
I think most of the weird stuff AnimationState currently does is a case of "that's not what everyone wants so you should tell it what you want specifically".
Explaining your case like you did is helpful so we can tell more cases that just make sense.
When an animation finishes playing, it should be cleared. So when people query the AnimationState to see if anything is playing, it can return that it's empty.
And that fact is just that the current version of AnimationState can't blend between "nothing" and an animation. It has a lot to do with cases where there's multiple Animations applied on multiple tracks and stuff. In general, that anything can be done to the skeleton dynamically by multiple animations and dynamically changing the bone local values.
What you can do here and now is make your animations much longer to hold the end pose, or make separate animations that are just the end poses for looping after the main animation is done (this is what I do. I consider every state that can be held for an indefinite amount of time as its own animation and it's a good place to be able to animate a moving hold instead of having no motion at all).
For queueing stuff, you can call AddAnimation which also takes a time delay (can be negative seconds if you want it to start before the last animation ends).
To lower the "alpha" of an animation, a TrackEntry has trackEntry.Mix. It's an alpha percent between 0 and 1.
If you were comfortable with Mecanim, why did you switch to SkeletonAnimation? If you were relying on a lot of Mecanim features, switching to SkeletonAnimation means you'll have to implement those Mecanim features yourself or do everything in code.
Honestly I'm a programmer who took on the responsibility of creating the animation controller, so it wasn't that I was ever comfortable with Mecanim. From what I can tell, SpineAnimation should be used by anyone new to all game dev and SpineAnimator is for those already familiar with unity and Mecanim correct?
I have no clue how to properly use mecanim's blend trees and layers, so it made sense to just ditch it completely. I also ditched it because unity animation timeline events are too unreliable and hand coding out events with float values was becoming daunting. I feel like the colliders are enabling/disabling much better now that I ditched mecanim honestly.. I can't tell you why but so far I have no "stuck" on colliders using NodeCanvas + SpineAnimation.
I considered the extra length end to some of the attacks and since you suggested it I think it's the right thing to go ahead with. Dramatic end to animations is pretty common in slower style hack and slash so this should work out well.
The errors I was getting above were a result of wiping spine-unity and spine-csharp and importing the beta 3.2 runtime and using Spine 3.2.01 to animate the characters. I can try importing everything from scratch again if you want but would be more than happy to try to reproduce issues before you guys sign off on the new unity runtime. I feel like something could be wrong, but I wasn't using anything custom. The unity runtime page says it's compatible with 3.1.08 and we accidentally went forward with 3.2.01 and I had to grab the 3.2 runtime beta to test but that's when I got the errors I posted.
Ah, thanks for reporting. That's a huge bug on my end. I accidentally packaged the unofficial AnimationState in the 3.2 beta. Will replace it in a bit, but you can do that yourself too by grabbing this code: https://github.com/pharan/spine-runtimes/blob/csharp-3-2beta/spine-csharp/src/AnimationState.cs
Or you can download the unitypackage for the fixed beta here: http://esotericsoftware.com/files/runtimes/unity/spine-csharp-3_2_beta2.unitypackage
But yeah, that's right. SkeletonAnimator is for people who want Mecanim. SkeletonAnimation is for anyone.
Aaand perfect, haha thanks.. 