Hi there,
I’m trying to merge 3 surfaces into one. They share the same edge. Brep join not helpfull.
Any component for this ? Or will have to deconstruct them in order to rebuild one srf?
Thanks,
CC
I can’t open your file because it uses a plugin I don’t have.
Can you use plain Surface components to internalise the geometry?
woops, here it is
MergeFaces2.gh (85.0 KB)
it´s a precision problem. there are gaps
1 Like
Simple answer: The surfaces do not share edges, not exactly. Here’s a closeup of the top end of the join between surfaces 2 and 3. I have extracted the edge curves and moved them to one side for clarity.
The trimmed edge of surface 3 (with many control points) does not match the much simpler boundary edge of surface 2.
2 Likes
MergeFaces2_cheat_jvs.gh (101.2 KB)
1 Like
thanks both for point this out. I still clueless tho on why this is happening the way I built these shapes… curious.
@Jakob_v_Schirmeister thanks for the script, it work just fine. I just want to make sure to understand it properly: the tolerence py component is adjusting the tolerence of the whole RH and GH file ? If its the case, is it something to do ? I’m not aware of further issue it could cause, if there is any.
Looks like your inputs are on different branches. Flatten the input to your join component or simplify the input components.
no . in most cases you should not do that.
the script sets the tolerance of the current rhinofile. but in most cases we need to deliver precise data. so we need to model precise (change your geometry!)
the script proves here that the precision is the problem.
open an new rhinofile or set the proper tolerance in the file settings after closing the file with that script.
1 Like
Also this looks like a pretty simple surface. Can you not generate the upper and lower edges as single curves and make a Ruled surface between them?
1 Like
@Tom_Newsom I’d like to, but they are the result of a much bigger script. The trimmed cones are connected through a blend surface GH component (which has been made roughly).. I think this is the problem, but I have no alternative for this now..
I will try to rebuild the buttom and top curves and join them with the ruled surface for the final part of the script.
@Jakob_v_Schirmeister I read a bit about tolerance, but like you said, not a good idea to mess with this. Still I’m tempted to do so, because at 0.12 tolerance it works…
@grbl9789 input was flatten further on ;). But i’d loved it would have been the cause…
Thanks btw, learned more about the whole topic of working with surfaces 
CC
Given these objects come from a bigger script, I’ll skip questions/suggestions about how this bridge surface is initiated.
After checking a few options with what you have at the moment, a rather silly one is to generate tween curves between the two edges constituting the bridge surface, pull and loft, then join all breps into one - no tolerance-tweaking* required:
MergeFaces2_cheat_rc.gh (117.8 KB)
*of course the tradeoff is ‘losing’ the original bridge to this new one.
For that matter, a better ‘clone’ results from more tweens:
Just keep in mind it comes at a cost, above 20 tweens things can get a little slower.
1 Like
The solution is clever @René_Corella ! rebuilding the surface to make it tight.
And of course the main issue is how blend between surface been made (I put it in this GH file below). Actually there is no script in GH to blend surface as powerfull as it is in Rhino itself. I think its on the roadmap… So I have to use a script of someone else does to “bridge the gap”. I might have to dig into it further to see why the solution end up to be un-tight.
BlendSRF-MergeSRF_cc_v1.gh (262.7 KB)
Regards,
CC
1 Like
Ah - got it.
Interesting - I did imagine the connecting lines forming the bridge were some sort of blending or bezier span.
I’m glad you shared the file, this way we can look at things earlier in the process.
If we must modify the resulting shapes afterwards in order to regenerate untrimmed surfaces or other operations, then why not take care of the transition surface earlier via a FitLoft.
What do you think of something like this:
BlendSRF-MergeSRF_cc_v2-FITLOFT.gh (141.1 KB)
Re-making the bridge surface wasn’t the cleanest approach, and regular lofting won’t do. I thought this other way could be helpful. I’ll wait for you to report back.
NOTE (important):
I removed the python component for this version and set Rhino tolerance to ‘normal’ (0.001); reason: as long as you keep this python module within the script it will adjust Rhino tolerance on its own, affecting alternative operations that are both unrelated to that python component and also attempts to skip having to change the tolerance in the first place. I understand you were comparing methods in your file, however it’s best to keep these particular ones separate.
*Edit 2:
Regarding the ‘Nu’ input for the FitLoft component, you can just use a regular integer slider there to come up with loft adjustment, if you prefer. I did it that way to make sure I at least matched (or surpassed) the highest control point count from the isocurves.
1 Like
@René_Corella why I didn’t thought of this earlier ..-.-’ think I was to close into it to see it ahah.
it does the trick perfectly without buttering to join all these srfs.
Thanks very much,
CC
2 Likes
Most likely 
I think you’re still trying to extend this surface as another step in your project. I wouldn’t expect that extend to work nicely right off the bat with neither native nor custom components but maybe I’m wrong.
How much do you want to extend?
Trusting the fitloft approach, maybe it pays to return to ‘curve format’, use ExtendCrv then loft again?
2ExtendSrf_cc_FitLoft2.gh (138.0 KB)
As you know, too much extension yields problematic results:
So if you need to really extend this surface quite a bit, it might be a good idea to pursue another approach or some sort of soft deformation?
Cheers!
1 Like
I’ve just noticed that the tight-loft component is processing some sort of NURBS math that result in a slightly different shape that the original (see img below). I played with parameteres but without succes to fit adequalty the original shape. I also tryed with the normal Loft component and it fits the orginal shape but creates one open brep composed of 42 surfaces… so we’re back at the orginal problem: merging surfaces.
ill come back to this message soon to complet it
1 Like
I see - something I noticed is that you lose the top and bottom 'edges" of your surfaces after the isocurves. In other words, the isocurves component does not generate the top and bottom ones.
You can integrate these from the actual surface edges, but I’m afraid their directions will differ compared to the isocurves, thus causing a mismatch with the blendcrv. Looking into it.
1 Like
Yeah, fitLoft and regular loft are different. I skipped checking the deviation from starting surfaces because…well…time + laziness. I should have asked you first.
Cool problem(s), too time-consuming, though.
Speaking of, something’s odd every time I open your files. First it was that python thing tweaking the tolerance, then those clusters you’re using? Don’t get me wrong, I love Quan Li’s work, but I had to go even more vanilla by getting rid of the clusters for now. Perhaps it’s my PC only.
So, after checking one more time, I’m guessing the single untrimmed surface was a nice-to-have for your surface extension goal, but it conflicts with merging trimmed surfaces.
Maybe we’re better off going back to what we did earlier but correcting the missing isocurves issue. Of course you’ll run into problems again when trying to extend this puppy. Again, it might pay to modify the genesis of this whole ordeal so geometry can be a bit friendlier.
Sure thing - let’s pick ONE battle, then lol.
Here’s the thing back to two breps (trimmed) and a bridge surface (untrimmed) that we’re able to join via brep join into a single open brep without messing with tolerance:
2ExtendSrf_cc_FitLoft3b.gh (90.9 KB)
Best,
RC
Yes this is mysterious… I had that issue too. but its supposed to be fixed by now. [BUG?] Trimmed surface shows fewer isocurves - #17 by brian .
Also, your last GH definition is really good!!, thanks alot for the time spent on this… you definitly mastered this software. I’ve seen a bug that I will try to correct. For a curious reason, the first surfaces devided in U and V does not have the same # or crvs (even if processed together).
… I still don’t understand the behavior of fitloft. I made sure all curves are present (even top and bottom), all good direction… I double cheked but no chance here… I made a new topic for this. FitLoft solution deformation
Haha this is what I’ve been doing for couple weeks now, one battle after the other… but it never ENDS !! Its seems so easy, but at the end its so much little twist here and there.. But i will go on with this thankss so much for the help! learned alot @René_Corella . tell me where I can “buy you a coffee”.
Best
CC
1 Like