precision vs uncertainty

[pca006132]

Related to the performance of offset due to less simplification...

I think even though precision is a key concept in manifold, most of our users are nof very aware of it, and our APIs are not helping this. There are two kinds of precision: One that user wants, and one that we can guarantee to keep.

For example, if users are working on some 3D printing models, they may say they want the precision to be around 0.05mm, transformations should not change this. In our library, the precision value does not work like this, it depends on the transformations applied because it is about the maximum floating point error that may accumulate in our operations. Our existing API allows the user to set the (second kind of) precision valud when they import a mesh, but I doubt if users know when they should be setting it. Most of the time they probably shouldn't be touching that, unless they want this to be scaled according to transformations... And users do want to control the (first kind of) precision, we should probably allow that, so more simplification can be done and things can work faster.

Proposal:

1. Rename precision into uncertainty, error or imprecision. Hide precision from public APIs.
2. Provide resolution tolerance field, which is independent of transformations and will become the min max resolution tolerance when performing boolean operations. Automatically set to maximum of itself and fp error in 1.
3. Provide SetTolerance that immediately performs SimplifyTopology when the tolerance is greater than the previous value.

[elalish]

Yeah, this is a good point. Perhaps precision as it currently stands should not even be exposed in our public API at all anymore? I think we need a different name than resolution though. People are used to resolution being pixels, where higher means more quality - in meters this will be the opposite. Precision actually has the same problem (high precision is small meters). How about tolerance? That's pretty standard in the CAD world for this.

How about GetTolerance and SetTolerance? So for Booleans, you'll get the maximum of the two tolerances as your result, but if you wanted the lower (say one object was meant to be more heavily decimated than the other), then you can just set the high tolerance object back to a low value before the operation.

[pca006132]

1. The first option sounds good.
2. Ah this makes sense. I think users probably won't be setting different tolerances that frequently anyway (hopefully, we don't record feature tolerances so it makes no sense to do this), so your example is probably the most common.
3. This should be added to v3.0 breaking change as well? Hiding precision and expose tolerances.

[elalish]

Yes, this sounds like good fodder for a v3.0 breaking change. I'd like to verify that it'll solve #993, though I suppose it's a good idea regardless. Do you want to tackle it?

[pca006132]

Should be a rather simple change, but I will only have time next week to do it.

[elalish]

SG - I need to finish my open PR and clean up our Doxygen. I'll let you know if I have time to attack this one, but I doubt I'll get to it before you anyway.

[starseeker]

Another question: should SetTolerance automatically run SimplifyTopology

My instinct would be yes - or perhaps, put another way, would there be a scenario where the user would set the tolerance but NOT be looking to have the mesh simplified? I.e., if they don't want the simplification isn't the correct thing to do to leave the default (tight) tolerance?

My immediate intuition says that we wouldn't want different tolerances on different objects - if we're not OK with the results of a very small object getting decimated out of the resulting manifold in an interaction with a much larger object, we should be setting the tolerance (if we set it at all) based on the dimensions of the smaller input for both inputs.

The obvious test would be how straightforward it is to set a tolerance to get #993 to behave more or less as it did with v2.4.5 (presumably a tolerance number based on float rather than double limits?) but I'd also be quite curious if we could function with even more aggressive decimation. In BRL-CAD, by the book, we define a minimum distance tolerance below which we consider points to be the "same" - 0.0005mm. Eliminating mesh details an order or two below that level should (in theory) be fair game, and large number of small/thin triangles are problematic for other reasons as well, so there are actually a lot of potential benefits.

[pca006132]

And another weird idea: Instead of number of faces/angle/segment length, can circle/sphere constructor take a tolerance parameter and calculate the number of faces required to meet the tolerance?

[elalish]

Yeah, that's a good idea. I think it'll have to be part of our global quality settings, right? We'll have to think through how they should interact with each other sensibly.

[pca006132]

Yeah, I think we can leave this to after v3.0.

[a-day-old-bagel]

Can I just add something, as a user:

I'd like to see a public method on Manifold that lets me decimate to some certain unit resolution, regardless of whether that Manifold was created from an input mesh or not. If this already exists, then the way to call it has eluded me. I think this is something that is done internally and automatically in some cases, possibly as the SimplifyTopology step, but I'd like to, for example, be able to say "simplify/decimate this manifold to a lower precision/resolution" on purpose.

Specifically, I've been working with large scenes in which I don't want any tiny triangles to exist if possible. And so I'd love to be able to decimate/simplify any Manifold to a low resolution of 1 mm, and take advantage of the double precision to be able to support extremely large scenes, rather than extremely precise ones.

So I do hope that, rather than remove precision controls from the API, there might be more exposed, in fact...

[elalish]

Yes, this is exactly what we're talking about here. I believe this is what you want:

should SetTolerance automatically run SimplifyTopology if the tolerance increases?

[a-day-old-bagel]

Ah yes, that does make sense now that you mention it. That does seem to be what I want. Ok, glad to hear that's being discussed.