Extract polybeam-crossections using sweep

Hello.
I have sweeped a crossection with a polyline as a rail-curve. Is there any way to extract the crossections at the kinkplanes?

If not, is there any way to extraxct the kinkplanes? I tried finding the tween-plan but it is not
100% accurate.

Polybeam crossection.gh (163.2 KB)

Geometry is far from the origin and LARGE, which makes it difficult to see plane icons.

“kinkplanes” :question: I probably did this wrong but the geometry is all there.


Polybeam crossection_2024_Jul5a.gh (21.1 KB)

P.S. This is probably overkill and maybe still not what you want?

The purple group derives five “kinkplanes”, illustrated by LARGE plane surfaces (PlaneSrf) because again, the size of your geometry makes it difficult to see plane icons.


Polybeam crossection_2024_Jul5b.gh (31.3 KB)

Here’s another, less intelligent and less rigorous method:


Polybeam crossection2.gh (171.9 KB)

I had initially started by trying to find the kink planes by finding the angle bisectors of two consecutive line segments on the polyline rail. Much easier, I found, was to pipe the rail and find the kink planes on the basis of the elliptical cross sections.

Unfortunately, using the planes to intersect with the Brep will not reliably capture the end profiles, and I down-right reconstructed the miter profiles from points so this won’t work if your railing profile is no longer a polyline.

I use mm in Rhino so maybe thats why the geometry is so large.

This was very helpfull, thank you! The optimal output for me would be closed polylines at the kinkpoints with the same defintion as the input cross-section. So I if want the same point (points that define the cross-section) in all the cross-sections I can use the same index.

By using project to plane with a given direction the definition of the cross-section will be the same. But I cant figure out how to use this repetitively without using list index multiple times. I will always need the last calculated polyline.

Polybeam crossection_2024.gh (26.9 KB)

Thank you for the help!

I had a follow-up question for joseph if you want to have a look :slight_smile:

What do you mean by “same definition as the input cross-section”? That the cross-sections at the miters have the exact same shape as the endprofiles? That is a geometric impossibility.

Or is you problem that the profiles do not start at the the same point in the shape relative to the rail? I am a little confused. Looking into your Grasshopper definition has not helped me understand either, unfortunately.

I believe what @Sigurd_Ostmoe wants is for the cross-sections at the miters to have the same relative start point and direction as the sweep section.

Not being able to see the plane icons due to the millimeter scale makes the task more difficult.

Yes. I assume so aswell. I will change the document units from meters to millimeters so that the scale is no longer a problem. I will scale of the model into meters.


Polybeam crossection_2024_Jul8a.gh (47.2 KB)

1 Like

Okay. Well, I was in the middle of it, but I don’t have your experience to solve it with such expediency. Was struggling with how to determine which curves to flip. I will look at your solution.

… I see. You made an interpolated line for correctly aligned perpendicular frames. Yeah, I was looking at the perp frames of the polyline rail. Those were no good.

Yeah, that gave me a lot of grief too. All in the purple group. The gray group culls duplicates, leaving 5 instead of 8. The orange group demonstrates segment selection.

I did that only to make the guide circles for Flip Curve. They are not the same as the miter planes but close enough for flip guides (in this case… :sunglasses:).

I didn’t understand how Rhino determines the direction of perpendicular frames, so I searched it and found a thread (I don’t remember where anymore) that explains that it is a combination of minimal rotation and something else. Since this is a building, I assume you could rely on the world Z-axis for determining the correct left and right sides of the curve.

Right. This one: Curve perpendicular frame orientation - #2 by diff-arch

Well, the main thing for this problem is that the pFrames all have the same Z-direction, which is basically the curve tangent at each point. Using circles as guides for Flip Curve has always worked well for me, provided they are on the same plane as the curve being flipped - or very close to the same plane.

Because Sigurd offset the cross-section profile from the XY-plane. :man_facepalming:

… I hate how Grasshopper applies blending on a Sweep. Because of this, the miter profiles always get chopped up into pieces instead of remaining a skewed, but whole version of the original profile. Like, I would expect the Pipe of a curve to have elliptical miters. But, no. Instead you get a series of “planar curves”.

@Sigurd_Ostmoe

To your remarks:

I don’t think this is possible without a plug-in that allows for loops such as Anemone, and the suggestion of using such a plug-in will inevitably draw the ire from users like Joseph, who find their use tabu when other solutions exist using vanilla Grasshopper components alone.

Since I have never used Anemone, however, I thought I would try it out. This is what your suggested approach would look like:


Polybeam crossection 5.gh (27.8 KB)

There is a benefit; namely that creating the section profiles in this way will give you true polylines instead of a collection of line-like and linear curves that make up planar curves. You could use these sections then with RuleSrf to obtain a body that has linear edges. As mentioned before, Sweep likes to do a little localised blending, it would seem.

I’m not following this but to clarify, I love Anemone! But I see no reason to use it here, as my post this morning shows. Is there something wrong with that solution?

Not at all! Works perfectly. The two solutions just produce different geometries, is all I’m saying. :slightly_smiling_face:

How can “different geometries” be correct?

OK, I looked at your latest using Anemone. Two things jump out:

  • Your GH file is 191.2 KB compared to mine at 47.2 KB.
  • Your curves are not internalized.

I don’t know why this was done :interrobang: Makes absolutely no sense to me.

Not being able to see plane icons at this scale is a very serious drawback. :frowning:

P.S. A ‘Perp Frames 3’ cluster :bangbang: :nauseated_face:

Mea culpa.

I have the geometry scaled in my version. Let me fix that and repost.

What is this?

Looks useless to me.

I copy/pasted the section and rail curves to see the code, but still - no point at all!