I would like to find a good way to match surfaces in GH, considering that I’ve already a set of Edge Surfaces that have good quality and area single-span (starting profiles are made of two curves and a G2 blend). My aim is to match the mid surface to the others on the sides.
As shown in the pic below the current surface are neither G1 or G2:
How you built the surface is no different from doing loft with the 3 pairs…
Both of your starting curves are made by 3 segments of different degree.
It’s better if you create the loft of only the first and last pairs and then create a blend surface.
You can pick the blend script from here or here …
Your problem begins from false assumption.
Having continuity with the curves is not a guarantee the resulting loft will also have continuity.
Example:
What I meant to say was that I don’t want to create a single Loft that connects the joined curves, since the result would be a dirty surface.
I’m perfectly aware that G2 curves don’t create G2 surfaces and this is why I need something similar to the Rhino Match Srf to solve.
Your suggestion is good for this specific case (I cannot share what I’m working on, so I made an easier example). What if I have something like that and I want to match the red patch to the others?
although I have written my own, (incomplete) match surface component some years ago, I can clearly tell you that this is nothing trivial. Currently I’m not aware of a proper Grasshopper component.
And no, it is not sufficient to blend the edges with G2+ curves, creating a edge surface out of it. At least if you deal with double curved surfaces.
The challenge for surface matching is a bit more complex. A potential solution would be to match all controlpoint-aligned iso-curves in u direction, and then doing the same for the v direction. After that you need to interpolate those together by creating a “Coons” patch. However even with that, not all boundary conditions are always matching in tolerance, so you also need iterative postprocessing. And to output a clean surface you should also include a smoothing algorithm. As an alternative you could increase the control point density, but this is kind of cheating, because by lowering the distance to the edges to match, you technically decrease the error, but you worsen the surface to match. Unless McNeel is adding it to Rhinocommon, I doubt you’ll see a good solution. However in Rhinocommon you can at least blend a surface.
Matching surface edges is not a 1 shot operation and sometimes needs to be iterated over a few times. and usually includes some manual checking to ensure tolerances are met, I don’t really see the point of including something like that in grasshopper.
I would build everything I need outside of this step, and do this as post-processing.
@Aaron_Borin can I ask why you need to do this in grasshopper?
Well, it always depends on your profession and your requirements.
Until I switched to software engineering, I have automated the creation of complex patterns found in car exteriors and interiors. I created models up to production quality. Grasshopper is one good solution to automate this process. Usually within a professional context, these patterns are required to have quality fillets with cornerblends. Its unrealistic to get perfect blends at all places, as you said. But if you already place the surfaces at the right locations, you can indeed minimize the manual post-process to a great extend. In many projects, matching hundreds of surfaces, already at the right location, pre-matched, reduced the job of post-processing from 1-2 weeks down to 1-2 hours. During that time I had multiple custom surface tools, such as what Refit Trim does in modern Rhino.
I guess, with having all the surface tools of Rhino inside Grasshopper, you would definitly see more quality surface models. Instead people switched early to the less useful mesh representation, or never really produce detailed and quality surface patterns. I think Grasshoppers full potential is never being achieved, unless you see the full Rhino toolset integrated.
I agree with Tom. I think having the same commands in Rhino and GH should be the goal, pushing the package in a place that can compete with strong parametric CADs, such as Catia.
I’ve found that a nice workflow for design and design engineering (expecially if you have to deal with a client and you have to make several adjustments) is to create the basic / main aesthetic surfaces in Rhino, both Nurbs and SuDs are a good option. Then switching to GH… but yes, it needs some improvements.
