I often see that the “Connect surfaces” tool does the opposite of what seems to be a natural output. For example, if I try to connect two surfaces whose considerably shorter ends I want to remove, Rhino opts to delete the longer ones instead. It’s kind of unnatural and leads to just hitting Undo and basically doing the job either with “Trim” or “Split”, because the “Connect surfaces” tool performed in its own logic that was not as intended by the user.
A preview and a command line option “Reverse” that is clickable after both ends are picked would avoid such scenarios.
My guess is that the developer was interupted by coffee break just when he was desciding which side of the remaning surfaces to keep as default…
// Rolf
My guess is that this tool was originally developed only as a way to connect two distant surfaces by extending both of them until they meet together. However, it works in an unpredictable way in situations where one or both surfaces already touch or cross through each other.
+1 for me.
this could be incredibly useful tool if developed a bit more.
should integrate sm of the extend srf function to achieve a clean cv layout after extension.
The part of each surface which is retained by ConnectSrf is determined by where you click on the surfaces when selecting the surfaces… The portion where you click is retained. Click on the side edges, not the ends.
Added: The current input system is consistent with the Connect command for lines and curves.
In general there are four, not two, alternatives when the two surfaces overlap.
When both surfaces don’t touch initially, the “Connect surface” tool demands to click on the nearest edges to modify and connect them where they eventually meet in the 3d space.
However, if both surfaces already cross together and I want to connect them with the same command, clicking on the exact same nearest edges produces an unwanted result. I find this kind of misleading, because in both scenarios the command prompt is “Select first/second surface edge to connect” while in reality it requires each of the opposite surface edge to be clicked in order to preserve it after the end of the operation.
That inconsistency of the command could have been eliminated with a proper preview, as I proposed above. It will also allow the user try the different variants before opting to end the command.
Hello -yeah… it is not ideal. In general for intersecting surfaces, click on the bits you want to keep, but along along the side edges not the edges to be connected, if you see what I mean.
It really should allow user input in the same way that FilletSrf does, not needing edge selection at all.
RH-58949 ConnectSrf: Input tune up
-Pascal
Thanks for the tip. It really needs just a little bit of a tune to become more predictable.
By the way, I noticed one typo in the text in your link: “ConnecetSrf”