Page MenuHome

UI: Don't Display Negative Zero Floats
AcceptedPublic

Authored by Harley Acheson (harley) on May 4 2019, 11:02 PM.

Details

Summary

This might seem like an April Fools joke, but...

IEEE Floating point numbers can represent both positive and negative zero. Which is fine, but we don't want to ever display them as they look quite confusing:

This patch makes it so negative zero can't be displayed in interface widgets. It does not change the underlying value, just what is displayed. The change might look funny, adding an amount of +0.0f to the value before displaying, but for negative zero that will make it positive zero without affecting any other values.

Haven't noticed negative zero? Load the default blend file, bring up the "N" sidebar panel. Change the rotation type repeatedly until you see negative zero. Or enter "-0.00" in a field and see if it sticks.

Diff Detail

Repository
rB Blender

Event Timeline

For anyone interested in how adding zero to a bad zero can make a better zero. LOL...

https://en.wikipedia.org/wiki/Signed_zero

Seems right to me, unless there’s a case I can’t think of where negative zero is needed?

Seems right to me, unless there’s a case I can’t think of where negative zero is needed?

Mathematically the zeros are the same number, so I doubt it. Besides, this is only for display. But it is really because of that uncertainty in many people that we need to not show it.

The topic was so cool to look into.

This revision is now accepted and ready to land.May 5 2019, 3:42 PM

Hi peeps.

I've got a question about this.

I'm not a fan of negative zero as I have found it to cause issues when exporting armature animations (and sometimes within Blender itself).

Last year we did a small game project at CGCookie and when troubleshooting a weird flipping error I found that if I turned off x-mirror and manually changed the -0.0 to 0.0 on the bones, the flipping was gone in Unity.
If this patch only changes the way the number is displayed and not the underlying value I never would have been able to find the cause of the issue.

So here's my question. Is it wise for it to only change the way it displays the value?

If -zero and +zero are mathematically the same, can't the underlying value be changed instead of the way it is displayed?

@Wayne Dixon (waylow) : I found that if I turned off x-mirror and manually changed the -0.0 to 0.0 on the bones, the flipping was gone in Unity.

Holy crap. Although positive and negative zero are mathematically identical, I can certainly see that there could be parsing errors if those are exported and are not expected. You just don't expect a "-" for zero.

If this patch only changes the way the number is displayed and not the underlying value I never would have been able to find the cause of the issue.
...can't the underlying value be changed instead of the way it is displayed?

Great question. Until you mentioned this I would have never guessed that this value was anything more than a confusion for people.

I imagine that @Brecht Van Lommel (brecht) will probably notice this ticket and your comment and will weigh in. And we can leave this the way it is, or do something different or better.

It's not possible to avoid -0.0 in general in an efficient way. It's just how floating point math works in C and Python and we can't possibly eliminate it everywhere.

Exporters could avoid writing -0.0, but that needs to be fixed in each exporter. If -0.0 causes in exported files causes issue in Unity, I would also consider that a bug in Unity. But it's also possible that -0.0 actually meant it was -0.0000000001, or that there is a bug in the exporter with handling of -0.0. In any case, that's for its own bug report and there is no general solution for it.

Just updating this patch for current source and with larger context.

I still think this would be a nice addition:

  • Many people do not know that -0 and +0 are mathematically the same so there is unnecessary confusion
  • This is only for display
  • This only adds +0 so doesn't affect any number except -0
  • This is in an area where we are already dealing with special cases inf and -inf