vhristov

Hello everyone,

Every time I upgraded to a newer version of unity I was willing to create a script that can re-export every spine project automatically. I have not seen anything on the forum so far, except for the reference script used by Spine team to export the example projects. This script was both neither generic enough, nor very useful for me and I finally decided to do my own script.

As I believe that my setup is not completely unique and there are other people that try to keep in sync the paths between their spine projects and their code repository (unity in my case) .

The script is located on github:
https://github.com/vhristov/spine-exporter

As an initial version it is currently very limited (and most probably pretty buggy) but it still did the job for my project. I have a few different spine export settings for a few skeletons, but what simplified most of the script was that I keep my graphics repository folder structure the same as in my unity repository (so to speak graphics/Characters/Character1/Character1.spine goes to unity/Assets/Graphics/Characters/Character1/Character1.j{son/atlas/png} and so on).

As with the 4.0 was recently released out of beta and we need to re-export the skeletons in our projects I hope someone tries my script and find it useful.

P.S. There are a few issues with the scripts, the most notable being it cannot handle spaces in paths. I was unable to make the script to properly quote the paths in a way for spine to accept them. If someone can help with this I would be more than happy.
vhristov
  • 전체글: 36

Nate

Cool, thanks for sharing! I think an export script is often application specified, especially when packing into a single atlas, but a script like this makes for a great place to start customizing.

It might be worth noting that this can work fine on Windows if Cygwin is installed. Personally I put the Cygwin bin dir on my Windows path, so I can access Cygwin stuff from a Windows command prompt. I dislike the Cygwin shell, as it often forces using Cygwin paths (the cygdrive nonsense).

For your quote problem, I think you just need to use \" (untested, and the forum wrecked the backticks):
spine_args="$spine_args -i \"$file\" -o \"dirname $EXPORT_PATH/$file\" -e \"$setting_file\""
FWIW, here's one of our bash scripts we used for the 4.0 blog post skeletons:
http://n4te.com/x/2183-QE7h.txt
It combines all the skeletons into a single JSON file for use with Spine Web Player. It also packs two atlases, one with a single project (surf) and one with all the other projects (it does that by copying the images to a folder and packing them from there). The second atlas uses whitespace stripping with meshes, so it collects the project file paths and passes them when packing using -j. This script expects the project files and images to be in a particular layout, eg:
project1/image1.png
project1/image2.png
project2/other1.png
project2/other2.png
project1.spine
project2.spine
All projects use . for the images path, so attachment names use the project name as a suffix, eg project1/image2. This layout allows a project to use any of the images from other projects, if needed, since they are being packed into the same atlas.
사용자 아바타
Nate

Nate
  • 전체글: 11261

vhristov

Nate 작성:I think an export script is often application specified, especially when packing into a single atlas, but a script like this makes for a great place to start customizing.
While I agree with you, I would like to think there are two kind of project setups - unique ones and not-so-unique ones. Maybe I am just wishing that my setup is more on the common side than it is, I don't know :)
Nate 작성:It might be worth noting that this can work fine on Windows if Cygwin is installed. Personally I put the Cygwin bin dir on my Windows path, so I can access Cygwin stuff from a Windows command prompt. I dislike the Cygwin shell, as it often forces using Cygwin paths (the cygdrive nonsense).
On windows I used it inside the git bash's shell (I believe it is unmodified mingw), but I guess it shall work on cygwin too, even though I have not tested it there. Here I just assumed everyone now days is using git to some extent and this might be a common enough setup.
Nate 작성:FWIW, here's one of our bash scripts we used for the 4.0 blog post skeletons:
http://n4te.com/x/2183-QE7h.txt
It combines all the skeletons into a single JSON file for use with Spine Web Player. It also packs two atlases, one with a single project (surf) and one with all the other projects (it does that by copying the images to a folder and packing them from there). The second atlas uses whitespace stripping with meshes, so it collects the project file paths and passes them when packing using -j.
Thanks for sharing your script too. I have not seen it before (if it was shared). This is a nice workflow that I have never even though it is possible to do something like this. I would need to think how this can be generalized enough to be supported too (without sacrificing my desire for close-to-zero configuration, if such thing really exists)
Nate 작성:For your quote problem, I think you just need to use \" (untested, and the forum wrecked the backticks):
spine_args="$spine_args -i \"$file\" -o \"dirname $EXPORT_PATH/$file\" -e \"$setting_file\""
Unfortunately that didn't worked for some reason. I suspect it is related to IFS= in the file loop. The generated arguments looked nice everything quoted and so on and so, it even worked when I copy-pasted the command and run it manually, but if i left the script running it it was not escaping the arguments on the bash level but was passing it to the spine and got this error from spine:
ERROR: Input path does not exist:
/home/vlady/test/graphics/"./Characters/Charcter1/Charcter1.spine"
I actually don't have paths with spaces and I don't hit this issue. I just know it is there and it drives me crazy :)
vhristov
  • 전체글: 36


다시 돌아감: Editor