mesh id handling

[pca006132]

We currently track mesh id for boolean operations and compose, which allows users to figure out where a particular triangle comes from and reapply certain properties. Triangles from different meshes will not be collapsed, so in some cases tracking this information can have significant overhead (#671).

I think instead of opt-out as in #671, we can do opt-in for mesh ID tracking. For example, we can say that we will not track mesh ID 0, so IncrementMeshIDs will only remap non-zero IDs. We treat meshes with mesh ID 0 as from the same mesh, and coplanar triangles can be collapsed. To opt-out from this behavior, the user should call AsOriginal for the boolean operands to give the mesh some non-zero initial ID, and future boolean operations will give the result different mesh IDs due to calls to IncrementMeshIDs.

// cubes have mesh ID 0, so result also have mesh ID 0
Manifold result = Cube() + Cube();
// give result2 mesh ID 1
Manifold result2 = result.AsOriginal();
// result3 has mesh ID 2 and 0, where ID 2 is from ID1 from result2, and 0 is from Cube.
Manifold result3 = result2 + Cube();

[elalish]

I like this idea quite a bit. Perhaps even we could allow AsOriginal(id) to optionally choose the ID to apply, allowing zero to go back to no tracking?

[pca006132]

sounds good to me

[elalish]

I've been thinking about this more and now I'm less sure. First, the experiment from #671 showed this only had a speed-up for a really hideous edge-case object, but still a 10-20% slowdown for common objects. This is because if we don't keep track of IDs, we might be able to collapse more edges, but we definitely need to check every edge for coplanarity after every Boolean, where now we only have to check coplanarity on input mesh constructors. I think for this reason it's better for users to make a conscious decision as to when to apply that check, via AsOriginal().

[pca006132]

Perhaps. I am not too worried about performance as that can usually be fixed through different tricks, either by having some sort of a data structure that tracks which part of the mesh is checked and unmodified after Boolean operations (damage tracking?), or ask the user to manually apply the check. Though I would prefer an automated approach (damage tracking) compared to a manual approach, as users not directly using our API will probably be unable to do it manually.

[elalish]

Yeah, I'm interesting in "damage tracking" for another reason too: better intersections for meshes with tangents. Tangents mean that the surface isn't really the flat triangles that the Boolean operates on. It would be cool to go through just the intersection verts and try to move them to the real surfaces and calculate interpolated tangents, collapsing edges as necessary. This would allow smoothed meshes to be pushed through Boolean operations without introducing oscillations.

A related idea: applying chamfers / filets to intersected edges. Anyway, this will all require quite a bit of work. Let's revisit the ID handling if/when we get to these concepts.