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 10, 2015 at 11:54pm

Use trigonometry:

Lets call the cylinders shown "struts" (actually they are strut adapters if you use a MERO type of space frame).

1. First and most importantly you need a faultless way to get connectivity data (in mesh cases: SandBox comes in mind but it fails in quite a few occasions especially when non manifold meshes are used).

2. Then and based on connectivity data compute the diagonal between each pair of strut axis. Then rStrut/strutLength = Math.Tan(diagonalAngle/2.0). Where rStrut = strut radius, strutLength = the length to compute. See this where Lengths are constantly variable depending on the diagonals/2.0 per axis pairs.

BTW: this shown does the "inverse" thing (VS a MERO): creates adapter nodes on a per node basis (made as one-off via 3d-printing) ... but the gist of the method is quite clear (I hope)

Permalink Reply by peter fotiadis on April 11, 2015 at 12:23am

BTW: this def captured it uses solely C# to do any truss (in this case: on mesh Lists open/or closed). 2 main C# scripts do the job (and 6 others act as auxiliary) :

1. The first C# does 10 DataTrees with every imaginable connectivity info (vertices, edges, faces, cats, dogs you name it) :

2. The second C# does the "adapter nodes" (in 3 different "modes": fast[indicative circles+balls], medium[tubes] and full solids[tubes+protrusion+balls]) and computes every imaginable connectivity data as well - in order to assemble the truss in real-life - plus (in other MERO type of cases) drilling axis etc etc:

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

Hi Peter,

Thank you very much for your detailed reply this is exactly what I'm trying to achieve.

Unfortunately my C# skills are very limited but hopefully I'll manage with Gh components.

I've got all my nodes in separate lists, from this I've extracted the angles between each axis. Now I'm assuming these are then paired according to the smallest angle. What's the logic behind dealing with an uneven number? Would you make the calculation based on the closest neighbor and apply the result to only that strut?

Secondly I don't quiet understand the calculation, would you mind clarifying this based on the drawing below. Where A1, B1 and C1 are the optimized lengths.

Many thanks!

Permalink Reply by Charles Fried on April 12, 2015 at 9:09am

Here are a few pictures of my first prototype:

Permalink Reply by peter fotiadis on April 12, 2015 at 10:36am

Hi Charles

Assuming that many struts may share the same node: For a given triad of struts C,A,B (where A is the "middle" axis):

1. Compute the angles angleCA = angle between (C,A) and angleAB = angle between (A,B). PS: in C# that could be: double angleCA = Vector3d.VectorAngle(C.Direction, A.Direction);

BTW: in fact we deal only with points where Pnode = the point for a given node and Pconnected is a collection of others that are connected with that Pnode in the mesh structure (thus we need connectivity info: always provided via indices of the related points).

2. Get the smallest of two angles, say: minAngle. Divide by 2.0 (NOT 2: we are after double values).

3. the "net" adapter length A1 has as follows: (AstrutRadius + tolerance)/A1 = Math.Tan(minAngle) > ... > get A1.

3. and finally (add some tolerance) A1final = A1+strutTolerance.

Of course I could provide to you the portion of the C# code that does this ... but it's unfortunately in C#.

But on the other hand: why bother with that? Just provide a test mesh (or graph) PLUS the tool that you use to extract connectivity data (kinda like SandBox). Or I could use my C# captured that tells you everything about anything for manifold (and not) meshes.

Permalink Reply by peter fotiadis on April 12, 2015 at 10:47am

PS: although you don't speak C# I do hope that the logic is clear (or "clear" he he):

Permalink Reply by peter fotiadis on April 12, 2015 at 11:21am

get this as well

Attachments:

170_node_angles-Default-000.pdf, 116 KB

Permalink Reply by Charles Fried on April 13, 2015 at 10:39am

Hi Peter,

Thanks you very much it's all clear now.

I was failing to establish the right angle so the Math.tan was getting me a little confused.

I've successfully applied it to one node but I'm having trouble matching the data for the angle measurement whilst keeping each axis in its own branch. Would you mind having a quick look? I laid it out as clearly as possible.

Thanks again

Attachments:

Node - Trigonometry.gh, 20 KB

Permalink Reply by peter fotiadis on April 13, 2015 at 11:43am

Hi Charles

In fact all you'll ever need is to translate this (stuff from the Dark Side, NOT politically correct ... he he) into GH components:

C# against your data in 2 "modes" (flat as you provided them and mine with some axis more in 3d space):

To tell you the truth you need a lot of other "constrains" for your nodes since they are shaped (I can easily guess the "method" used) by "fusion" and not connected via some ball type (MEANING: that the clearance between adapters should comply to a second constrain AFTER clash matters are addressed: this is one line of code more into that C#).

So ... I'll thy to translate the C# into components (but is 100 times easier to work with code than with these ... er ... mysterious/cryptic GH components, he he).

more soon

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

BTW: Take a random node: if there's no variable/provision for the min adapter length and you are solely rely on clash+some tolerance check(s) you'll end-up with this :

instead of that (suitable for your type of adapters/nodes "fusion" design approach - minus my ball [obviously]):

That said you need the connecting protrusion in the struts instead of the nodes but that is less than a line of code in that C# thingy.

Permalink Reply by peter fotiadis on April 13, 2015 at 1:01pm

To prove that clash is only ONE constrain ... here's some "comparisons" (i.e. "straight" VS "fused" nodes) closely related with the (highly temperamental) ExoW for the liquid thingy :

Permalink Reply by Charles Fried on April 15, 2015 at 6:04am

Hi Peter,

Thank you very much for sharing all this information. There's certainly a lot more to consider when creating a node than I anticipated. I'm not sure I understand it all but it's slowly sinking in.

I still haven't managed to apply my trig definition to multiple nodes. Would it be too much to ask for your C# component so I can study it?

Many Thanks