A smarter way of doing this - Crash detection

Hi there,

I'm getting close to finalizing my node definition.

One of the last steps is to optimize the position of each node so that they are as close in to the center point as possible. This in order minimize printing cost and avoid mesh issues when they collide.

I've made an initial definition which does want I want but is not accurate nor recursive, it simply moves forward once by a given value if it collides.

Is there a more accurate way of doing this? Ideally setting a distance between each rod and working out the placement according to this, perhaps using a solver?

Thanks in advance,

Charles

Attachments:

Simplified Nodecrash solver.gh, 17 KB

Replies to This Discussion

Permalink Reply by peter fotiadis on April 16, 2015 at 1:07am

Well ... I'll try to remove a lot of "sensitive" functions from that (100% AEC oriented) C#: most notably MERO related complex topology calculations and create an oversimplified "abstract" version for you (suitable for simple furniture cases etc etc).

In the mean time one of the reasons that is difficult (if at all) to do this without code is the sorting neighbor points puzzle (in order to inquire them sequentially for the clash detection).

Here's a typical example. Neighbor order out of SandBox (the big sphere is any given node):

Attempting to sort them using the classic sort along curve method (plane intersects sphere > sorting curve).

Bad news: wrong sort result (sort along curve works if pts topology ... is "ideal"/"suitable", so to speak)

So a totally different approach is used (based on connectivity data) in order to enumerate properly neighbors otherwise the calculations are totally wrong.

more soon

Permalink Reply by peter fotiadis on April 16, 2015 at 11:58am

Matrix reloaded (via Plan C: the black pill):

Here's a greatly reduced (300 lines VS 1200+ of the real thing) C# "truss out of lines" thingy for you.

1. 4 node modes (3 of them are related with modular nodes).

2. The 4th "liquid node" mode is (obviously) related with that "temperamental" ExoW thingy: due to that I've set up the related output on a per node basis > first exploit what's possible with Exo (and adjust the variables accordingly) and then ... fire and forget.Not all topologies yield return something worth looking mind:

3. The other modes are straight stuff (always doable)... so all nodes are created at once.

4. Load Rhino file first for the demo test data.

5. I've reworked the functions by removing LINQ and other weird stuff ... in order to allow you to follow what's happening with the most "palatable" way. This means that several portions of the code are ... er ... a bit stone age, he he.

6. I strongly recommend the modular node design: simpler, faster and always doable (note that protrusions are the other way round allowing to use hollow tube struts ... instead of struts + some insert adapter)

best, Peter

Attachments:

Truss_from_GraphLines_V1.gh, 341 KB
Truss_from_GraphLines_V1.3dm, 137 KB

Permalink Reply by peter fotiadis on April 16, 2015 at 1:15pm

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

Permalink Reply by Charles Fried on April 17, 2015 at 7:38am

"crisis of Vodka starvation" Ahah this is very impressive stuff, thank you very much!

My original plan was to use the trig calculations to create some perp frames at the right offset from the node center. Looking at your C# Component it seems making a plane at the end of "nodeLinestree" will work perfectly. I can then insert these in my node definition which give me a slightly more organic node and also solves the collapsing mesh issue. I will post this is here once it's fully functional.

However the exo produces a hollow mesh which would be cheaper for production. Unfortunately when I open the file "nodeLinesTreeLiq" returns a null. Have I missed something? My bad I spoke too soon, awesome :))))

Permalink Reply by Charles Fried on April 17, 2015 at 8:12am

Perfect, made myself a "Hybrid" off it goes to the SLS :)

Thanks again!

Permalink Reply by peter fotiadis on April 17, 2015 at 10:20am

Well ... in fact you can do the above node topology using the modular options (see 3dPDF > the only thing that you need is some decent solid modelling app [ or a friend who has it]).

PS: Hollow stuff is maybe cheaper but structurally speaking ... better safe than sorry. Especially with the advent of carbon fiber (you can already buy cheapo CF tubes) sizes are shrinking > nodes shrinking > hollow NOT a safe solution.

PS: Get the trad update (with a critical bug fix as regards tolerance matters: can you find where the fix is? he he). Added some test cases more (towards your design orientation).

Attachments:

Permalink Reply by Charles Fried on April 19, 2015 at 6:56am

I've had a go at combining them together using both 3DS and Meshmixer but it's too laborious, I'm hoping the exo mesh will work as is.

Yeah, thankfully I Found a printing bureau that charges by the bounding box volume and not part so I'll follow your advice. Magics 3D Nesting function does a beautiful at job. :)

For the more complex designs I've also made a Snap-off tab with a reference number.

My original though was to use carbon fibre rods, I assumed they'd be too expensive but I'll take a good look.

I can't seems to spot the fix but I'm guessing it's hidden somewhere in the C# component?

Peter, thanks you very much!

Permalink Reply by peter fotiadis on April 19, 2015 at 8:29am

Nice stuff my friend, keep walking the walk.

PS: this puzzle is far more complex than it appears - as usual (since you MUST add "special" adapter ends to support seats, glass, mounts etc etc). I'll add some removed functions for a similar capability soon (impossible to do it with GH components).

The fix is well hidden. mind (he, he).

On the other hand a far more sophisticated node topology control is required (adapters as cones for instance, ball conditional radius etc etc). The ultimate challenge is to allow MERO type of modular mini joints (a very complex problem, despite appearances): for instance can you guess what is the primary clash consideration here?:

Permalink Reply by Raul Matagringo on April 20, 2015 at 7:25am

@ Peter:

the check for "inner" collision is very important. Also keep in mind: dont make the bolts longer as needed. For MERO you can take 1.5*D. Next point is the contact area between cone/sleeve and node. For your case take Dcone+2 mm.

Permalink Reply by peter fotiadis on April 20, 2015 at 8:03am

Hi Raul

Well I know that (I do a lot of MERO and/or custom stuff for my AEC projects): the as above "sketch" is a rough (and very inaccurate) indication of the MERO type of constrains for Charles (if and when he decides to jump into the (mini) MERO bandwagon for his designs).

Anyway doing parametric MERO solutions using lines-as-a-kind-of-graph (as in this particular case here) is rather a totally wrong approach for more than obvious reasons.

best, Peter

Permalink Reply by Raul Matagringo on April 20, 2015 at 8:11am

thats true...

Permalink Reply by Alex Bodkin on April 22, 2015 at 9:34am

Hi Peter,

I was testing your definition out and it seems to stop working when you have a "dead end". I assume this is because the component you wrote requires at least 2 struts at every point, and obviously a dead end piece will only have 1 strut at its dead end (as you said earlier, "Then and based on connectivity data compute the diagonal between each pair of strut axis.")

Is this true? Or am I missing something? I've never worked with C# components before, but I assume there's a way to get the component to ignore these dead end points?