Arithmetic types in Blender

Technical Feedback
6

An issue with boolean (maybe bevel too) is that it’s import to make calculations at a higher precision than the input data.

So for a correct result a certain set of cuts might need to be made, however if these locations are already so close - the limits of float precision mean vertex calculations (possibly even placement) are not capable of representing the geometry, making the result unreliable (inside/outside calculation may fail or the output order of locations may be wrong).

The cork boolean library (used in production by Cícero Moraes) - quantizes locations.
Since this library is known for it’s robust operations, I think it’s worth taking this approach seriously.
It’s may be technically possible to workaround the limits of float precision, but I’d like to see evidence - Carve has issues with overlapping surfaces too.

Heres a test patch that adds an option to blender’s booleans that quantizes floats by any number of bits, I tested this and it does fix T47108 although it didn’t resolve all issues in the tracker relating to overlap.
(Edit: the patch offsets each side of the boolean, that part isn’t so important, easy to quantize both sides evenly)

The problem with this is the mesh is degraded by quantizing it’s locations, if we use double precision for booleans we effectively have quantized input by using 32bit floats. So that alone may be worth considering.

This raises the question how to use doubles for some spesific operations, while it’s possible I can only think of changes that are disruptive.

Have BLI_math source files use a float type which can be declared (call it real for eg?), then define single and double versions of the functions using includes and defines.

This is done already for single/double linked list sorting, see:

Doing this for a large portion of BLI math is going to be much more disruptive, although I think it could be done without being too noisy.

  • every double version just gets _db suffix.
  • math functions use a signature:
    void M_REAL_FN(madd_v3_v3)(real a[3], const real b[3]) { ... }

Am uneasy about recommending this, but think it would be workable of having double version of our math libs (also kdopbvh) is important.