• Editor
  • Runtime status: meshes, FFD, skinning

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.

Related Discussions
...

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:

May be I am doing something wrong?

Thanks!

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?

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.

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

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

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

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

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. 🙂

Great, works now! Thank you.

anggog wrote

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

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

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?

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.

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?

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.

Nate wrote

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 🙂

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?

The folder in the cocos2d-x ZIP is named cocos2d-x-cocos2d-x-3.1alpha0.

The iOS and Android example projects are till for v2 and haven't been updated, I'll do that last. I considered deleting them until that was done but then figured that would make more work if someone wants to get to it first.

kzerse, from a few small polls, it seems most users wanted cocos2d-x v3. It is a lot more work to support multiple versions of the same libraries. With 18 runtimes, even just twice as much work is significant. I would rather not officially support older versions if at all possible, especially if only a handful of users need it. If you need to upgrade for new features (meshes, FFD, skinning) then I would suggest back porting those features to the v2 runtime. spine-c does most of it for you, it is only rendering that needs to be implemented. If the existing runtime is working for you, maybe you don't need to use the latest runtime?

When we purchased your product, we heard your plan to add new features including meshes of Spine-Runtime through your forum and Trello board. Of course, we’d want to benefit such new features, so we started game development, utilizing your product actively as soon as the meshes implemented in Spine Editor. Since we had no knowledge that you would drop the support for Version 2, and have been using new features a lot, we need support for V2. (As you know we can’t just version up the engine and we believe there will be many more clients like us as your current customers start utilizing your updated version and realizing your drop of V2 support)

Anyway, if the whole support for V2 is too much burden for you, we are willing to help out and to bear the burden with you together. We can implement the porting for Version 2 but after this initial implementation, the maintenance should be your work to do. Since the changing points of Editor should be reflected in Runtime, I’m afraid that we can’t do the maintenance work. Let us know if it’s possible for you to maintain it once we implement it? Our initial implementation work will also include bug fix

Thank you for your consideration and hope to hear from you soon. Also, if you’d like to discuss this unofficially, please feel free to contact me directly (<removed>)