JS/TS library simple manifold operations are susceptible to floating point error

[fzembow]

My issue

I was 3d printing some parts generated using this library (a fantastic combination!) and one of my pieces (a compound object that was a union() of a few manifolds immediately adjacent to one another) was not actually physically connected when I had expected it to be :)

Turns out that JS floating point error is the culprit -- one of my manifolds was .000000001 away from the other, and the union() of them therefore the union was actually composed of two disjointed manifolds.

Simple reproduction

import Module from 'manifold-3d';
const manifoldWasm = await Module();
manifoldWasm.setup();

const cube = manifoldWasm.Manifold.cube([0.1, 0.1, 0.1]).translate([0.2, 0.2, 0.2]);
console.log(cube.boundingBox());

Results in:

{
    "min": [
        0.2,
        0.2,
        0.2
    ],
    "max": [
        0.30000000000000004,
        0.30000000000000004,
        0.30000000000000004
    ]
}

It's not surprising, since in JS,

> 0.1 + 0.2
0.30000000000000004

due to floating point error.

---

Discussion

I've used proper Decimal libraries in the past when I've run into issues like this, such as decimal.js, but I'm not sure I can use that here since it seems internal to the manifold library.

For this particular project, what I think I'll do is just use micrometers instead of millimeters and always deal with non-fractional values for the dimensions of my manifolds (or just fatten my manifolds by some tiny amount to ensure they actually overlap), but I'm wondering if there is perhaps some library-level solution to this?

• Perhaps the library could use a Decimal library under the hood?
• Perhaps there would be a method like .snapTo(gridSize) on Manifolds to place all the vertices on some multiple of gridSize

I appreciate this might just be a limitation of using this in JS, but thought I'd at least point this problem out, maybe you have some ideas!

Thank you for a wonderful library, it's brought me a lot of joy to work with!

[fzembow]

The workaround approach I ended up taking was actually to just scale up everything by 1000, Math.round(), perform my union, and then scale back down the result manifold and continue. Seems to work.

[elalish]

Indeed, this is the correct approach. To avoid surprises, we let our transformations happen according to standard floating point math, rather than trying to "correct" it. You've outlined a good approach to avoiding floating point errors.