Sweep 1 Causing Gaps Along Polycurve

Hi all,

I’m trying to create a series of beams and columns for a old canopy. However, when creating some of the more complex details the sweep 1 component is leading to gaps within the geometry, the curve is sweeping along a closed polyline too.

I’ve also noticed sweep 1 causes a lot of issues, sometimes it works fine while other times I needed to use a custom #C script. I don’t understand #C at all, the custom component is extracted from a solution I’ve seen on the forums.

I’ve highlighted the script in blue for the specific area which is a issue is located:

GH Script: Structure.gh (80.8 KB)

That is a massive GH script that is difficult to read because of its size and redundancy of components rather than better use of data trees. Each branch of the Sweep1 components (four of them) is producing three open breps instead of one closed brep. I’m sorry you got this far before realizing that sweep wasn’t working for you.

Did you consider producing one of the white “arms” in your posted image and rotating it (Polar Array) to get four? For that matter, did you consider producing just one of these pole structures and then copying it (Rectangular Array) to get the 36 you need? The code would be so much simpler! Easier to read and maintain too. That’s the best advice I have for you. So much redundant code is not “The Grasshopper Way”. Keep it simple!

1 Like

Thanks Joseph, I’ve still very much a novice with grasshopper and appreciate the criticism! I sometimes come to a conclusion in a inefficient way, let me try to clean up the script to align with your suggestions

Please study this code. I produced it in the crudest possible way…

  1. I baked these squares at the top of your poles and measured three dimensions in Rhino.

  2. I internalized 36 planes you used to make them and copied that param into a new GH file.

  3. I moved the planes down 1/2 of their thickness because your sweep method assumed the planes were centered in Z and I wanted them at the bottom of the squares.

  4. I recreated the square “box beams” using a simple, reliable method.

box_beam_2023Feb10a.gh (11.8 KB)

1 Like

P.S. Additional comments based on a quick overview from 10,000 feet:

Can the “Define Lighting Glazing” group be replaced by very simple changes to the code I posted? It looks like the bottom surface of those square beams will be lighting panels?

You are using lines (division or endpoints) to get points and planes instead of defining them directly. And using scale instead of actual dimensions. There are better ways.

Somewhere there must be a base plane for this whole project because everything is rotated ~45 degrees from the usual World XY plane? I see you know about Plane Origin so that single base plane could be referenced in many places. That should be more obvious in the code.

Pull Point? Why?

The planes for the columns are the same ones I used for the squares, except for their Z positions? That isn’t obvious in the code. Better to move them vertically instead of using Plane Origin again.

The “Create Rectangular Beams (Canopy)” group looks very similar to the squares I posted, except for their dimensions and location. Ditch the C# sweep bits.

Overall, the geometry of this project is rather simple. The code should be too.

1 Like

Hi Adam,

You have demonstrated a good understanding of GH to get this far. I am fascinated by the project and keep looking at it, learning more and more about what you have done in this script. I decided though that before giving you more advice about how to keep code simple, I should first address the sweep problem that caused you to start this thread. Unfortunately, when I work on that in depth by focusing on just one of the four “arms”, my brain soon gags on the needless complexity of the GH code.

When I see code patterns like this, and there are many of them, my brain freezes. In part because it’s so difficult to modify one thing without affecting many unrelated things and in part because I know that whatever I do for one branch of the data tree must be repeated manually four times.

Another irritation, though not so much of a show stopper, is the many labeled groups that spread the code out on the canvas. This requires frequent moving of the canvas to see where wires are coming from instead of a complete logical block on one screen. An old rule of thumb in programming is that functions should be no larger than what can be seen without scrolling. Also, when zoomed in enough to work in GH, this sprawl covers the entire screen with groups, making it impossible to right-click on the canvas. Fortunately, double-click to search and the mouse scroll button still work on groups, offering the same options as right-click, but habits are hard to break.

Two more issues related to that last paragraph when groups when groups cover the screen:

  1. You can’t click anywhere to deselect all without selecting a group.

  2. Alignment of components is more difficult because you can’t start a selection rectangle outside of the group; each component to be aligned must be selected separately. That’s a deal breaker! :frowning:

End of rant, back to work… Aargh! I cobbled a fix using that C# sweep thing you had, setting ‘List Access’ on the ‘shape’ input so it handles a list of sections. At first I saw some bizarre results that I managed to filter out, leaving what you want. Later, after clustering it and replacing all four copies of Sweep 1 with it, I noticed that alternate rows were missing geometry. :man_facepalming:

Spent a long time looking for why… Found that two sets of rails had their start points opposite of what was expected so applied Flip Curve to them, with no apparent effect. Finally discovered that it was the garbage cleanup I had added inside the cluster that was responsible for removing alternate branches (as originally intended to remove the erroneous artifacts coming from C#).

Looked again and found there was no garbage anymore! But two rows were tapered in the wrong direction, starting small at the column end and ending large. :man_facepalming: So removed the flip curves I had added, cleaned out my diagnostic bits and got this:

Inside the cSwp1 cluster: (I moved Cape Holes inside it)

Structure_2023Feb11b.gh (85.1 KB)

It’s still a sprawling mess by my standards but I touched as little as possible, for now.




1 Like

I hope you are still keeping up?

If you disable preview on the columns and examine the top and bottom of where these “Diagonal Beams” meet, you will see some anomalies - they aren’t all the same. The red one in these images is from the first sweep group. The green one is from the third sweep group:

Two ways of dealing with this leap to mind:

  1. You can trace back through all the code and locate the reason(s) why they are different OR…

  2. You can create a polar array from the first one and discard all the unused bits.

Naturally, the second option appeals to me. It’s REALLY EASY! Just one component, ArrPolar (green group) using the same planes as the columns. They have to be grafted to match the data tree from cSwp1. Done! :sunglasses:

The result is beautiful - all the same meeting precisely at the center point.

I deleted unused components only within the “Construct Diagonal Beams” group. I didn’t want to go further because, you know… rat’s nest! The parts that still have unused points are in yellow group.

There is still a lot of unnecessary code in this file, but significantly less than before. A lot more would disappear if I replaced the “Create Rectangular Beams (Lighting)” and “Define Lighting Glazing” groups with a slightly modified version of the box_beam_2023Feb10a.gh code I posted yesterday.

Structure_2023Feb11c.gh (76.1 KB)

P.S. The forum software munched the 619K .png image of the canvas, you can see it here:


Hey Joseph,

Sorry for the late reply, I’ve been updating the script to align with your comments, it’s been extremely helpful! The overcomplicated areas have been refined and I’m sure there is still a lot of potential to further reduce complexity.

As for the project, this is a very small part of the overall scope. However, one of the goals I want to achieve out of the scheme is to learn grasshopper.

I’ll try to answer the questions you’ve been asking:

  1. Polar Array was the correct suggestion, I have a bad habit of using list item to brute force the result I want which I need to stop doing.

  2. Rectangular Array didn’t really work to further simplify script. I’ve already got a set of curve parameters which allow me to refine and adjust the column constraints which Rectangular Array doesn’t achieve.

  3. Your first script your sent was very helpful I was able to simply to rectangular beam and lighting detail

  1. Pull Point was used because the column heights are fixed, so I just selected the top point of the column and pull them down to the ground plane in order to extract the extrusion length.

  1. The duplicate Plane Origin was removed and replaced with the Move component you recommended

  1. As for the organisation of the script it’s more for me to keep track of what’s going on as I’m learning while creating the script. I can see why the labels are confusing for someone who isn’t familiar with the code and went a bit OCD about not crossing wires too much, I’ll attempt to density the script next.

  2. Sweep 1 seems very temperamental, but maybe it’s my lack of understanding to realise the error the component keeps producing. Sometimes it works, most of the time it fails. The C# solution is unfortunate, as I want use only grasshopper components to understand what’s going on, but it’s okay this seems to be the best option when overcoming this issue.

Again, I greatly appreciate the effort you’ve gone through, it’s always insightful!

I’ll post the adjusted script for anyone who wants to take a look.

GH: Structure_V2.gh (70.7 KB)

1 Like

I may not get to your code tonight but will reply to some of your points.

YES! Grasshopper is very powerful about working with data trees, as long as you keep them organized and always know what is coming out of and going into components.

From what I saw, that code did 95% of the work of both groups since the bottom surface was a freebie in what I wrote. I had looked forward to integrating it myself because so much was already done.

Nearly useless, in fact. Do you realize what you just said there? That labels only make sense if you already know the code… so why bother giving them such prominence? I use groups with text labels but am not dogmatic about it. More than the labels, what bothers me is having the entire screen covered by one group, for several reasons that I mentioned. Small blocks of code that can be seen in their entirety with zoom level at 100% is the way to go.

Yes, Sweep 1 is very temperamental. I started down a different path to replace it but then realized that those beams are tapered so looked again at the C# thing. It’s only one line of code so I don’t mind because it worked fine after setting ‘List Access’ on the ‘shape’ input . Don’t worry about it.

You have the aptitude for this, not everyone does, so keep up the good work. I might have comments on your code in the morning.

Less Code Is Better Code.

By that standard, your V2 file is an improvement, though I don’t think it goes far enough. To some extent, programming has always been a matter of personal style. For me, less code applies to screen space as well as number of components in GH. That’s why I don’t use ‘Display | Draw Full Names’. After making a mess while coding, I get rather OCD about component alignment to tidy things up but don’t care much about crossing wires (I hate relays because you can’t preview them.).

Your style of HUGE groups that cover the screen at 100% zoom doesn’t work for me, as I’ve already explained. BIG LABELS only make that worse and I usually ignore them anyway. I have various methods for analyzing code that don’t depend on massive groups and labels. Remember that GH occupies only half my screen, with Rhino in the other half so I can see the geometry produced by each component or group using “Only draw preview for selected objects” mode.

Other analysis techniques include temporary text panels to view data trees, a ‘Tree/List Viewer’ tool I wrote myself and components to color branches and lists of geometry. All found here:

Here is an update to the simple box_beam_2023Feb10a.gh code I posted on Friday. This version replaces two groups in your code:

  • “Create Rectangular Beams (Structure)” and
  • Create Lighting Fixture"

box_beam_2023Feb12a.gh (18.7 KB)

Yours is 4968 X 926 pixels, mine is 787 x 599 pixels at 100% zoom. Which is easier to understand and modify? Here it is integrated into your V2:

Structure_V2_2023Feb12a.gh (76.4 KB)

By the way, I recommend that you rename sliders instead of relying on HUGE LABELS.

There is much more we could discuss about how this model derives points and planes from ten hidden “Canopy Boundary” curves (imported from Rhino?). Rectangular Array isn’t the only option for making grids, Orient works very well. But this is enough for now, eh?

1 Like

Hi Adam,

I started puttering at the beginning of your code, the hidden “Canopy Boundaries”, creating a “Master Plane” (white group) and a grid of column planes on the ground (Z is up instead of down :wink:) from them. One thing led to another and I ended up with substantially new code. I was very careful to match your V2 results by baking V2 and comparing my new V3 to it. It’s way easier for me to understand, though you might recoil at the tightly bunched code. It won’t look good if you ‘Draw Full Names’ so please don’t.

It’s still a big, sprawling canvas (4012 x 1263 pixels) but the groups are not tall so even at 100% zoom, it’s possible click the canvas above and below them, which makes selection for alignment easier. The important stuff is the code itself. Even if you don’t use it, I hope you’ll give it a look.

The five components in green groups are the bits that need to be baked.

Structure_V3_2023Feb12c.gh (63.7 KB)

Click the image twice to see it full size.

1 Like

Hi Joseph,

Sorry for the late reply I have a PC issue at the moment, so haven’t been able to check until now during work! After reverse engineering your script I’ve learned a lot! Again, I appreciate the extra effort you’ve gone to!

Wired question, but is there anywhere you can post completed scripts to be reviewed, critiqued and receive feedback? I want to improve, but it’s hard when resources are so scattered and have a very limited knowledge.