Grasshopper

algorithmic modeling for Rhino

Creating Multiple Surfaces from Collections of Polylines

Hi all, does anyone know how to create surfaces from a collection of curves/polylines such as in this example? I just want a surface to form within each branch whenever possible (these are building rooftops). Thanks for any tips.

Views: 1416

Attachments:

Replies to This Discussion

That's elementary my dear Watson (via the Dark Side, what else?)

Is the sample provided typical? Or there's the "usual" other type of cases around? (I'll charge you extra for that).

If no the C# ... written at once in 5 minutes [under a great frustration as the Mercedes plan against hero Lewis starts to roll (yesterday's F1 race at Spa: 52 places penalty for changing engine/gearbox whilst only 22 idiots were dancing > rather obvious "plan" I guess)] without any proper check et all ... could be yours as soon as I receive some goats (in good shape I do hope) and/or 12 cans of the usual stuff (sardines, what else?).

BTW: What happened with your C# adventures? Have you abandoned ship? Why? When? Where? 

Amazed as usual Peter, thanks. These samples are pretty typical, yes (all courtyards). Curious if there's an equally intuitive method using just the GH components? 

Well I've decided to stick with Python for now-- C# is something I'm still looking forward to further down the road!

Hi. Andrew.

This is my try with native GH, but I'm not sure this is of some help to you.

Attachments:

Thanks Hyungsoo, this works like a charm!

Hi Hyungsoo 

How did you put curves to curve component. at the first component. 

I just used Andrew's file posted above.

Here's the thing ...

... but in order to really shine (and expose the true power of the Dark Side) requires several tests more and some sophisticated report "capabilities" ... in order to deal:

(a) with any imaginable wrong user input [rather the norm I confess] and/or

(b) with more complex profile combos etc etc.

That said dealing with wrong/unexpected/freaky input is the true essence of programming.

Attachments:

Hi Peter, thanks, but for some reason this script is not working for me. I'm getting a "error: Object reference not set to an instance of an object. (line: 151)" error on loading. 

It works 100% OK here (with the provided "ideal" [internalized] data : otherwise why posting it? you tell me).

As I said many times: 1 line of code that does something requires 9 lines that check this, this (or that). That's the difference between 10 minutes of coding VS 100++.

Anyway ... provide the dataset that caused the issue.

In the mean time get the trad update that proves that the pink color is good for the Pink Planet (after Utopia turn left Math.PI/666.0).

Other type of (rather expected) oops moments:

1. Dupes, 2.Closable (but not closed) "final" (see code) profiles, 3. Shortage of cigars (critical), 4."Unexpected" polylines, 5. Loft failure(s), 6. Not "matching" final profiles (N of nodes) ... 666. ...

Attachments:

And here's the trad update (of the update).

Since the "general case" (get line graphs > make breps) requires "slightly" more than 100 minutes  of coding ... I've added a very important advisor that can safely guide you into the unknown: WHAT bike to buy? Forget roofs and similar stupid things > that's the most important puzzle of them all.

PS: Shown an oops case (but ignore it: life's short).

Attachments:

YIKES!

I was playing with the silly idea to write something to deal with case 2 (see def) ... and so I've reopened the def after a workstation restart> Armageddon > Rhino crashed AT ONCE every time > Adios Amigos. I've seen this happening when data are internalized.

Thus take the safe walk home: load the attached R file  first.

Additionally: what happens if curves are wrongly sampled into branches? Curve inclusion test per branch (or better: clustering) is a must I think - not included yet.

Attachments:

BTW: With regard that $#%$ line 151: The reason is that null check (happens when the internalize part fails) was not included (1 line or code requires 9 more ... blah, blah).

Do the following:

Load V1C without the R file > nothing is internalized > thus > nulls around (i.e. the polyTree is a bunch of nulls, that is) > def turns red and the notorious line 151 strikes back.

Now ... load V1D still without the R file > a grey def and a message that reminds you you that's time for that double espresso. There's an additional pass after that looking for valid Polylines (if not > time for a triple espresso). Note: in order to avoid a gazillion of "if this then that" ... IF a single non valid Polyline is found within a given Branch ... the whole Branch is removed (life sucks).

Good news: Notice that the bike advisor works in any situation (and this is what matters the most).

Attachments:

RSS

About

Translate

Search

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service