When trying to extend surfaces I sometimes get this message and nothing is done. I can’t find an explanation in the documentation or discourse. What does it mean and how do I get round it?
What message? Could you add screenshot?
could you upload the file or a screen capture?
Here’s a small part of the model that illustrates the situation. You get the message if you try extending the blue surface through the orange one.
ExtendSrfCollisionSample.3dm (232.2 KB)
However if you untrim the blue surface first then you can extend it, so the “collision” may relate to moving a trimmed edge past the untrimmed border. One for McNeel to advise on as the documentation does not suggest that should be a limitation.
Incidentally, if you try to untrim the blue surface edge all edges are untrimmed even when AllSimilar=No…
cant’t open r6 files yet but extending trimmed surfaces maybe is not the goal, you can try with removeEdge or rebuildEdges to get cleaner ones.
also applying ShrinkTrimmedSrf would help to further untrimmings going so far.
Other cause may be that the blue surface results in a bad object due to the trim boundaries.
Thanks for the suggestions Diego. I can’t find removeEdge in R6 (ReplaceEdge maybe?). But my goal is very definitely to extend the surface rather than clean up the edges - I want to eliminate the narrow gap between the current rim of the blue surface and the orange surface because it would be a nonsense to manufacture that gap. So Untrim or ExtendSrf are what I feel I need, but I suspect that neither are working exactly as documented (in 6.7.18190.21071) and therefore my not uncommon task is harder than it need be.
I’m hoping McNeel guys can either explain the limitations or fix the behaviour.
The message about “Collision detected” is incorrect here. What is happening is that the extension is failing. I’ll fix the messaging. I’m also investigating why it is failing in this case to see if it is a bug, or otherwise there is some reason for it.
Thanks Rajaa. Please could you also look at why Untrim applied to the same blue surface edge is affecting all the edges even when AllSimilar=No.
Untrim behaves as expected here. This is how Untrim AllSimilar option work.
In the image below with Blue face and AllSimilar=Yes, if click on 1 or 3, either all outer or inner trims are removed. If you use AllSimilar=No, then only the selected portion of the outer or inner trims is removed. This is predictable.
It is easier to predict an inner trim (hole) and remove only that hole. In outer trims, the way to recognize a connected trims to remove (the chip on the right of the blue surface, but not the one on the upper left), is by including all trims UNTIL hit a trim that is right at the edge of the underlying surface.
Now, in the red example, none of the edges of the face is on the boundary of the surface, and hence when pick 2, all boundary edges are included to define one loop to untrim. AllSimilar does not matter here because this is one boundary.
I hope this helps explain how AllSimilar options work. @KelvinC you might want to clarify this in the help.
Hi Rajaa,
Thanks for the clear explanation of what Untrim does. I’m afraid that I don’t find this intuitive. In the following discussion, assume AllSimilar=No.
When faced with example 1 I would expect an untrim to “fill in” the missing quadrilateral, and only the missing quadrilateral, regardless of whether the rightmost edges are at the edge of the underlying surface or not (assuming the edges adjacent to 1 are each single curves - if there are multiple segments on either side I’d settle for the extension going only as far as the curves immediately adjacent to 1 do because I recognise that there won’t be a universal solution to automatically handle anything more than this). A use case is that I need to fill in a notch that I have cut out - that is unaffected by whether the surface I cut was previously trimmed (in the model I am working on at present it is more likely to have been trimmed than not).
To handle more extensive untrimming, as in a situation with an edge adjacent to 1 being a series of curves, after selecting the edge at 1, I’d like Rhino to allow me to see the untrim’s extent indicated somehow and give me an option to specify how much further to go on either side, by picking successive curves.
When faced with example 2, if I pick the single edge then I would expect that edge only to be untrimmed and the adjacent edges to be extended to close the new surface. A use case is that I want to extend a surface to meet an intersecting surface that I just moved slightly.
I modified the description as below. Any suggestions?
AllSimilar
In the image above, the surface boundary consists of trimmed (red) and untrimmed (blue) edges. Holes are trimmed edges (green) that do not touch the boundary.
Yes
- Clicking on (a) untrims all red edges.
- Clicking on (b) untrims all holes.
No
- Clicking on (a) only untrims the connected red edges.
The red edges on the opposite side are retained. - Clicking on (b) only untrims the hole.
Thanks,
-Kelvin
1 Like
Seems crystal clear to me @KelvinC!
2 Likes
Excellent. Thank you Kelvin
1 Like
ExtendSrf should do that for you. (I realize it does not always work as in your example, but this is likely a bug and I am investigating right now).
Also, to fill a notch, does ReplaceEdge help?
I think the general suggestion is valid, and there might be an intuitive way to implement some edge chaining with highlight, and the ability to select specific trims, etc. That is said, I’m not sure if it should fall under Untrim. We have ExtendSrf to extend one edge regradless of ttrim conditions, and ReplaceEdge to fill gaps. @pascal might have some insights.
Hi All- I don’t, off hand see a way to logically make Untrim work consistently in case ‘2’ (red) above - that seems more in the realm of ExtendSrf. If I understand the request, the ‘side’ edges would need to be extended to the natural edge near 2, thus introducing new trims at the side - sort of counter to the command’s original purpose.
Currently we have -
Untrim
UntrimBorder
UntrimAll
UntrimHoles
ExtendSrf
ReplaceEdge
With all of these in the toolbox, we should be able to come up with a workflow, but the things that a user might want to do in any particular case seems so varied that it almost wants a more interactive tool or mode –MonkeyWithEdges.
-Pascal
+1 for MonkeyWithEdges 
Some rationalization of the tools in due course would probably be helpful
Hi Rajaa,
Yes, I realise there’s a functional overlap with the tools, and I don’t think it would matter too much where the functionality is implemented - maybe Pascal’s Monkey can subsume the others.
I’ll take another look at ReplaceEdge for notches, thanks for the suggestion.
Jeremy
RH-47367 is fixed in the latest Service Release
I am currently having this issue. Could the “fix” have been retracted in subsequent service releases?