- Modificato
Downgrade from 3.8 to 3.7 losing default scale
Try to downgrade from 3.8 back to 3.7, since 3.8 export changed skins field from a map to list, while not all runtimes support it so far.
1) Use 3.8 editor export a json with nonessential data.
2) Downgrade editor to 3.7. However the json file can not be imported into 3.7 using import data feature.
3) Use JsonRollback to rollback to 3.7 json.
java -cp ~/bin/skeletonViewer.jar com.esotericsoftware.spine.JsonRollback example.json 3.7 example-3.7.json4) Import data into 3.7 editor. It works but all nodes scale field seems set to zero (for all animations).
Check the json file exported by 3.8, it seems missing the x,y of scale field if it was default value (1). But old editor treat missing x, y as value 0.
"scale": [
{ "time": 0, "curve": "stepped" },
{ "time": 0.0667, "curve": "stepped" },
{ "time": 0.1333, "curve": "stepped" },
{ "time": 0.2333, "curve": "stepped" },
{ "time": 0.4333, "curve": "stepped" },Workaround: write a script change all nodes scale to 1,1 if no x or y appears in a frame object {}.
Possible fix: 3.8 export shall always export scale x, y values.
Off-topic, please consider make it easier to load new version project file in old client. The process is not very smooth. It's common we did some cool stuff in new version, but the runtime always slower than the editor, we need fall back to old version for exporting. It mostly a design decision I think. Even a patch version upgrade caused old client can not open new version file, feels not very necessary.
I'm not seeing that. Are you using the latest skeletonViewer.jar? Here's 3.8 JSON for an animation that keys scale 1,1 at frame 0:
"scale": [
{}
]
After using JsonRollback:
"scale": [
{ "time": 0.0, "x": 1.0, "y": 1.0 }
]
Note the JsonRollback source is provided in spine-libgdx if needed, which may be easier than writing a separate script.
The process of loading new data into an old editor is not smooth for a few reasons, but mostly because it is not a workflow that anyone should be using. There is no good reason to do so, except that someone accidentally updated to a new version and did work they want to use with an older runtime. That is a scenario that should be avoided. The runtimes are always up to date with all editor features for non-beta releases.
Just a quick note on runtime compatibility with new Spine Editor features. New features always first land in the Spine Editor beta versions. Updating the Spine Runtimes usually take less than a week to support the latest features (this happens in the beta branch on GitHub). When a new Spine Editor version is released, all runtimes are guaranteed to support all features (minus engine specific omissions, e.g. meshes in spine-ts Canvas) on release day.
What we have no control over, and where you might see "lag", is when using a 3rd party runtime. We try to work with 3rd parties to make sure they use the latest and greatest, but we can't give any guarantees for these inofficial runtimes.
Export json from 3.8.73 pro. Keyframed the initial fields (translate, scale, rotate...) of one bone, and give translate field a curve.
{
"skeleton": { "hash": "ig2UR8CgI2EjkroO5WDTYD4tFds", "spine": "3.8.73", "images": "", "audio": "" },
"bones": [
{ "name": "root" },
{ "name": "bone", "parent": "root", "length": 209, "rotation": 90.27, "x": -5, "y": -191 },
{ "name": "bone2", "parent": "bone", "length": 220, "rotation": -0.27, "x": 209, "y": -1 },
{ "name": "bone3", "parent": "bone2", "length": 156.08, "rotation": -1.84, "x": 231, "y": -1 },
{ "name": "bone4", "parent": "bone3", "length": 127.94, "rotation": 153.87, "x": -24.52, "y": 78.25 },
{ "name": "bone5", "parent": "bone4", "length": 237.3, "rotation": 25.07, "x": 151.01, "y": 7.72 },
{ "name": "bone6", "parent": "bone5", "length": 157.89, "rotation": 54.07, "x": -146.8, "y": 209.85 },
{ "name": "bone7", "parent": "bone6", "length": 181.34, "rotation": -44.2, "x": 158.22, "y": -3.59 },
{ "name": "bone8", "parent": "bone7", "x": 496.77, "y": -411.31 }
],
"animations": {
"animation": {
"bones": {
"bone2": {
"rotate": [
{ "curve": "stepped" },
{ "time": 1.1667 }
],
"translate": [
{},
{ "time": 0.5333, "x": -0.41, "y": -86 },
{ "time": 1.1667 }
],
"scale": [
{ "curve": "stepped" },
{ "time": 1.1667 }
],
"shear": [
{ "curve": "stepped" },
{ "time": 1.1667 }
]
}
}
}
}
}
Downgrade to 3.7 using the skeletonViewer downloaded from http://esotericsoftware.com/files/skeletonViewer.jar. (a few hours ago. Not sure how to check the jar version).
Diff the results
$ diff -u skeleton.json skeleton-3.7.json
---
skeleton.json 2019-10-08 22:17:57.124285000 +0800
+++ skeleton-3.7.json 2019-10-08 22:22:38.927490100 +0800
@@ -16,20 +16,20 @@
"bones": {
"bone2": {
"rotate": [
- { "curve": "stepped" },
- { "time": 1.1667 }
+ { "curve": "stepped", "time": 0.0, "angle": 0.0 },
+ { "time": 1.1667, "angle": 0.0 }
],
"translate": [
- {},
+ { "time": 0.0 },
{ "time": 0.5333, "x": -0.41, "y": -86 },
{ "time": 1.1667 }
],
"scale": [
- { "curve": "stepped" },
+ { "curve": "stepped", "time": 0.0 },
{ "time": 1.1667 }
],
"shear": [
- { "curve": "stepped" },
+ { "curve": "stepped", "time": 0.0 },
{ "time": 1.1667 }
]
}
Missing value of x,y of all default frames.
Example project attached.
Nate ha scrittoThe process of loading new data into an old editor is not smooth for a few reasons, but mostly because it is not a workflow that anyone should be using. There is no good reason to do so, except that someone accidentally updated to a new version and did work they want to use with an older runtime. That is a scenario that should be avoided. The runtimes are always up to date with all editor features for non-beta releases.
I understand it's no good reason to do so, but sometime it just happens. I have just finished my spine work with 3.8, then the client realized the cocos-creator runtime (I guess it's out of your control) is not 3.8 ready because the skin fields breaks, and the compact export issue. So I have to go through the process.
Upgrade to a patch version (major.minor,patch) then downgrade could be a less restrict process (achievable in editor, without the knowledge of cli).
I've made my point. I never worrying about my file is losing back-compatibility when upgrading photoshop and AI. So I keep my software up-to-date. As spine became more mature and powerful, I would expect something similar experience.
From a programming view, it may be better to version control the export format, so a higher client can export data format for lower version. i.e. 3.8 can export 3.8, 3.7, 3.6...
badlogic ha scrittoJust a quick note on runtime compatibility with new Spine Editor features. New features always first land in the Spine Editor beta versions. Updating the Spine Runtimes usually take less than a week to support the latest features (this happens in the beta branch on GitHub). When a new Spine Editor version is released, all runtimes are guaranteed to support all features (minus engine specific omissions, e.g. meshes in spine-ts Canvas) on release day.
What we have no control over, and where you might see "lag", is when using a 3rd party runtime. We try to work with 3rd parties to make sure they use the latest and greatest, but we can't give any guarantees for these inofficial runtimes.
Thanks for the info. I really appreciate the hard work of the team.
Ahh, my apologies, the skeletonViewer.jar available on the Skeleton Viewer page was not the latest that I tested with above. I've put up the latest now, 3.8.74. You can see the version when you run the Skeleton Viewer UI, in the upper right corner. It handles scale keys correctly (my output) but if you run into anything it does incorrectly, please let us know.
favoyang ha scrittoI never worrying about my file is losing back-compatibility when upgrading photoshop and AI. So I keep my software up-to-date. As spine became more mature and powerful, I would expect something similar experience.
Thanks for the explanation, it does make some sense. Spine differs a little in that it has runtime components whose version must match the editor, and updating a software library dependency should never be done lightly. Still, I do agree the editor could work like you expect. So far it has just been a question of the effort being worthwhile, since it isn't a suggested workflow.
favoyang ha scrittoFrom a programming view, it may be better to version control the export format, so a higher client can export data format for lower version.
This would break things when newer features don't exist for older versions. Eg, exporting a project using paths to an older runtime that doesn't know anything about paths. Paths could be stripped so the data can be loaded, but the animations won't look right.
Yeah, we're on the same picture now.
BTW, I hope the forum has a like button, so that I won't need to bump a thread to get your attention for a "I agree" thing.