- تم التحرير
bezier handles stored in global coordinates now (json, 4.0
I wonder why the bezier handles are stored in global/absolute coordinates now. If you export an animation as JSON you can see that.
Example:
- Two points p1 and p2 in the rotation timeline
- p1 at 11.0 seconds with an angle of -123.29 degrees
- p2 at 11.5 seconds with an angle of -155.14 degrees
- between these points a bezier curve with 2 handles (left and right)
After export to JSON you can see the curve as [11.381, -125.64, 11.153, -141.86]. These are absolute values [time1, angle1, time2, angle2]. If you have high values (huge time values, huge angles) than you can see here large numbers with many digits.
But you can calculate them back into relative values between 0 and 1 as before (or outside 0 and 1 for overshoots):
curve = [0.761, 0.07, 0.305, 0.58]
The first value in the list is a time value. 0 means 11.0 seconds (p1), 1 means 11.5 seconds (p2). And 0.761 corresponds to 11.381 seconds accordingly. So you only have to store small values (between 0 and 1) but with high accuracy. As long as I know Spine (8 years) always relative values were stored for bezier handles. Why has this changed? This has nothing to do with the appearance of the new timeline...
Lebostein wroteThis has nothing to do with the appearance of the new timeline...
The change to store key curves using values rather than percentage was required for the graph in v4.0. Consider keys like this: Image removed due to the lack of support for HTTPS. | Show Anyway
Both keys are at 100 and there is a curve between them. The relative difference between the key values is zero, so the handle Y positions cannot be stored as a percentage of that difference.
Lebostein wroteSo you only have to store small values (between 0 and 1) but with high accuracy.
The numbers are stored in binary using 4 bytes, regardless of whether the numbers are a 0-1 percentage or using the keyed property's value range. If you mean that the numbers are larger when using JSON, that is not a concern because JSON is not a format that minimizes the serialized size. If you care about a human being able to read the data or want to have an easier time parsing the data yourself, use JSON. If you care about size or speed, use binary.
Note when using the Spine Runtimes, you don't have to care about how key values are stored. You just need to export your Spine projects using v4.0 and use that data with the v4.0 Spine Runtimes.