このサイトを正しく表示するには、最新のブラウザを使用し、Javascriptを有効化してください。

Mecanim - Motion Time & Cycle Offset not supported?

PeterBacall

Hi!

I'm using Unitys Animator with SkeletonMecanim. When applying a parameter to the "Motion Time" in the Inspector of the animator, I'm getting this error:

State "Aim Down" in Controller "Character Controller" uses parameter "" which does not exist.
UnityEngine.Animator:Rebind ()
Spine.Unity.SkeletonMecanim:ApplyAnimation () (at Library/PackageCache/com.esotericsoftware.spine.spine-unity@60922f90b0/Runtime/spine-unity/Components/SkeletonMecanim.cs:126)
Spine.Unity.SkeletonMecanim:UpdateAnimation () (at Library/PackageCache/com.esotericsoftware.spine.spine-unity@60922f90b0/Runtime/spine-unity/Components/SkeletonMecanim.cs:116)
Spine.Unity.SkeletonMecanim:Update () (at Library/PackageCache/com.esotericsoftware.spine.spine-unity@60922f90b0/Runtime/spine-unity/Components/SkeletonMecanim.cs:101)

More detail of what I'm trying to achieve:
When shooting, the character can aim at 4 directions, so there's four separate animations for that. When shooting and changing the aiming-direction mid-trough, the shooting restarts for the new aiming-direction. The solution would be to jump to a specific position in the animation, so it continues where it was. I'm trying to achieve that with Motion Time or Cycle Offset (hardly any documentation on Unitys part, but I guess those are the ones to test). And I noticed SkeletonMecanim doesn't support it?

PeterBacall

Harald

Unfortunately we are limited here by the Mecanim API providing playback time information, which does not seem to include or expose any cycle offset. For more details see this posting here:
Offsetting spine animation with cycle offset

PeterBacall

Thanks for the quick reply! What about the "Motion Time" parameter (in the animator state inspector), I think it's the "normalizedTime" https://docs.unity3d.com/ScriptReference/AnimatorStateInfo.html, I'm not sure but Motion Time used to be named "Normalized Time" in the inspector way back. Then I'd could add a parameter to it "ShootTime", and then fast forward all shooter states to that shared time?
Edit, more clarification: If I add a parameter now, I get those errors (the first post). But it should be able to work? But I get why Cycle won't

Harald

PeterBacall wrote
Thanks for the quick reply! What about the "Motion Time" parameter (in the animator state inspector), I think it's the "normalizedTime" https://docs.unity3d.com/ScriptReference/AnimatorStateInfo.html, I'm not sure but Motion Time used to be named "Normalized Time" in the inspector way back.

The SkeletonMecanim component uses AnimatorStateInfo.normalizedTime already to determine the animation playback timepoint:
https://github.com/EsotericSoftware/spine-runtimes/blob/4.1/spine-unity/Assets/Spine/Runtime/spine-unity/Components/SkeletonMecanim.cs#L267
If your modifications have no effect, the problem is as described earlier, unfortunately we are limited to what the Mecanim API provides as playback time.

Edit, more clarification: If I add a parameter now, I get those errors (the first post). But it should be able to work?

State "Aim Down" in Controller "Character Controller" uses parameter "" which does not exist.

If Animator.Rebind() causes the above error, perhaps your Mecanim state machine has not been saved, or something similar. Does that also happen after saving and if so, after closing and reopening the asset or the Unity Editor as a whole? In general there is no reason why adding parameters to the state machine should be incompatible with SkeletonMecanim.

PeterBacall

The problem is if I:

add a float to the Animator, called "Time".
I then add the "Time" as a Parameter to the "Motion Time" (of any State).
If I set the "Time" to 0.75f, theoretically the animation should now start to play from 75% in to the animation? If I have an event added around 50% mark of the animation (in the middle of the animation), it still fires when played from the 75% mark. But it shouldn't?

I don't know if this is a Unity problem, Skeleton Mecanim problem or if I've totally misunderstood the use of "Motion Time" as there's hardly any documentation on Unitys part.

Edit: I thought it was a way of of playing an animation from a specific point in time. E.g. I insert 0.25f into "Time", now all states with the Motion Time parameter "Time", should play from the 25% mark. But they don't

Thanks in advance!

Harald

I just tried it myself, strangely it seems that setting Motion Time via an Animator parameter has no effect, not even on the blue progress-bar in the playback preview of the Animator window. Admittedly I don't know what else could be done about it, as on the Unity forum users describe to have working solutions with just the above setup. If you would like to spend more time on this, you could have a try if a normal animated 3D asset shows is affected by set Motion Time and if perhaps just the blue playback progress-bar displays incorrectly.

If switching from Mecanim is an option, we highly recommend using the SkeletonAnimation AnimationState API instead of the Mecanim API, which allows you to customize any time offsets reliably.

PeterBacall

The project has come very far into development, over a year. I’m very tempted to switch to the SkeletonAnimation API, but I’m afraid it would take a lot of time to implement.
I can imagine a lot of animators out there prefer an animation blend tree, instead of having to code. At least in my case :/

Harald wrote
… if perhaps just the blue playback progress-bar displays incorrectly.

Unfortunately I have no experience with 3D, but will try to find an asset and check. But the SkeletoMecanim is definitely not updating correctly, or it’s events.

Harald wrote
Admittedly I don't know what else could be done about it …

Thank you for looking into it. In your opinion, should I move on and forget about it or is there a plan to try and fix it?

Harald

PeterBacall wrote
Unfortunately I have no experience with 3D, but will try to find an asset and check. But the SkeletoMecanim is definitely not updating correctly, or it’s events.
[..]
Thank you for looking into it. In your opinion, should I move on and forget about it or is there a plan to try and fix it?

The problem is that SkeletonMecanim can only update to the information it receives. Here Mecanim is either used incorrectly to set the motion offset (and the blue progress bar in the Animator window is correct), or it is used correctly (it would animated a normal 3D or 2D animation asset correctly) and does not forward the relevant data. If it does not forward / provide the required data, we're out of luck on our side with SkeletonMecanim.

[Edit:] Since you said you have no experience with 3D: To find out if it would work in general I only mentioned testing with a 3D asset, but you can as well use a 2D Unity asset, any standard asset that can be used in a Mecanim controller for testing purposes will do.

PeterBacall

For anyone curious who finds this in the future:
It's very strange... Tested a 2D animation asset, it animates the asset correctly, but the blue progress bar is always full (even though it moved the animation to the middle or wherever). The float I insert to the Motion Offset seems to randomly reset to whatever default value was set from start. (No code is manipulating the animator, it's strictly Unity). It's either very buggy or idk... Testing the Skeleton Mecanim, it seems to ignore whatever I input to the Motion Offset, the events are fired randomly instead of where they should. Unfortunately the Animator doesn't seem to forward the relevant data :/ I'll look into other work arounds

Harald

Thanks for sharing your findings!

PeterBacall wrote
Testing the Skeleton Mecanim, it seems to ignore whatever I input to the Motion Offset, the events are fired randomly instead of where they should.

Events firing randomly is something I haven't yet encountered (or noticed). I assume that you saw the animation playing back from the start (ignoring any offset) all the time, is that right? Or did you also see the animation playing at random offsets?

PeterBacall

Harald wrote
Events firing randomly is something I haven't yet encountered (or noticed). I assume that you saw the animation playing back from the start (ignoring any offset) all the time, is that right? Or did you also see the animation playing at random offsets?

Yes, the animation was playing from the back, but the events were fired out of order (not where they were placed).

Harald

Sorry for the late reply.

PeterBacall wrote
Yes, the animation was playing from the back, but the events were fired out of order (not where they were placed).

Hm, this is unfortunate, I'm afraid there is not much we can do on thye spine-unity side then. :wounded: