- Изменено
Rounded off value in V4.0.17
Congratulations and thank you for releasing the new V4 of spine.
I imported an old file from v3.8.99 into the new version for testing. I realize all value have been rounded off to 1 decimal place. Apparently there’s no displacement I can see within my project, I concluded that is just the display that got rounded off for cleaner UI.
I wonder if there’s a way to make spine to show the initial 4-5 decimal places, and let me copy and paste the unrounded value. Or maybe it’s somewhere in the setting that I’ve missed?
In 4.0 Spine can actually show more decimal places. However, the larger the number, the fewer decimals places are shown. This is done so the number fits in the text box. How large is the value? Also what kind of value (translate, scale, etc) are you having the problem with?
6 дней спустя
Hi, thanks for the reply.
The value seem to round off even it is small. There is 3 places I found with rounding problem, there maybe more on another places that I haven’t come across with.
1 Weights tool (1 decimal place)
After selecting one vertex point on the mesh it will show all bones bind to the mesh, the percentage weight value on the list of bone (bottom section, right) is always round up to whole number without decimal on both version(yes, it doesn’t add up to 100 most of the time). If you select a bone with value from the list, the weight display box on the top will display the values to a few decimal points. For instance in my project one of the weight value is 47% on the bottom list, after selecting the corresponding bone it is 46.2341%(v3) and 46.2%(v4) on the top. I need to copy and paste the exact value to another section or bones to do the weights quiet often, this rounding to 1 decimal place is a big problem for me to work in the new version. For example if I need to set a symmetrical weight on the other side of the same mesh, even the initial value is still 46.2341% but display as 46.2% in v4, I cannot recover the exact value anymore by copy and paste(I can only get 46.2000), therefore the new vertex will not behave as I wanted. Also a lot of the time vertices are set quiet closely to each other so they share a similar but different weight, with the new v4 version I will have difficulty viewing the gradual changes aka 46.151 and 46.249 will be the same 46.2 value in the text box.
.
2 Offset and mix value in constraint setting (1 decimal place)
All values in offset (rotation, translate, scale shear) and mix (rotation, translate, scale shear) have rounding off issue to 1 decimal place.
In v3 the offset values for one of my constraint is rotation 3.0517578E-5, translate -1.3034953 / -33.51594, scale -155.55501, shear -179.9681. But the same constraint in v4 the values become rotation 0, translate -1.3 / -33.5, scale -155.6, shear -180. As I mentioned above, I do need to recover the exact value by copy and paste. A lot of fine tuning needs the decimal place, after I press enter in the field, the value after 1 decimal place is lose forever to me even it is in the system and display on screen, it is very annoying if I need to come back for extra fine tuning at a later time.
3 5 digits limit in the main setup/animation panel (this is on both version)
As you mention in the reply, as the number get bigger spine display less decimal place. At the ones it can display 4 decimal places, and 3 decimal places in the tens, but when it gets to the thousands, there’s only 1 decimal place left on display, the rest is rounded off.
This is quiet unfriendly to me if I do an animation with big displacement (translation), for example jump off a cliff and land on the bottom, after landing when I need to line up with the floor or other objects perfectly I need to memorize the number and punch in the value to 2 or 3 decimal places. It is also not as convenient for fine tuning animation with 1 decimal place (there is 2 decimal place by normally).
I wonder if Spine can put in an option in setting to toggle <Auto round off for display / Keep all of the decimal places>
Or by default only round off after 4or5 decimal places instead of 1 decimal place and regardless of the value being in the hundreds or thousands.
Or display the rounded off values normally and only display the full number when clicked on the text box.
Or some other way might be easier for the programmers that can help with the decimal display.
Hi, I just wonder if there is any news regard to this display problem or any plan to fix it in future updates. I really need the decimal places to work properly. Thanks.
Sorry for the delayed response! Thanks for listing the problematic areas, that is very helpful.
Previously we'd show the actual transform value and some digits would get cut off, eg for 1234.5678 you might see 4.5678, so you'd not see the most important part of the value. The intent in 4.0 is that we show useful values. Eg we'll show 1234.5. In 4.0.18 we've changed it to show transform values without rounding when a text field is focused. Hopefully that achieves both goals. Losing the value was definitely not good.
We've also increased decimal places for the weights view and all constraint offsets and mixes. If you find any other places where the rounding isn't good, please let us know!
(=´∀｀)人(´∀｀=)
Hi it’s me again. I got a few questions regarding to the new v4.0.18
1 Adjustment of value by dragging on top of the text box
When I can enjoy my decimal points again, I run into small trouble when I wanted to highlight and change only 1 or 2 digits. It will trigger the slider bar function. For example, I have a translational value of 1234.5678, I only wanted to change 3 into 6 (i.e. 1264.5678), the fastest way is to highlight the 3 and type 6. But when I try to highlight 3 (drag my mouse from left or right of 3 to select) it will trigger the slider bar function and the value will change.
Is there a way to highlight values without triggering the slider bar, or somewhere in setting to turn off the slider value adjustment function, or it slides only in vertical dragging which does not interfere with horizontal highlighting.
This happens in the main panel transform setting, weight tool and constraint offset & mix setting. The later two actually have a slider bar as a part of the UI next to the number box, the text box slider bar function seems redundant.
2 Decimals again
When I’m updating the project some values in older version are more than 4 decimal places, when I copy and paste those values they still get rounded down. Is it possible to display, copy and paste the unrounded values (maybe up to 8 decimal points)? The rounding seems to generate a small discrepancy especially when I try to copy the value to make symmetrical objects. Maybe it’s me but it does feel slightly off to me.
From previous posts I see exporting in Json rounds to 5 decimal places. Does the values get rounded down if I export the project in binary?
3 New constraint calculation in 4.0 compare to 3.8
I realized in the same project have like 200 extra bone transformation in 4.0 than in 3.8. It seems to have no effect within spine but I’m curious if it may take more resource and affect performance, especially when there’s multiple assets on screen.
KLCL написалIs there a way to highlight values without triggering the slider bar, or somewhere in setting to turn off the slider value adjustment function, or it slides only in vertical dragging which does not interfere with horizontal highlighting.
There's not, sorry. I recently posted about it here:
Drag Selection Value
Vertical only is what we used to have, but you run out of space more quickly. We could try to do something like if the text box has focus, then disable drag left/right so we can allow left/right text selection. That seems like it could be OK, though it adds a click.
FWIW, we try very hard not to add settings unless something really needs to be configurable. Adding a setting is an easy way of letting the user decide how the software should work rather than use finding the best way it should work. This leads to software that is more complex than it should be and with a million settings. It's not always possible to avoid settings, but it should be a last resort.
KLCL написалThe later two actually have a slider bar as a part of the UI next to the number box, the text box slider bar function seems redundant.
There's a difference: the slider sets an absolute value based on the mouse position while dragging left/right adjusts the current value relatively. This can be helpful when the value is outside the slider range (many sliders allow dragging past the start/end).
KLCL написалFrom previous posts I see exporting in Json rounds to 5 decimal places. Does the values get rounded down if I export the project in binary?
The rounding for JSON data varies depending on the value. For example, translation has 2 decimal places while scale has 4. I do think it makes sense that the JSON data matches the rounding done in the UI, so you get the same results at runtime.
The values in binary data are not rounded.
KLCL написалIs it possible to display, copy and paste the unrounded values (maybe up to 8 decimal points)?
No, not currently, sorry.
Rounding is done in JSON mainly to make the data easier to read, since that is the really the only reason to use JSON. It also decreases the JSON data size, but if you are worried about size then you shouldn't be using JSON. If we allow many decimal places in the UI and JSON has rounding but binary doesn't, it would be possible to get different/wrong results when using JSON. In practice it doesn't come up very often. If it were a problem, we could provide a setting (I know what I just explained about settings! :p but I don't see any other way around it).
KLCL написалNew constraint calculation in 4.0 compare to 3.8
I realized in the same project have like 200 extra bone transformation in 4.0 than in 3.8.
4.0 applies constraints differently. It is explained why in this commit:
https://github.com/EsotericSoftware/spine-runtimes/commit/4f73fbbb396f406954646af76f167d8238802171
And also this forum thread (prepare yourself for quite the read! 
):
Editor: Parent constraint order breaks child constraints
Basically we have to do slightly more work in 4.0 but it makes constraints a lot more powerful. The additional bone transforms do use more CPU. Whether that matters depends on a lot, as mentioned on the metrics page.
6 дней спустя
Thanks for your reply.
Please do implement the disable left/right drag selection function in later update. It will be great help to put the workflow efficiency back on track.
I really miss the control of 3.8 (´°̥̥̥̥̥̥̥̥ω°̥̥̥̥̥̥̥̥｀)
Thanks a lot for offering the extra decimal option in setting. It will be great to have and give me a piece of mind. It still feels slightly off, maybe just me. But I can try to work with the current decimal places in 4.0 while testing out the effect of the new constraint first and see how it goes.
I will let you know if I absolutely need those decimal places. I don’t think too many people goes that far. Thanks a lot for your help. It’s really appreciated.
After testing I do need the decimal places. Please provide a setting to display, copy and paste the unrounded values (or to 8 decimal places).
Sorry for the trouble. Thanks a lot for your help.
Any updates?
In 4.0.20 dragging only changes the value if the text field doesn't have focus. This means you can click the text field to focus, then drag to select characters with the mouse.
Also in 4.0.20 we've tried to address the rounding and precision issues. Please give it a try (when released, likely tomorrow) and see what you think! We made a lot of changes to nearly every numeric slider and text field.
A setting to access unrounded values was not what I proposed previously. With these changes JSON data is slightly more precise and a setting for more precision in JSON is not needed.
I would rather not provide access to the most precision available. The limit is not 8 decimal places, rather it varies based on the magnitude of the number (that's why they call it floating point). Users really don't need numbers like 24.728351593017578 or even 6 decimal places 24.728352. Floating point numbers are extremely complex and myriad problems can occur when performing math near the precision limit.