Dynamic input component

Hi,

I did a definition for testing if two elements connected to the same node are touching each other or not (collision test).

It looks it's working well, but the issue is that I have to change manually angle slider and see when they touch each other.

I cannot do a series of 360 pieces because it would require a lot of memory and Grasshoper would crash.

Is it possible to have a dynamic input that changes time by time the slider and it stop when I have a sort of "true" response?

thanks a lot!

Replies to This Discussion

Permalink Reply by peter fotiadis on April 21, 2015 at 4:31am

Use trigonometry rather than trial and error (although the thing that you've asked is easily doable - with code).

This thread can clarify the gist of my meaning:

http://www.grasshopper3d.com/forum/topics/a-smarter-way-of-doing-th...

Permalink Reply by User on April 21, 2015 at 5:31am

thank you Peter. Actually at the beginning I was thinking so, but, as I have a lot of different and complex components (spider, gears, simple bar), it is not so simple simplify them with trigonometry.

Permalink Reply by peter fotiadis on April 21, 2015 at 5:42am

Well ... complex actually means a few loops (of if's or some functions more) in the code - nothing actually challenging at all.

In fact ... after inspecting what you are after (not bad at all > keep walking the walk, but the planar glass curvy mounts/brackets they do ... er ... require some "rethinking" he he) I would opt for trigonometry without any hesitation.

Anyway ... I would strongly suggest to attack this solely with code.The simple thing that I've provided to Charles (NOTE: totally different requirements/constrains since he does "one-off" nodes via 3d-printing) is tested up to 5K nodes and works almost in real-time (calculations time NOT time required for creating the "solids" or some of them).

PS: since Rhino is not a feature driven solid app (nor has any assembly/component capability) > you should use GH as a topology/constrain solver and then export the components of the system (as nested instance definitions) to some MCAD app for finishing the job + construction details + specs + BOM's + doing FEA/FIM stuff + variation management + PLM + ...etc etc.

Permalink Reply by peter fotiadis on April 22, 2015 at 12:16am

BTW: I'll try to outline the critical assembly/component thingy:

1. Imaging having some (or several) simple or very complex C# scripts that address the abstract topology of a given truss (any truss in fact) according a vast variety of "modes" PLUS the required clash detection (ALWAYS via trigonometry). In plain English: outline any collection of Breps and "apply" a truss that is topologically sound (planarization in case of quads etc is an added constrain). PLUS outline/solve what comes "next" after that truss (like the planar glazing "add-on" brackets of yours [ the ones that need redesign, he he], or some roofing/facade skin system [secondary supports, corrugated sheet metal, insulation, final cladding, dogs and cats])

2. Imaging doing this in real life (nothing to do with "abstract" formations of "lines" or "shapes" or whatever). This means primarily adopting a BIM umbrella: in plain English AECOSim, Revit or Allplan (I'm a Bentley man so I use AECOSim + Generative Components). This also means using "in-parallel" a top MCAD app for 1:1 details, FEA/FIM and the vast paraphernalia required for real-life studies destined for real-life projects (made with real-life money by real-life people). My choice: CATIA/Siemens NX.

3. What to send to Microstation (if not using Generative Components, that is) and/or CATIA? In what "state"? To do what exactly? For instance even if you could design this feature driven tensile membrane anchor custom node in Rhino (you can't) it could be 100% useless in CATIA:

4. Imaging masterminding ways to send them nested instance definitions of ... er ... a coordinate system (all what you need). In plain English: since is utterly pointless to send them nested blocks that can't been parametrically controlled (variations/modifications/PLM management/BOM/specs etc etc)... send them simply the "instructions" to place coordinate systems of components that ARE parametrically designed within Microstation and/or CATIA (classic feature driven design approach blah blah). So GH solves topology et all (working on data imported via, say, Excel sheets related with sizes of components etc etc) and sends to Microstation simply this (a myriad of "this" actually):