Unexpected non integer values #52222

New Issue

Serge Lyatin · 2017-07-29T22:46:30+02:00

Serge Lyatin commented

2017-07-29 22:46:30 +02:00

System Information
Win7 64bit

Blender Version
Broken: 2.78c hash fb1cd76

Short description of error

Exact steps for others to reproduce the error
Load default scene, go to Autosmooth and click left mouse button as on screenshot. Also appears in modifiers

**System Information** Win7 64bit **Blender Version** Broken: 2.78c hash fb1cd76 **Short description of error** ![Noninteger.jpg](https://archive.blender.org/developer/F685691/Noninteger.jpg) **Exact steps for others to reproduce the error** Load default scene, go to Autosmooth and click left mouse button as on screenshot. Also appears in modifiers

Serge Lyatin commented

2017-07-29 22:46:30 +02:00

Changed status to: 'Open'

Serge Lyatin commented

2017-07-29 22:46:30 +02:00

Added subscriber: @SergeL

Bastien Montagne commented

2017-07-30 17:03:51 +02:00

Added subscriber: @mont29

Bastien Montagne commented

2017-07-30 17:03:51 +02:00

Changed status from 'Open' to: 'Archived'

Bastien Montagne closed this issue

2017-07-30 17:03:51 +02:00

Bastien Montagne self-assigned this 2017-07-30 17:03:51 +02:00

Bastien Montagne commented

2017-07-30 17:03:51 +02:00

Thanks for the report, but not a bug, just how floats work in computers (and a trade-off between precise manual editing of values, and nice-to-the-eye rounding of them).

Serge Lyatin commented

2017-07-30 18:11:21 +02:00

Hm, but there were nice integers in build 2.78c 29ec0b1, for example

Hm, but there were nice integers in build 2.78c 29ec0b1, for example

Bastien Montagne commented

2017-07-30 19:22:15 +02:00

Yep, and when you were entering e.g. 4.9999 you’d get 5.0 when editing the value again, which was clearly much more annoying (preventing any really precise value editing, being limited at the 4th digit at best) than having a glitchy 7th digit popping up in some cases…

Brecht Van Lommel commented

2017-07-30 19:49:55 +02:00

Added subscriber: @brecht

Brecht Van Lommel commented

2017-07-30 19:49:55 +02:00

I expect we'll get a lot of reports about this change. I think the old behavior made a better trade-off to be honest, as far as I know it would still store the more exact value, just not display it.

Bastien Montagne commented

2017-07-30 20:07:22 +02:00

I don’t understand what is the issue here - this is not general drawing, this is only when you manually edit a value. Imho, you want maximum precision in that case, not 'cute' over-rounded value.

Bastien Montagne commented

2017-07-30 20:09:32 +02:00

Feel free to revert if you like though, tbh I’m more than tired spending time on that kind of things, there is no good solution anyway, only better trade off or not.

Brecht Van Lommel commented

2017-07-30 22:24:28 +02:00

I think the right behavior would be to show a number matching the one the user typed in, up to as many digits as we can preserve. The old code seems to round even 4.999 to 5.0, but we can keep up to 6 digits for floats, so 4.99999 can still work safely.

On the other hand the new code shows 180.000005 which is 9 digits with the 8th and 9th digits being essentially random and not useful information to show. The code seems to assume the 6-7 significant digits are right after the decimal point, which is wrong.

So we can improve things here before we get to the trade-offs, but it's too close to the release for that now. I think we should revert ecb5b55d7f in the meantime.

I think the right behavior would be to show a number matching the one the user typed in, up to as many digits as we can preserve. The old code seems to round even 4.999 to 5.0, but we can keep up to 6 digits for floats, so 4.99999 can still work safely. On the other hand the new code shows 180.000005 which is 9 digits with the 8th and 9th digits being essentially random and not useful information to show. The code seems to assume the 6-7 significant digits are right after the decimal point, which is wrong. So we can improve things here before we get to the trade-offs, but it's too close to the release for that now. I think we should revert ecb5b55d7f in the meantime.

Bastien Montagne commented

2017-07-30 22:37:57 +02:00

Eeeeh, angle buttons is actually an issue! Those go through the 'unit' path, which handles precision in the old, weird way - with max precision value :/
will fix that, should not be too hard…

Eeeeh, angle buttons is actually an issue! Those go through the 'unit' path, which handles precision in the old, weird way - with max precision value :/ will fix that, should not be too hard…

Brecht Van Lommel commented

2017-07-31 12:57:12 +02:00

Ah, it seems to be an issue with display of units in general. I'd still suggest to cap the number of digits shown at 6 instead of 7, that last digit being +-1 off from the value the user typed in is confusing.

Bastien Montagne commented

2017-07-31 15:53:30 +02:00

@brecht agree, actually that’s what I did in dc6fcb8ecf… But forgot about units cases (especially angles, which are somewhat in the middle btween 'regular' and 'units' number drawing :/ ). Shall be OK now though.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Unexpected non integer values #52222