Hey Nate!
When you get to updating the runtimes, I have a request for Spine-Unity. This post is kinda long but I swear, it's less work implementing than reading this post. I just wanted to share my thoughts. XD

The two main chunks of update work seem to be
1) Animation.Apply(skeleton) (done by AnimationState.Apply via SkeletonAnimation.UpdateSkeleton(delta) ) and
2) "Rendering"/building the mesh ( currently done directly by SkeletonComponent.Update )

I understand you made Update and UpdateSkeleton overridable methods for the purposes of extensibility/customization, but the current setup seems to be a bit confusing because SkeletonComponent's SkeletonComponent.Update calls UpdateSkeleton but SkeletonComponent.Update also does the rendering.

This doesn't make it possible for a few fairly common useful uses (implied by the overridability) by just making a new class, regardless of whether you're extending SkeletonComponent or SkeletonAnimation :
1) Custom delta for slowmo/timewarp or game-time-independent animations like pause menu animations - Can't pass a custom delta time to UpdateSkeleton because the base class SkeletonComponent automatically calls UpdateSkeleton and passes a delta itself in Update. Update is automatically called by Unity. Overriding Update will override rendering.

2) Staggered update/frameskip - Can't skip rebuilding the mesh or applying the Spine.Animation to the skeleton every other frame or two, whether for the purposes of staggering update work for performance (great for making large numbers of skeletons lighter) or for aesthetically making things look low-framerate or like stop-motion (ala Tearaway's special effects).

And maybe the not so common
3) External update control - Related to staggering updates, the current setup doesn't allow a separate entity to handle the timing and limiting of Animation.Applys and mesh rebuilds. I mean, right now, we could freely Apply Animations to the Skeleton held by SkeletonComponent, but SkeletonComponent would still proceed to burn away cycles updating the mesh naively/uselessly most of the time.

I know all this amounts to is some simple method call juggling but, personally, I'd rather the refactor from official Spine.

My recommendation is:
1) Move rendering code out of SkeletonComponent.Update into its own separate method. UpdateMesh?
2) Don't give SkeletonComponent an Update method. (It doesn't need to update itself and rebuild the mesh if the skeleton it holds isn't moving. If ever something updates its skeleton, that thing could/should call a rebuild of the mesh whenever it needs to.)
3) Give an Update method to SkeletonAnimation. Make that call a mesh rebuild every time after Animation.Apply (via AnimationState.Apply).

I think that'd allow these and other less-standard functionality to be built by simple extension of classes.

But I'm sure you built this with some architecture in mind so maybe you have a better idea for how to accommodate this.
The other reason I brought up Skeleton.time in the other thread is because that seemed to be the only thing SkeletonComponent.UpdateSkeleton did. I was wondering if it did something important.

Re: order of updates
MonoBehaviour Updates are called based on the order scripts are loaded, "which is arbitrarily", unless you specify them manually in Script Execution Order in the editor.

I have the impression that people generally don't want to touch Script Execution Order unless they really have to.
It makes it a bit messier/error prone to add the Spine runtime into a project or work in groups.

There's a page describing a bunch of other automatically called MonoBehaviour Event Functions but I dunno if anything fits the bill. LateUpdate is there though, and the method execution order, in case you're curious.

Re: doing something after AnimationState.Apply and before Skeleton.UpdateWorldTransform
I think the current setup where there's an UpdateBones delegate called right between these calls works well.
It could probably be renamed something more generic though.

It being a delegate type is pretty handy. You can subscribe and unsubscribe, and you can reorder the invocation list.

Did you have a problem with this?

Re: a dirty flag so SkeletonMesh can determine when to update itself
Unity tutorials have always recommended not to have "empty Update methods".
But I'm not actually sure how badly it impacts performance to many objects that have Update methods that do nothing.

But considering the dirty flag is precisely to save on performance of updating hundreds of skeletons...
I lean more towards SkeletonMesh not having an Update.

If only to heed Unity tech's ominous warnings. : p

On the other hand, what's your motivation for separating SkeletonMesh and SkeletonAnimation?

Re: the applications
Yeah. I think it'd work well.

1) If I wanted a Spine animation setup to be "immune" to the game pausing, slowing down or speeding up, I'd extend SkeletonAnimationthat overrides the Update method so it passes a delta time source that's different from Unity's Time.deltaTime. Then make SkeletonMesh update.

2) If I wanted something to update only every other frame, I'd extend SkeletonAnimation and override its Update so it does nothing every few frames, tracks its own deltatime to pass to AnimationState.Update(time) and then make SkeletonMesh update only when it updates.

1 and 2 both assume Update is still overridable.

3) For external update control, I'd make my own version of SkeletonAnimation that does the AnimationState stuff and update the SkeletonMesh but not automatically on Update. Instead, another class can call a method to do that stuff.
To stagger the update, I'd store a bunch of SkeletonAnimations in an array in a separate class, then traverse and update its elements with an i + 2 or i + 3 or something, with a different starting index each update.

And there's more than one way to do these things cleanly now without jumbling up Spine's runtime code (and making it harder to update when the runtime updates).

Re: limiting updates for the SkeletonMesh and SkeletonAnimation
There's a thing that UnityEngine.Animation does that has an option to stop playing animations when the mesh exits the camera's view.
This enum kinda describes it concisely.

If you're gonna refactor to allow customization of when/how often updates happen, might as well make sure this animation culling optimization can be done by the user, even if you don't build it into the runtime officially.

A Unity user can easily detect when the renderer enters and exits view through OnBecameInvisible and OnBecameVisible or the MeshRenderer's boolean Renderer.isVisible.

Re: the name of the posing and updating component with the AnimationState
Why don't you keep it as SkeletonAnimation?
or SkeletonAnimator
SpineAnimationState?

I'm not sure how this naming will affect the other runtimes and documentation.
I'm partial to SpineMesh and SpineAnimator.

Another reason is we may have multiple implementations of SkeletonMesh if meshes or FFD would negatively affect rendering for skeletons that don't use those features. Eg SkeletonMesh, SkeletonSkinnedMesh, etc. There could also be a SkeletonMesh that improves performance when using only a single atlas page, if that proves true.

Makes perfect sense. I like it.

The delegate is ok, but it is not as nice as being able to control when components on a GameObject are updated, which IMO is a basic necessity for a system like Unity. Having Update and LateUpdate is pretty terrible and leads to stupid things like LaterUpdate, LaterererUpdate, EarlyUpdate and EarlierUpdate... :no:

lol. LaterererUpdate.
I'm going to include that in code someday.

I suspect, behind the scenes, these components are added to an array per Component type and just iterated through, instead of in any specific order per object.
Because prefetchers.
And hence you can reorder Script Execution Order globally but not per object.
But we may never know the workings of closed-source things... mysterious hands

It's not a huge bother to reorder. And you can. But it's just one more place where you can get user-side errors. So people avoid it.

But really, with the new structure of SkeletonMesh and SkeletonAnimation you described, and since as you said, SkeletonAnimation really isn't much code, it won't be difficult to make a different implementation (via a subclass or just a different class outside the hierarchy) of SkeletonAnimation that makes stuff happen between the AnimationState Update&Apply and skeleton.UpdateWorldTransform. I totally think the delegate is a great way to go though.

For all the basic functionality, we'll have vanilla SkeletonMesh and SkeletonAnimation.

You can do this now with AnimationState#timeScale.

SkeletonAnimation uses AnimationState.Update(UnityEngine.Time.deltaTime * timeScale).
That won't work for pause menus, in a paused-game or timestop situations (ie, where UnityEngine.Time.timeScale == 0f. Time would just keep giving AnimationState zero deltaTimes).
Plus it'd involve having to slide every AnimationState's timeScale you want to 'immunize" by the reciprocal of UnityEngine.Time.timeScale.
More manageable to centralize their deltaTime source with a customized timer and make the immune SkeletonAnimations use deltas from that.

SkeletonAnimation is hardly any code, it mostly exists just so it can be controlled by the Inspector. It isn't hard to write your own class that applies an AnimationState if you need added control.

True. But in its relationship with SkeletonComponent, you can't. SkeletonComponent Updates every frame, and causes SkeletonAnimation's AnimationState to update and apply every frame, then builds the mesh.
I think this really isn't an issue with the new structure you mentioned. It's just an additional perk, I guess, because it'll be totally doable.
It is doable now but I just needed to point out that the current resulting call stack doesn't allow it. Just needs minor adjustment for which method calls who.

What if SkeletonMesh used OnWillRenderObject to check a flag and update the mesh if needed? This also means the mesh won't be update when off-screen.

This is one way to implement the animation culling thing (and in Spine's case, the rebuild-mesh-culling thing). But I think the there should still be the option for the thing that poses the skeleton to determine when to make SkeletonMesh rebuild the mesh.

But if you really want official SkeletonMesh to be self-updating, I guess this passiveness could be a different implementation of SkeletonMesh.

Oh, you mean OnWillRenderObject will check the flag.
That'd fix the LatererererUpdate predicament too, I guess. Plus it's descriptive and in the right place in execution order.

Ohh. and this separation is cool 'cause it'll easily support an alternate version of SkeletonMesh that uses multiple GameObjects as its "rendering" method, which will be easier to ragdoll and attach things to and influence with physics.

Sorry! I was out for the day. I'll be out again tomorrow.

(1)
The one I made also assigned new triangle indices every frame because it's unpredictable where the meshes insert themselves especially with draw order animations, or when they swap to other meshes with a different number of vertices.

I also added a public bool alwaysUpdateTriangles so I could easily optimize and switch this behavior on and off for specific skeleton setups.
I'll actually just readd it to my project whether you put it in there officially or not, 'cause I kinda need it for our crowd setup. :p

I'd be modding it either way to darken the vertex colors it pushes 'cause we're using a modified version of the Skeleton shader that allows it to overbrighten the texture way past RGBA(1,1,1,1)— because flashing skeletons make good game feedback!

In Spine-C#, I also cached vertexCount in the attachments themselves in SetMesh so I could avoid the array property access and int divisions in SkeletonRenderer:line 130, 135, 326, 330.

(2)
I expected the awkwardness of having SkeletonMesh and SkeletonAnimation both needing to hold a reference to the same skeleton.
And it would also be a bit weird to require and to not require SkeletonAnimation to have a SkeletonMesh component to be attached to the same GameObject, considering the point of the separation was to allow SkeletonMesh to have a different implementation.
And I was averse to the separation at first because it'd mean that it'd break the setups of everyone already using Spine.

But I think the separation would still be useful as an option for people who need to mix and match.
I guess it's not that hard to implement though. Anyone who ventures into that territory of modifying Spine will know how to be careful with the separation.
I think extending SkeletonAnimation will do for most cases.

The ragdoll-friendly individual-gameobject setup will be interesting to make. And we can put them side by side with the single mesh version and see who wins in performance. But that's for another day and for when we have more time.

(3)
BoneComponent currently has some problems that I wanted to fix but didn't really get around to just yet, like it doesn't follow the bone properly when the skeleton flips because it doesn't know of flipX and flipY at all.
I thought it could be a bit agnostic and not really need SkeletonRenderer or SkeletonAnimation, but I guess it really does need that reference to their Skeleton object at the very least to know the state of flipX and flipY.
The caching logic also needs some accounting for cases when things aren't assigned or the BoneComponent is added at runtime through code. That's my bad, really for adding it the way I did. I'll fix it, I'll fix it!

(4)
API:
I like how UpdateBones now passes the SkeletonAnimation to the subscriber. Though one would expect the subscriber to have already had the reference to that SkeletonAnimation at the point of subscription. But I guess this removes the necessity of one centralized object having to store references to a hundred SkeletonAnimations if it needed to do UpdateBones for all of them. Can't imagine why you'd pattern code that way though.

If I wanted to change the conditions that cause a mesh rebuild, would I override OnWillRenderObject and go

if(conditions) {
     base.OnWillRenderObject()
}

?
That'll do, right?
And if I need another class to determine when to repose the skeleton and rebuild the mesh, the condition can just be a dirty flag.

(4) addSubmesh needs to be AddSubmesh.

Just attempting to update to the new runtime.

So Initialize is now Reset?

I don't think Reset is safe to call now.
The point of the original Initialize method was so scripts that ran their Awake before SkeletonComponent's Awake could force SkeletonComponent to do its thing (particularly initialize its skeleton) so it could do things like get references to slots and bones and the skeleton itself.

Without the check, it would create and orphan instances of Skeleton (in SkeletonRenderer) and AnimationState (in SkeletonAnimation) with each call to Initialize (or Reset).

There's a bug in SkeletonJSON in C#. The JSON scale isn't being applied to the meshes.
line 223 should be

float[] vertices = GetFloatArray(map, "vertices", Scale);

I'm having strange bugs. Some of my skinned meshes are being drawn upside down.

Some other meshes have UVs that are just plain messed up.
This isn't a rotation problem. These were atlases packed before meshes and skinnedmeshes supported rotated regions so they were exported with rotation disabled.

My bad, it's not just meshes.
Specific entire skeletons have region attachments that are mapped all wrong.
But others are fine.
It can't be an atlas problem. I have several skeletons sharing the same atlas. Some skeletons have ALL attachments that have messed up uv-mapping. Some of them are completely fine.
Some of the ones that are messed up use meshes, some of them don't. Likewise for the skeletons that are fine.

Things outside of SkeletonMesh shouldn't have to worry that the SkeletonMesh is not initialized. Scripts should use Start to communicate with other components, not Awake:

This is the LaterererUpdate all over again. Some scripts need to do this on Awake so other scripts can start in Start. The scripts that could be doing this may very well be lower-level systems just on top of Spine but below everything else.

How about this:
Add Skeleton and State getter properties that forces initialization when it hasn't initialized yet and just returns the skeleton and state if it already has them ready.
That way, other scripts don't have to worry about SkeletonMesh or SkeletonAnimation not being initialized to get to the skeleton and the AnimationState.

One thing I find weird though: I don't see what use replacing the existing skeleton reference with a new one would be except in Unity Editor.

I don't see any changes that would've fixed the problem with the weird uvs.
And it didn't fix the problem.

I'm still readding the alwaysUpdateTriangles bool to mine 'cause that still allowed meshes to be used as long as they didn't change order or swap to other meshes, which can be pretty common for enviro stuff. (ie, didn't require the triangles indexes to be updated after the first time.)

Re-exporting doesn't fix the problem. At least that rules that one out. My primary suspect is SkeletonJSON.
I'm trying to figure out how to get examples to you.

If it's any clue, the UV maps are messed up but consistently mapped at 180º rotated boxes with incorrect coordinates. Though the coordinates seem to have some sense since the mapping isn't skewed or stretched. Just at the wrong place and rotated 180º.

(There's 2 SkeletonDataAsset fields in the inspector for SkeletonAnimation.)

I think the UV thing is related to Unity's (u, 1-v) coordinate system for UVs.
Addressing it flips which ones get broken and which ones are okay.
It doesn't explain why it's ok for entire skeletons of some, for any type of attachment, and everything's flipped for others.

Is it an Atlas thing? Is FlipV being called for some but not for others? But since it's shared, shouldn't it apply to all skeletons trying to use the same atlas?

See SkeletonDataAsset.cs : line 76

In this situation where the atlas is shared by different SkeletonDataAssets;
for each SkeletonDataAsset gets initialized by GetSkeletonData, the shared atlas gets flipped by line 76.

Woo! That flipping thing was funny while it lasted. :rofl:

Awake gets and stores the SkeletonRenderer/SkeletonAnimation reference but doesn't use it. Start uses it. SkeletonRenderer/SkeletonAnimation don't have Start, so there is no problem with a script's Start happening first. Is that right? What is a scenario where Awake and Start won't work?

Scenario:
In a separate low-level component type (Let's call it SpineCharacterAnimator), Awake would need references to Skeleton and AnimationState to find bones and animation references and make the animation autoreset and other things, so that the higher-level scripts can use Start or do a safe initialize to do their things with the lower-level components.

This is under the assumption that the best way to use SkeletonRenderer/SkeletonAnimation is not to extend it or make sibling classes for it but to have various other component classes to manage it in different ways depending on the need. (This is at least the option for people who subscribe to component-instead-of-subclassing architecture, plus making making the rendering work in UnityEditor without having to write a new inspector class for each new extension)

Either way, without the safe initialization or a lazy-instantiation getter, you'd be taking away the user's ability to use Awake cleanly or chain a bunch of initializations safely for their own purposes in all other scripts related to SkeletonAnimation.

Unity forces public fields so to use a property we'd have to renamed skeleton to _skeleton.

I'm not sure what you mean by "forces". You mean Unity forces fields to be public? That's not true.
Does this have something to do with things being visible in the inspector and compatibility with playmaker or something?

Not sure what you mean. At runtime Reset will only be called once.

Ah, you're right.

I'm still readding the alwaysUpdateTriangles bool to mine 'cause that still allowed meshes to be used as long as they didn't change order or swap to other meshes, which can be pretty common for enviro stuff. (ie, didn't require the triangles indexes to be updated after the first time.)

I suppose that is a good optimization, though a little scary since it can completely break things if used on the wrong skeleton. I'll add something.

What I did was make this field default to true so we could turn it off to opt-in for optimization. And I didn't add it to the inspector script so whoever uses it is forced to enable Debug mode for the inspector panel to get to its serialization, and also to make it a bit more clear that it's something to be careful with.

Hmm.. okay. I'll review some stuff and do some digging. :wonder:
Seems like rather ambiguous ground in places. AnimationState kinda has what you'd expect as the API of a MonoBehaviour so I would think the ideal of storing references to scripts in Awake kinda apply to it.
If things were different, SkeletonAnimation would be the thing you'd tell to SetAnimation and subscribe to for events and stuff like that.

I guess for the official thing, it'll be fine to leave it as is.
I haven't really gone through my code that thoroughly yet either.
I'll let you know about the instantiation thing.

:think:

If I wanted to get Animation references... I really should've been going through SkeletonRenderer.SkeletonDataAsset.GetSkeletonData. That has safe initialization.
Bones and slots and the skeleton flipping interface are a different matter.

I think I'll do a PR sometime to better illustrate recommended arrangement stuff in Unity through an example scene with Spineboy.
And so I'll have a place to check and point to in case I forget.
Maybe mark it "Advanced" so people just trying Spine out don't think it's super-required just to get things running.

We found and fixed the bugs anyway. (I liked the mini-goblin.) So ,yay!

By the way, you removed mesh.RecalculateBounds()?
Its absence was causing meshes to disappear even before it completely left the camera's view.

It's possibly expensive to put in an Update method but we should probably allow it to at least set some good bounds values at some point.

viewtopic.php?p=12483#p12483

We needed it after all. And I don't know what to believe anymore.