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.