Cycles Render Engine - inconsistent Math Node values #49605

New Issue

Pan Thistle · 2016-10-07T19:56:33+02:00

Pan Thistle commented

2016-10-07 19:56:33 +02:00

System Information
OS: Microsoft Windows 7 SP1 64b
GC: NVIDIA

Blender Version
Broken: (2.78 4bb1e22)

Short description of error
Cycles Node Editor Shader Nodes from Object - when I use the 'Greater Than' Math Node to compare input values I get inconsistent output

Exact steps for others to reproduce the error
In a very simple setup, I have passed the output of two math nodes (multiply and divide) which should produce the same result ( i.e. multiply 0.053 by 10.000 and divide 5.300 by 10.000 ) through a 'greater than' node to check the result. Since both calculations result in 0.530 the output of the 'greater than' should be 0. Instead it returns 1 (I check this by feeding the output through a Emission shader).
Strangely enough, when I use values where the calculations result in values other than 0.530 or 0.580 the output of the Greater Than node is 0 (meaning it returns what is expected). I suspect that if I used a 'Less Than' node instead of 'Greater Than' I should get the reverse results..?

This might be due to some internal rounding of the Math Nodes calculations however that would imply that the accuracy of the Math Nodes output value cannot be trusted.. I hope there is some explanation to clarify this erratic behaviour which at the moment renders all of my Node Group setups that use Math Nodes unreliable.

Thank you for your attention,

I have attached the file and I should also mention that I have observed the same behaviour using Blender 2.77a

Cycles_Node_Values.blend

**System Information** OS: Microsoft Windows 7 SP1 64b GC: NVIDIA **Blender Version** Broken: (2.78 4bb1e22) **Short description of error** Cycles Node Editor Shader Nodes from Object - when I use the 'Greater Than' Math Node to compare input values I get inconsistent output **Exact steps for others to reproduce the error** In a very simple setup, I have passed the output of two math nodes (multiply and divide) which should produce the same result ( i.e. multiply 0.053 by 10.000 and divide 5.300 by 10.000 ) through a 'greater than' node to check the result. Since both calculations result in 0.530 the output of the 'greater than' should be 0. Instead it returns 1 (I check this by feeding the output through a Emission shader). Strangely enough, when I use values where the calculations result in values other than 0.530 or 0.580 the output of the Greater Than node is 0 (meaning it returns what is expected). I suspect that if I used a 'Less Than' node instead of 'Greater Than' I should get the reverse results..? This might be due to some internal rounding of the Math Nodes calculations however that would imply that the accuracy of the Math Nodes output value cannot be trusted.. I hope there is some explanation to clarify this erratic behaviour which at the moment renders all of my Node Group setups that use Math Nodes unreliable. Thank you for your attention, I have attached the file and I should also mention that I have observed the same behaviour using Blender 2.77a [Cycles_Node_Values.blend](https://archive.blender.org/developer/F375162/Cycles_Node_Values.blend)

Pan Thistle commented

2016-10-07 19:56:33 +02:00

Changed status to: 'Open'

blender-admin commented

2016-10-07 19:56:33 +02:00

#49604 was marked as duplicate of this issue

Pan Thistle commented

2016-10-07 19:56:34 +02:00

Added subscriber: @panthistle

Aaron Carlisle commented

2016-10-07 20:04:42 +02:00

Added subscriber: @ThomasDinges

Ray molenkamp commented

2016-10-08 05:09:03 +02:00

Added subscriber: @LazyDodo

Ray molenkamp commented

2016-10-08 05:09:03 +02:00

Changed status from 'Open' to: 'Archived'

Ray molenkamp closed this issue

2016-10-08 05:09:03 +02:00

Ray molenkamp self-assigned this 2016-10-08 05:09:03 +02:00

Ray molenkamp commented

2016-10-08 05:09:03 +02:00

Internally all numbers are stored as a 32 bit float ( https://en.wikipedia.org/wiki/IEEE_floating_point ) this has some inherent precision issues (not limited to blender, this applies to ALL computing code using floating point numbers) using your numbers you end up with the following

0.053 * 10.000 = 0.529999971
5.300 / 10.000 = 0.530000031

which explains the behavior you're seeing. Even if we moved to 64 bit representation (which is unlikely to happen, given some gpu's have about 1/24 FP64 performance compared to FP32) you'd still be able to find number pairs where this would be an issue.

Internally all numbers are stored as a 32 bit float ( https://en.wikipedia.org/wiki/IEEE_floating_point ) this has some inherent precision issues (not limited to blender, this applies to *ALL* computing code using floating point numbers) using your numbers you end up with the following 0.053 * 10.000 = 0.529999971 5.300 / 10.000 = 0.530000031 which explains the behavior you're seeing. Even if we moved to 64 bit representation (which is unlikely to happen, given some gpu's have about 1/24 FP64 performance compared to FP32) you'd still be able to find number pairs where this would be an issue.

Pan Thistle commented

2016-10-08 13:32:18 +02:00

Hi there,

Thank you for the clarification. I was almost certain this was a floating point precision issue and your very clear explanation confirms it. Your advice as to how we could overcome this issue when using Math Nodes in Cycles will be greatly appreciated.

Thank you and have a nice day.

Hi there, Thank you for the clarification. I was almost certain this was a floating point precision issue and your very clear explanation confirms it. Your advice as to how we could overcome this issue when using Math Nodes in Cycles will be greatly appreciated. Thank you and have a nice day.

Pan Thistle commented

2016-10-08 16:42:00 +02:00

This is a message for LazyDodo

Hello again,

Further tests have shown an error probability of approximately 13.5%, I used a simple setup (attached file) which allows me to scan all possible values between 0.000 and 1.000. I have taken this range because it is representative of colour values, ColorRamp Fac, etc.

I believe this issue could be overcome by means of rounding to 3 decimal digits but I don’t know whether such a ‘Decimal Round Node’ could be easy to implement.

At any rate, I do not think that 13.5% error probability is a negligible percentage when you compare colour values, for example.. maybe we should re-open the task? What do you recommend?

I would also like to point out that since I am a new member of this forum, I am a bit lost with all the codified actions and such stuff, so I apologize if I posted something in the wrong place. I could use some pointers to help me understand the philosophy of the site and become more certain about posting something in the correct place and involve the right people.

In the hope that this message will reach you, I would like to thank you in advance for your patience and understanding.

Cycles_Node_Values1.blend

This is a message for LazyDodo Hello again, Further tests have shown an error probability of approximately 13.5%, I used a simple setup (attached file) which allows me to scan all possible values between 0.000 and 1.000. I have taken this range because it is representative of colour values, ColorRamp Fac, etc. I believe this issue could be overcome by means of rounding to 3 decimal digits but I don’t know whether such a ‘Decimal Round Node’ could be easy to implement. At any rate, I do not think that 13.5% error probability is a negligible percentage when you compare colour values, for example.. maybe we should re-open the task? What do you recommend? I would also like to point out that since I am a new member of this forum, I am a bit lost with all the codified actions and such stuff, so I apologize if I posted something in the wrong place. I could use some pointers to help me understand the philosophy of the site and become more certain about posting something in the correct place and involve the right people. In the hope that this message will reach you, I would like to thank you in advance for your patience and understanding. [Cycles_Node_Values1.blend](https://archive.blender.org/developer/F375555/Cycles_Node_Values1.blend)

Ray molenkamp commented

2016-10-08 16:58:28 +02:00

This really isn't the right venue for general support, but if you are ok with an error of 0.001 when comparing numbers i'd probably solve it like this

AboutEqual = Absolute ( Value1 - Value2) < 0.001

You could do it easily do it with 3 math nodes

This really isn't the right venue for general support, but if you are ok with an error of 0.001 when comparing numbers i'd probably solve it like this AboutEqual = Absolute ( Value1 - Value2) < 0.001 You could do it easily do it with 3 math nodes

Pan Thistle commented

2016-10-08 17:41:25 +02:00

Ok! I will try that though i'm not sure about internal assignment of significant figures. Nevertheless, thank you for your help and apologies if I wasted your time.. it was not intentional.

Regards

Ok! I will try that though i'm not sure about internal assignment of significant figures. Nevertheless, thank you for your help and apologies if I wasted your time.. it was not intentional. Regards

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

Cycles Render Engine - inconsistent Math Node values #49605