- Đã chỉnh sửa
Set + AddAnimation Behaviour bugged?
Hi,
I've been using Spine + Unity for 2 years now and after upgrading to the latest Runtime and Spine versions, my scripts' Set and AddAnimation Behaviour is completely bugged.
Before, I would be able to do this:
exampleSkeleton.state.SetAnimation(0, "walk", false);
exampleSkeleton.state.AddAnimation(0, "loop-stuff", true, 0.0f);
This would play the "walk" animation and after it completed, play the "loop-stuff" animation on loop.
After the changes of the new Spine & Runtime to "AnimationState" etc. this seems to have changed.
The first animation plays correctly but the "AddAnimation" call mixes back to the Setup-Pose, which is SUPER weird and completely bugs 50% of my game.
I then read about your changes to AnimationState and, what bewilders me: This seems to be intentional? Or did I read this wrong:
https://github.com/EsotericSoftware/spine-runtimes/issues/621
- Mix unkeyed properties to/from setup pose:
track 0, animation 1, keys a
track 0, animation 2, keys b
Result: a is left in the state it was when the animation changed, b snaps into position.
Expected: a mixes back to the setup pose, b mixes from the setup pose.
Solution: Need a TrackEntry setting for animations to mix to/from the setup pose during mixing.
There is only some edge cases where I would WANT this to happen.. so is this a bug on my part? Did I not understand something fundamental? Or is this indeed a change to the system, and if so, how can I use AddAnimation the way it used to work so I can fix my game?
Thank you very much! :handshake:
EDIT: I have now read that this is, indeed, intentional. Don't really understand the benefits yet as this brought way more problems to my project than it solved so far, but anyway:
How do I (in Unity) Set an Animation on e.g. track 0 and then Add an animation that LOOPS on the same track to play after the first? Right now, the second animation does NOT loop and glitches back to the setup pose..any way to prevent that? Why doesn't it loop?
It used to be that if an animation stops being applied, it left the skeleton in the state when the animation was last applied. If you then play another animation, you often have unwanted state from the previous animation. To "fix" this, your second animation needs to key everything the first animation keyed to the setup pose values. Once you have a few animations you find that you need to key EVERYTHING at the start of EVERY animation
every bone scale, rotation, translation, shear, every slot attachment, every slot color, every constraint, etc. This can be hundreds of timelines, and that makes applying animations slower.
With 3.5, AnimationState mixes animations back to the setup pose when they are no longer applied. This removes the need to key everything at the start of every animation. It also enables other functionality, such as mixing to/from an empty animation which can be used to mix to/from the setup pose, or to mix in/out an animation on a higher track.
It's not clear what is glitching for you. Your example code should play walk for its duration and then play loop-stuff forever, looping. What happens instead?
Can you try going from walk to loop-stuff in Skeleton Viewer?
Skeleton Viewer: Download
Nate đã viếtIt used to be that if an animation stops being applied, it left the skeleton in the state when the animation was last applied. If you then play another animation, you often have unwanted state from the previous animation. To "fix" this, your second animation needs to key everything the first animation keyed to the setup pose values. Once you have a few animations you find that you need to key EVERYTHING at the start of EVERY animation
every bone scale, rotation, translation, shear, every slot attachment, every slot color, every constraint, etc. This can be hundreds of timelines, and that makes applying animations slower.
With 3.5, AnimationState mixes animations back to the setup pose when they are no longer applied. This removes the need to key everything at the start of every animation. It also enables other functionality, such as mixing to/from an empty animation which can be used to mix to/from the setup pose, or to mix in/out an animation on a higher track.
It's not clear what is glitching for you. Your example code should play
walkfor its duration and then playloop-stuffforever, looping. What happens instead?Can you try going from
walktoloop-stuffin Skeleton Viewer?
Skeleton Viewer: Download
Hi, thanks for the reply.
Our problem is mainly that what you describe as "unwanted" was something we completely built upon in our project, which now screws us in many little ways: Whereas before we "knew" that something was in a certain state when animation A ended and so B could build upon that, now this is no longer the case.
We usually have an "init" animation for each spine object that sets up this object's default pose, then we use other animations on many different tracks..SOMETIMES we would have liked the now default setting to start everything in the setup pose but most of the time we don't want that AT ALL.
It would be awesome if there was a way to set what should happen, e.g. in SetAnimation, another parameter that determines if everything should start from the setup pose or not, but right now, this makes our 2+ year project almost completely unusable and we have dozens of issues that stem from this new way of doing things.
My main problem is that I don't have a choice what to do, now, but the system automatically sets everything to setup poses all the time, which is giving us a major headache right now. I can't be the only one that's having problems with this, right?
It's not clear what is glitching for you. Your example code should play walk for its duration and then play loop-stuff forever, looping. What happens instead?
When both animations are on the same track, the second one does not loop and instead sets itself back to setup pose after one run.
When the second animation is on a higher track, it seems to work right, but it should not have to be necessary to set such simple animations on two different tracks, since they don't even play at the same time or mix in any way..
What happens in Skeleton Viewer? Is it different than what you see at runtime? I'm trying to determine if the problem is with the new AnimationState or with spine-csharp.
Keeping what is essentially game state in the skeleton isn't a great idea. It couples the model and view, which will make serialization hard/impossible. Still, I expect a small number of applications were built relying in this, given that it was the default mode for the old AnimationState. We considered making the new behavior optional, but decided not to mainly because 1) we don't want to encourage storing state in the skeleton, which is a bad practice in general, and 2) AnimationState has already become extremely complex (1100 LOC!) and adding optional modes worsens the problem.
You may want to stay at 3.4.02. If you need 3.5 features, you could port the old AnimationState to 3.5. That shouldn't be hard at all, you probably just need to change the Animation apply call. However, the new AnimationState brings many improvements beyond mixing back to the setup pose, so probably your best move is to edit AnimationState (or copy to your own code and rename) so it does not mix back to the setup pose. To do that, you just need to do two things:
1) Find all calls to Timeline apply and pass false for the setupPose parameter.
2) Find all calls to AnimationState applyRotateTimeline and pass false for the setupPose parameter.
Awesome, thank you for your answer! I will try out your editing of AnimationState and see how it goes, but on the other hand, I have been using Spine for 2 years now and I want to use it as it is intended, especially as I plan on using it for future projects..and I don't want to hack the runtime every time I update it.
Anyways, I guess I will have to get used to the new way and so far, I've been slowly getting to grips with it and updating my scripts..step by step I'm making progress..
The main problem for me, and maybe of interest to you as well, is this:
The fact that animations revert to the setup pose as a default seem VERY counter-intuitive to me, the old system might have had its problems but the way everything worked was very intuitive. I might, of course, be super biased about this, too, as I have been using the old system for so long now.
I would focus on your project. It's hard enough to get something finished, you don't need distractions. 
You can always start the next project using an AnimationState without edits.
Just the fact that the old way required everything to be keyed makes it suboptimal, but also you don't really want your game state stored in the skeleton's pose. Eg, if your skeleton has a sword attached, you should not use the skeleton's slot to store that information, it should come from your game's data model.
Hello everyone. After update to 3.5 our team remove keys of unused keys(key to cancel the previous animation) at the start of every animation. But after playtest we noticed that color key not set to setup automatically.
Can you start a new topic, vzlomvl?
I tested on a few skeletons and checked the code. It seems to work correctly.
10 tháng sau
Hello, I am having the same problem. Im trying to port all my animations because I think its good practice to accept newer versions of spine and also I cant find version 3.4.02. Previously I had an animation where a character picked up his sunglasses and put them away on the table. Previously all new aniamtions accept the fact that the sunglasses were on the table. With this new, back to pose idea, the sunglasses always snap back to his head (like in the default pose). How can I avoid this? Also I have a lot of animations where I want to go from 1 animations end pose to antoher animation. They all look strange now because they are strangely mixed to the default pose in between these animations. I can't wrap my head around this new idea of spine please help, I need to put out an updated version to my audience!
09 Sep 2017, 11:11
Also altering the code as a temporary solution is not an option anymore.
There is no setupPose in the apply timeline method
There is no setupPose in the applyRotateTimeline
I totally agree to the comment: "The fact that animations revert to the setup pose as a default seem VERY counter-intuitive to me, the old system might have had its problems but the way everything worked was very intuitive."
The old way required everything to be keyed and that was very bad. The new way is much more manageable and enables us to have the animation Clean Up feature.
One way to do it is to use tracks. After an animation throws the sunglasses on the table, for as long as the sunglasses are on the table, play an animation on a higher track which keys the sunglasses on the table. This makes the fact they are on the table explicit, rather than being a side effect of an animation that was played previously.
Instead of using a higher track, you could modify the bones appropriately after applying the AnimationState each frame. This may be less easy when manipulating bones, but is often used to hide/show attachments.
You can edit the current AnimationState. In applyMixingFrom, try replacing the switch statement with the contents of the SUBSEQUENT branch. I haven't tested this thoroughly and it may work strangely when you don't key everything.
You can use the old AnimationState, but you need to fix up the Timeline and applyRotateTimeline calls, passing the appropriate values.