Forces and attractors

Replies to This Discussion

Permalink Reply by peter fotiadis on November 3, 2017 at 1:40pm

Well

Assume that the whole thing is a collection of "modular" rods each one has a ball pivot join (one end) and a ball pivot "socket" (other end). If you connect several similar things you'll get a "chain" like combo but way more elaborated that any chain. Such a combo could be suitable for some classy installation. For the abstract part and for the moment forget the actual parts and think them as line segments in a Polyline.

The issue is how to convince a "real-life" collection of parts to bunch with focus different "attractors". Again at an abstact level think axis (the polyline segments) instead of the actual things. That's not nuclear science with Kangaroo ... but in fact since GH is a-cyclic by nature (not to mention handling instance definitions) this is addressable via code (for a very elaborated effect using the actual parts etc etc).

The other big issue is to get the gist of Kangaroo.

So ... see these 2 attached.

The first (using K2) is a first step towards controlled bending of a polyline (abstract/incomplete for this entry level demo)

The other (using K1) is about bending a grid (a graph actually). On first sight it's not related with what you want ... but never say never, he he. Is a relative nightmare for anyone not familiar with code ... but it can you give a very rough idea about a "real-life" definition that could emulate "real-life" parts the way that you want.

Attachments:

• Bendi_polyline_K2_V1.gh, 21 KB
• Bend_a_3dgrid_V1C.gh, 274 KB

Permalink Reply by peter fotiadis on November 4, 2017 at 3:00am

BTW: For a classy real-life "chain" demo I would strongly recommend a system like the attached. Emulating a real-life chain is a very complex task whilst the ball pivot joins greatly facilitate the whole simulation.

Note: For a given "chain" condition replacing lines with instance definitions is impossible without code (not to mention recursion with regard the K2 engine itself).

Attachments:

• BallPivot_demoMinRod_V1.3dm, 1.2 MB

Permalink Reply by Melaine Ireland on November 5, 2017 at 10:39am

I haven't had time to check it out yet, but I really appreciate the explanation!! You are very correct about the difficulty level when one knows nothing about coding. I actually made a series of grids and had attractor points on lines to make a collection of movements, but I could not achieve the chain movement. I just need a way to make even a one segment line react to an attractor in series of waves to determine how a person could make a chain reaction like a magnet moving through the space. I've made a few physical models with arduino uno and electromagnets that make hanging chains dance in a series of proximity to the electromagnet.

However, now I've somehow got to translate these prototypes into a pavilion. I may have had too much fun playing in the physical realm, and now moving into the digital has me perplexed. At any rate I really can not thank you enough for responding!! I'll check back once I check out the models!

Permalink Reply by peter fotiadis on November 6, 2017 at 12:59am

One intermediate (towards  "realistic") solution looks like this captured screen. The next step could eliminate all these by solely using code:

On the left are things that you could recognize (the so called "native" components mostly related with GH primitive geometry and K2 stuff). On the right is C# code that puts in real-time (zero delays) actual rod models (like the one provided) whilst the K2 engine is running.

Kinda:

The latter is an instance definition with springs in rods thus allowing them to "bounce" for a more ...er... intriguing effect (for an installation anyway).

If you think that you can dig in in such an approach (that goes from abstract/Academic [lines/points/etc : meaning nothing to me, mind] to realistic objects) drop a world. Note: you can have a demo on all these just by enabling the part that deals with instance definition  placement (without knowing anything about code > you just click on a button and things appear instantly in some Rhino Viewport).

But the necessity of a code only approach is far deeper than that:

K1/K2 are physics engines meaning that ultimately do some sort of equilibrium on Points depending on forces applied and the Point relations. If the left "easy" part has a myriad of sliders that can affect the equilibrium ... the actual question is: how we can "optimize" (or "self-optimize" by a "machine learning" process) these for the most "sticking" visual effect (that more or less gives some clues about reality via (a) the motion itself (b) real-life objects that perfectly "emulate" pretty much anything that you gonna use in your installation [AVOID chains at any cost: kitsch and ugly]).

This question can only being addressed by code.

So ... if you are determined enough (and ready to deal with a lot of frustration, he he) ... just give the attached a go (no pain no gain)

Permalink Reply by peter fotiadis on November 6, 2017 at 1:55am

Road map to "happiness" (tears optional):

1. Load R file first (this contains the instance definitions [as "blocks"] hidden from view [use BlockManager to see them]). The first is wrongly placed/"oriented" in space (at instance definition creation phase): indicates the obvious fact that if garbage in > garbage out (try it).

2. Load the GH thing. Task for you: Using Named Views locate the points of interest as described further and make a suitable view. That way you can navigate rather easily around (hope dies last).

3. Your attractors are controlled from here:

The slider in blue picks some attractor to play with. You can use this while the K2 is running.

4. Don't change anything here (think of it as a black box: who cares how it works? nobody actually):

5. Enable the other "black box": job done your real-life stuff is placed:

6. Enable the solver: your "real-life" things start to bounce around:

7. Go there are play with the slider. A different attractor yields an other solution:

8. With real-life things in place if you disable the C# ... they are instantly deleted and you are back in lines/points and the likes:

9. Either with instance definitions or Lines/points change ... er ... hmm ... these "simple" parameters and discover the truth out there:

10. Since these are a "few" and they affect the simulation with a variety of ways ... we need a "self calibrating" system: some mini big Brother that does the job for us. Kinda like applying safely the brakes when it rains (I hate ABS mind).

NOTE: the rod with springs requires some additional code ,more (that deals with NESTED instance definitions) in order to (b) bounce as a whole and at the same time (b) elongates or shrinks a bit.

More soon.