One other side note on your Orthello runtime - I think you likely need to handle case where an attachment drops from a bone in a given frame. We've got scenarios in our rig where we render a bone for a few frames in one behavior and then hide it
Working on a C# runtime
I wish I had time to follow what you guys are doing more closely, but I'm in C++ land for a bit longer before I can move on to Unity/C#. One thing I should note is that I wrote a class called AnimationState for managing the current animation and blending between animations. Example usage is here. When using mixing this is a lot easier to manage than doing it manually. Beware however, that today I will refactor it to two classes, AnimationStateData and AnimationState. This way AnimationStateData will hold the mappings and AnimationState will hold the per instance state data. Edit: done.
@Nate - awesome. Anim blending definitely a challenge - glad you're building it :o)
After poking around the perf a bit, I think I agree with ngomes - game object per bone isn't really optimal. Uploading the bone mesh directly likely to be more performant, but takes a bit more expertise than I've got with U3D
I also like the idea of the Unity runtime not being specific to a plugin.
That mixer looks a lot neater than the first version. I shall pull that into the obj-c runtime. Cheers Nate
Another update, I've added the ability to pass in string skeleton/animation data to the skeleton controller. This allows you to build the animations at run-time. Useful in cases where you want to download the animation data or read it from disk (Not bundled in a Unity Text Asset).
Jmcguirk, thanks for the feedback! I've added the ability to play multiple animations to the skeleton controller similar to what you did.
I'll be adding the Animation State changes and shoring up the implementation to look more like Libgdx. On the performance topic, I'm seeing 5 draw calls while running a single spineboy animation even with sufficient Z-Spacing. Once I add in a second/third animation like the dragon or goblin it spikes up to 15-20.
I'll have to look and see what Orthello is doing under the hood, but that performance is not scaleable. When testing on a mobile device it didn't look like the number of game objects was the current bottleneck. I really see the performance degradation when the draw calls spike up.
That's crazy. On my custom obj-c runtime, I get 40 spine boys, 30 goblins of different skins, and 5 dragons with one call to glDrawArrays
12 días más tarde
A few scratchy updates here -
#Ngomes - noticed the Orthello runtime isn't currently handling bone scaling (meaning a scale timeline exported by Spine is effectively ignored [easy change])
Noticed that skeleton parse time in our scenes was going up pretty enormously - this is because our naive implementation did a JSON parse and creation of SkeletonData and SpineData for each character. Our Skeleton JSON file is now 50k, and anims are 15 @ 10k a piece, so this became pretty nasty on IOS.
Solution is pretty easy - SkeletonData.cs and SpineAnimation.cs are both cacheable and reusable across all instances of a rig. Not sure it makes sense to pure static caching of parse results at the runtime level, but current setup of the skelly controller def sets up people to make the same mistake
Cheers!
How are you merging this in unity? I used the github but seems that I am missing something.
Ok i have TK2D I just need look at NGomes svn. Thanks for the help. At this moment I turned all my Spine animation to png and uploading all them to create a moving sprite. However, using this might be able to fix animation much faster. So far on the images I see it look pretty good.