- Editado
Spine 3 CLI export bug
The initial question from Spine 3.0 released thread:
Hi, we have a problem with the CLI exporter: some attachments are consistently getting width and height equal to 1 if we run export from CLI, but if we run export on the same project from Spine itself then everything is fine. I reproduced it with 3.0.07 and 3.0.09 on Windows. There was no such problem with v.2.
Answer by Nate:
Normally Spine saves the image sizes in the project. The CLI export doesn't read the images, so it should use the sizes from the project. It is not clear why the project doesn't have the correct sizes. We haven't been able to reproduce the problem. Can you email a project file that shows the problem when exported from the CLI?
Thank you for the answer! I've got some ideas about the reasons of that behavior. The peculiarity of the project that cause this problem is that it is very big project of the character which can use different kinds of weapon. Each kind of weapon has its own bones and set of battle animations. An artist need to hide all kind of weapons except one which he edit now. We did it by writing our own tool to replace all unneeded sprites with 1x1 empty placeholders. Before running CLI export on build server we run our tool to restore all original sprites for all kinds of weapons. This process is running without opening Spine GUI, so .spine project remains unchanged. If I run our tool with opened Spine GUI then CLI export produces less bad sprites in .json but there are still relatively many of them. GUI export works well.
We already had some issues with our tool: Spine doesn't always react to changes of many sprites on the disk (Spine just ignores those changes sometimes). So I think it can be at least a part of the reasons of our problem.
I'm not sure that I can send you a project but I will discuss it with my boss if my explanation will not be enough.
If you have any suggestions how we can change our workflow to avoid this problem and still having the ability to create many kinds of weapons for our character without using our own tool I would be glad to hear them.
Thank you in advance, if something in my explanation is not clear, please ask.
The other important thing that CLI export worked fine in Spine v2 with that project.
Another problem we've got on this project is that CLI export adds (0, 0) vertex to bounding box (we have only one bounding box in this project). Normally our bounding box has 7 vertices, after CLI export it has 8 vertices: (0, 0) at start and 7 normal vertices after that.
I'm glad you followed up, I had wondered what happened.
The extra bounding box vertices was fixed in 3.0.13.
Spine only loads the images that it needs to render into memory. Eg, when not playing, only the displayed images are loaded. When hiding/showing an image, the images are actually loaded and unloaded on the fly. When playing an animation, all the images that are shown during that animation are loaded so that there is no loading delay during playback. This means you can have many thousands of images and Spine will work just fine (unless you show them all in an animation and don't have enough GPU memory, which is unlikely). How many images do you have? What is an average size for these images?
Spine uses the OS provided APIs for file watching. Unfortunately it seems sometimes this doesn't work well. I've seen it stop reacting to file changes for seemingly no reason.
Interesting, so you replace images with 1x1 placeholders as a fast way to hide all the attachments so the artist can work easily?
In Spine v2, the export was not headless, meaning it actually was running a lot of GUI related code. In v3 it is headless, when possible. Data export and texture packing run in headless mode, but image or video export cannot because those use OpenGL to render images. Headless is faster and allows export to be run on computers that don't have graphics hardware, like a build server.
This means one way to workaround this issue is to include an image or video export along with your data export. Eg:
Spine -i yourProject.spine -e dataExport.json -e imageExport.json
The image export can be anything, you can just export a single frame PNG to the temp directory. By doing the image export Spine will run in GUI mode and should read your image files to update their actual size.
Another thing you can do is to restore the images to their normal size, open the project in Spine as normal, save (which will store the image sizes in the project file), then export via the CLI and it should use the saved sizes.
We will investigate having headless mode read the images if they are available to ensure it uses the right size. Decoding images is fine (that is why texture packing is OK), it's just loading them into OpenGL for rendering that requires GUI mode.
Another thing you might do is to avoid replacing the images. Maybe you can use skins to show a subset of attachments?
Starting in 3.0.17, headless export will update the images sizes, if the images are available.
Thank you for detailed explanation, everything is much clearer now.
Nate escribióInteresting, so you replace images with 1x1 placeholders as a fast way to hide all the attachments so the artist can work easily?
Exactly.
Nate escribióAnother thing you might do is to avoid replacing the images. Maybe you can use skins to show a subset of attachments?
It's not an option in our case: we have different genders and too many weapon kinds which can be used alone or in a combination... We would get a combinatorial explosion if we would try to maintain different skin for each variant.
Nate escribióThe extra bounding box vertices was fixed in 3.0.13.
Starting in 3.0.17, headless export will update the images sizes, if the images are available.
Great news! I will wait for the next release to test it. I'm not hurry so I will not try to use workaround described. Thank you for everything!
You could still use skins in the editor for grouping. Eg, if you have weapons made up of many images, you could have a skin per weapon. There is no need to define all possible combinations of attachments. At runtime, you can fetch attachments from various skins and populate a new skin dynamically for use on your character's skeleton. Eg, say you have flame armor and a lightning sword equipped, then you'd get all the attachments from the flame armor skin and all the attachments from the lightning sword skin, you'd put all those in a new skin and assign that skin to your skeleton.
In Spine this might help your animators by easily hiding or showing a group of attachments. It has been on our todo list for a long time to allow multiple skins to be active at the same time in Spine.
Nate escribióThe extra bounding box vertices was fixed in 3.0.13.
Well... Extra vertices are disappeared from bounding box. But you are removing them from the wrong end :sweat:
CLI export:
[ 0, 0,
-6.13925, -15.1407, 12.95675, -18.17875, 50.28073, -19.0467, 54.18672, 10.46528, 41.16676, 41.71328, 9.91873, 36.50528 ]
GUI export:
[
-6.13925, -15.1407, 12.95675, -18.17875, 50.28073, -19.0467, 54.18672, 10.46528, 41.16676, 41.71328, 9.91873, 36.50528,
-11.78127, 19.14528 ]
Another example:
[ 0, 0, 0, 0, 0, 0, 48.34244, -5.76704, 28.67444, 59.79293 ]
[ 48.34244, -5.76704, 28.67444, 59.79293, -60.12949, 110.45287, -66.68549, 28.80092, -2.31754, -14.70704 ]
Hmm, seems to be dependent on the vertices. I believe this is fixed in 3.1.00.
Yay! It seems like all our problems are really resolved now. Thank you a lot!