Volume calculation is not deterministic about manifold

[pca006132]

Oh and it seems that this is indeed another thing! The failure is for Boolean.Sweep but not Boolean.Close, I guess I was too sleepy yesterday.

Boolean.Sweep indeed has different number of triangles, I will try to trace down the source of the non-determinism.

[pca006132]

I did look at the output, it seems that the problem is a combination of decimator being sensitive to halfedge order, and numerical error accumulation. There are quite a few really really small triangles not being removed by the decimator and contribute to the error due to magnitude difference.

I also triggered a decimator bug while testing this, trying to debug now. not decimator bug, but triangulator bug returning an invalid triangulation.

The volume error is small (<0.01) after using a numerically stable summation.

[elalish]

Interesting - do you think the volume calculation itself is introducing the error, or is the generated mesh actually coming out differently because of non-determinism in e.g. the decimator or triangulator? A NumFace() check might clarify, but I intentionally kept that out of tests because even if it were deterministic, it tends to change with any small tweaks to the algorithms, so it's very noisy. Generally volume has been better behaved - I wonder if this is because this object is geometrically invalid; that might be making it more sensitive.

[pca006132]

Indeed, it is hard to say what is causing the issue.
I'm thinking if we should compare output vertex and edges to determine if the output is deterministic (with sorting to make the order deterministic), and maybe also implement self intersection test?

[elalish]

I would guess the output is not currently deterministic, and will certainly change as we make small adjustments to the algorithms - I wouldn't want people to assume the output is identical from minor version to minor version. If we can get it to be deterministic in a run-to-run way, that would be nice, though I'm not sure of the best way to test that.

A self-intersection test is tough due to floating point rounding error. I decided it would be more reliable to check a sample's output manually once to make sure it's correct, then rely on volume and surface area checks to verify it hasn't changed. That amounts to a pretty good checksum, even if it's not actually testing validity.

[pca006132]

Sleepy thought: Is it possible that this is caused by precision loss in floating point addition and non-deterministic addition order? The interesting thing with the Boolean.Close test is that it has a lot of faces and each face contributes a very small area/volume. Our current code just do a parallel reduce to add them up, which is known to be prone to floating point error.

Even if this may not the actual issue here, I think we should pay more attention to this as this can make our result unreliable.

[elalish]

Yes, I think that's exactly right. I was originally writing this for CUDA, where the order of almost all operations is non-deterministic, so I wasn't expecting that sort of determinism in the result would be possible (another example is the order of the triangles input to the degenerate removal step, which is highly order-dependent). Also the fact that I didn't use stable sort everywhere (though that's probably more of a compiler-to-compiler non-determinism rather than run-to-run).

Now that we've abandoned CUDA, determinism may be more in reach, which would be nice. However, I still wouldn't want our users to expect that getting a result with e.g. a different triangulation of a face to be a breaking change.

[pca006132]

I think there are three things here: 1) Accurate result, 2) deterministic result (run-to-run) and 3) deterministic result across versions. 1 is orthogonal to 2 and 3, we can have non-deterministic mesh result but the volume/surface area calculation is accurate with respect to the output, and we can have deterministic volume/surface area calculation that has a large rounding error. While 3 is not our goal, I think 2 would be a nice to have optional feature.

To get 1, we should probably make a binary heap and only add minimal elements together for each iteration. This will be significantly slower, but I am not sure if there is anything faster. Using double in place of float here can also give us more precision, but this alone will not guarantee the error being minimal.

To get 2, we can add a ManifoldParam about deterministic results. When it is on, we will disable optimizations that are non-deterministic in the multithreaded case, e.g. the batch boolean optimization that is racy or parallel unstable sorts.

[elalish]

Regarding Sweep, did you look at the output meshes that had non-deterministic results? Do you think they are all accurate? Do you think the deterministic output you now have is accurate? I'd like to know if these are just rounding errors or something more serious.

[pca006132]

I think in addition to numerical stability issues, this also reveals that the current decimator algorithm is unable to collapse certain small triangles. I guess we should open another issue about decimator design and explore other algorithms. IIRC in my UG graphics course they talked about using quadratic error, and somehow prioritizing collapse of smaller triangles or something.

[elalish]

Well, most decimators are trying to reduce triangle count, so sorting is important. Here we're only trying to remove degenerates, so effectively we only care about triangles "smaller" than our precision and we're trying to remove them all. There are a bunch of situations that make a degenerate difficult to remove. Since I wasn't making any guarantees about not having any degenerate triangles in the output, I've been looking at this as a best effort algorithm. Have you found these certain small triangles to be causing bigger problems?

[pca006132]

No, I don't think they cause bigger problem than this, but I wonder if there exists a certain collapse order such that we can collapse the largest number of triangles. (just some theoretical thing here, even though I am not studying this field)