I made some minor requests for changes. I think it is ready for commit after those are addressed, but Campbell might want to look too.
The code below assumes neither angle1 nor angle2 is zero. What if triangles are degenerate?
This will fail if either a or b is a zero vector. Do we believe that all calls of this will guarantee non-zero length arguments? E.g., in find_vertex_to_opposite_angles_correspondence below, what if a triangle has two equal vertices?
The 3 here seems kind of arbitrary. How was this arrived at? Should there be some kind of user control over this?
Are we guaranteed that dblA != 0? I wonder what happens with degenerate triangles.
Since this is part of the external interface of slim to the rest of Blender, it would be good to do a better job of documenting what these data members are. For instance, the vectors called ..._matrices are actually linearized versions of matrices and the comments could explain things like that.
I know that this file is an adapted version of https://github.com/libigl/libigl/blob/main/include/igl/slim.h and as such, we probably want to allow disobeying some of Blender's code style conventions in order to make it easier to incorporate upstream fixes. But skipInitialization, validPreInitialization, etc., as well as withWeightedParameterization etc below, all seem to be new coded added for Blender. As such, I would prefer that Blender's naming convention be used, which is snake_case, so, e.g., skip_initialization, etc., for all variables that are not in the original igl code. However I am not insisting on this point, since there are numerous other variables not following the convention. Campbell, do you have a strong feeling one way or the other here?
Would be nice to explain what this added field is for in a comment (of course it would be nice to explain what all the fields are for in the comment). I notice that There is a Python API object, BMLoopUV, https://docs.blender.org/api/current/bmesh.types.html#custom-data-layer-types , giving access to this struct. Should that be extended with this new field?
I agree that is appropriate for interfacing with code in intern/
The final set of reviewers is me and Campbell. I am going to have time to look at this tomorrow.
I tried this out and it seems to work well. @glukoz are you still working on things, or do you think it is ready at this point?
This looks good to me. Will you commit it to the release branch please, as this needs fixing before 4.2 is released.
Germano, I looked at this some, but the combination of efd3c4b3c9 and the previous one have so changed the logic of what is going on that I can't figure out what is supposed to be happening. It…
No, I am not sure I will complete this version of Exact Boolean V2 at this point. I was running into a number of hard-to-fix issues and then I learned about the Manifold Boolean library, which…
It triggers an assert in CustomData_get_active_layer_index (the data argument has no layers or any other data).
Try moving the ensure_lookup_table() calls after you delete things.