I was wondering if there was a supported solution for getting events to trigger from Edit Mode when scrubbing through an animation? I have tried several different things but do not seem to be able to get them to trigger anywhere but in Play Mode.
I have tried using a script to apply the animations manually and also using the Timeline but none seem to work.

I'd be fine with even a work around since I am just using this to make an editor tool to visualize and edit hitboxes. I don't want to use the Spine bounding boxes and want to just use simple geometry like circles and capsules that are based on the animation frames. So I am trying to hack together a simple tool that makes it easier to edit the data linked to the animation events that facilitate this.

Related Discussions
...

  • Harald

  • Messaggio #2
  • Questo post è in inglese

@havok635 Thanks for providing the full description of what you're trying to achieve.
We have just added an additional static EditorEvent callback delegate for the Timeline extension package. From the changelog:

Timeline extension package: Added static EditorEvent callback to allow editor scripts to react to animation events outside of play-mode. Register to the events via
Spine.Unity.Playables.SpineAnimationStateMixerBehaviour.EditorEvent += YourCallback;.

A new 4.1 Spine Timeline UPM package is available for download here as usual:
https://esotericsoftware.com/spine-unity-download
Please let us know if this helped.

    Harald
    That looks like what I need, I'll give it a shot once I get home in a little bit. Thanks

    On a side note, is there any chance that Spine will support simple geometry like circles and capsules as an attachment so that this data can be designed with the animation in spine rather that having to implement it in some things like the runtime editor? It would be fine to implement the collider stuff involved runtime side, but the actual shapes and there position and rotation spine side.

    Similar to this image from smash bros

    I know there is the bounding box already but from my understanding it is much less performant to use more complex shapes to test for collisions. Plus it needs to create GameObjects in unity to follow the bones, which is another performance heavy operation.

    At present I am just having an event notify unity that a hotbox is active and then grabbing a hotbox bone location. Then taking that location and doing a Physics2D.OverlapCirlce with the location and unity side data for the size and angle(for capsules). I'd like to be able to design the size and angle data in Spine, but for now I am just making a tool in unity to do so.

    Sorry for the lengthy explanation and thank you for your support and help.

    • Harald ha risposto a questo messaggio

        Harald
        So I have com.esotericsoftware.spine.timeline version 4.1.12 installed and when I went to use EditorEvent it did not show up for me. Checked the source in the file SpineAnimationStateMixerBehaviour.cs and there is no EditorEvent in the file.
        Not sure what I am doing wrong

        • Harald ha risposto a questo messaggio

            • Harald

            • Messaggio #5
            • Questo post è in inglese

            havok635 So I have com.esotericsoftware.spine.timeline version 4.1.12 installed and when I went to use EditorEvent it did not show up for me.

            It seems like you have downloaded the old package. The feature was implemented in 4.1.13 (with date 2023-09-13). Perhaps you need to reload the download page to see the updated URLs.

                • Harald

                • Messaggio #6
                • Questo post è in inglese

                havok635 On a side note, is there any chance that Spine will support simple geometry like circles and capsules as an attachment so that this data can be designed with the animation in spine rather that having to implement it in some things like the runtime editor?

                That's a valid point, thanks for sharing! I'll forward the idea to Nate. I'm afraid it would take some time however, as the physics features are consuming major parts of the development time currently.

                havok635 Plus it needs to create GameObjects in unity to follow the bones, which is another performance heavy operation.

                This would not really change, as you still need to have separate GameObjects for the circle or capsule colliders. It's not really a heavy operation to let GameObjects follow the bone locations.

                    • Harald

                    • Messaggio #7
                    • Modificato
                    • Questo post è in inglese

                    @havok635 I just noticed that a bounding-circles feature is already on the roadmap:
                    EsotericSoftware/spine-editor39
                    Unfortunately that ticket is already very old and got delayed for quite some time now.

                    In the meantime, perhaps a suitable workaround could be to utilize bounding box attachments in Spine and then replace them with box- or circle-colliders on the Unity side. This way you could see and activate/deactivate a bounding box attachment in Spine (of unit-size, width and height controlled only via scale instead of moving vertices around) and replace it with a bounding box component in Unity. You could copy and modify the BoundingBoxFollower component and replace occurrances of PolygonCollider2D with BoxCollider2D respectively.

                      Harald I was pulling from GitHub and hadn't updated to 4.1.13. That worked thanks

                        Harald Thanks I think I can work out a way using this and then if the official way gets implemented I'll just write it in a way that is easy to replace. Thanks for all the quick responses and insight!

                          I do have one more question if that is alright. Now when I have this implemented it seems to hammer the event call every frame following the frame call based on the Spine animation. My question is this a symptom of something I designed wrong in Spine or is it on the Unity side. My understanding is that when you key an event in Spine it just fires for the frame it was keyed on.

                          Thanks again

                          • Misaki ha risposto a questo messaggio

                            • Misaki

                            • Messaggio #11
                            • Questo post è in inglese

                            havok635 Sorry for the delay in response! Harald is currently on vacation and will return on September 21st. Sorry to keep you waiting, but please wait for his return.

                              • Harald

                              • Messaggio #12
                              • Questo post è in inglese

                              @havok635 Sorry again for the delay.
                              The SpineAnimationStateMixerBehaviour.EditorEvent is by design issuing all events from timepoint 0.0 to the current Timeline seek timepoint. This might seem strange at first, but ensures that you always receive your events in the correct order and have a consistent state regardless where your previous frame in the Timeline was, also when seeking backwards. Imagine for example that you have the following events:

                              • time 0.3: enable small hitbox
                              • time 0.6: enable medium hitbox and disable small
                              • time 0.9: enable large hitbox and disable medium

                              Now when seeking to timepoins 0.4, 1.0, and 0.5, you get the following events:

                              • seek to 0.4: first event only, enable small hitbox
                              • from 0.4 seek to 1.0: all 3 events in order: enable small hitbox; enable medium hitbox and disable small; enable large hitbox and disable medium.
                              • from 1.0 seek to 0.5: first 2 events: enable small hitbox; enable medium hitbox and disable small.

                              Thus you didn't setup anything incorrectly in Spine. What you likely need to add in your code is to set your initial clean state (similar to Skeleton.SetToSetupPose()) in the first SpineAnimationStateMixerBehaviour.EditorEvent callback of a frame before the first animation event is processed. You could e.g. do this by checking if Time.frameCount increased from the last callback call.

                              If you see any problems with this design, or need additional help, please don't hesitate to let us know.

                              Thanks for the detailed reply, I appreciate that. That makes sense and I will that a go. Thanks again for all the help!

                              • Harald

                              • Messaggio #14
                              • Questo post è in inglese

                              Glad it helped, thanks for getting back to us.