I have drawn a small wood shed but the further I got in the drawing I found more and more small errors. I realized this was the result of having used ExtrudeSrf at the end of some wood beams to make them longer. After doing that I used MergeAllFaces to get rid of the old isocurves. However, I still get snap on where the beam used to end, and also in the mid of the new extrusion and in the end of that. Since some beams were only one millimeter short I didn’t realize that I wasn’t snapping to the “old end” of my new and longer beam as I kept building.
I’m sure this is a noob pit that many of you have fallen in to. Hope you can share some wisdom on how to avoid this in the future. Thanks.
Try “MergeAllEdges”
A simpler way would be to select the end face (ctrl-shift pick) and move it. or MoveFace.
@Thestripper maybe even cleaner, if the objects are in fact extrusion-like, is testConvertToExtrusion on the extended object. Set DeleteInput=Yes and select one of the long ‘extrusion direction’ edges to set the direction.
-Pascal
Yes but, sometimes, you have to extrude the face to preserve other borders.
Would be good that the MergeAllFaces would merge all edges (when the face is replaced).
MergeEdges doesn’t do anything to remedy the situation…
Sorry but did you call MergeEdge or MergeAllEdges?
Here it works… can you post an example?
I see… It seems that the edge need to be rebuilded to solve.
I’ve selected the polysurface, exploded, RebuildEdges, Join.
Untitled_LZ.3dm (104.6 KB)
Selecting the edge still shows weird arrows after rebuilding edges… but the end and mid snap works correctly.
Here, when I extrude a face (on a simple polysurface) the edges merge without problems… (I mean, using MergeAllEdges).
1 Like
At any rate, this is currently not possible - see
https://mcneel.myjetbrains.com/youtrack/issue/RH-47066
-Pascal
1 Like
Hi Johan -
There has been a change in Rhino 7 in this area and I can’t force the behavior from scratch. Based on the YT issue that Pascal linked to, it appears that the fix was to the command that creates the geometry and not to any “merge” post-process command. To be sure if that’s the case, do you have the exact steps that are needed to create such object?
-wim
Thanks Lucio. I should have mentioned that I’m in Rhino 6 so I can’t open your edition of the drawing. So you can’t snap to those places -where the surface direction arrows are, but only to the real end of the small box correct?
Untitled_LZ.3dm (105.7 KB)
Saved in 6.0 format
I see that the osnap works correctly but the direction arrows are weird.
This problem could very well be a bug or poor software design decision done in Rhino 6 and has since been rectified. I am relatively new to Rhino so I’m not going to say anything bad about it yet. But extending one side of a box, perhaps many times, and then having to live with all the snap locations of previous geometry, that can only serve to cause havoc, seems very junior software development to me. I should have just used MoveFace instead. I learned that here today!
So what I did was simply that I used ExtrudeSrf at the end of a box… To make it look cleaner I used MergeAllSurfaces but that only cleans up the Isocurves, not the snap locations.
I second that. The redundant osnaps are gone and the current end/mid snaps are the actual end and mid points of the object. Not sure how you got the direction of the edge to show up. When I do Dir on the box it just looks like this.
Probably exporting to v6 forced the edges to reset…
Someone else with v7 should check to see if the arrows are displayed as there.
Hey Johan,
I opened it in 7 and there’s the same problem. I exploded the volume, rebuilt the surfaces and joined, which seems to work. ( I guess a screenshot is useless here)
In general I avoid “joinedges” as nearly ALWAYS you’ll have trouble afterwards with boolean operations and/or production. I’ts always better to rebuild a surface with border lines or something alike than to force things together. The cleaner every step is, the less problems you’ll encounter afterward.
ExtendSrf is very useful, but I usually make them much longer and cut a precise piece instead of extending to the good size. For the reason that quite often the edges of the extended srf don’t fit perfectly and force you to rebuild or “mergeEdges”.
if it doen’t look clean, it’s because it is not clean and mergeedges seems like a good “quickfix”, but it isnt for volumes. The best way is indeed as Pascal Golay described with the shift-ctrl-pick.
Sorry but I don’t think someone told to use joinedges… or I missed something?
Sorry but, again, I don’t get it… If I have a planar surface with a linear edge splitted and I want to get it back to a single one, I don’t have to use mergeedge because the resulting edge would be “Wrong”?
I always thought that the mergeEdge command simply try to remove the splits points to have a single edge where it is possible… something like untrimming the surface keeping trim borders, doing a SimplifyCrvs on those and trim back the surface…
Agree, the mergeedges was only to try to fix the polisurfaces already done (to avoid to go back to rebuild everything).
1 Like
Oh I didn’t mean to critizise your solution.
I rememberd there was something with Points being adjusted, but not the edge itself, which results in correct display meshes, but causes problems for boolean operations afterwards, but not sure if technically I described the problem correctly. it was about joinEdge and not MergeEdge. I was sure the problem would come from partially unjoined edges in his model combined due to the description he delivered with the extendSrf command and just quickly read your solution.
indeed, fixing fishy volumes “the easy way” will result in more problems later on when you create complex models. My answer was not very helpful to quickfix his problem, but to fix it correctly and to avoid problems if he needs to work on on this project or for future projects. I was trying to point more on that than to comment your solution.
cheers
Ben
1 Like
Thanks Benedict, now I underestand better.
I agree with your approach, I always try to have the curves very simple (arcs and lines) and extrusion in the same way.
From V7 I tried to give more confidence to the automatic commands inserted by McNeel but always checking if the final result has any oddities (isoparms in places where they shouldn’t be, not perfect meshes, incorrect Osnap…).
I think that the “old way” is always a good choice if something isn’t working correctly (I mean, extract borders simplify and rebuild)
Ciao 
Just to conclude this thread -
In Rhino 6, MergeAllFaces will clean up coplanar faces and their edges but will leave old snap locations in place. In Rhino 7, MergeAllCoPlanarFaces doesn’t leave old snap locations in place.
When “MergeAllFaces geometry” from Rhino 6 is brought into Rhino 7, MergeAllCoPlanarFaces will not get rid of old snap locations. You need to rebuild the edges to clean those up.
-wim