@isovector This PR isn't ready for merge, but if you've got the time I would love to hear your thoughts on the overall concept! I believe you've looked at this same area of the code quite a bit.

I like the idea. One issue we ran into when trying to fix the whiskers (#353) is that the triangles were fine, but the points they contained were crazy. In a codebase as numerically heavy as this one, the solution was to manually binary search some asserts through the codepath, but it took a few days.

I'm not sure what your intended use case is for this stuff, but it seems to me like you might want to track an analogous sort of providence (where in the code it came from, rather than just how it's built conceptually.)

@isovector Awesome! Yes, I agree, code locations would also be useful - in fact, I originally started with CallStack rather than a custom datastructure. Since sometimes triangles get combined, I wanted to be able to track those back to the ones they were combined from, so CallStack isn't enough on its own, but it'd be nice to also have that in there.

Regarding the whiskers: I think i've solved some of them in #375, though I definitely did not improve the solving; it looks like your patch does. It would be great to have points that are "pretty good" instead of just "not wildly bad" (about as much as my code does)!

TODO:

• i need to know the performance impact of keeping a tag around on every single triangle (it did not seem massive, but i'm sure it's nonzero)
• it needs an official interface to get the data out, rather than Debug.Trace.trace
• A couple of the provenance things are just Ints, which is silly
• i don't think i completely followed the style rules

for official output, i recommend adding a 'debugasciistl' file type, that is an ascii stl, with the final 'solid' being followed by this metadata, in structured form. Or, implement 3mf. :D