Tensile Membranes test3

Well friends,

For test1/2 see:

http://www.grasshopper3d.com/forum/topics/tensile-membranes-test

https://www.google.com/url?q=http://www.grasshopper3d.com/forum/top...

And so we arrive to this test3:

A myriad of options, gates, modes, a paranoid C# membrane maker (to feed kangaroo), 2 Kangaroo engines, 12,45 bugs, 4.78 divisions by zero, a human figure that can't be internalized (use Rhino file), a chaotic logic, a heavily modified v5 version (that doesn't work).

Plus: one - traditional- invisible GH Component (makes sardines out of membranes):

What's not to like? he he

Mode "Mesh" is for no hole stuff (simple, fast and furious):

Mode "Brep+holes" is a bit more complex (and slower) - use it for holes:

Note: use named Views.

Note: full explanations about how to control the C# membrane maker in v5.

Note: forthcoming version v5 is far superior (for instance instead of a stupid rectangle you can define a vast variety of "boundaries"/"shapes" to deploy the whole thing, you can control what cone is inverted or classic, what cone is missing, you can vary high points individually etc etc etc) but ... hmm... there's "some" C# issues still unresolved.

best, Peter

Attachments:

Tens_from_random_polyline_v4c.gh, 621 KB
Tens_from_random_polyline_v4c.3dm, 119 KB

Replies to This Discussion

Permalink Reply by peter fotiadis on October 17, 2014 at 12:40am

Update :

Project abandoned for a while, then resurrected: V5 is almost ready: no GH components of any kind (except the Kangaroo related ones): just 5 (quite complex) C# scripts that do all the work. Variation possibilities are 100 times more than the ones found in V4.

Additionally: a totally new (and vary fast) approach to feed Kangaroo with a proper mesh (case: no holes) based on triangulation of anchor points. Here's a preview (StarlingStar is way inferior for "long" shapes):

Additionally: a brand new way to offset a planar polyline (convex/concave/anything).

Weak point : my "uniform" random point generator is a "bit" inferior to the one found in the PopGeo component (obviously a custom thing - written, most probably, by David).

I would be very interested to get some hints about the logic used (or in an ideal world ... er... some C# code). On the other hand, this is David's work ... thus why share it?.

more soon

Permalink Reply by peter fotiadis on December 10, 2014 at 4:29am

Update :

Project abandoned for a while, then resurrected: V14 is almost ready (but get the V10): no GH components of any kind (except Viz stuff and the Starling/Wb/Kangaroo related ones): just some (quite complex) C# scripts that do(?) all(?) the work(??).

Variation possibilities are 10000 times more than the ones found in V4 - but actually handling this def ... well ... no pain no gain, he he.

If however you fail to get the whole gist of the thing, just press Control+ Alt+Defeat.

Tip1: Handle with care (still WIP, lot's of bugs, 12.45 divisions by zero, 456.03 exceptions).

Tip2: Load Rhino file if you intend to use the blocks provided. Read comments inside def.

Tip3: Inspect captured images (zip) in order to get the gist of what's going on as regards the blocks and their parameters (values). These things are made far and away from Rhino: they are fully parametric nested feature driven solids imported as blocks. Since Rhino doesn't support any of these concepts/capabilities you can't have an interactive Top<>Bottom design flow (in Plain English: if you change the topology it's more than probable that you should re-create new blocks, sorry friends that's not my fault).

Other than that "little" Top<>Bottom thing ... the whole def is under a major reconstruction in order to allow (a) individual control of items in collections (Lists, Trees) and (b) allow "control slider" events to control "slave" sliders ... blah blah (creating "scenarios" of solutions, for instance).

may the (dark) Force be with you (and me), best, Peter

Attachments: