Hi Martin, I had thought of that, but the shape of the Breps I need to connect doesn’t allow for that.
I really need to generate a surface based on the continuity of faces, and not edges.
By the way, I’m amazed that you could use blendCurve with a closed curve as input. It looks like some kind of hack, or there is something to BlendCurve that I don’t understand…
It’s funny you should be the one to mention this, because the first place I went looking for a BlendSrf component is Pufferfish, only to see it was cruely missing
Because I didn’t stop supporting R5 yet (and also I find it in general a tough thing to use parametrically, look at all those input requirements) I think @TomTom had a blend surface in his plug-in back in day.
Edit: actually that method is what @RIL is using in his component. Ive just always found that method difficult from a general user standpoint because selecting correct brep edges can be annoying and hard to predict. I also don’t think it works on trimmed edges.
By the way, I wonder why the “Brep Edges” component doesn’t output the edge indices…
In spite of the “Edges from” GH components which should allow to cherry pick an edge or set of edges, I also find that quite cumbersome, but that’s not a reason to try !
We just need smarter ways to segregate edges, or at least fix those that are buggy like the “Convex Edges” @DavidRutten ?
I wonder why the “Brep Edges” component doesn’t output the edge indices
If you use “Deconstruct Brep” then the order of the Edges output list would be equal to the indices. It would be nice if Brep Edges also output indices yes.
Can you post the geometry closest to the trimmed edges? I have no problem finding and blending trimmed edges, so the problem must be the Polysurface thingy, right?
If so it only means that one must look around and examine all adjacent surfaces and pick the edges that connect to the previous one and stop when arriving at the initial edge again.
That should be doable (I actually did something like that a few months ago). But just to be sure I know the real problem I’d rather test it on a slice of the geometry closest to the edges concerned in your picture.
My previous solution only really works on pipes. I created circular arrays of curves. Those are used as tangents for the blend curve component.
As soon as the surfaces you want to blend have corners, it’s a bit different. I closed your parts with 4-point surfaces manually since we need the normal of that opening.
Although Christmas is coming closer I’ve tried some coding, and grabbing the edges isn’t the most difficult part, instead I experience problems with the direction of the edges. Flipping the edges with the RhinoCommon commands doesn’t seem to do its thing, or at least I had problems with that part.
I want to integrate everything to make it as simple as possible to use the component, so I’ll have to work on this some more until I master the swappin’ & flippin’ of the edges so that BlendSrf can match both sides without the surface getting twisted.
The idea I’m working on is the user can either manually pick the starting edges (by edge Index), or the component makes guesses based on nearest naked edges.
The auto-edge-guessing is illustrated in the Gif below, in which the component has almost all inputs detached (including edge indexes). When two Breps (A & B) are connected and the EdgeA&B index inputs empty, the component immediately starts guessing. Also while moving one Brep around, the Component keeps trying to find new “nearest edge” to Blend against and… well, it’s shown in the Gif.
Fig 1. Auto-finding Nearest Edge-pairs when swapping Breps or simply moving them so the distance between Edges changes (Desired edges can be “locked” by feeding their indexes to the inport, but here Edge indexes are detached altogether):
I also made an EdgeFilter (helper) component (noty shown here) which culls away all non-naked edges so that one can conveniently manually pick among the few remaining naked edges. A “nice-to-have” thing when the Breps has several hundreds of joined/connected edges.
For example, in Osuire’s rather complex Breps (with hundreds of edges), the component traverses hundreds of edges and, filters away the connected ones, and finally it presents only four (4) naked edges to manually pick from (their indexes that is). The desired indexes thus can easily be picked and feed directly into the BlendSrf component’s input EdgeA and EdgeB (indices to the edges to be Blended). Searching of edges among hundreds of edges, like in a haystack, doesn’t have to be a problem at all.
But as indicated, there’s some more work to do before the more complex Breps/Edges can be properly rotated (Seams), Oriented (edge directions) and Chained (auto-traversing openings with multiple naked edges from multiple surfaces, like the square opening in Osuire’s Breps which has four edges from four different surfaces).
But now family calling. Merry Christmas to all of you!
(and also I find it in general a tough thing to use parametrically, look at all those input requirements) I think 
