The problem is not with 3.5 animations. It's with the new AnimationState code.

I'll try to make an alternate (experimental) AnimationState.cs people can try like before.

What's the status of this issue? And or the experimental code?

We have an important deadline in 2 weeks and atm it seems reverting to pre 3.5 would be the best option. But that would be a massive pain becaue of the new converted.. Spine files.

Basically would have to revert them and make remake / import new Animations.

The glitches this causes are unacceptable for the build

Xelnath написав

Looking at the code, isnt this just a bug where because 1 ->2 -> 1 means 1 qualifies as being 'first' its not getting added to the list as 'last' as well - or worse is being mixed from the original mix at full alpha when it shouldnt be?

No, if the animations are A -> B -> A, the entry for each A is a different TrackEntry instance.

Xelnath написав

aren't both of these sections going 'backwards' up the linked list, when one you want one to be going backward and one to be going forward?

No, timelinesFirst adds the last linked list item first using call stack recursion. timelinesLast adds the first linked list item first, which doesn't need recursion.

Xelnath написав

A->B, and a key is only set in 'b', TimelinesLast won't be set for a value that was keyed in B, but not A, because the first thing it does is skip to the previous entry...

Not sure what you mean by skipping the previous entry. The code doesn't bother computing timelinesLast for track entries below the lowest track with a mixingFrom entry.

I believe the timeslinesFirst and timelinesLast calculations are correct. If there is a bug, it's elsewhere. Otherwise the logic to solve the dipping is flawed.

BinaryCats написав

Results in when Pickup is nolonger playing (i.e. currentTrackEntry.animation.name != "pickup") the skeleton, for one frame, snaps to setupPose, then continues playing idle.

I doubt this is related to this thread. Your Skeleton Viewer unit test idea is interesting. It's on my (not so) short list.

Xelnath написав

freeze the mix % between the current Timeline and the Bind Pose until the new Track reaches 100%

I'm not sure why or how this would solve the problem.

BinaryCats написав

What's the status of this issue? And or the experimental code?

Many other things needed attending so I had to stop working on this for a few days. You can try the experimental code, here it is updated to the current master branch:
http://n4te.com/x/1128-aAAq.txt
It works, there is no dipping, but interrupting a mix can have snapping. You could avoid that by disabling multiple mixingFrom entries. To do that, find this code:

if (from != null) {
   if (interrupt) queue.interrupt(from);
   current.mixingFrom = from;
   current.mixTime = 0;

   from.timelinesRotation.clear(); // Reset rotation for mixing out, in case entry was mixed in.

   // If not completely mixed in, set mixAlpha so mixing out happens from current mix to zero.
   if (from.mixingFrom != null && from.mixDuration > 0) current.mixAlpha *= Math.min(from.mixTime / from.mixDuration, 1);
}

And replace it with:

if (from != null) {
   if (interrupt) queue.interrupt(from);

   if (from.mixingFrom != null) {
      if (from.mixDuration > 0) {
         current.mixAlpha = Math.min(from.mixTime / from.mixDuration, 1);
         if (from.mixTime / from.mixDuration < 0.5f) {
            TrackEntry mixingFrom = from.mixingFrom;
            mixingFrom.mixingFrom = from;
            from.mixingFrom = null;
            from = mixingFrom;
         }
      }
      from.mixTime = from.mixDuration - 0.0001f; // One frame to mix out the old animation.
   }

   current.mixingFrom = from;
   current.mixTime = 0;

   from.timelinesRotation.clear(); // Reset rotation for mixing out, in case entry was mixed in.
}

This is how the old AnimationState worked, it chooses the closer of the 2 animations being mixed and discards the one that is further away. This means when interrupting a mix you'll get a snap, but it won't be nearly as bad as without this patch.

Thanks for the information, hopefully I will get a chance next week to check it out

Holy crap this is a lot of info. I'm experiencing this after the update as well. I will try that last code patch you suggested tonight and see how well it mitigates the issue.

Here's the modified AnimationState.cs in a gist for convenience. https://gist.github.com/pharan/cffdc3b2aee9288c9ca8b4ab94ee97d2

I've replaced the code block that Nate suggested with unfortunately even worse results. I made a short vid demonstrating. After I recorded that, I tried replacing the full code with what pharan posted, but had the same results as with Nate's patch.

I have a milestone deadline coming up in less than 10 days, so I may just downgrade to the previous runtime for now. Any cautions on downgrading, or is it just the same process as upgrading?

This has not solved my dip problem either

Guts написав

I've replaced the code block that Nate suggested with unfortunately even worse results. I made a short vid demonstrating. After I recorded that, I tried replacing the full code with what pharan posted, but had the same results as with Nate's patch.

I have a milestone deadline coming up in less than 10 days, so I may just downgrade to the previous runtime for now. Any cautions on downgrading, or is it just the same process as upgrading?

We have alpha in 3 days. We are just sticking with the bugs, and fixing what bugs we can.

The problem with downgrading is if your animator has made new animations and saved them in 3.5. as, and I may be wrong, I believe older runtimes will not support these animations (?), so you will have to downgrade spine, then do some magic to get the new animations in the older version of spine. As spine version 3.4 can not open 3.5 .spine files

BinaryCats написав

We have alpha in 3 days. We are just sticking with the bugs, and fixing what bugs we can.

The problem with downgrading is if your animator has made new animations and saved them in 3.5. as, and I may be wrong, I believe older runtimes will not support these animations (?), so you will have to downgrade spine, then do some magic to get the new animations in the older version of spine. As spine version 3.4 can not open 3.5 .spine files

I was actually using 3.5 editor with the older runtimes for quite some time. I got a warning whenever Unity imported skeleton data, but no actual bugs emerged in the game. (Your experience may vary :wait: )

I'm going to make a backup and take the plunge back to 3.4 after everything else I need to do is done.

goodluck

You can just go back to the 3.4.02 AnimationState (with minimal changes) and continue using the 3.5 editor and the rest of the 3.5 runtimes.

December 13th, 2016, 11:56 pm

I gave the modifications I posted a whirl and it didn't work as intended. I tested it when I wrote it, so that's odd. Here's the fix:
https://gist.github.com/NathanSweet/3aaeb489c2e8cdca76b31f5ae87f2b8b

This is an experimental AnimationState which fixes dipping and disables multiple mixing from. See the Gist history to go from the master branch AnimationState, to one which fixes dipping, to one which also disables multiple mixing from.

You should not see dipping, but you will see snapping when interrupting a mix because there is no multiple mixing from. That snapping happened with the old AnimationState, so you should be no worse off. Hopefully this helps!

Updated the C# version. same link. https://gist.github.com/pharan/cffdc3b2aee9288c9ca8b4ab94ee97d2

If you're not familiar with gist/github, make sure you click on Raw to get the plain text version instead of the formatted page. Makes for easier copying.

To use it, copy the contents of this version of AnimationState.cs, and use it to completely replace the contents of the AnimationState.cs in your project.

Thanks for this. I will give it a try too!

Will report back after I get around to implementing this. Thank you!

Hey, so I tried the edited version of AnimationState, and it does fix the dipping problem.

But I do also see snapping between some animations. I know you said it was there before Nate, but opening up my project with the old runtime I don't see it.

I think it might be because I spent a lot of time previously writing scripts with little quirks and workarounds to fix little problems like snapping, and now with the update some of these issues are redundant, but it seems other ones have popped up (or at least my workarounds don't work anymore). So I think I'm personally probably best off sticking with the old runtime and Spine 3.4x.

Would be great if you could find a solution to the Holy Grail: multiple mixing from AND no dip!

Thanks!

Thanks for trying it. It's expected to see snapping if you interrupt a mix. Are you seeing snapping at other times? Can you reproduce it in the Skeleton Viewer so I can see it?

It still happens for us on latest unity package. Do I need the experimental thing?

3.5+ Attachments And Mixing <- is the problem

19 Dec 2016, 10:51

oh.. I used the above animationstate.cs and it somewhat worked. The blend time looks very long now though compared to what it use to be :S :wonder:

My mixing issues have inexplicably vanished without addressing it. :wonder:
I must have inadvertently changed something in my implementation that phased out the emergence of the bug in my project. Maybe it was something to do with eliminating all uses of timeScale = 0...that was the only major thing I changed.