I need to work a lot with meshes from 3DScanners and found what I believe to be a serious bug in the ProjectCurveToMesh rhinoscriptsyntax function.
Here, trying to project a curve (a simple line below the XY-plane in the Z+ direction) onto a simple grid mesh with a U-shaped hole gives NO curves at all if the projected line coincides with non-border mesh triangle edges… You will find this test mesh MeshToSplit1.stl (35.4 KB) along with the simple test script producing this error ProjectCurveToMeshBug.py (773 Bytes).
I know this problem is related to lots of other curve/mesh, mesh/mesh intersection problems. Maybe this simple test case can help solve the problem? These core geometric algorithms really needs to be rock-solid if I am to be able to do some reliable production quality work.
To try and isolate the problem, I split a simpler mesh MeshToSplit5.stl (11.5 KB) by projecting a small segment onto it. This segment was supposed to disconnect the mesh along it and create new triangles but it should still result in a SINGLE MESH, NOT TWO (as we got here!).
From a topological point of view, this is a complete mess! As this is a textbook example, the problem cannot be blamed on floating point tolerances, inside/outside test numerical instability, invalid mesh, etc.
Something funny is going on. If you just use the Project command, it will fail. But if you exude the curve into a mesh plane and run MeshIntersect, you will get the result you want. All this using your MeshToSplit1.stl file.
For a few months now, I have been using the project curve than split pattern instead of a mesh/mesh intersection because I had bad experiences with it and the curve projection way seemed to be more robust.
I know the first example uses a line coinciding exactly with some of the mesh edges and that is what might have cause the failure. Do you have any idea about the second example in which the split should not have produced two meshes?
Do you have any information about this example where we see the SplitMeshWithCurve giving the wrong number of connected components? Theoretically, this split is suppose to create a single mesh with a kind of duplicated border (one for the upper part of the mesh and one for the lower part) along where the split segment was projected.
I have had similar problems. I have a batch script that trims an input mesh using an input curve. It works well most of the time however sometimes the result is a thin disjointed mesh consisting of triangles just around the (closed) curve similar to “split component 2” above.
Unfortunately this occurs randomly and does not seem to be repeatable and so it is currently requiring an operator to babysit the computer and approve each split before it can proceed. Any advice on how to avoid this problem or even predict its occurrence would be appreciated.
Here is a relatively involved (and costly) strategy to bypass this problem.
1) Use the CGAL library for the meshing operations where you need robustness.
This C++ library can be used freely for academic purpose but buying the modules you need for commercial development will probably cost you a few thousands dollars. As I’m working for a consulting company where we can amortize this investment across multiple projects, this made sense for us. It provides lots of geometric algorithms.
2) Build the CGAL functionalities you need as a .dll and write a Python binding for it.
You will also need conversion function from and to CGAL triangular mesh structure. This simple step hides much technical details and I haven’t started yet but these posts tell me it can be done. Where there’s a will there’s a way!
I imagine many Rhino users do not have the technical programming skills to attempt this on their own. It would be really great if Rhino could use this approach to improve their core meshing functionalities for the benefit of all its users.
It is unfortunate that one would have to go to such lengths to fix something that should be working out of the box. @dale is this being actively worked on for V6?
I think the part of the bug related to the topology of the split has not been reported to the developers in the RH-31360 Project fails but MeshIntersect works ticket. @dale, could you report it also please?
In the automatic process I’m implementing, this part of the problem is as important as the absence of split when the intersection is exactly ON the mesh vertices (this problem, I could possibly work around by adding a small perturbation to the line or mesh in case there is no intersections).
BTW, I’m still working on the CGAL solution I was talking about. More details when I succeed… I’m still at the building of demos and their dependencies.
Finally, I wrote a stand alone applications that would take a .STL and a,b,c,d plane parameters, split the mesh and save the resulting mesh(es) in files. I did not have the time nor the experience to write Python wrapper around the CGAL code. I also wrote a Python function that would do the following steps:
Create a temporary directory
Save the mesh to split in this directory
Call my CGALTrimming .exe with the right parameters in a subprocess.Popen(…) command and wait for it to finish
Import back the splitted meshes.
Delete the temporary directory and its content.
Unfortunately, I cannot share the executable or the code due to licensing restrictions. Again, if Rhino could base their core geometric mesh algorithms on such robust library, they would save the trouble to ALL their users!
