Entering numeric values

Support Basics & Interface
1

Hi, (using Blender 2.69, Win7/64)

first, I’m a software developer for 25 years, so I know how to deal with numbers, and I’m also aware about floating point (in)accuracy. But this is something different.

In this example, units are set to metric, scale is default (1.000). I have a vertex. In the properties panel, we can change the coordinate by entering numeric values. I’ve put all screenshots into one image due to the limit of 3 attachments per post, and I describe each item as follows:

  • Let’s start with zero
  • Then I enter the new value (0.0001) and press Enter
  • Blender correctly displays the value (as 0.0001 means 0.0001 meters, it is 0.1 mm)
  • Then I change the value to 3 m
  • Again I enter 0.0001.
  • This time Blender shows a different value. This does not make sense. It should just store the entered value. It shouldn’t matter what was the value before.

Bild258.png211×571 40.5 KB

Not only the values seems to be parsed/converted differently from the first time I entered exactly the same value, it also doesn’t display any unit. In previous versions, Blender showed µm and nm. Maybe there is a setting that I didn’t find.

If I now change “99.89738” to “99.8973” - which is really a minor change - and press Enter, Blender “thinks” it’s meters. I do understand it assumes meters if no unit is entered explicitly, but then it should consequently display a unit if it’s not meters, i.e. it must display “99.89738 µm” (or better “0.1 mm”, which is what I’ve entered).

Another issue is, if “99.89738” is displayed and I start typing “µm” at the end, the edit box just freezes when typing the first character. I can not navigate or delete anything even though it still dispalys “99.89738”. Only pressing Esc works. However, If I enter the edit box and first delete the last “8”, then I’m able to enter “8 µm” at the end. It doesn’t matter that the unit won’t be accepted when pressing Enter because this is during editing.

The problem is not the small scale. (I don’t intend to go < 0.1 mm). The issue is the inconsistency.

EDIT:
Binary format (little endian) of decimal value 0.0001

  • after entering it the first time (correct): 0x17 0xB7 0xD1 0x38
  • after entering it the second time (incorrect): 0x00 0x80 0xD1 0x38

EDIT #2:
Blender 2.68a: like 2.69
Blender 2.67b: Same conversion problem, but it displays the unit “µm”.

2

Good catch!

3.0001 works, it only seems to affect millimeter values up to 1m.
And it doesn’t seem to occur in object mode, only edit.
I’m suggest reporting it as a bug to https://projects.blender.org/tracker/index.php?func=browse&group_id=9&atid=498&set=&start=0

3

Thanks for your reply.

Reported:
https://projects.blender.org/tracker/index.php?func=detail&aid=37327&group_id=9&atid=498

4

blender is limited to 7 digits
so for a scale of 1 you might have 1234.123
anything else entered wont work cause it will be rounded to 7 digits!

happy bl

5

You didn’t get the point. Whenever I enter the same value twice, I expect to get the same result twice. Moreover, Blender uses floating point values, i.e. this is not limited to 4 decimal digits before and three after the decimal point. 1234567.0 and 0.1234567 are both valid single precision floating point values.

6

you can enter it but when blender takes it and process this number it will round it to 7 digits anyway
sometimes you can see large numbers with 15 digits or more but this is only the button format which use the system format and does not show the real value use inside blender

but it may also be considered as a bug

let us know what happen for the bug report

thanks

7

Yes, it’s rounded, but that’s not a problem but the natural effect of limited storage space. The point is, everytime you enter the same value, which is a sequence of decimal digits and the decimal seperator in this case, the input must be converted to the same floating point value. It’s hard to disagree with this. :slight_smile:

sometimes you can see large numbers with 15 digits or more but this is only the button format which use the system format and does not show the real value use inside blender
The real values can have infinite decimal places as it’s stored in a binary, not in a decimal format. Displaying such a value is usually limited to 7 relevant decimal places as displaying more digits doesn’t make sense. It’s 15 reliable decimal digits for double precision values. (see http://en.wikipedia.org/wiki/IEEE_754 if you’re interested in details)

A different story is if Blender truncates the input to 3 decimal places (after the decimal point). As I can enter 0.0001, it obviously does not. I’ve tried older Blender versions, and IIRC, before 2.5, input after the 3rd place (thousands) has been truncated.

BTW, if you create a new project (without switching to metric system), Blender displays 5 decimal places after the point (e.g. “1.00000”). If I enter “0.0001”, input is accepted and displayed as “0.00010”.
So, one might think that Blender would also accept an additional place, but if you enter “0.00001”, it does not display “0.00001”. Instead it displays “0.00000”, which indicates it has truncated the input after the 4th decimal digit (after the point). This is not a problem, but just misleading.
But, you can enter “0.00002”, which is then also displayed as “0.00002”. In opposite to the sentence before, this tells me input is not truncated after the 4th decimal digit in general.
(This is only meant to be a follow-up analysis; I don’t intend to model such small-scaled objects.)

BTW #2: The initial problem of this thread does not appear if blender units are used (no metric system), so there must be a problem at the conversion between metric<->blender units. However, as the scale between the units is 1.0, there must not be a difference.

But, thanks anyway!

8

yes blender internal is limited to 7 digits whatever the scale is
this is for internal calculations
so like i said your limited to something like 1234.123 = 7 digits

now for button showing values that is something else
i’v seen button in N panel showing like 27 digits
but these are only formated value for the button it does not mean that internal blender is using all these digits!

hope you get the idea that when you enter more then 3 digits after point with scale 1 blender internal in any case will truncate to 3 digits anyway.

i know that many peoples think that blender can do more then that but this is how variables are declared in blender !
unless you built your own version and change these variables then it wont have more precision!

happy bl

9

Ricky,

even a day later, after reading your message(s) again, most of your argumentation does not make sense. Your post count doesn’t prevent you from this.

  • Nobody doubts there’s a limit of 7 decimal places. The opposite is true: I told you that it’s 7 decimal places, so there is no need to produce this echo indicating it was me not getting it. I’ve pretty clearly shown that I do know the basics and also the background, so there is no reason to treat me this way.
  • The fact that 27 digits are shown in some places has neither helps you or me in the argumentation. It only shows that output is not limited to 7 or 15 relevant decimal places in some situations. I don’t know when or why, but it doesn’t matter because this fact has no relation to what I said. If you say " not […] using all these digits", I’m not sure if you know what you are talking about. Of course, Blender is internally using the value as a whole, and consequently it is using “all digits”, however, on the other side, it’s not using any decimal digits at all because the value is stored in a binary format. So your statement doesn’t make sense in itself.
  • I’ve proved that input is not generally truncated after three decimal places. You just ignore it and claim the opposite. I can only suggest you try something before making such statements, so you are able to see the facts. If input was truncated after three decimal places, “0.0001” would result in 0 (zero, not more, not less, just zero). Believe me, Blender is capable of storing and displaying zero exactly and correctly. If not mentioned otherwise, I’m always referring to the latest release, and in this thread to vertex coordinates in particular.
  • I do not want to change the single-precision limitation and I never wrote I wanted to. You wrote “many people”, so a reader might think I’m one of them, but I’m not. Just to make this clear explicitly.

So, what’s left is

  • the fact mentioned in the first post and reported in the bug tracker.
  • The lack of the missing units (“µm” and “nm”) that have been displayed in previous versions is a different issue and not been reported as a bug (yet) because I carefully and thoroughly make sure whether or not it is one in order to exclude that it is a user’s (my) fault, or a setting to be changed or intended by the developers. Maybe I will check this.
    (In advance: I do know that these units are not stored literally as characters along with each value.)
  • The 3rd issue is that, even though 5 fractional decimal places are accepted in general, e.g. “0.00002”, “0.00003”, “0.00004”, the input “0.00001” is stored and displayed as zero. This problem also still needs verification.

I won’t add more to this thread. Don’t take it personal, but everything’s said from my part.