I’ve stumbled across an unexpected behavior and am wondering if I am doing something wrong or missing an obvious solution. When I select the face of a polysurface and move it to be coplanar with an another adjacent face I would expect that MergeAllCoplanarFaces would simplify these 2 faces into 1. However, when I try this I get the response that there are no coplanar faces to merge.
Looking at the details of the object I see there are 10 faces although only 9 are visible in the viewport. My assumption would be that this would not mater inside of the MergeAllCoplanarFaces command, but I’m looking for confirmation on that.
Attached is a video and a model of what I am talking about. the model is of the final object that I would expect to be able to merge the faces.
Steps to reproduce.
draw a u shape polyline with all right angles.
extrude the curve as a solid.
select the face of one of the extruded ends.
using the move command move the wing until it is coplanar with the adjacent face.
MergeAllCoplanar command on resulting L shaped object.
Explode the polysurface. Right in in between the two faces that will not merge is a very thin surface that has 0 area. Delete that surface rejoin everything and the coplanar will work.
Thanks for the confirmation that I’m not missing any easier solution. Is there any chance that MergeCoplanarFaces would skip faces with 0 area in the future? It feels like a lot of work or a technical exception / disclaimer when using the MergeCoplanarFaces command. I’m asking for my users who don’t understand all the nuts and bolts of Rhino.
I believe it would fall under the push pull command, although the functionality to move the face by sub object selection has been around since before Rhino 8. The video in the original post shows how the object was modified into a state with a 0 area face. This is the primary way I see my users interacting with volumes in early building massing phases. I can try to teach around it knowing that this problem exists. At the same time it feels like this is in line with what push pull is intended to do.
Rhino8 reports that the object in your file is a BadObject.
If you turn on CheckNewObjects it Rhino will tell you when BadObjects are created.
Go to Options>General>Run these commands when Rhino starts and insert this macro:
-CheckNewObjects check=yes enter
This is probably when the BadObject was created.
Yes, its a bug but Rhino developers have created so many of these bugs in the solid editing processes it is doubtful the bugs will ever get fixed.
My preference is to avoid using such techniques. Its a lot easier and safer to just go back to the original curves (Undo or Delete) and construct a new solid from the edited curves.
@Wade_Vollink While I agree that MoveFace should check the result and remove these 0 area faces, I highly recommend to use PushPull for this type of work instead. Not only does it remove that face, but also merges these faces afterward automatically.
For the record: MoveFace does remove those 0 area faces in current WIP it seems.
Thanks everyone for your help I believe I’ve sorted this all out in my head! I’d like to give my lessons learned to wrap up and summarize this thread.
My main take away is that I should be instructing my students to use the PushPull command through the command line when desiring to manipulating volumes with snapping behavior or greater precision than the gumball provides.
I had a misconception that PushPull was synonymous with the cut/extrude functionality implemented directly on the gumball and had not explored the command directly. As pointed out through the thread, moving the subface to be coplanar is a bad practice and was causing invalid Polysurfaces with 0 area faces. The practice of moving subfaces came from my own learning days in Rhino 5, and while it may have been a convenient method for editing volumes back then, the new commands have made that old method obsolete / problematic.