Catenary Surface with attracting points in the middle of plane?

I need to make a surface that hovers over a landscape and then reacts by following individual points int he middle of the surface and contacting them at the ground level. How do I do this? My previous attempt have been disappointingly fruitless.

Replies to This Discussion

Permalink Reply by peter fotiadis on March 27, 2016 at 8:32am

Like this?

Attachments:

Surf_follow_V1.3dm, 113 KB
Surf_follow_V1.gh, 127 KB

Permalink Reply by Alexandra Foster on March 28, 2016 at 11:39am

Thanks so much Peter!

This is awesome! It's not exactly what I need, but maybe you know how to create something that looks a bit like the following?

Attachments:

maxresdefault.jpg, 198 KB
KangarooLattice.jpg, 149 KB

Permalink Reply by peter fotiadis on March 28, 2016 at 11:54am

Er ... that's very easy with Kangaroo but let's check that I've got it correctly:

1. You have a randomly made FLAT mesh (there's another far easier way to do that - without mesh: just a 2d "graph").BTW: since Daniel does the job we don't care about making the mesh curvy: for instance randomly populating a region and then doing a Delauney triangulation and/or some user controlled elimination of faces or whatever (or other mysterious things if you treat that as "graph").

2. You have some terrain and you want some selected mesh/graph vertices being pulled by the terrain (making the mount /anchor points for the structure) whilst all the rest being pushed (say by applying some Z pos "force").

If so I have exactly that already but it's not suitable for you since is using solely C# code (including the Kangaroo2 related stuff). But I could "translate" it to native components (I hope, he he).

Permalink Reply by Alexandra Foster on March 28, 2016 at 12:15pm

I know its pretty easy to do with Kangaroo :P but I keep getting really dumb solutions. Im really a novice at all of this. If you know how to do something more like the second solution you suggested, my life would be so beautiful!! Thank you somuch for all of your help!

Permalink Reply by peter fotiadis on March 28, 2016 at 12:33pm

OK, don't panic: just send the terrain (small details matter) and have faith.

BTW: K1/2 are physics engines meaning that they try to achieve some sort of equilibrium (should I call it "fitness" ?) among a zillion things/parameters. Do it wrongly (wrong values, that is) and havoc is assured not to mention response time.

BTW: The "inflated" shape is the easiest of things ... but the pain comes when you want to do something in real-life with abstract stuff on hand (but that's another story; so keep the tears for some other future time).

Permalink Reply by peter fotiadis on March 28, 2016 at 12:45pm

In the mean time have some fun with this attached. (very old thingy using K1)

On first sight is not very related with your Holly Grail ... but look closely: what is the issue Numero Uno in both cases?

Elementary: Some ability to pick proper Anchors, that is.

Of course in this "abstract" case that's not a thing worth writing C# for doing it ... but in your case is the only way.

more soon.

Attachments:

Gone_with_the_wind_V1.3dm, 275 KB
Gone_with_the_wind_V1.gh, 145 KB

Permalink Reply by peter fotiadis on March 28, 2016 at 12:23pm

For instance this very old thingy (a bit more simplified version using some native components [they didn't survived for long, he he] and K1) ... works either with a surface or a grid of points (no mesh/surface) and then "inflates" lines via a myriad of parameters (shown the Vector for the unary forces). .

Surface (not actually needed ... but anyway) prior Daniel:

and the surface after Daniel:

BTW: If on the other hand you want to individually pick the anchor points (and probably keep design variations in some parameter as persistent data) ... this - although very easy - is doable only via code.

Permalink Reply by Alexandra Foster on March 28, 2016 at 4:24pm

this is excellent! YOU ARE EXCELLENT!

I've attached my topography and I'm playing with the file you uploaded- great stuff!

So if I individually pick points... I have to do it in code? Yuck. Now if lets say perhaps maybe 200 points are randomly generated and appear on my topography (each representing a random person) and some sort of mesh catenary connects to each of these points (a funnel for each of em) all funnels being sorta pulled from the same stetchy fabric that is hypothetically suspended above the surface....

Do I need to code that :P?

Attachments:

TOPOGRAPHY FOR SITE.3dm, 3.1 MB

Permalink Reply by peter fotiadis on March 29, 2016 at 12:07am

Er ... there's a confusion here:

1. Assume that you have a FLAT mesh/brep/graph with holes. In the brep case holes are known as loops: Outer means the obvious and Inner ...well .. ditto.

2. Our goal is to create an "inflated" structure (by balancing unary Z+ "forces" against Spring values and ...er ... properly selected Anchors). We must anchor some vertices on a per hole basis (or not: hole up in the sky). Ditto for the outer loop. If the Anchors are wrong (or "wrong") > Adios Amigos. If no Anchors: anti gravity is finally invented (I'm working on it, mind).

3. Since this type of stuff is the "same" (cost/engineering wise) no matter what Anchors we pick (provided that the max spans fall within reasonable limits) the only thing worth mentioning is the method for picking the Anchors.

4. One of the rare cases where aesthetics are clearly rated on top of the other design constrains (the other is tensile membranes). Do that in other type of Designs and ... become ... er ... hmm ... Zaha (avoid at any cost).

5. Code is required for doing this properly (AND managing design variations; in plain English: OTHER Anchor collections, that is). Code doesn't bite. GH is made with code, you know. Code IS my responsibility not yours : just press the red button and be a happy bunny.

6. So due to this (and that) finally we have the "inflated" thingy on hand. That's the peanuts part of the equation. Doing this in real-life ... that's the tears part (and THIS also requires code, lot's if real-life is real-life).

In order to clarify things I'll provide a series of "variations" (V1, V2 ... etc) on that matter. The first WITHOUT a pro policy for picking the Anchors: that way you'll understand (gradually) why the code is a must.

But ... maybe (just maybe) I'll do some entry-level freaky stuff with code for placing humans (or cats or dogs) in your terrain (as instance definitions).

Permalink Reply by peter fotiadis on March 29, 2016 at 12:34am

And until the Big Thing is ready (the hot potato is "controlling" the Delauney triangulation - via code [as usual, he he]) get the small Thing: very old def using K1 099 and some components. K2 allows to use code meaning: no K1 type of "components".

As is noted: this works either with an available Surface (internalized in the example) or - if you choose so - with a grid of points.

Problem is ...er ... that you can't pick Anchors on a per point basis because the C# part that does this is removed (life sucks, he he). The only thing that you can do is pick Anchors due to a "global" policy (using Attractors for doing that is naive). Of course I could include a "random" pick policy ... but a design worth the name should NOT relate to fate.

So ... the available policy yields canonical Anchor collections > ruins the "I want these particular points as Anchors" goal > bad thing > no thanks > gimme the other way.

See what I mean?

more soon.

Attachments:

Bend_a_3dgrid_V1B.gh, 167 KB

Permalink Reply by peter fotiadis on March 29, 2016 at 12:58am

BTW: you can do some LOL stuff even with this "restriction" on Anchor points ... but not the right type of LOL.

Moral: the only thing worth considering is the Anchor policy.

Permalink Reply by peter fotiadis on March 29, 2016 at 8:03am

And here's the V1 (extensive cut and paste stuff from a variety of available defs... you know engineers: always cheating, he he). BTW: your surface is scaled in order to "fit" viruses (humans that is): read below.

1. Using code for the random pts on BrepFace (yours + some holes to spice things a bit). Main reason? Well ... to control the miin distance (critical for engineering purposes). The other one is that you can disable the "even" distribution option and get random points as Fate brings them to us. That said David did a fantastic job on the equivalent native populate component.

2. Then the points are "elevated" (or not) according a user defined Z range. Reason? Well ... Plan B that is (making a tensile membrane system instead of that pessimistic "vault" thingy [ideal for funerals, mind]).

3. Then a user controlled (with regard what mash faces to kill) Delaunay mesh is created. Viruses in the mean time are placed around (you can use any block you like - see BlockManager). C# that does this is independent from the main action (but it doesn't work if the named block specified can't been found). Then the mesh is subdivided further (for obvious reasons). You can switch off this stage (that feeds finally Kangaroo 099). That said increase the N or viruses and spot the response time: this is the only way to do proper business with "identical" objects (same applies for truss members and for any collection of things in fact).