Thanks! I will take a look on that 
Hence my proposal for a limited preview consisting no more than 20 control points in either direction. Or, alternatively, set a minimum distance between control points (or a percentage of the entire patch surface, such like 5%). That will eliminate situations where the “Patch” tool tries to add a huge amount of control points in a small area.
Thanks . now I see that Patch isn’t meant for Class-A surfacing, but it’s still exciting to see how it’s evolving.
I will definitely play around more and post some examples when I see something interesting. Really looking forward to seeing what’s coming with the new surfacing tools!
Sure, but imo, THAT should be addressed instead. If the preview takes too long, you should be able to cancel the calculation.
That would work if the user requested cancellation is immediate.
I’ve added RH-89762 Patch: add a way to immediately cancel the calculation
Make sure to add an optional limit of the minimum distance between adjacent control points. Or minimum percentage (2-5%) of the entire length of the surface). That will prevent the tool generating a surface where 5 rows of control points are located super close to each other.
If you remember, several months ago we had a similar discussion about the “Blend surface” and “Match surface”, as well. They both tend to overly-build the surface, too.
thanks for these suggestions
RH-89834 Patch: limit complexity
Thank you for considering these improvements! This particular option could be a huge time saver!
I was not able to get to an appropriate result like the old patch could for this surface, and the new Patch just made a mess, but maybe I didn’t provided the right input to it:
What I really was looking for was the result I got with NetworkSrf, BlendSrf getting close too, and no patch variant got me this result. The issue is that with this technique I have to split the edge to make the NetworkSrf or the BlendEdge work, losing history:
(The Loft technique for soft round caps is too much work and won’t fit most cases I’m workin on)
Rhino Wip file attached:
Tube Patch.3dm (495.9 KB)
Tube Patch_SG.3dm (736.6 KB)
Maybe the attached helps, I created the patch with two helper points.
@diegodx
my guess your issue is related to:
@Gijs
puuuhh this is getting a really long and messy, big topic.
maybe closing it and tell users to start single topics for single aspects ?
Worked well! Faster than NetworkSrf. The new patch seems so powerful, it really needs to be deeply documented in the help file, or at least a video tutorial explaining what its possible when R9 launches. Thanks Gijs!
(Other than that, I could have used SubD like I’m used to, but this specific file is a shared workflow with a few dependencies that cannot support SubD at the moment.)
Imho, as a tool in the development state, I find it easy to find all info about the new patch in a single topic, rather than to hunt around for several threads.
I have an expansive Grasshopper sketch that started with the legacy Patch command and extensive surface point rebuilding. Shifted to XNurbs, quirky but productive. After a few false starts (the paid XNurbs $500, it ain’t broke, don’t fix it factor) with the ContinuousPatch, commited this month to integrating as test and quickly realized fully capable of switching over.
I am blown away. Incredible for my application. It gives consistent solutions where XNurbs failed and the granular control is very useful, loving the exploration. Has opened a lot more conditions of control.
Observation, in my application, the flexibility input has smaller variations through 0.1 to 0.7 to 0.9 and large effects from 0.994 > 0.995 > 0.998, natural maximum at 1.0
I can deal with this given a high resolution input, it just seems unusual.
Question: Can internal points be given weights? Either a single value 0.0-1.0 or a list according to the points.
What is the development alignment of the Grasshopper component ContinuousPatch vs the current Rhino command Patch?
Are they kept at the same stage in terms of features?
They will be aligned before v9 goes out. Are there any discrepancies that you would like to see addressed?
Thanks for the response.
I am using 100% the GH ContinuousPatch component, all day, everyday. 
Just wanting to know if it has all of the capabilities incorporated and the same algorithms that are (seem to be) being tuned with the Rhino command. Feels like more than the dialog is being worked on since my incorporation of the GH component.
To make it more apparent the depth of my interest, here is my workspace in progress.
The first screen below is my front end for the ContinuousPatch in GH, elements to be toggled in and out of the solution on the left side. Elements to be displayed lower left. Upper panel for the current Patch settings quick toggles.
Middle section for control of the input vectors, with the high resolution tuning legend for a physical dial box on the lower left.
Touchscreen interface.
Second monitor, the live geometry.
test patch.3dm (124.6 KB)
Hi, is this just my problem or are others seeing it too?
In the latest Rhino WIP version I no longer see the visible icons for G0, G1, G2 and I during the command activation.
I can’t select the edges or set the values anymore.
It’s a known problem that will be solved in the next WIP version.