Curves on a polysurface

Hi everyone,

In the following example, I’m trying to create a curve from the offset corners of each face on a polysurface (one curve per face). It works on individual faces, one at a time, when specifying the face using the List Item component. I thought the next step would be to feed a list of indices persistently through the List Item using a Range component. However, this doesn’t work. The solution needs to accommodate a variety of numbers of faces. In the attached image, the left side is what I currently get; the right side is what I’d like to get.

I assume the solution probably doesn’t involve using the list item component. Are data tree components required? Any help on this is much appreciated.

Thanks,

cbass

Attachments:

Replies to This Discussion

Permalink Reply by Pieter Segeren on July 6, 2011 at 3:39pm

Yes, do learn about trees.

Attachments:

Openingsonpolysurface PSG.ghx, 97 KB

Permalink Reply by Pieter Segeren on July 6, 2011 at 3:49pm

Edit: I just read the title of the file, I missed the openings:

Attachments:

Openingsonpolysurface PSGv2.ghx, 117 KB

Permalink Reply by cbass on July 6, 2011 at 3:58pm

Thank you Pieter, I will take a look at your file when I get back to the studio.

The "openings" in the file title was premature on my part, though ultimately that is where I'm headed with this. I just figured if I could get by my current dillema, I might be able to figure out the holes on my own. Sorry for any confusion. I'll let you know how it goes...

cbass

Permalink Reply by Chris Hanley on July 6, 2011 at 5:53pm

I'm away from my GH computer, but i would think the following logic would work. (if all your surfaces are planar as shown in the example).

1-explode polysurface to get faces

2-explode faces

3-use average component, (from vertices of last explode), to get center point of faces

4-use a line component to draw lines from vertices to center point

5-use point on curve component to get points on lines

6-curve from control points, using points from point on curve, (set boolean to true for closed curves)

adjusting point on curve component should sort of "open and close" the opening.

Permalink Reply by cbass on July 6, 2011 at 11:47pm

Thanks for the help, Chris.

I hadn't even thought of this approach. It does work on the pyramid shape, though when applied to a box, the order in which the points are selected is skewed. I'm not sure how this would get resolved...

cbass

Attachments:

Chris' solution_1.ghx, 65 KB

Permalink Reply by cbass on July 6, 2011 at 11:50pm

Hi Pieter,

I just wanted to thank you. I’ve learnt a couple of things.

1-Creating planar surfaces from the edges is a great way to create planes that are in the same orientation relative to their parent surfaces. I had never thought of doing that (whenever I’ve needed a plane, I’ve always gone to the planes section and proceeded from there). Furthermore, at least in this case, it ensures that the offset is always in the same direction, making my clunky work-around obsolete!

2-I had never heard of the Discontinuity component before. That seems like a pretty simple way to get the endpoints of the curves.

It’s great to see such a reduction in the number of components you used.

I have read and done exercises using data trees in the past. Unfortunately for me, I have a hard time bridging the gap between the theory and how it is used in practical situations. It looks like you didn’t explicitly use data tree components. Rather, you kept the data as simple as possible.

One thing I need to start getting used to is when and where to use the List Item component. I keep thinking of it as a loop which only accepts one index at a time and this is getting me into trouble. It’s helpful for isolating behavior and for trying things out, but there doesn’t seem to be a straightforward way of replacing it with a persistent flow of data without some fundamental changes in how the data is organized upstream and/or downstream from it. I went back to your definition and reintroduced the List Item to see how different it is from your solution for comparison sake...

This helped me to better appreciate how the two approaches deal with data differently. You solution was relatively easy. I can imagine in more complex situations, it might not be so simple.

That said, I wonder if Hoopsnake may work in combination with the List Item to overcome its one-index-at-a-time limitation.

In any case, thanks again for your help!

cbass

Permalink Reply by Chris Tietjen on July 7, 2011 at 4:16am

Hi cbass,

Here using multiple indices with the List Item component without changing the upstream data.

Chris

Attachments:

cbassOpenings.ghx, 128 KB

Permalink Reply by Chris Tietjen on July 7, 2011 at 4:31am

For the Box.

Chris

Permalink Reply by Chris Tietjen on July 7, 2011 at 4:36am

But not limited to the box.

Chris

Permalink Reply by cbass on July 7, 2011 at 4:37pm

Hi Chris,

Fancy meeting you here :-) After seeing your first example I wondered how that might work with non-pyramids. Your last post took care of that.

Moreover, I'm blown away by what you did with the series component. I never realized that Series could pass more than a single branch of information. Likewise, I didn't realize that List Item's index could include more than one branch. I did try feeding List Items multiple indices in the past using Series, but not at multiple branch levels. The thought never even crossed my mind, and now I have to rethink how I use these components.

In the words of Hedley Lamarr (from Blazing Saddles): "My mind is a raging torrent, flooded with rivulets of thought cascading into a waterfall of creative alternatives". (taken out of context, of course, but you get the idea)...

Thanks!

cbass