Esoteric Software

[Nate]

Now that skinning is ready, we're working non-stop to get meshes, FFD and skinning into the official runtimes. I just committed spine-csharp and spine-xna. Next is likely spine-unity and spine-tk2d, then probably spine-c, spine-cocos2d-iphone and spine-cocos2dx.

You can follow the progress by subscribing to the Trello task.

[randeroo]

Awesome!

[Lazrhog]

Fantastic Work guys !!

[knish]

Awesome!! When can we expect meshing support for cocos2d runtime?

[Funbox]

In a few days we'll start with our new game with unity, so we are glad to listen this news.

[Nate]

spine-unity and spine-tk2d have been updated to support meshes, FFD and skinning! The goblins example project shows it in action. For TK2D I had to remove the goblin girl skin, since TK2D doesn't like having images with the same name in different directories.

---

spine-c and spine-sfml have meshes and skinning, missing FFD though. Should be in tomorrow.

---

spine-c and spine-sfml have FFD, they are complete.

[thedjcoder]

EDIT2: I found another issue related to the FFD implementation. In _spFFDTimeline_apply you memcpy too few bytes
memcpy(slot->attachmentVertices, lastVertices, self->frameVerticesCount);
should be:
memcpy(slot->attachmentVertices, lastVertices, self->frameVerticesCount*sizeof(float));

EDIT: It seems the old ffd example file doesn't work anymore, I replaced it with the latest one in the sfml folder and it now works!
I did find another big bug (memory overwrite) in there. It seems you create spFFDTimeline by casting from a base timeline struct which is smaller in size. I added some reserved space in the spBaseTimeline struct and the guard malloc now do not give an exception there. I found it by trying to debug some random crashes in spine so I debugged it with malloc guards to find this issue. Hope this helps!

---
Hi Nate, I integrated the latest changes in spine-c into our engine from github but now skinned meshes do not work. It seems this line:
i += 1 + boneCount * 4;
in spSkeletonJson_readSkeletonData function breaks it.

If I revert back to something like this:
i += 1;
It works fine again.

Am I missing something, I haven't had the time to really go through the code within spine to know if your change is correct and maybe something else breaks it or if you were too drunk to submit
J/K, thanks a lot for your hard work! I am looking forward to start using FFD, meshes and skinning!

Is there a better way to report bugs like this, email directly to you instead or forum is fine? I have found a few more issues of less importance that I would like to report!

Cheers,
Daniel

[Nate]

Thanks for the pointers Daniel! I've fixed the memcpy and spFFDTimeline size problems.

About the i increment problem here, that for loop is counting how many bone and weight entries there are. If you look at the very next for loop after that one, it iterates the data again and this time stores the values. These two loops should match and I think they are correct.

[kamend]

Hey Nate,
I have a problem with FFD and Unity, for some reason, the Mesh animation I do in Spine, comes different inside Unity. I noticed that the mesh inside Unity is a little bit different that the one in Spine or at least there is some problem with the size of the texture. I think inside Unity the mesh is not with the correct UV coordinates.

I am attaching screenshots from Spine and Unity:

Screen Shot 2014-05-02 at 8.20.08 PM.png

Screen Shot 2014-05-02 at 8.19.56 PM.png

May be I am doing something wrong?

Thanks!

[Nate]

Hmm. Is it possible you are using whitespace trimming in your atlas?
viewtopic.php?p=12562#p12562

[kamend]

Yes, when I disabled the stripping, the Mesh aligned with the texture, but for some reason, the animation is still wrong, some of the vertices I animated in Spine are not moving at all. Seems like a weight problem.

Kamen

---

Something weird I noticed in the exported Skeleton JSON is that the number of vertices in the FFD animation section does not equal to the numbers in skins section.

{
"bones": [
{ "name": "root" }
],
"slots": [
{ "name": "Circle", "bone": "root", "attachment": "Circle" }
],
"skins": {
"default": {
"Circle": {
"Circle": {
"type": "mesh",
"uvs": [ 1, 1, 0, 1, 0, 0, 1, 0, 0.23828, 0.76757, 0.16601, 0.68945, 0.13671, 0.58593, 0.13671, 0.45703, 0.16796, 0.36914, 0.4082, 0.81445, 0.73632, 0.7539, 0.8457, 0.60351, 0.83789, 0.3164, 0.7246, 0.1914, 0.53906, 0.125, 0.41992, 0.13281, 0.33203, 0.16601, 0.24218, 0.24023 ],
"triangles": [ 0, 1, 9, 1, 4, 9, 9, 10, 0, 10, 11, 0, 11, 3, 0, 1, 5, 4, 1, 6, 5, 1, 7, 6, 7, 1, 2, 10, 9, 8, 14, 10, 8, 11, 10, 14, 17, 14, 8, 15, 14, 17, 17, 16, 15, 9, 4, 6, 9, 7, 8, 11, 13, 12, 13, 11, 14, 4, 5, 6, 11, 12, 3, 9, 6, 7, 7, 2, 8, 8, 2, 17, 12, 13, 3, 17, 2, 16, 13, 14, 3, 16, 2, 15, 15, 2, 14, 14, 2, 3 ],
"vertices": [ 249.34, -274.82, -262.32, -262.84, -250.34, 248.82, 261.32, 236.84, -137.61, -146.77, -173.65, -105.93, -187.4, -52.61, -185.86, 13.33, -168.82, 57.93, -51.23, -172.79, 117.37, -145.74, 175.14, -70.1, 174.58, 76.89, 118.12, 142.2, 23.97, 178.4, -37.07, 175.83, -82.44, 159.89, -129.3, 123 ]
}
}
}
},
"animations": {
"animation": {
"ffd": {
"default": {
"Circle": {
"Circle": [
{ "time": 0 },
{
"time": 0.8333,
"offset": 8,
"vertices": [ -39.01, -43.34, -65.02, -40.45, -46.23, -8.66, -34.68, 5.78, -24.56, 5.77, -18.78, -36.12, 0, 0, 28.9, -2.88, 40.46, 0, 33.23, 24.56, 0, 23.11 ]
},
{ "time": 1.3333 }
]
}
}
}
}
}
}

May be some error during the export?

[Pharan]

The runtime skips vertices that don't get animated. The number of vertices skipped is stored as offset.
I wonder what's going on though.

Oh yeah, have you re-exported it recently? There was a bug in the editor before where if you exported in Animate Mode, it exported the deformed mesh as the setup pose. So your animations would also look weird. That bug was fixed in a recent update though.

[kamend]

I have the latest version, tried exporting both in Animated mode and Setup, same result. It's animating the wrong vertices.

[Nate]

I'll need to reproduce the problem so I can investigate what is wrong. Can you email a Unity project showing the problem? contact@esotericsoftware.com

[kamend]

I have sent you an e-mail with the project attached.

[anggog]

Cococs2d does not currently support spine mesh function?
I need help！！！

[Nate]

Thanks, fixed in git! Your project was empty, but I set it up using your assets. It was also confusing to mix the Spine project and files with the files used at runtime.

[kamend]

Great, works now! Thank you.

[Søren]

Cococs2d does not currently support spine mesh function?
I need help！！！

Nate is working on the runtimes atm, it shouldn't be long now.

[OlegDustcase]

Hi everybody! I need to generate atlas files by directories! How to make this? For example, I have two directories with textures "Head_Textures" and "Body_Textures", so I need to get two atlasses for each of directories! Is this possible in Spine?

[Nate]

Sure, just run the packer twice. You can run it from the menu, you don't have to create an atlas when you export data. Doing that is just a convenience.

[OlegDustcase]

Ok! I created two atlas textures for each directory! And I have two .atlas files! I use Unity! But I can't use both .atlas components in one animation object, because there is only one field for Atlas in Spine Data Component! I want to use two atlases in one animation!
I can use two or more materials in one Atlas Component, but how to combine two atlas files in one? Or what I should do?

[Nate]

You said you wanted 2 atlases, so I told how. If you want one atlas, then point the packer at the parent directory. You will end up with 1 atlas that has 2 pages (if you have 2 subdirectories). Check Combine subdirectories if you want to try to pack all the images on a single atlas page.

---

spine-cocos2dx has been updated to use cocos2d-x-3.1alpha0. It doesn't have meshes yet though.

[eq2k]

spine-cocos2dx has been updated to use cocos2d-x-3.1alpha0. It doesn't have meshes yet though.

Just a heads up looks like you've not updated the Example Spine project to reference the correct cocos2dx project file for iOS (unsure about others).

Just a suggestion the cocos2dx folder in example maybe should be renamed to cocos2d-x to reflect the real cocos's folder and as mentioned above should reference cocos2d_libs.xcodeproj in build folder rather than cocos2dx.xcodeproj which doesn't exist.

Keep up the great work, can't wait for meshes to be done

[kzerse]

Hi nate, I saw you're working on spine-cocos2dx runtime with updating cocos2d-x version 3.
I'm worried about how spine-cocos2dx support past version of cocos2d-x.

our project is decided to stay on version 2, because we have tons of code extending cocos2d-x to improving its functionalities.
there's about a hundred classes extending cocos2d-x, and it is hard to do make all that classes working on version 3 stable.

I do need support cocos2d-x version 2.
have any plans?