Hey all,

I took a keen interest in this tool and decided to start implementing the C# run-time for Unity.

spine-csharp

I've got the core data serialization/animation generalized so any C# library can use it. I let the library specific implementations be handled by external "controllers" while the generic library only holds an interface for working with the controllers.

I have an example of Unity controllers that can draw/animate debug lines.

Right now I've got the transformation timelines implemented with stepped and linear curves. Bezier curves should be coming soon. I also still need to work on the Attachment and Color timelines.

Hope I'm not stepping on any toes by diving into this. Hope it helps, cheers!

Oh, I get what the data classes are used for now. Instancing the same skeletons/animations multiple times. Shouldnt be too hard to refactor, just moving serialization out into those specified classes. I'll push to follow the libgdx runtime more exactly. I aimed to release under the same license as the current runtimes, no sense in duplicating the work.

I was mostly just trying to get the workflow into in Unity as a proof of concept for future projects. I felt my work would be useful to the community. The less runtimes you all have to write, the more you can work on improving the toolset.

Just a quick update - I added the Bone, Skeleton, and Slot data classes which are now used to initialize instances. I've got bones drawing and transforming in the proper hierarchy in Unity. Each bone is a unity game object that updates its own local transform using bone data. I plan on implementing the actual sprite drawing using Orthello and Texture Packer.

At the moment Unity handles updating the world transforms so I haven't implemented that code generically yet. I hope to get to it once I finish the sprite rendering.

Here's a quick screen cap of the current progress using Spineboy's walk:

HTTPS desteği olmadığı için görsel kaldırıldı. | Yine de Göster

That makes sense since I believe Unity uses some sort of reflection for their Update calls. So having that many game objects/reflective calls might incur quite a bit of CPU overhead. I was planning on using Unity's colliders attached to the bones for collisions which is why I used game objects.

I'll have do some profiling to see what the performance looks like with rendering. But it will definitely perform better by handling the animation logic under one object's update call.

Hey iAlwaysLoseThis,

It looks like you followed the libgdx runtime almost exactly. That's definitely more desirable than the work I did initially. Right now my focus is more on the Unity side of the C# runtime, where as you look like you're focusing on XNA. Perhaps it would be good if we combined our efforts. I could merge over your core code into the repository and add you as a dev if you'd like. That way we can work in parallel :rock:.

Also just an update on the unity side. It looks like I won't be using a game object per bone after all! There was an issue in Orthello were Sprites set the Game Object's scale to the pixel dimensions of the sprite....made some very interesting relative scaling artifacts haha. I switched the debug drawing to use world transforms as calculated by Spine.

Yea I realized that any work I did on the port would make the cross-runtime management a little difficult. I've started to undo most of the custom stuff because of that. I thought it'd be useful for bug tracking, updating and integrating with the official run-times if most of the C# stuff was centralized.

Also here's an Update on my work in Unity:

I've got basic non-sequential attachments resolving!

HTTPS desteği olmadığı için görsel kaldırıldı. | Yine de Göster

I did run into an issue in Orthello after a quick first pass. It appears that individual sprites in Orthello need to be attached to individual game objects. I had to flatten the Game Object hierarchy as well because of the relative scaling issue I was running into. There's probably a workaround but i'm going to focus on profiling the performance hit first.

I suspect this may be the case with other Unity 2D plugins.

Finished the Attachment Timeline work. So now you can swap out attachment images as seen in the dragon example.

I've done a bit of research into what it would take to have only one GameObject rendering all of the bones and it seems a little more complex. You would have one GameObject with the following: a mesh renderer, multiple meshes created for each sprite, and a material with the sprite atlas. You would then have to set each meshes' Texture UV co-ordinates and Position vertices. This would probably have to be done before a draw call inside of PreRender() using Graphics.DrawMesh(). I think this might??? still have the downside of multiple draw calls but it will eliminate the overhead of GameObjects.

I believe using this method would be plugin independent. Here are some links I used as references:

-Third Helix - Making 2D Games with Unity
-Unity Script Execution Order
-Unity Draw Mesh Reference
-Unity 2D Performance

Hey all just a quick update on the status of my work. I've been a little too busy to profile on an ios device/research more efficient rendering methods. I might be able to do that this week.

Here is a screencap of the AttachmentTimeline in action.

HTTPS desteği olmadığı için görsel kaldırıldı. | Yine de Göster