I’m splitting a mesh using different cutters (letters for engraving) that are joined into a single disjointed mesh. In some cases the split fails - some faces just disappear.
If the split is done using the individual letters, then it works.
All the geometries are generated parametrically, so I’m looking for a solution that works as much as possible independently from possible specific issues related to the location of the mesh intersections.
I’m coming back to this, as I discovered a possible solution. When working on a custom Mesh Split C# script, I noticed that the Split method has a tolerance input. By setting it small enough, it seems that the mesh splitting problems I was having are fixed.
If this is something to be expected, wouldn’t be a good idea to expose a Tolerance input in the Mesh Split component? (Or to add an “advanced” Mesh Split component with the added inputs as in the Rhino Common method?)
–Edit: even with a very small tolerance there are some failures, however I think having a tolerance exposed would still make sense.
Thank you for the observation. In this case I believe the issues are generated when there are intersection vertices very close to each other. Anyway, it’s good to know that at least we can specify a different tolerance value.
PS on a different note, in those cases where the geometry is far from the origin, wouldn’t it make sense to move the geometries closer to the origin, execute the split operation and then move them back to their original position?
So wouldn’t be a good idea to have Rhino do it automatically (I mean inside the Mesh Split function, hidden from the user).
I know we can script this, but I’m wondering if having it done automatically would cause any issue (apart from a minor slowdown).
