- UMotion - Animation Editor
-
Questions
Using an animation event handler with the AnimationEvent parameter in code
Hello Peter,
First of all, thank you for this great product, UMotion Pro makes it so much easier for me to author animations quickly in Unity rather than using Blender (although I miss the ability to use NLAs, if you ever want to add a new big feature, that would be a good candidate *wink* *wink* *nudge* *nudge*).
It seems that since Unity 5, we are able to write an animation event handler method in the code with an "AnimationEvent" parameter instead of an int, string or float. This is great for blended Animators so you can finally know what animation clip sends the event, and more importantly, what weight is the Animator layer at that time. That way, when your Animator uses a blend tree, blending between two "walk" animations, for example (one slow and one fast, or a walk and a run, or whatever you can think of), you can decide what sound to play and no longer have two sounds play at the same time, or at least the same code being run twice. This information comes from MecanimDev himself : https://forum.unity.com/threads/mecanim-5-blend-tree-animation-event-called-twice.318747/#post-2071893 (yes that post is 7 years old).
However, UMotion Pro does not seem to offer that option yet. It is possible to do it, but we get a small warning icon on the animation event in the UMotion Clip Editor because it wants either a void, or an int, or a float or a string. In practice, the handler still does its job so this is not really a problem, but the warning icon is a bit distracting.
Would it be possible for UMotion to detect whether the name of the function we write in the animation event window matches an event handler with the AnimationEvent parameter so it knows we really mean to use that function and this is not a typo please?
PS: When looking at the About window, I saw Pärtel in the Special Thanks section, which is nice except his name is "Lang", not "Lange" :)
Customer support service by UserEcho
Actually, after some more testing, I think this is a more serious issue than I thought.
In Unity, it is possible to inspect the data for an animation event in the animation clip itself, without needing UMotion for that. There is a field for an int, a field for a float, a field for a string, even a field for an object, and the important part is that you can set all of them at the same time. Before Unity 5 (if I'm not mistaken), we had to create a method to handle the event with only one parameter at a time, either int, or float, or string, or object, but not all at the same time. This is also what UMotion provides, only one parameter for the function.
However, since we can now specify an AnimationEvent object as the parameter of the handler method in the code, we can now access all four arguments at the same time, in the same handler. This is much better than before so we don't need to parse a string parameter anymore every time we receive an animation event, which saves time.
But UMotion does not let us do that, we can still only specify one parameter of one type and that's it. It would be great if you could improve the animation event window to include all four parameter types instead of only one, so it is on par with Unity's interface. Without this feature, it is still possible to use all the parameters but only by modifying the ".anim" file after having exported it from UMotion, and the next time we export it, those changes are lost.
Thanks!
Hi Nightkin,
thank you very much for your support request and thanks for your great words. I'm glad you enjoy working with UMotion.
Yes this makes sense, I'm going to update this in one of the next UMotion updates.
I wasn't aware that a way of accessing all parameters at once even exists. Thanks for mentioning that. I'm going to update the UI to support that in one of the next UMotion updates.
Please note that the next update might take a few weeks as I'm currently in the launch phase of a project I've been working on the last 3+ years. Thanks for your patience.
Thanks for mentioning that. I've corrected this in the upcoming UMotion patch release.
Best regards,
Peter
Thank you for your fast answer and for looking into this. And yes the documentation on this AnimationEvent parameter variant on the Unity website is a bit light, to put it mildly.
If you need an example code or any further information, please let me know.