We're not using Mechanim, just your SkeletonAnimation component. Mechanim seemed more limited / less supported, which sounds like you're confirming?

I hadn't seen that module. Was that linked somewhere? I will give this a shot. However, I think what Xelnath is describing has been one of our issues as well. I've struggled with the root motion bone blending back to the origin when the animations blend (e.g. from walk into idle). Another thing that would be super helpful, along with an official script, is an official suggestion of how to prepare the Spine file.

To clarify my "movement code" comment. None of our Spine characters are actually controlled by the player or via physics. They're all AI-driven. So they move until they reach a predefined target, basically. For what's relevant to this discussion, our characters simply translating left/right only on X (we conform them to the slope and angle of our ground outside the scope of root motion logic). Here's some videos from our game, it might make what I'm trying to describe more clear: https://twitter.com/OKDracula http://giphy.com/channel/okdracula

Our ideal character motion code allows the Spine animation to drive the translation along X. So I could play the "walk" animation, which has root motion information baked in, and it translates along X until it reaches the target.

We tried BoundingBoxFollowers initially but as I recall it acted very strangely. The collider ended up as a big jumbled overlapping mess, which didn't really move around in-line with the character's motion. Like the points were all in the wrong order, or something maybe?

So, to that end we ended up using a BoneFollower on a separate GameObject with a Collider2D and a Rigidbody2D.

My understanding of the docs was once it has a Rigidbody2D, you aren't supposed to reposition it with trasnform at all, you instead use MovePosition/MoveRotation. Did I misinterpret that? I did some profiling of the differences but maybe I misinterpreted it. They changed the way Rigidbody2D works a bit in 5.5, as well. https://docs.unity3d.com/Manual/class-Rigidbody2D.html

What would you say is the recommended way to add a Collider2D to a character, and have it track as it moves around? BoundingBoxFollowers? Any guide on how to set it up on the Spine and runtime sides?

I see that update on the spine-unity-download page. I think it's normally common for changelogs to be reverse-chronological. Also, none of this is in the "important spine unity topics" thread, nor the docs, nor the getting started page. This is my frustration, the information is all over the place., and naturally some is also outdated. For example, this page still says events don't fire during mixing which is longer true in the latest version yes? And the sample code is also incorrect now Coding for Spine Events and AnimationState callbacks

FWIW we'd love to help define and test officially supported root motion support! Would it help if Pasquale walked you through how we're currently implementing our root motion information in Spine?

Just to make things clear, Pasquale is my animator whom I referenced earlier.

I think you should focus less on how many posts we have, and just on whether or not what we're saying might happen to be true. I've read and searched on the forum since finding Spine. You can surmise a lot about a community without posting yourself.

In a small way, your post is an example of what I'm talking about. Isn't this my thread? Why not just reply to my concerns here? You sort of just glossed over them, and only replied to the update stuff. Which, thanks, those changes would be appreciated. While I can obviously choose not to update my runtime, what's the point of you publishing changes if I don't incorporate them? I've only ever downloaded the latest unitypackage from the website.

So, we're not trying to be a pain in the butt. I don't doubt your intentions. We are obviously passionate about this and have put a lot of effort and energy into launching our upcoming game with Spine runtimes at it's core. If Spine wasn't worth the effort we would have ditched it a long time ago. It could just be so much more effortless. The language we see on the forum and GitHub issues just often leave us scratching our heads about who your target market is. To be honest, it seems too large!

Anyway... I'd like to continue discussing our specific problems.

Our biggest one is with root motion. There's all kinds of old and dead end posts on the forum about it. Its mostly users trying to help each other. Overall, Esoteric employees seem to have an aversion to it.

Root Motion and Animation Blending
Applying Root Motion
Root motion Mecanim
Root Motion - Animation movement or engine movement ?
Leap Attacks, Jumping, etc
Root motion is not working
Root Motion - How to code it properly?

We're having issues getting this to work in our game. It's pretty frustrating, as moving around seems super core to implementing a Spine character. To us, root motion seems like the most reliable way to implement high quality animation cycles. If not via root motion, I never found an official guide on "how to drive a Spine character with your own movement code." How do you do it in Spine? We see this, and ask "aren't people moving their characters around? What is this thing for?"

Another, on the editor side, is with looping. To make an endless loop, we duplicate the first and last keyframe. The editor has an option to control where your loop cycles from. However, when we export for the runtime there's no way to exclude that final duplicate frame. I've found that via "trackEntry.animationEnd" there's a way to control where a loop stops, but it's time-based. It'd be so much easier to just "drop the last frame". Instead, once it's in the runtime, I have to do some magic-number-backed math to figure out where the final frame starts. This is looping, which seems incredibly core. "How are people doing looping? Do they not run into this?"

The last example I have right now is the way BoneFollowers work. They're incompatible with physics-backed GameObjects in Unity. Once something has a Rigidbody2D, you get a performance hit if you move it with it's transform (as the physics engine has to recalculate the scene). I've had to reimplement your BoneFollower script to my own based on Rigidbody2D's MovePosition/MoveRotation. Our characters have colliders, which we track to a bone. "Are we really the only ones doing this? Has no one else noticed the performance hit?"

Thanks for hearing out our feedback. And thanks for dedicating your time into making this thing at all.

Have to admit, there's a lot that's frustrating about your reply.

1: You can't subscribe to changes on GitHub in a way that helps here. Moreover, you have one repo for all runtimes. I only am interested in updates to Unity.

2: Not sure what you mean to imply by the unitypackage mirroring repo. It's listed as the preferred method for installing the runtime in Unity. Why would I go anywhere else?

3: Should I be expected to just subscribe to the entire (noisy) Unity support forum for a potential new meaningful post from you? At least make a single changelog announcement post, so we can just subscribe to that. Pin it and instruct everyone to do so.

4: Again, my desire is to not just occasionally check on pages and grep for changes. I'd like to be notified when changes are available... like the asset store handles.

5: As davidsvson said, it's difficult to even tell what version I have installed in Unity at any given time. I end up checking my own commit history, hopefully I included what date the download page said. Why don't you use version numbers, and include it in the files?

6: Lastly, I'm far from a lawyer but this is the only asset we use that seems to have that issue. What's the incompatibility? Skimming the Asset Store and Spine Runtime licenses, I don't understand what it'd be.

Overall, and this is getting into emotional territory, my impression from using Spine and implementing the runtimes for the last year is that your company isn't user-, animator-, or developer-centric at all. I'm constantly frustrated by the unhelpful responses from your company on this forum. My animator is frustrated with the lack of support for common animation-industry techniques. It feels like you begrudgingly support all these different runtimes, where none of them get the attention they deserve (jack of all trades, master of none).

We're constantly left wondering "who and what is Spine for?" when our seemingly basic desires are completely unaddressed. We've paid a lot for this software, and the support is abysmal.

Hello,

Is there a newsletter, or some way to keep up with updates released for the Unity runtime? As it stands now, my understanding is I need to just occasionally check on the http://esotericsoftware.com/spine-unity-download page to see if the "last updated" date changed?

It would be nice if I could be told when I should update. Have you also considered submitting the package to the Unity Asset Store (as a free package, naturally)? It handles notifications of new releases automatically.

Thanks

I haven't tested this, but are you just looking at the stats overlay, or did you check the frame debugger to see what's being drawn on each draw call? It has much more info on why something is being rendered when it is.