C# In C# we trus(t)s - WIP

Replies to This Discussion

Permalink Reply by peter fotiadis on September 4, 2014 at 3:57am

PS: of course knowing what member ("strut" that is) is under compression (= some tube) or tension (= some SS cable) ... could yield to the final stage of truss design:

Permalink Reply by Arend on September 6, 2014 at 3:40am

Hi peter, seems awesome.  I can imagine that GH/Rhino is well suited for form generation, and that detailing  of joints is best left to other software that can handle constraints? Or Are you planning to create a library of joints? (I can imagine this to be a titan's work)

Permalink Reply by peter fotiadis on September 6, 2014 at 6:48am

Hi Arend

Well ... no plans for a library of joints. In fact the parametric thing these days is a 2 face thing : (a) creating abstract topology without actually designing a thing or two - the way that GH works (b) creating feature driven very complex parametric parts manually (the trad way) ... and then combining them in assemblies derived from (a) with components derived from (b).

Exactly what Generative Components does (if we forget the bugs, the extremely slow response, the lack of any development, the bugs, the bugs and finally the bugs).

Creating collections (libraries) of components in Rhino it's pointless since he doesn't support feature driven modeling. This means constrained driven geometry (solids NOT surfaces - another reason for totally excluding Rhino for the scope) that describe the actual components (that belong to nested assemblies etc etc). 

So back to (a) : The only thing that Rhino/GH can do (in real-life) is to outline an abstract topology with "basic/primitive" geometry in place (= lines in this case). Exactly what this WIP script does, in fact. Of course it can do calculations as well (clash detection AND drilling axis related stuff).

But never say never: let's inspect an example from some WIP project (AECOSim + Generative Components) of mine to see what can GH/Rhino additionally do (in real-life):

Imagine a rigid "ring" (the truss shown) that manages tensional forces (via cables) in a "ring like" formed tensile membrane combo. Membranes (inverse cones) pull the ring thing downwards and mast attached cables pull it upwards  = equilibrium (or disaster if some cable fails, he he).

So assume that the abstract layout (lines, that is) is made with a similar GH script with the one posted here. Rhino can't even imagine doing the parametric fasteners shown - thus we exclude them from the equation.

But GH could(?) "indirectly" feed a proper CAD app (from AECOSim to CATIA) with "seed" information in order to help making the components and the assemblies of components.

For instance assume that every truss linear member is a classic MERO system (ball - sleeve - cone - tube -cone -sleeve - ball). It's pointless to create (in GH) and bake a nested Block structure with "real geometry" (surfaces, that is) and export it via STEP : we can export lines + coordinate systems instead (ACS) ... that could be sufficient for AECOSim to replace "parts containing lines + ACS" with real-life "parts containing constrained/feature driven solid objects". 

So the real challenge here is to mastermind a suitable nested block structure (and an equivalent GH_structure) that could pass the right assembly/component info.

I'll be back soon with some add-on script that takes truss lines and makes them MERO style "surfaces" in order to practically outline the issue(s) and the goal.

 

Permalink Reply by peter fotiadis on September 6, 2014 at 7:14am

BTW: A very old design that one (prehistoric, he he). Use Model Tree in the latest (and "greatest")  Reader to exploit the structure used (and the components) and get the gist of the challenge (mixing topology(a) with real-life(b)). Made with Generative Components a million years ago.

Attachments:

• 170_ThematicPark_V5_STR-STR_MASTER-034.pdf, 2.8 MB

Permalink Reply by peter fotiadis on September 7, 2014 at 3:22am

Here's a small "visual" demo of the whole scope (using Generative Components and AECOSim as the final AEC content recipient):

This is a small collection of assemblies and components related with some quite complex truss:

In fact the entities listed in Models list are stand alone "files" (take the block concept as found in Rhino and multiply it by 1000) that compose void models (the assemblies, that is).

This is a nth variation of a strut-end Model (a parametric full solid component) :

This is what Rhino/GH could(?) contribute to the party: Just a line (axis) and a suitable coordinate system - aka ACS (the "world" as regards that component):

This is what happens when the line/ACS components are placed in 3d space with respect the truss portion in question:

This is one millisecond before replacing the abstract thing with the real thing:

And this is the result:

So the goal of the C# script is just to feed Microstation (AECOSim) with oversimplified "representations of the real things" properly structured into assemblies (i.e. nested blocks hopefully correctly translated via STEP214) ... the rest is feature driven parametric stuff way beyond of what Rhino/GH can do.

more soon

Attachments:

• 212_UAE_STC12a-TEST-FROM-WIRE-TO-SOLID-000.pdf, 356 KB
• 212_UAE_STC12a-TEST-FROM-WIRE-TO-SOLID-001.pdf, 323 KB
• 212_UAE_STC12a-TEST-FROM-WIRE-TO-SOLID-002.pdf, 342 KB

Permalink Reply by peter fotiadis on September 12, 2014 at 1:37am

Jelly fish mind situation occurred: ADVISE from any willing guru is urgently required.

Progress report:  several (MERO) stuff is almost ready (not implemented in the v13 version posted here) but ... I'm facing a quite strange issue with an "intermediate" script (that counts branches on a per "node" basis).

Let's describe first why this "intermediate" script is required:

As you can see the "main" script provides points/lines et all in non identical data trees (obvious: since the path structure depends upon if a surface is open or closed). Thus if we need to "post process" (iterate correctly through branches, that is) these trees (in a variety of scripts) we need a way to count branches on a per "node" basis.

This is what this (WIP) script does :

And now the strange issue:

The first function finds the max path dimension ( i.e. for path {a;b;c;d} dimension is 4).  Then this value is passed to other functions as argument and life goes on:

The function is really simple:

Now choose this as test tree (works OK: max path dimension=3):

Then switch to the crazy tree (works OK, max path dimension=4):

Then switch back to the initial tree (Oops : max path dimension=4 instead of 3)

Maybe has to do with the exception handling here:

best, the jelly fish

Attachments:

• C#-SurfaceTruss_WIP_13.gh, 804 KB

Permalink Reply by peter fotiadis on September 12, 2014 at 1:50am

PS: with this line added function works as expected: