If I backed the extracted curve and then manually extracted the border using the Rhino DupBorder command, the two curves look similar. But if I use the SelDup command in Rhino, I get:
”No duplicates found. Nothing added to the selection”.
Instead, if I extract both naked and interior edges using Grasshopper, I get 3300 edges, exactly as many as I get with the Rhino extractwireframe command. But now if I use the SelDup command, I get (as expected): Found 3300 duplicates. 3300 curves added to selection.
I can reproduce this by creating a randomly sized mesh plane in Rhino. I then select the naked edges, run DupEdge and Join to get the boundary.
For the second, duplicate curve, I simply run DupBorder like @ar00302.
Now, when I call SelDup, I also get No duplicates found. Nothing added to the selection.
I’ve inspected the resulting polylines a little and concluded that they might not be duplicates because their end points are different. In other words, when you manually select the naked edges, you might start at a different segment than the algorithm behind DupBorder. The vertex order of the polylines is the only difference I found.
The vertex counts of both curves are identical and each vertex from one curve has a corresponding identical vertex (within model tolerance) on the other curve.
Interesting. You are partly right. I tried this. From my first script, I extracted the naked edges without joining them. Then I manually extracted the border using the Rhino DupBorder command and then exploded it. Now the SelDup command finds all of them as duplicates, as expected.
But then I returned to my first script, where I extracted the joined naked edges, returning a closed polyline, and also extracted manually the border. Using the CrvSeam command, I placed the start points of the two closed polylines in the same corner, and using the Flip command, I ensured they had the same direction. Now SelDup doesn’t find anything. If I slightly move one of the two polylines and then bring it back, but using snapping, then SelDup finds one curve as expected.
I tried two different movements: one vertical and one 3D. The vertical-only move doesn’t return a duplicate, whereas the 3D one returns a duplicate.
I don’t expect this to be related to the document tolerance settings, as all these operations are with first-degree geometry where Rhino uses full double precision operations.
Now, if you ask what I am trying to find, take a look at this:
I am using both the border of the mesh to feed the boundary, and both interior and naked edges to feed the creases of Rhino.Inside.Revit into the Toposolid component.
I haven’t checked it, but what invalid has this mesh? I tried to model it as clearly as possible. Often have problems with Rhino meshes. When I checked them with mesh tools, I received a bad mesh. I really don’t understand. This mesh was created using only points with a 2m grid distribution. This distribution breaks only at the edges.
But I believe the behavior I described can be reproduced with another mesh. Also, the individual edges seem okay, but the problem appears to be from the joined curve. And solved if I move it in space and bring it back using snapping. It’s as if the joined curve is not in the same exact position as the individual segments. Very strange.
Yes, that’s also something I’m unsure how to solve. Sometimes individual faces of a joined mesh are flipped. A ‘rebuildmeshnormals’ command doesn’t solve the problem. I should extract these faces, flip the normals, join them back, and weld the vertices.
I am not on the computer right now, but I will try to reproduce the initial error using a Rhino mesh privative.
Here’s one more try in Rhino: Two rectangles with the seam / CrvEnd in different places. As long as the curves have the same segments, Rhino 9 WIP detects them as duplicates.
I just confirmed it myself. In Rhino WIP it works as expected — SelDup doesn’t check the curve seam. In Rhino 8 it doesn’t work unless you move it and bring it back by snapping. If you move it in a direction by a certain distance with the gumball, and then apply the opposite move again with the gumball, it doesn’t work either.
If you use ShowEnds to view the border curves created by GH and the border curves created by BupBorder, you will notice that their end points are at differenct positions. As a result, they can’t be selected by SelDup. Howwever, if you explode them and then run SelDup, you will find that it works, for your reference.
