I’m struggling to find a way to get the surface associated to those closed curves.
Tried “Boundary Surfaces” component but not working (I guess because the curves are not planar).
Tried also “Patch” component, but it patches in a very weird way (which I don’t understand, can someone by the way enlighten me on the way this component works?..).
Do you guys have an idea ?
HI Valentin -
You didn’t post your .gh file, but from the looks of that image, the curves are the result of a projection / intersection with a polysurface. That means that you should be able to split the surfaces with those curves to obtain what you are looking for.
Wim’s suggestion is great, especially if you need to keep properties of the projected surface.
If you don’t need an strict adherence to the projected surface, it looks like you have all the elements for sweeping 2 rails, with the short edges being the cross sections and long edges the rails.
This may give you a “simpler” surface to do further work with down the pipeline. Depends on what you need to do with the created surfaces.
Simplified: Explode your curves, sort into long and short edges, sweep 2 rails.
You could also use the long curves to creat a new surface with the ruled surface component or loft but for a bulletproofed solution it would be great to have your script
Thanks a lot for your answers, and sorry for my late reply.
Here is the .gh and the .3dm associated.
Test part.3dm (610.2 KB)
Programmation V3.gh (83.1 KB)
I understand your strategies, but for Wim’s, the issue is to be able to automatically extract only the inner surfaces of the curves and not the outer.
As for Rahul’s one, I’m having issues to extract only the corner points. I tried with the derivative component, but I get more points than only those corner points…
I didn’t include these in the file in copy, but what do you think?
You can use the Split Brep Multiple component, then cull the item at index 0 of the output to get the result you are looking for.
Note: The Split Brep Multiple component takes some time to get a solution (~22 seconds on my old computer).
Programmation V3_re01.gh (86.5 KB)
References the Rhino file you uploaded:
Thanks @kev.r, but what I get are BREPs, and I need surfaces (because in the end, I’m getting robot trajectories from the curves, and I need local surfaces to compute the normals for the robot orientation).
I still need an extra step
Programmation V3_Loft.gh (248.7 KB)
@valentin.bonneau Hey, hope you’d managed to figure out a workaround for this problem.
Here’s a rough, hacky way of going about the problem.
Separated out the curves you had generated according to an angle based change in direction of the curves (not a great general solution, but works in this case) i.e. any segment that changes direction more than 66 deg relative to the previous curve segment defines where the corner is. You can play around with this parameter and improve.
The curves are then rebuilt, in this case with 200 points. The curve is therefore, not a perfect intersection of the surface, but you can pump up this number to find the right compromise between surface “complexity” and accuracy.
The long curves are lofted, leaving you with an untrimmed surface which should give you some good normal information. Again, all of this is approximate, so you will have to make the call about whether this is good enough for your application.
Hope this makes a dent in the problem.