Upgrading spine files without re-exporting.

Riccardo

Hi!
I have around 300 spine skeletons (saved in Binary format) in my project that were made with an older version of Spine (3.4) and I would now like to upgrade to version 4.1.

I was wondering if there was an alternative to re-exporting all the files. I do realize I can automate the process, but I'd still need to find the matching source file path for all my spine skeletons in the Unity project, which would be time consuming.

I was thinking of re-using the code to read the binary Skeleton data in the SkeletonBinary class from the older (ver 3.4) runtime and writing some code to save it in the new format, by looking at the upgraded code in the SkeletonBinary class (ver 4.1).

Is there any reason why you'd advise against this? There might be something I'm missing as I'm not that knowledgeable about what it means to actually re-export as opposed to upgrading the skeleton files.

Thank you!

Harald

Riccardo I was thinking of re-using the code to read the binary Skeleton data in the SkeletonBinary class from the older (ver 3.4) runtime and writing some code to save it in the new format, by looking at the upgraded code in the SkeletonBinary class (ver 4.1).

Is there any reason why you'd advise against this?

This sounds like an unnecessarily complex way (unnecessarily re-inventing the wheel) to achieve your goal. If you want to write a script which imports the skeleton data of the old format and then write your own exporter of the data manually, why don't you instead use the Spine Editor via the command line to import the data in the old version and export it from the new version again?

but I'd still need to find the matching source file path for all my spine skeletons in the Unity project, which would be time consuming.

Could you please explain what you mean by "find the matching source file path"?

Riccardo

Hey Harald, sorry if that was confusing. I'll explain more clearly.

In my Unity project I have around 300 characters/entities, each with their own .skel.bytes, atlas .png file and atlas.txt file.

The .spine files are not in the Unity project though, I keep them on Google Drive.

From what I've read in the documentation, I'd need to open the .spine file and re-export it in the new version.
The issue is that, for each of the 300 .skel.bytes file I find in the project, I'd need to find the matching .spine file.
It's definitely something I can do, but given the amount of skel.bytes files I have, it could take a while and that is why I was exploring alternative solutions that don't require knowing the path of the .spine file for every .skel.bytes file I have in the project.

I hope that cleared it up.

Harald

Riccardo Thanks for the clarification. Sorry if my above reply was not clear. I was trying to say that instead of writing your own exporter, you could use the Spine command line interface (CLI) to perform these tasks, they are already provided. First import data like when using the GUI via Spine - Import Data.., and then re-export the skeleton. You can do both via the CLI. You don't need to use the original Spine project files for that.

Mario

I would strictly advise against importing the exported skel.bytes files, as they may lack information the editor can't magically generate.

If you have the original .spine files, the way to go is to re-export them. Matching them up with the .skel.bytes files may sound daunting, but it is the only way to ensure your skeletons and animations will work in the new version.

Nate

As mentioned above, using the Spine files is definitely better. That said, importing the data and re-exporting should work. The downsides are 1) if you encounter a bug, especially in the old version that we no longer do releases for, and 2) if you exported without Nonessential data checked, then data import will lose some information such as mesh edges. Also there is a small amount of generally unimportant data loss even with that checked, for example you'll lose your bone icons. Using the project files you won't lose anything at all.

Riccardo

Thank you for your replies. I think I might give it a shot just to see if it does the job. If not, I'll revert back to using the .spine files and exporting from them.

Just one thing I'm not sure about: how do I do this with the CLI? I've gone through the documentation but I'm not sure how to import first (with the older version) and export after (with the new version).

So, the importing would look something like this, from what I've gathered:

before_version=3.4.02
"$SPINE_EXE" \
-u $before_version ${@:2} -f \
-i ../Desktop/Lock/OldExport/skeleton_Lock.skel -o -r

I'm not sure how to locate the file the new .spine file that gets generated by running the above command. The documentation states that -o, --output Path to project file to import into. Created if nonexistent., so I assume it does get created somewhere but I'm not sure where.

I guess I would then run something like this:

after_version=4.1.00
"$SPINE_EXE" \
-u $after_version ${@:2} -f \
-i ../Desktop/Lock/newlyCreatedSpine.spine -o ../Desktop/Lock/NewExport -e binary

Nate

Old version data to project file conversion:

spine -u 3.4.02 -i skeleton.skel -o project.spine -r

However, very old versions may not support CLI data import and conversion to a project file. I don't remember when that was added, but 3.4 is extremely old: 8+ years old. If you try it and it doesn't work, you'll have to use the UI to Import data and save a project file. That's a bummer, though it is a one time pain (times 300 projects, I know 😥).

Project file to data conversion:

spine -u 4.1.xx -i project.spine -o output/folder -e export.settings.json

The data files are written using the skeleton name (a project may have more than one skeleton).