Extract polybeam-crossections using sweep

That is from the original file from Sigurd. It isn’t necessary for the script.

I wonder if taking it out will reduce the file size, or if it really is the use of Anemone?

The file should now have the correct geometry so that the all sections are caught.

Nope. Still huge. The original file from Sigurd is 163 kB.

EDIT: Jeez Louise, how did I not see all that :poop: above the canvas ?!? File size now 16.6 kB Thanks for drawing my attention to that.

Yep, I just noticed that too and was about to say so. UGLY :bangbang: :-1:

Perhaps all those logos are necessary for his work?

To return to your question, though:

Sections made of polylines will only have line segments. The planar curves that your script produces are NURBS curves that look like lines, but carry with them all the extra information that the generalization of a NURBS curve needs to be defined. Perhaps it would be incorrect to say the scripts produce “different geometry”, and I should have said “geometry types”?

If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.

I’ve messed around with that Anemone code and am truly mystified by the part before the loop that derives the five planes? Baffling :bangbang: I finally got the idea but WOW, that’s weird!

Even so, I’m pretty sure you don’t need Anemone for this. Anemone may be required and appropriate when each iteration through the loop affects all subsequent iterations but I don’t see that being the case here, where all geometry is fixed.

This version started out elegantly simple, without the purple group, only the gray group. You can still see that by toggling the Value List (yellow group) to “raw”. But as you can see, fixing directions and seams was required so the purple group was added. Still, no Anemone.

The orange group is only to show the results, borrowed from this morning’s post.

Polybeam crossection_2024_Jul8b.gh (32.2 KB)


I’d agree. In fact, I am surprised that you and I are not on the other opposite sides of the debate: you arguing for the purity of geometry type, and me arguing it’s all the same. In the end, producing cross-section profiles that are only polylines will produce less overhead, and allow the user to select the profiles on the basis of geometry type, if that was a thing he wanted to do.

If you want to get the profiles by projecting the intial profile progressively through the section planes of the rail, a loop will be necessary, because as Sigurd said:

The intial profile can’t be used to project on all the section planes at once. You have to project the intial profile on the next section plane and use the resulting profile to project on the next section plane and so on. That is how “each iteration of the loop affect all subsequent iterations”.

To be clear, I am not arguing that you can’t get the section profiles without using a loop. I am simply providing the OP with a solution that complies with his suggested methodolgy. Personally, I would have tried to use the section planes to filter the edges of an initial sweep for the edges that make up a section profile. In hindsight, I appreciate how the method of geometry projection provides section profiles without have to reorient the section planes and flip the profile curves.

I have updated my script so that it creates ruled surfaces for each section of the rail:

Polybeam crossection 6.gh (44.5 KB)

The individual ruled surfaces are joined and capped for the final figure. This is obviously an inspiration from you.

:man_shrugging: :sweat_smile:

Yeah, it looks great! Shorter than the previous? Unfortunately, don’t have time to look at it right away. I’ve got work. But I will take a look at it when I get the chance.

1 Like

Ah, so. Thanks, it makes sense now. Still a weird approach though. :roll_eyes:
Good intro to Anemone, eh?

Here is a version that is different. The white group derives 5 “kink planes” (green group) solely from the rail curve. The middle three by geometric construction ending in Rot3D and the end frames from PFrame. The yellow group is a kludge that slightly extends the rail curve (by 0.1 mm) to ensure intersection by BBX. I don’t like to do that but avoiding it is cumbersome.

Polybeam crossection_2024_Jul9a.gh (35.6 KB)

1 Like

I will look at your solutions when I get a chance. Am very curious.

Move Sigurd’s original profile to the XY plane, and you can avoid this. I don’t know why it is floating a bit above.

Yes. I was excited to have the chance to do this.

1 Like

I used Planar to get its origin plane but it would be nice to avoid that minor kludge.

P.S. Good tip, I hadn’t noticed that, but extending the rail by 0.1 mm still looks necessary… :thinking:

On another project, I just discovered a setting for this: ‘Display | Preview Plane Size’

Default is 8, I increased their size 100 times.
Way better! (I know you already changed the scale of your geometry to see these…)

Yes, I know. I didn’t want to say anything earlier, because I assumed having geometry not at a scale where you can see Grasshopper’s default size of plane was some sort of personal peev. But that doesn’t make sense, because depending on the assumed units you’re drawing in, the default plane size can be too large or too big. Unfortunately, the Preview Plane Size is tied to the program and not to Grasshopper documents, so once you change the plane size, you will see this size in your other projects aswell. Sigurd shouldn’t drawn his geometry in millimeters in a document where the units were set to meters however, so it’s good that you took issue with the planes.

Ha! I like this. :grin:

Mostly because it shows me how to properly execute what I initially attempted. You should have seen the ridiculous acrobatics I was doing to find the angle bisectors of consective rail segments: creating spheres that intersected with the rail to get those equidistant lengths away from the cornerpoints… :man_facepalming:

At the end I feel I was pretty close when looking at the Eval component, but then I cheaped out and derived the section planes from a piping of the rail. This is more rigorous. With the pipe hack, it could be that the given rail has colinear consecutive line segments that produce a circle profile that the script would interpret as an end plane. Then the script would break down.

I guess to avoid the slider you could compare the two line segments adjacent to a corner and use the shorter of the two as the radius of the chord subtending the inner angle? Did you ever figure out why you had to extend the rail by 0.1 mm?

Is that because you are interpreting text? That part lost me. :roll_eyes:

Assume less. :wink: I have forgotten most of what I knew in life and don’t mind being reminded.

I’ve done nothing more on this as I have things to do that are more fun. :sunglasses:

No. The text searches for the difference between the circle profiles at the end of the rails and the elliptical curve segments to disambiguate between the mitering planes and the end planes. I don’t think it would break down because it interprets text, more on the assumption that sections the piping creates on the mitering planes will never be circles.

I get it. That definately looks like more fun! And there’s enough here for Sigurd to draw from, should he ever return. I wish I had cool things I am doing like your boat (?) that I could show you, but sadly I’m just a hobbyist putz’n around.

Me too. That boat has been a work in progress for almost 40 years :bangbang: The GH code in that image is only a small part the whole thing, which spans ~20 files or so. Only a dream…

This SketchFab 3D viewer is pretty cool:

This is so much more than i hoped for! Thank you both for multiple working solutions and alot of discussion around my problem :slight_smile: It is cool to see how different approaches can solve the same problem. Now I got a introduction to Anemore and looping in gh as well!

Much appreciated guys!