Wow! Amazing!
If you notice, I don’t know why it happens — sometimes it does, sometimes it doesn’t — but there is a slight delay between when I click on an edge and when the G0, G1, G2 icon appears. Rotation also slows down, as does the Patch start-up screen… sometimes it’s choppy, other times it’s perfectly smooth.
I see this lag as well.
After a fresh start it is a little better, but comes back.
Please find a more in-depth topic on G2 matching in the Patch command here.
Where is the Trim option now? It was there in the beginning…
About the Starting Surface.
I think this belongs to the UV category.
So why introduce another collapsible category?
And, if really wanted, I think using 2 different words for the same thing is irritating.
“Eingabefläche”, “Startfläche”
Same in English.
We removed it.
I agree it makes sense to move that
RH-92621 Patch: move starting surface to UV control
why was the trim command removed?
simplification of the UI. We gathered you would want to trim 99% of the time.
The isocurve layout, derived from a starting surface, is not as good as in the previous version.
In the marked region it was more straight, it followed the starting surface better.
Starting surface:
This is with (9.0.26055.12305, 2026-02-24).
2026-02-27_WasBetter.3dm (1013.1 KB)
To test, move the starting surface using grid snap to the other geometry before.
EDIT:
When I rebuild the starting surface with to 70 U points, the patch looks better:
What? On seeing that image my mind goes:
Who the f**k uses patch like that??? 
That’s one heck of a stress test you give it Charles, I like that though, it’s great for finding and setting boundries for what the tool should and should not be able to do.
Everyone who wants to create troublesome geometry 
In this case it’s a test regarding isocurve layout.
I know a patch using vertical walls needs more input…
But Patch shouldn’t choke on this.
PatchOld at least gave an ugly result immediately.
2026-03-05_Choke.3dm (112.5 KB)
We have this on the list as RH-88315 patch fails on this simple surface (vertical surface)
…you blowed it up…
(should read as a compliment ;-D)
Just curious how the new “Patch” will handle making a button from these vertical extrusions named “1” and “2”. Preferably G2. The point is a target height for the tip.
Test patch.3dm (1002.9 KB)
how did you create this geometry? you have somehow rotated UV directions when i create a circle from scratch with the point it works, but with your geometry it fails.
this is what you get with a circular extrusion that i used a new circle as a basis for.
you can play with the stiffness but i am sure you have figured that out since the file was a v9 already you should be able to test it yourself or did i miss something?
the result satisfies g2.
but it seems to have an issue with oval shapes in general. as soon as i create an ellipse and extrude it fails. also when i resize both the circle then extrude or the working circular extrusion along one axis patch also fails.
Test patch.3dm (750.9 KB)
It was a basic cylinder, but I extracted the flat faces and deleted them.
In another is topic, there was a discussion about the flipped U/V directions depending of how a cylinder is made. Rhino’s lightweight extrusions also get flipped U/V.
How was the file V9 already? I created it in Rhino 7.
What about the scaled version of the pipe? Was the “Patch” able to make a button from it, since it should work with vertical extrusions now?