vmatikainen

In page Spine Json Format http://esotericsoftware.com/spine-json-format
and in the Bone timelines section, the translate and scale properties all refer to bone's X, which should be first X and then Y.

Also when stating that bone timeline scale animation values are relative to the setup pose, it would be beneficial to state that they are multipliers to setup pose values. (If I understood it correctly).

Keep up the good work.
vmatikainen
Postovi: 16

Shiu

Thanks for the heads up, I've changed it to display both X and Y. Scale values aren't multipliers to setup pose values though. I'll let Nate look into it.
Avatar
Shiu

Shiu
Postovi: 2129

vmatikainen

The scale values then seem to be absolute, as in example json exports they seem to be around 1.0 as are the setup pose scale values. So either the documentation is incorrect regarding the relativity or could benefit from clarification.
vmatikainen
Postovi: 16

Nate

Wow, it seems scale has always been wrong in all the runtimes. :tmi: It should be combined with the setup pose scale using multiplication. Eg, setup scale 1, set key for 0.5, change setup scale to 2, the value of the key should be 2 * 0.5 = 1.

I will fix this for the next Spine version and all the runtimes. I will be sure to adjust older projects to the correct scale. Good thing all the infrastructure is in place to make handling changes like this a breeze. 8)

---

Runtimes have been updated. Note this means your skeletons need to be exported again using Spine 2.0.00+, which will be released today.
Avatar
Nate

Nate
Postovi: 7250

Nimai

Nate, I know you guys are neck-deep in the new release, but with the new code, bones that have zero for scale in their set-up pose no longer work at all.

For example:
Go into the Editor, new project, in Setup mode and set a 0, 0 scale on "root".
Go into Animation mode and keyframe scale at frame zero.
Now try to set a keyframe to scale 1, 1 at frame 20.
Drag the time around. The scale boxes are blank, and it doesn't have the expected result at any time.

---

Just a recommendation: you could use the "spine" version number in the "skeleton" data entry to provide backwards compatibility with old data. For example:
"skeleton": { "spine": "1.9.17", "hash": "TQSnS....
^^^^^^
The run-time could support migrating 1.x versions of scale timelines at run-time. Not ideal for performance, but it let's developers decide how important that is vs. re-exporting all their Spines.
Avatar
Nimai
Postovi: 62

Nate

Ah, a setup scale of zero is probably why I didn't multiply the setup scale by the key. The reason it is good to multiply the setup scale by the key is so you can scale everything by changing the setup scale. Setup=1, key=3, then at runtime I change setup=2. Should the value for the key be 3 or 6? It should be 6, because by changing the setup scale to be twice as large, I want the key to be twice as large. If it just used the key, then changing the setup scale to be twice as large would not affect animations that key the scale.

The problem occurs when you use a setup scale of zero, because then it doesn't matter what you set for the key, you always get zero (0 * key = 0). This means using a setup scale of zero does not make sense unless you plan to programmatically change the setup scale to something that does make sense. One alternative is to use a very small scale, but I'm not really a fan of this as it means the keys have to be huge to get the scale you want. It's best not to set the setup scale to zero, then to key it to zero in animations if you want.

What do you guys think?

---

Re: the runtime knowing about all previous versions so you don't have to export your data again, this would lead to a mess not just in the official runtimes, but all 3rd party runtimes would try to do this. The Spine project file already handles loading all previous versions, so it is cleanest to not complicate the loading and simply require the skeletons to be exported again if things change significantly enough.
Avatar
Nate

Nate
Postovi: 7250

Nimai

Yes, you nailed the nature of the problem, Nate. It's a choice more than a problem, really. I like the way it is now; changing the scale of the set-up pose should affect the scale of the animation multiplicatively.

Regarding migrating old data, I hadn't thought of 3rd parties as well. If it were just in the Spine run-times, it's straight forward to organize data migration functions in the code neatly and centrally.

It's fortunate that the JSON data has that "spine" version in it, because that at least allows us to write a data migration script that scans our data without having to re-export. I'll share that script as soon as I get it working.

---

I've put a script to migrate pre-version 2.0.0 Spine exported JSON files to the new scale timeline values. Free to use.
spine_migration.py

https://github.com/Bee-Cave-Games/spine_export
Avatar
Nimai
Postovi: 62

Mitch

It's fortunate that the JSON data has that "spine" version in it
Yea. Nate.

viewtopic.php?f=11&t=2921

<3
Avatar
Mitch

Mitch
Postovi: 959

Nimai

@Nate- an artist here just pointed out that if he imports JSON data exported from earlier Spine versions, the Spine editor does not migrate the scale animation. Loading in earlier Spine projects does migrate fine, though. Please extend the support for migrating data to include JSON import. Thanks!
Avatar
Nimai
Postovi: 62

Shiu

Thanks for the heads up, I've informed Nate of it.
Avatar
Shiu

Shiu
Postovi: 2129

Nate

I've fixed Data Import to convert the old scale values for older exports.
Nimai je napisao/la:Yes, you nailed the nature of the problem, Nate. It's a choice more than a problem, really. I like the way it is now; changing the scale of the set-up pose should affect the scale of the animation multiplicatively.
Thing is, it only matters for people who want to change the setup scale later. Most people don't.

It's also a bit confusing that you can scale the bone and key it, but the key stored isn't for the value you expect. One solution could be to disable scaling a bone in animate mode if the setup mode scale is zero.

I wonder if we should special case a setup scale of zero to be equal to 1 when applying a scale key? This means any scale key set would effectively ignore the setup scale if it is 0. The downsides are 1) results are surprising if a setup scale of 0 is used then later changed to something else (solution: don't do that), and 2) results are surprising if someone tries to set a setup scale of zero to hide a bone (bad idea anyway).
Avatar
Nate

Nate
Postovi: 7250


Natrag na Bugs