在使用skel或者json导入spine文件的时候，用的是命令行，发现保存后的spine文件会出现2个情况，一种是打开spine后，有默认选中的动作，一种是打开spine文件后默认没有选中任何动作。这两种情况带来的问题是，当你用没有默认选中动作的文件导出gif的时候，有时候会发现gif图的画布是不完整的，残缺的。而当你选中了其中某个动作，然后再进行导出gif的时候，图片是完整的，画布也不会出现残缺问题。请问如何解决这个问题？如何在导入的时候能实现生成的spine文件默认选中动作，或者不管有没有选中动作导出的gif文件都是完整正确的？期待回复。
非选中动作的时候：
有选中动作的时候：
关于gif图片导出的问题
{
"class": "export-gif",
"exportType": "animation",
"skeletonType": "single",
"skeleton": "E800021",
"animationType": "all",
"animation": null,
"skinType": "current",
"skinNone": false,
"skin": null,
"maxBounds": false,
"renderImages": true,
"renderBones": false,
"renderOthers": false,
"scale": 100,
"fitWidth": 0,
"fitHeight": 0,
"enlarge": false,
"background": { "b": 0.11372549, "r": 0.11372549, "g": 0.11372549, "a": 1 },
"fps": 8,
"lastFrame": false,
"cropWidth": 0,
"cropHeight": 0,
"rangeStart": -1,
"rangeEnd": -1,
"outputType": "filePerAnimation",
"animationRepeat": 1,
"animationPause": 0,
"colors": 256,
"colorDither": 50,
"alphaThreshold": 0,
"alphaDither": 0,
"quality": 8,
"transparency": false,
"repeat": 0,
"pad": false,
"msaa": 4,
"smoothing": 11,
"alphaDitherType": "diffusion",
"alphaDitherOption": "expand",
"renderSelection": false,
"cropX": 0,
"cropY": 0,
"output": "",
"input": "",
"open": false
}
这是我用的导出配置表信息。
经过我多次测试，好像跟版本无关，跟导出配置表无关，跟选中动画也无关。应该跟编辑模式有关，打开任何一个文件只要切换过动画编辑模式，或者在直接动画模式，无论选不选择动画，导出结果就是正确的。如果直接打开一个新导入生成的spine文件，没有切换过动画编辑模式，就有可能导出的图片是不正确的。
这意味着我们通过导入文件生成的spine项目，如果想导出完全正确的gif图，至少需要打开文件切换一次编辑状态？或者有其他解决办法？
之前说的有点错误，还是跟选中动画名称有关系，
打开一个新导入生成的spine文件，切换到动画模式，导出的也是错误图片。
在任意模式下，如果不选中动画直接导出第一遍是所有动画图片都是错误的，再进行导出一次就是正确图片。
在任意模式下，第一次导出只有选中动画对应导出的就是正确图片，没有选中的动画导出的是错误图片。再进行一次导出操作，即使没有选中的动画导出的也是正确图片。
yianti Thank you for sharing your export settings! I tried to reproduce this problem with Spineboy but unfortunately could not reproduce it successfully.
What I tried is:
- Open the Spineboy project in the editor and export it (with an animation selected).
- Importing the Spineboy .skel file from the CLI, creating a new Spine project and exporting it from the CLI.
Then I could see a slight difference in the size of some exported GIFs between the two approaches, but I did not get the result where part of the skeleton is obviously cut off, as in the image you attached.
Since you said you could reproduce the problem with any version I tried with the latest beta version, 4.2.63-beta.
Sorry to bother you, but if you don't mind, could you please email the Spine project via email that can reproduce the problem?: contact@esotericsoftware.com
Please include the URL of this forum thread in the email so we know the context. We will check as soon as you provide it to us.
yianti I have confirmed that I can reproduce the issue in a Spine project I created from scratch, so I have created an issue ticket here to fix this: EsotericSoftware/spine-editor787
You can subscribe to this issue ticket to receive notifications when there is any progress on this issue.
We apologize for the inconvenience and ask for your patience until we have the fix in place.
好的。期待早日修复问题。谢谢
我试着更新了最新版的 4.2.66-beta，使用起来依旧会遇到同样的问题。
yianti I am sorry to hear that you are still having problems. Is the problem occurring when exporting via the CLI? I think at least the problem you mentioned of exporting with no animations selected in animate mode and exporting causing the exported images to be the wrong size should have been fixed, but that didn't work either?
很抱歉。我尝试了任何模式下不选择动画，依然会导出错误的图片。任何模式下选中动画导出正确，未选中的动画依然导出错误。CLI模式下导出错误。
yianti I see, I have tested again using the Spine project you sent us and have indeed been able to reproduce the problem you seem to be experiencing. When I open the project created with Spine 3.8.99 using 4.2.66-beta and immediately export the animation, it is indeed exported at the wrong size.
However, if I import the skeleton data created with Spine 3.8.9 via the CLI, save it as a new Spine project with 4.2.66-beta, and then export the project, the exported GIF file is the correct size.
I'm sorry for the inconvenience, but maybe the old 3.8.99 data is interfering with something, so could you please try saving and exporting once in 4.2.66-beta as I described?
我试了一下，将已有的3.899的spine文件导出json或者skel，然后再用CLI还原生成新的3.899spine文件，结果再用3.8或者4.2的版本导出都可以获得正确的图片。
可能正如你说的，旧的骨架数据或者旧的spine文件里有干扰数据导致。我一直以为无论你什么数据导入spine的话。即使原始数据有偏差，但是转成spine文件都会处理成正确的方式。现在看来并不一定。
这意味着如果我想获得完全正确的图片，需要将就的spine文件完全导出后再重新生成一遍新的spine文件。然后再导出图片。
然后我发现一个有趣的现象。如果你用手工拖放导入骨骼数据的时候，默认是会选取最后一个动画。当你用CLI的时候，生成的文件就不会选取任何动画。
感谢一直分析解决问题。
Sorry for the confusion! It confused even us. 
Unfortunately this usage is not actually supported. I added to this the issue, pasting here for easier translation:
Region sequences always use the size of the setup sequence frame. If some images in the sequence are a different size, they are scaled to the size of the setup sequence frame. This is similar to how it works for meshes.
Requiring the same size (or scaling) is what most users will do anyway. Any extra whitespace can be stripped by texture packing.
It works this way for simplicity and technical reasons. There is less work to do at runtime to change the region. Also, for exports, we would need to load ALL sequence images to determine their size before we could start an export, and then load them all again to perform the export.
The behavior in the Spine editor was misleading. It did not work like that at runtime. We've fixed the editor behavior in 4.2.67-beta.
5 gün sonra
使用最新的4.2.69beta版本导出gif已经没有遇到之前的问题了。太好了。