algorithmic modeling for Rhino
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,
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 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:
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.
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.
get this as well
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.
In fact all you'll ever need is to translate this (stuff from the Dark Side, NOT politically correct ... he he) into GH components:
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).
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 :
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?