objects with partially overlapping geometry - as example several unjoined curves (green) and one closed polyline (red).
Workflow:
Start Join and pick individual pieces of geometry one by one.
Observation:
When you reach geometry that is (partially) overlapping, Rhino will pop up the Selection menu even if one of the objects is not eligible for selection.
Currently, the ineligible object is too often offered as the first choice.
Expected Behavior:
Rhino checks eligibility on the fly and only offers the selection menu when two or more objects are available.
In this case, even if the red polyline was exploded into its individual line segments, I would expect Rhino to find out that the curve ends are beyond (2 x) the document tolerance of the green curve ends and NOT offer the red segments in a selection menu.
Why would the red closed polyline be offered as a choice at all for Join? I agree that closed objects should be specifically excluded from selection when running join - you shouldnât be able to pick them⌠I do this kind of filtering in my scripts when applicable.
I assume the current behavior exists not because of an oversight, but rather to inform the user that closed curves are ineligible, otherwise I guess they fear getting all kinds of support calls on âwhy canât I pick this curve to join?â
Looks like this is by design. The code that would make it behave as you suggest is there, but commented out. Iâd guess it is exactly because we wanted to let you know that closed curves donât work. The picking filter mechanism doesnât give feedback on what it skipped, so there is no way to both skip closed curves at the point of selection where the âchoose one objectâ dialog appears, and give a message that you tried to pick a closed curve. @pascal What do you think?
I suppose we could limit the potential confusion by changing the prompts to say âSelect open curve to joinâ, rather than âSelect curve to joinâ Same goes for polysurfaces.
I guess I just donât understand the âshow us that it doesnât workâ argument.
Also, the solution that is being offered now still will lead to an enormous amount of waisted time - for me - errr⌠something about a real user and real workâŚ
Itâs the recent discussion here about making it the first choice again to join curves that are far apart that finally made me report this issue. When 2 OPEN curves are partially overlapping, I donât want the one that obviously shouldnât join to come up in a picking selection eitherâŚ
Hi Wim - I think the first thing to do is just eliminate closed objects, other than meshes, from any consideration in Join, so youâd never get the âchoose one objectâ pop-up in your example with the closed curve. That will help some, right? Next would be to offer technically eligible choices in some useful order of likelihood - closest ones at the top. I suspect this is quite a bit harder but that would be the next thing to shoot for, right?
Trouble with that is that I think that my definition of that is not the same as that of others. I get it that Dan and Jørgen want to be able to work comfortably with sloppy (garbage) input curves but to go on and say that that shall dictate the workflow for all - I find that a great leap to takeâŚ
