intact_tibia.3dm (2.8 MB) Hi all,
I have a problem I haven’t yet seen a solution to based on various versions on the search. What I’m trying to do is:
Take this single mesh bone geometry, and if you zoom in, you will see that the ankle parts are connected to the shin bone by a single tunnel. There may be more tunnels when we segment these and generate meshes. So I tried slicing from the bottom of the foot with planes and trying to find the smallest surface area rings to cull, didn’t work since the tunnel was angled and was a larger area than most inner geometries. I’m not tied to the inner geometries so If there is a way to cull them, that might work.
I don’t have anything useful to share on the grasshopper code side besides what i described so i won’t bother sharing that. If you have any suggestions, I would appreciate it.
Hello
it is not yet clear what you want to do with Grasshopper.
Why not doing it with Rhinoceros ? What would be the use of Grasshopper ? If you want automatic mesh healing it is surely a long and specialized task. I have seen that @RIL is doing this kind of specialized job.
Yup, I want to do it automatic through GH. I am chatting with @RIL and wanted to get some more thoughts on it, in case someone had any ideas.
To be clear, instead of just physically deleting the tunnel, i want a more rules based approach. If it can be done in Rhino, it can be somehow done in GH. I just want a rule based on thin connection, mesh connections per area, etc to use for deleting it instead of visual confirmations.
This is 100% code territory. If you are familiar with C# (medium to advanced) and you can 100% deal with Mesh connectivity matters I could provide some indicative hints (but not a solution since the things that do that (cross fingers) are strictly internal to the practice),
As Plan B you can attempt to use the free MeshLab (but has many bugs meaning that it works when it works).
When in the practice (Monday) I’ll try to isolate Methods that you may find usefull. In the mean time since I don’t work with R6 a R5 file could help to isolate your issue(s)/goals.
BTW: I guess(?) that your issue(?) in general is (a) what to remove and (b) how to heal. For the latter see this simplistic demo (assume that the Polylines shown define Mesh “holes”).
Here you go. See the small connection between the two bones in the talsar. Filling the holes after the removal is relatively easy, I’m more concerned about the identification of small 5-10 triangles attaching to each other that I would like to delete. intact_tibia_r5.3dm (2.9 MB)
Bad news: Well … there’s hope (but I must re-check what is allowed to post and/or remove a thing or two or many)
Good news: Hope dies last.
Here’s a primitive demo using one of the many available (related with fuzzy AEC reverse engineering matters: reconstruct a plant from LIDAR data etc etc):
BTW: That C# works in 2 phases: the first yields “seed” candidate faces and the other recursively (depth via loops var) expands the collection. It shoots rays “inwards” meaning that is not affected by portions of “outer” faces being in a close distance,
That’s great, looks like exactly what I need and had in mind. I was tinkering with knn for very close edges, similar to I think what this is doing shooting rays from a neck. Hope you can share.
Removed things (the “critical” ones) and added various other (kinda like Windows 10: 99% of the stuff available is not the stuff that you need). I’ll post it when it appears that does some meningfull job (i.e. more tests required in this stripped state).
The general idea (shooting rays “inwards”) is OK (and fast) but the big thing is how to deal with what you get from phase 1: i.e. how the phase 2 recursive expansion (that would be an option) yields results.
See why the direction of mesh face normals is paramount (obviously if the mesh is closed and since we can inquire the orientation … blah, blah) so I added a flip option for open meshes (The first pic yields zero results since the Rays target Mars).
BTW: Have in mind that in real-life a fire and forget solution is a chimera. In fact we use a variety of user-assisted semi-automatic methods … but these are far and beyond of what I can post.
Update: Testing your mesh: the thing is a terrible mess (and that C# is written having “usual” AEC reverse engineering matters/scans). Is not oriented (and non manifold) meaning bananas results (and/or more or less unpredictable ones at least related with the recursive expansion that is using classic Mesh connectivity stuff):
Love the running commentary. The solution is exactly what I’m looking for. I think the one way to reduce bananas is to omit all internal features first leaving the outer mesh only. Any thoughts on that? I can do without the inner features, or even run without inner then add the inner later if I need it with a Boolean.
No I’m afraid: is useless for onion type of meshes like yours. Anyway … get the banana thing and don’t spend too much time by trying to discover the Holly Grail.
Here’s an indication on Plan B (a rather complex semi-automatic semi-interactive approach).
Imagine using a way to section a mess (i.e. a banana mesh) by locating visually areas of … er … banana spots. Then you get the related Polylines, you trim them at will and you define Intervals (from-to) that could yield unwanted faces in the same way that the first C# in the Clip demo does. Then you sample the face indices (into a HashSet) and do the right thing. Not automated stuff … but as I said in real-life we rarely use automation (until A.I. arrives).
a more realistic approach on the inspection goal is to define and control way more Clips than the one used. Notify if you think that a similar capability could be usefull to you (but that requires storing volatile data to a parameter (as persistent ones) and access them (via parameter’s nick name) before the C# re-executes … a classic interactive loop that allows to modify items in a collection on a per item basis … etc etc). That way you can store/delete/manage the Clips used in a Tree (as a history) and recall any combo suitable at later time.
Here’s using 9 Clips derived from a Facet Dome that engulfs a given collection (Imagine using, say, an icosahedron and attempting to modify a given Clip individually … this is what the volatile<>persistent loop is all about):
