Sub-dividing trimmed cylinder

Hello, this is a development from another post linked here Thanks to Joseph_Oster who helped with that part of the script.

I’m looking to turn this trimmed cylinder to segments like in my image below. However my solution to dividing it is not particularly “elegant”. I use surfaces that intersect with the cylinder in order to get the divisions, but I feel like there is a better way. One that may also solve the problem of the missing panels at the top due to the curves changing from closed to open.

Any advice on a better method to go about dividing the trimmed cylinder like the image it would be awesome! Even a hint, I’ve got time to mess around with it.

dividecylinder.gh (26.6 KB)

Inserting List Item between SrfSplit and Srf SL (yellow group) is a mistake. The Srf SL cluster is intended to remove the need for a specific index value, which can change, and return the largest and smallest surface based on sum of edge lengths (which is faster than area).

SubSrf (your red group) works as expected, on the untrimmed surface, so your group label “Doesn’t subsurface properly” is incorrect. I used that in the white group.


dividecylinder_2021Feb15a.gh (27.0 KB)

If you don’t want curved panels, the yellow polylines can be used to get flat panels instead.

P.S. Actually, there is a problem with that… the panels near the opening are non-planar polylines.

Is it OK that panels near the opening are not planar?


dividecylinder_2021Feb15b.gh (29.5 KB)

P.P.S. Is this flailing? :sunglasses:


dividecylinder_2021Feb15c.gh (32.8 KB)

1 Like

Oh this is great! It’s useful to know I can split the surface to make the edge work. And I see you also show how to make them planar. Though I am actually looking to have the grid change according to the opening. So the more it opens at the bottom, the more condensed those rectangles are in each layer.

In the image I provided I was able to do this relatively successfully. My end result is how I’d like it to look (except for the missing panels). But I’d like to reach the solution better, as my method of intersecting the breps is not great…

Have at it. More panels (or is it shorter panels?) at the bottom sounds like an arbitrary constraint.

You could use plane intersections instead of surfaces.

Shorter panels. Which is a bit different than what you gave me? Perhaps using the word grid is confusing. It’s like each horizontal row is independent from the one above, but with the same number of rectangles. So their width decreases (they condense) as the opening gets larger.

Perhaps what you’ve shown me is closer to my goal than I realize. I’ll fiddle around with what you’ve given me so far and see if I can figure it out!

All your rows are the same height so the panels are not shorter at the bottom, they are narrower (have less width).

You can fix your model by adding a Closed (Cls) component as shown highlighted below:

There was so much I didn’t like about your code (TweenCrv) that I zoomed right past that.

Oops, yeah narrower. Yes, the closed component helps! Maybe I can figure it out from here.

Yeah my script is a mess :pensive: On the bright side I’m learning a lot from the feedback by reconstructing what is given.

The Tween Curves I don’t like either. This is also what I was hoping to get some help with. A better way to divide the cylinder without using the tween curves.

Yes, please! Here is a cleaner way (white group):


dividecylinder_2021Feb15d.gh (25.7 KB)

Again, the Srf SL cluster is more than helpful, it is a better way. It makes no sense at all to give it only one surface selected by List Item.

P.S. Oh drat, there is an off-by-one error in my code. :frowning: And using 7 or 10 for the Range input is absolutely bizarre!? The off-by-one error is easy to fix with Shift List but I have no clue why intersections are failing BADLY on the trimmed surface. It doesn’t happen using the original cylinder but that doesn’t help us. It happens with your model too.


dividecylinder_2021Feb15d2.gh (25.8 KB)

1 Like

Yes, I noticed the error too! I thought maybe it would reoccur with a different script. It has to do with the beginning of the opening. The closer it intersects to the top of that opening, the greater the strange error.

I think if I fiddle around with the different parts of the script I can avoid it. But it is annoying.

I’m glad I wasn’t too far off from your script. Seems I was on the right track, with the Brep | Plane being an important component I didn’t know.

Thanks for all the help!

@DavidRutten I believe we have encountered a significant bug here, using R6. We start with a vertical cylinder and cut an opening into it, centered on the cylinder’s seam (not sure yet if that is significant?).

Then we find horizontal rings using plane intersections. As you can see, some of these rings are wildly inappropriate depending on how many divisions are used, radius of the cylinder and the height of the opening. Applying ‘ShrinkFaces’ to the trimmed surface makes no difference.


dividecylinder_2021Feb16a.gh (30.4 KB)

@martinzanolli I went back to my original code from a week ago to make sure your version didn’t introduce any significant changes. It doesn’t. I noticed that you modified the Graph Mapper X and Y domains internally and recommend that you avoid that by reparameterizing the Divide Curve input to keep the ‘t’ values in the 0 to 1 range and increasing the value of the ReMap ‘T’ (Target) after Graph Mapper. I made both of those changes in this version.

P.S. NEWS FLASH! It does indeed matter where the opening is relative to the seam?!

I added the teal group at the top to rotate the opening ±180 degrees (slider in blue group), leaving the cylinder seam in place and it works fine at all rotations except zero.


dividecylinder_2021Feb16b.gh (35.9 KB)

This model needs cleanup work to create the opening better regardless of the cylinder base location.

1 Like

Here is a much simpler way to move the opening by rotating only the curve that cuts it.


dividecylinder_2021Feb16c.gh (34.7 KB)

What I discovered in the process is that it’s very easy to create an invalid curve by having the left-hand Bezier curve “handle” too horizontal and too long, which causes an extreme peak at the top of the opening. Changing the angle from horizontal and/or making it shorter widens the opening at the top and avoids the weird section bug!

1 Like

Awesome, thanks so much @Joseph_Oster

I hope the bug gets fixed!

I noticed that you modified the Graph Mapper X and Y domains internally and recommend that you avoid that by reparameterizing the Divide Curve input to keep the ‘t’ values in the 0 to 1 range and increasing the value of the ReMap ‘T’ (Target) after Graph Mapper. I made both of those changes in this version.

Got it :+1: