Looks awsome. Hopefully you can join the reconfigured MeshFaces along the edges back to their original “part”. I think this is something that is messed up in Rhino’s algorithm, it deletes the wrong bits and pieces after split.
Yup. In addition to Plane splitting, I’ll give you two examples. The first example is about cutting out parts of the mesh. In this case using a box (fig1 & 2).
Fig 1. Box cut of Glenoid - side view:
Fig 2.Same as above but top view (the points are “vertice density centroids” directing the angle of box)
Cutting with a Box in non-world direction is gold, but I can probably do without such lyxury.
What is less forgiving though is when a cut must represent the exact “real thing”, that is, the cut to be done to the bone during the real life operation, like cutting out a wedge like so:
Fig 3. Second example, Surface cut. Cutting out a wedge using two surfaces (and this is where planes would cut through when it is important that it does not, because during operation they actually bend the intact bone (remaining on the backside) when closing the gap created by the cut) :
The reason why the last example must not cut through is that the remaining mesh is bent and analysed for making (real world) guides to be applied to the bone, both for drilling guides and other (brute force) tools used during the operation.
“Straight” edges along the cuts are important.
Edit: To sum up; Surface cuts would be able to handle “all cases”. The variants mentioned are only tailored approaches while surface cuts covers all possible cases. So far I think I can do with only flat surface cuts.
mec soft has a plug in called rhino 3d print https://mecsoft.com/rhino3dprint/ it has some very nice mesh tools. The boolean and splitting/ trimming tools actually work because they license a good mesh tools library. this is why it’s not free.
plus Uday and his crew are very helpful people. Give it a spin and see what you think.
As said, speed is seconday so far. But you can also try using the attached meshes in your tests, because this is what i am going to end up with processing anyway. They are made isotropic with, if I recall correctly, ~0.6mm or 0.8mm edge length. In any case, that will be a big difference to the original meshes. Moreover, these meshes are considered “bad” by Rhino’s MeshRepair tool, which makes them good test objects… < evil look >
Thank you for the tips @theoutside. In my case I can use only automation, that is, code control of all functionality. No manual interaction (other than possibly to guide the automated processes where to start or where to go).
I will “resort to” manual interaction only in such nasty tricky cases which my creativity is too limited to automate.
The end product is, in the best case, going to be a freestanding product (no funding involved though). And for obvious reasons limiting third party plugins is important. Especially compiled plugins are toxic due to software versions out of sync, aso. Full control of essential core functionality is very important.
I think this is spot on considering a few of what must be ‘easy fixes’ like the long time and reported a lot bug with splitting meshes that are disjointed with disjointed parts disappearing: https://mcneel.myjetbrains.com/youtrack/issue/RH-31155
This not being fixed is a clear example of even basic mesh operations not being a priority @ RMA despite a lot of reports and reasonable requests.
I’m sure there is a deeper core work to be done too to make it perfect with mesh booleans on more complex on not clean meshes, but we are still missing a lot of basics.
I did my part of convincing and listing the obvious shortcomings here: More Mesh friendly Rhino A few of them were addressed in V6 but still hope some more basic ones could make it to the V6 release so we don’t wait another 5+ years for the much needed improvements in that area. Rhino is well beyond NURBS modeler now and for a mature and versatile tool like that it is still surprising to see some basic problems and lack of mesh-related functionality.
@RIL - many times I would use MeshToNURB if mesh splits/trim fail - the chances of surface cutting commands working are much higher. Then convert back to mesh. In your case though with more dense meshes it most likely will not be a viable workaround.
Sooo… I am slowly getting results by splitting with a X value, but the intersecting faces I have to split one face at a time (it’s fully automated of course) as there are some serious bugs in the mesh intersecter when long, thin meshes are encountered. But it does handle them when dealt with one by one.
Wow, sounds interesting. I will definitely check it out. Thanks!
BTW, I couldn’t resist trying to hack a bit and at least try identifying the mesh faces intersecting a Surface, detecting only intersecting faces. This one detects also quads (blue), although they can be triangulated :
Clearly the goal here seems to be to get Rhino to do this stuff , however, if I read between the lines correctly via a quick read, you have a problem to solve too, correct?
To that end I opened the obj attached to the thread in the Fusion 360 Mesh workspace, and with one construction split plane ran Plane Cut, and - ‘lickity-split’…
Yes, I do have a problem to solve. Or many. But I need 100% automation, and different meshes, a zillion number of times (I’m designing an application). So I need to handle the splitting in code, fully automated. No manual interaction.
Splitting with a “vedge” sounds difficult, but a box I should be able to manage.
Here I did a test on my “proof of concept” code:
I just updated it to handle multiple objects, but it still only splits with one YZ-plane (pickable X-value).
(So right now I manuall rotate the objects for the Y and Z plane)
As you surely understand this takes time to develop so we should talk a bit on how to solve the business part if you are interested.
I live close to Oslo by the way.
I absolutely do understand. Unfortunately I have no funding for the project at this time so you shouldn’t spend more time on this for my part. The funding part may change after this year, and perhaps then I can consult you for some tricky meshing?
It would be interesting to meet you over a cup of coffee if I visit Oslo in the near future (I have two children studying there).
Small progress update:
The Proof of consept is almost there now.
Just need to fix a small intersection issue on large meshes where none of the vertices are inside the box, but the mesh is still intersecting the cube.
Remains to check for edges [intersecting] the faces?
I have done some experimenting with meshes as well in order to see what it takes to manipulate these meshes (I’m out in the wild if I don’t master at least the essentials). As a first step I could find the intersected faces. At pretty good speed at that (147 000 faces in this dense version mesh … with ~7000 intersections)
It remains to check for mesh faces that are so large that they extend from one out side of the cutting box to the other outside of the box. I check all faces vertices to see if they are either inside the box, intersecting the box by having one or more vertices inside and outside at the same time, or if they all are outside of the box. Then new meshes are generated and the others are split and joined to the correct parts. Hacky and slow (3 seconds), but it appears to be stable even on bad meshes.
edit: I only code in Python, C# is too much { } for my taste
A strategy could be to collect all faces\vertices inside long narrow “bounding boxes” along the edges of the Cutting Box (to reduce the number of faces to test), Fig 1.
… then, through the few collected faces, RayShoot rays based on the edges of the Cut-Box (something like "var ray = new Ray3d(ptA, ptB-ptA); ). That should capture the teasing faces along the edges as well as the nasty ones at the corners which has edges “circumventing” the Cut-Box corner edges (pictured) :
Fig 2. Intesection points from shooting along the edges.
I don’t know what optimization strategies you’ve used, but if you have not already done so, you could drastically reduce the number of vertices and faces to test along the edges and surfaces by using two extra “filter” boxes:
One box to be used as a “outer capture box” which is a little bigger than the CutBox, for collecting only items inside of itself,
and then an additional “inner exclusion box”, a little smaller than the CutBox, for filtering away most of the inner items. Then you are left with very few items to test for intersection along the edges and in the corners as mentioned in the prev post.
Perhaps there are even smarter strategies but at least this should work.
Haha, I wish! I am no hard core coder yet, but I know may way around Rhino and this is all about breaking it down in a manner so it suddenly becomes easy for Rhino to do previously difficult tasks.
