1
$\begingroup$

Whenever I enter the 11/12 digit number that I need for one of my projects into the value input of any (shader) node, Blender lowers the number.

For example, I've tried to input the number '12345678910', an 11 digit number and gotten '12345678848' instead. I know that Blender often rounds and hides the displayed numbers sometimes, but given that the number is completely different, I'm not sure that's the case.

If it is a bug, then it's been there for a while. I checked and it was present in Blender 2.81 as well. I've also replicated the issue on Mac and Windows systems. You can replicate it by inputting a 10 or higher digit number into a value node (in the Shader Editor).

I want to figure out what's going on and how to fix it. Any help would be very appreciated. Thanks!

Improve this question
$\endgroup$
2
  • 4
    $\begingroup$ Yep it's only possible to ensure 8 digits of precision in the floating point values. Maybe you can try to achieve it by other means, it seems like an oddly high and yet precise number to work with. What were you trying to do ? $\endgroup$
    – Gorgious
    Commented Feb 10, 2022 at 6:59
  • $\begingroup$ Thanks for the great answers @Gorgious and Gordon Brinkmann! Knowing that there's no way to get around this, I'll just stick to my current method. I'm making a barcode shader, and instead of someone inputting 12 digits of values (imgur.com/a/X00oY78) in different inputs, I wanted them to just put be able to put it all in 1 input. I then had the issue described above and adapted to a system where they could input the first and last 6 digits instead, and that's what I think I'll keep using. (imgur.com/a/tvnTNs1) Thanks, everyone! $\endgroup$
    – Exporer
    Commented Feb 10, 2022 at 7:51

1 Answer 1

Reset to default
7
$\begingroup$

As far as I know, it is not a bug and thanks to @Gordon's comment, I dig up a bit more in the subject and figured out that it's actually more complicated that what I thought it was.

What is happening here is, as @Gordon and @Gorgeous said, a Floating point precision problem.

Float numbers are stored as bits with 3 parts : the sign bit, the exponent bits and the mantissa bits. The mantissa bits (sometimes it can be called a sinificand) are the ones that give the actual precision to the number while the exponent bits tell how big the number is. Basically, the bigger the exponent is the lower the precision is going to be.

It's explained by this chart

enter image description here

which I took from this page.

The second column indicates the range of the represented number and the 4th column gives the amount of precision you'll get if you represent that number as a float, if the difference between two numbers is less than the number in that column then they will be considered to be the same.

You can have an exact precision for whole numbers up to $16777216$ (which is $2^{24}$) but if you go beyond that, whole numbers will not be represented accurately anymore. You can try typing 16777217 for example and you'll see that it'll get "round down" to 16777216.

And contrarily to the previous answer I wrote 12345678910 is not the larger number Blender can handle, it can go as far as 340282346638528859811704183484516925440 (it will be considered as inf) but as explained earlier, accuracy will suffer a lot at that range.

Improve this answer
$\endgroup$
7
  • $\begingroup$ Well, although I think your answer goes into the right direction, it is simply not correct that 12345678848 is the maximum it can handle. If I enter 99999999999 (11 times 9) it gives 99999997952 for example, which is a lot larger than 12345678848. Or enter 12 times 9, it gives you 999999995904. $\endgroup$
    – Gordon Brinkmann
    Commented Feb 10, 2022 at 7:09
  • $\begingroup$ You're right, my bad. My answer is misleading in this case, I will edit it to be more accurate. Sorry. $\endgroup$
    – mqbaka mqbaka
    Commented Feb 10, 2022 at 7:16
  • $\begingroup$ I think it's as @Gorgious and I said in the comments below the question, it's more a matter of floating point precision or something like that. Whereas the frame range limit to 1048574 seems to be an actual maximum that cannot be exceeded. $\endgroup$
    – Gordon Brinkmann
    Commented Feb 10, 2022 at 7:36
  • $\begingroup$ Yes it's a floating point precision problem. I'm reading an article on it right at the moment. It's actually pretty interesting. $\endgroup$
    – mqbaka mqbaka
    Commented Feb 10, 2022 at 7:38
  • $\begingroup$ It is, but my Computer Science studies are many many years ago and I don't remember everything without looking it up ;) $\endgroup$
    – Gordon Brinkmann
    Commented Feb 10, 2022 at 7:44

Not the answer you're looking for? Browse other questions tagged .