Not sure if this is the right place to ask. I’m working on a material that involves a very small number in the math node; Plank constant, Boltzmann constant. in which Blender always round those numbers to 0 (floats precision maybe). I have proved it using this:
The top one is Plank constant and the bottom one is Boltzmann constant, which is clearly TWO different numbers. But when using a Compare node, Blender outputted 1, which means is see both of this as the same value. Also, I could not increase both of these two values using a Multiply node. So, I conclude Blender rounded it up to 0.
I didn’t input those minuscule numbers on the field itself but the number became absurdly small in calculation; Plank constant inputted as
instead of “6.6260702e-34” on the field. Which, before you ask, the second method didn’t work too.
So, Is there any way to increase Blender’s precition. Script? Add-on? or something I might not have known before. Thank you in advance!
Double might be better, but I don’t think cycles does that.
You would probably be better of with mitsuba or some scientific renderer.
But the question is - what you want to achieve. If your range of operation is small, you can just multiply all values with one trillion or more and be fine
Edit: this all concerns the range, your specific question of input - ‘just’ multiply your inputs
Blender uses single precision float (float32). It therefore should be able to handle numbers down to 10^-38 with enough precision. The compare node uses a delta epsilon do derermine equality. In your picture it looks like it is set to 0 but i am not sure if blender really compares with epsilon 0. Try if greater and less do work as expected.
But why do you need these numbers with their true exponent. Can’t you scale your calculations to a more reasonable level?
I just tried it out and as i thought: Blender uses single precision floating point numbers and can therefore handle any number down to about e-38. So as long as you dont multiply these constants, every calculation works fine with high enough precision.
If you need it for some highly scientific calculations with more than 7 decimal digits precision, then Blender is definetly not the right choice here.
It does the following calculation: (h / k) * 10^10. This should give 0.4799. And the HSV Value (0.4799, 1, 1) - with H from 0 to 1 and not in degrees - is excactly this blue.
So if you have any problems with calculations with such small numbers it is most likely a mistake on your side as long as you dont go as low as about e-38.
There are some rare cases where blender use double precision: angles and they are noted 123d.
As a final note i’d have to say that in most cases ( say 99,99% ) doubles are as fast to handle as floats on modern CPUs. Okay this is not the case on a intel 486sx25 but who runs blender 2.9 on those machines ?
Mostly when you know that blender is compiled towards 64 bits archs !
@Atair Thank you! Indeed that is something I am working on it right now.
@Patrick Appreciate your answer. I tried the Greater Than and Less Than node. And It works! Blender does recognise it is like two different number. It is probably my error which I have to figure out where. (I probably shouldn’t divide Plank number with light speed to the power of three anyway)
@RickyBlender Thanks! I do have simple external python, but scripting in Blender is currently out of my reach. Using externally calculated value kind of defeated my purposes as I wanted to create a node group that corresponds with the input value.
@pitibonom So it is a limitation then. A bit disappointed but also expected. Thank you for your answer.
@Hikmet I do not directly type those number into the socket. But it also my error as blender did saw two of my examples as a different number. Thanks for your advice!
