Hello,
You can use the menu entry Spine -> Import Data... to import your exported assets. Then re-export the project from Spine 3.7 to use it with the 3.7 Spine-Unity runtime.
We do not recommend adapting Spine 3.5 for Unity 2019.

Have you tried importing the data in an older Spine version (especially in the version that has been used to export the files) and then upgrading the project to Spine 3.7 (by opening the project in the new Spine editor version)?

You can quickly switch versions via Spine -> Settings Spine version. After restarting Spine you are at your desired Spine editor version.

And this won't affect the texture packing, right? So that I can keep the old atlas and atlas txt? Just to make sure.

The old atlas (.atlas.txt and png files) can still be used.

Note that you could also use Spine's Texture Unpacker to restore your images from a packed atlas (you need both the .atlas.txt and png files).

But when I import data in cmd. It just open the editor for me, but the data is not imported. Any clue?

Can you post the command line commands that you are using?

Spine -i myPath\char_01.skel -o myPath\tmp.spine -r

Back at the time of version 3.5.51 there seems to have been no -r parameter on the command line:
https://web.archive.org/web/20161230224555/http://esotericsoftware.com/spine-export/#Usage

You could either try different syntax from this docs page, or try Spine 3.6 (e.g. 3.6.53), since the first time the -r option appears on waybackmachine is 2018/05/14:
https://web.archive.org/web/20180514003607/http://esotericsoftware.com/spine-export

Apart from that, maybe doing it via the GUI could be the quickest way before trying all different sorts of versions.

Hey，I have the same problem when use command line in spine3.5 to import skel to generate .spine project. It's failed and just open spine.exe and do nothing

Please send us you spine.log file as described here Spine Troubleshooting

Please also provide the full command line you used to import this specific example.skel.

Spine -i E:\Temp\example.skel -o E:\Temp\exampleExport -e E:\Temp\SpineTest\jsonExport.json -u 3.5.51

I think my command line may right，because i exported 1000+ successed and 100+ failed. I use spine GUI import it and export is ok, only command line failed. I think it maybe single spine's project's problem, it may use some feature that command line export not supported.

export json is:
{
"class": "com.esotericsoftware.spine.editor.Prefs$ExportJson",
"project": null,
"output": "",
"extension": ".json",
"format": "JSON",
"nonessential": true,
"prettyPrint": true,
"createAtlas": false,
"texturePacker": null
}

Mario yazdı

Please also provide the full command line you used to import this specific example.skel.

Hello，how it going?

I was able to reproduce the error. We are working on it.

The error appears to be that a path attachment doesn't have the lengths of its segments computed in the setup pose. It seems 3.5.51 has a bug where the lengths don't get computed when run from the CLI, that's why import succeeds when done from the UI. Unfortunately 3.5.51 is very old and it would be very difficult for us to make any changes and create a new 3.5 build.

Thankfully I found a workaround for you. When you do CLI export, Spine uses a "headless" mode when possible. This is faster because it avoids creating the Spine window, all the UI, etc. Image and video exports can't use headless mode because they require use of OpenGL, which needs the Spine window/etc. What you can do is include one image/video export so Spine doesn't use headless mode, then your exports will happen more similarly to using the UI.

spine -u 3.5.51 -i example.skel -o test.png -e png.json -i example.skel -o . -e export.json

The -i example.skel -o test.png -e png.json using this png.json exports a single frame and is needed to avoid headless more. After that you can include any number of exports and they will all be done using non-headless mode, which avoids the 3.5.51 bug.

Nate yazdı

The error appears to be that a path attachment doesn't have the lengths of its segments computed in the setup pose. It seems 3.5.51 has a bug where the lengths don't get computed when run from the CLI, that's why import succeeds when done from the UI. Unfortunately 3.5.51 is very old and it would be very difficult for us to make any changes and create a new 3.5 build.

Thankfully I found a workaround for you. When you do CLI export, Spine uses a "headless" mode when possible. This is faster because it avoids creating the Spine window, all the UI, etc. Image and video exports can't use headless mode because they require use of OpenGL, which needs the Spine window/etc. What you can do is include one image/video export so Spine doesn't use headless mode, then your exports will happen more similarly to using the UI.

spine -u 3.5.51 -i example.skel -o test.png -e png.json -i example.skel -o . -e export.json

The -i example.skel -o test.png -e png.json using this png.json exports a single frame and is needed to avoid headless more. After that you can include any number of exports and they will all be done using non-headless mode, which avoids the 3.5.51 bug.

Wow, that's work! Thansks a lot!

:cooldoge:

Hey，I'm sorry I meet another problem that need help :sweat:
I find accuracy diff by my export way：I import skel and export json by 3.5.51，and use spine3.8 import this json and export binary. This is because binary to json lose accuracy. Is there any way to fix it?

My core case is our project want to update to spine3.8.99 from 3.5.51，and we have 1700+ spine skel need to re-generate，so CLI is need.

I have tried use spine GUI import skel data to generate .spine project，and use 3.8 to open it and export binary，it's perfect.The only problem is that I can't use command line to generate .spine in 3.5 as this blog say.

My command line is
spine -i example.skel -o test.spine -u 3.5.51 -r

It's only open Spine GUI and do nothing.The spine.log is upload.

Thanks anyway!

As you found, unfortunately 3.5.51 doesn't support importing data to create a Spine project. Your options are only to export to JSON or to use the GUI to save a project file.

Are the differences in accuracy meaningful? I would expect that not to matter most of the time, though I don't remember exactly how 3.5 behaves.