RemDust

Hello guys :)

I'm having a hard time understanding what is the expected behavior about attachments when mixing animations runtime.

Expected behavior FOR ME :
- no attachment keys in editor = no attachment changes whatsoever when transition between animations : if I sprite-swap a hand during A and then transition to B I don't want the hand to reset at his original state but i want it to keep up with the change I've made during A.

Now this is the behavior I get when mixing animations on track 0 but when I try to animate on track 1 it always end up reseting my attachments even if I don't know what difference I have between track 0 and track 1 code... :sweat:

I checked for any ClearTrack operation and I don't have any, also don't have any SetToSetupPose/Slots, so it's not the problem. :bang:

Any idea about what I might be doing wrong ??
RemDust
Messages: 140

Nate

RemDust a écrit:if I sprite-swap a hand during A and then transition to B I don't want the hand to reset at his original state but i want it to keep up with the change I've made during A.
When using AnimationState, when an animation will no longer be applied, the pose state that animation was changing is reset to the setup pose. In your example, the hand will reset to the setup pose when A is no longer applied. This is true for all tracks.

It is not possible to configure AnimationState to customize this behavior. If you want the desired behavior you described, you would need to modify AnimationState.

Rather than keeping application state in the skeleton, it would be better to keep it in the application. What if you need to save the game state? How will you know what hand attachment to equip after loading the game? Serializing a portion of the skeleton isn't great. If the hand attachment matters for gameplay (eg, how much damage a punch does), it would be better for the application's data model to know what hand is active rather than inspecting the skeleton.
Avatar de l’utilisateur
Nate

Nate
Messages: 8424

RemDust

Nate a écrit:Rather than keeping application state in the skeleton, it would be better to keep it in the application. What if you need to save the game state? How will you know what hand attachment to equip after loading the game? Serializing a portion of the skeleton isn't great. If the hand attachment matters for gameplay (eg, how much damage a punch does), it would be better for the application's data model to know what hand is active rather than inspecting the skeleton.
It is actually already the case but only when I'm equipping an object, switching a weapon or initializing a level.

Check for what is equipped for every slot, piece of gear at every animation start seems a little bit overkill to me.
(right now the data model are actually changing fine but the attachments don't match the data)
RemDust
Messages: 140

Nate

Setting the Slot attachment is very cheap: it does nothing if the attachment is already the right one, else it sets a couple fields. It's not overkill to set all your attachments based on your data mode, even every frame.
Avatar de l’utilisateur
Nate

Nate
Messages: 8424

Pharan

You could also do this via runtime skins.
Blank out the runtime skin entry if you don't want anything equipped.
No need to set anything every frame or every animation in that case.

But you would need to animate your skeleton so that it shows every possible equip whenever you want them to be visible.
And at runtime, you only need to assign the equips to the skin you want.

Otherwise, yeah. Setting the attachment every frame is just a property assignment (which behaves as Nate described).
It's up to you which way you want to go.

But for sure, the way where you use animation sideeffects to leave attachments the way they were in previous animations would be a nightmare to manage on both Unity and Spine editor side. That was how Spine used to work and it caused a lot of problems for people and was incredibly unintuitive and time-consuming for animators. You can imagine having to hunt down attachments from every possible previous animation's changed attachments to every possible next animations attachments and have to make sure all of those are keyed, just to get animation mixing to work properly. Then imagine having to add new attachments or new slots to that skeleton. It got messy. And dopesheets got messy.
Avatar de l’utilisateur
Pharan

Pharan
Messages: 5338


Revenir vers Unity