OK, that is going to be tricky to describe and perhaps to recreate but it has been with V5 from early stages.
the workflow:
I have a few polysurfaces which I convert into meshes.
321 meshes added to selection.
I run Command: _ShowEdges,
Found 234 edges total; no naked edges, no non-manifold edges.
I then Export to stl,
luckily i have the prompt active and get the error message that there open object in there. looking more carefully I find and fix.
I know you are probably going to ask me for a sample, but it will be of no use, when I open it in a new instance of rhino I cannot replicate the bug.
You are saying that you have good closed meshes in Rhino and the stl’s you export from them are open?. Or that at the moment of exporting Rhino tells you that one of the mesh objects you are exporting is actually open…?
----H
Please try _ShowEdges when multiple meshes are selected and the command is started eg:
Create two mesh cubes, select both cubes and run _ShowEdges. The commandline says: “Found 12 edges total; no naked edges, no non-manifold edges.”
It does not report the second cube. You had 321 meshes selected but ShowEdges command is reporting about one mesh only. If possible, you could join all into a single mesh before calling _ShowEdges to circumvent this.
Thank you for pinpointing the reason Clement. If i join the meshes it does address this issue, but I am going to hijack my own thread to bring into focus that joining meshes that are not in joining tolerance gives me new trouble…
In some of the plugins I use, ie RhinoGold, there are mesh entities that Rhino sees as Custom Objects.
If they join with other meshes or Custom Objects they lose their definition and don’t work as intended.
Is there a single reason that makes meshes join (regardless of their proximity) benefit Rhino’s functionality?
I need to remind you that R4.0 did not have this limitation.
Yes. Multiple meshes joined into one take up far less memory. This may not really matter if you only have a few mesh objects, but if you have thousands, it can make the difference between being able to open and do some work with the file or not. Rhino is also not the only program out there that supports disjoint mesh objects, I think.
Rhino 4 and 5 behavior is identical in this regard as far as I know. In Rhino 4 you can certainly join disjoint meshes into a single mesh object.
–Mitch
Oh, you are correct Mitch, sorry, I was thinking of R3.0s behavior regarding meshes. And you make a valid argument about memory issues when a very large number of meshes are present.
Still, there has to be a provision for a user who needs meshes not to join if they are not in joining tolerance. And no, filters cannot do this for me because i still need to select meshes while modeling.
Well, I’m not sure how easy it would be to write a script that would only join meshes within tolerance, I have an idea for a couple of hacks maybe… However, that would still not eliminate the command Join from also joining meshes out of tolerance if you select them with other objects…
–Mitch
@yianni OK, here is a script hack to try - will (in theory) join only meshes that are within file tolerance of each other. Drag and drop the script into Rhino, it will add an alias “JoinMeshesWithinTolerance”…
@pascal But perhaps a global switch “do not create disjoint meshes” is in order…
i´m confused now. Doesn`t your script join all meshes first and then all the custom user data and properties Yianni likes to keep is lost ?
I think it would be a solution if a script first tries to find the Tolerance (Distance) between the meshes he likes to join using Rhino.MeshMeshIntersection. Then if, and only if intersections are found, the set of meshes should be joined, leaving other floating meshes (and their user data) untouched.
The problem i see with this approach is that even then it becomes unpredictable which custom user data or property per mesh set is kept and which is matched by the join operation.
Yes, I said it would be a hack… there was no mention of custom user data or anything else, only that disjoint meshes are being joined. This is the fastest way out.
It certainly can be scripted differently. However the problem is that determining which meshes are close enough to to each other to be joined can be be computationally expensive (using the scripting tools available and my tiny brain). So I put forth this hack to see if that would be an easy way out. In reality this needs to be changed in the core of Rhino, everything else is just a band-aid.
–Mitch
No complaints at all. I was referring to what Yianni said in his second post, that RG seems to have problems once a custom object is joined with a standart object made in Rhino… it looses the definition. I guess that RG is writing custom user / object data per mesh which is invalidated by the join operation.
I would as well appreciate an option for the join command to control this.
Well, as I said, trying to find only the meshes that are close enough to each other to be joined is not completely trivial (unless my brain is too small to grasp the concept, definitely possible)…
It would require a recursive algorithm as far as I can tell - as there could be several collections of joinable meshes but that are separate from each other. As soon as something is joined it gets a new ID, the originals don’t exist anymore, so you have to recurse back and start over with the new joined mesh object… As I said, not trivial…
Hi Yianni- well, there were several things discussed - to get around the ShowEdges problem: SelOpenMesh and SelClosedMesh will help in cases where ShowEdges is being stingy with the truth. I can make a script for SelNonManifoldMeshes if that would help, though I doubt that is so commonly needed. That command (ShowEdges) is on the bug pile now.
As for joining and keeping user data… I’d have to think about that- not sure what is possible. Presumably two joined objects have different user data in the same keys… which one do you keep, assuming it is accessible at all?
Hi H, Yianni- Does the switch mean that rhino looks for ‘general proximity’ of meshes to within tolerance, or only open edges that are within tolerance? Do the edges need to match up?
SelOpenMesh will work fine until you are able to fix ShowEdges.
Mitch’s script would have worked just fine, if it was not for RG 's design / workflow. I will go bark at that tree for a while now
Thank you everybody for shedding light and helping in this !
I m not sure I understand the question exactly, but I think even general proximity would work for us, simply because the distance will deter joining and all would be happy !
Doesn`t your script join all meshes first and then all the custom user data and properties Yianni likes to keep is lost ?