Angles for space frame nodes for Fabrication

Hello, I am an architect and working on space frame structures I am done modelling a detail definition which makes a space frame structure including pipes,cones and somewhat nodes. I can create holes in nodes in all the sides from where the connection is building. I am stuck in one part which is I dont know how to determine or generate all the angles of holes/drills for manufacturing purposes. I need help in this.

I can upload the definition if anyone wants to, Plus I am willing to pay for this. Its Urgent


If you are familiar with coding (C# in my case) this is solved via connectivity trees (VV, VE, EV) on line Graphs (the stuff that SandBox/Topologizer do) and then classic List Intersections for sorting neighbor vertices and then computing Vector angles (taking into account the proper plane) etc etc ( general case: random truss in 3d space).

For a variety of obvious reasons all the things that I have are strictly internal … but if you post your graph I could compute the angles and provide the result. Paying for that is out of question: this is a 100% Academic Forum after all.

Plan Z: You can also contact MERO: If there’s some signed serious letter of intend Germans could do that.

I dont Know about coding much. I want a perfect system/plugin or a definition that can resolve my issues in space frames. I have attached the Rhino file as well as grasshopper. I used the panelling tools(Lunchbox) for space frame grid. Also I baked the geometry curves incase you dont have Lunch box .

Thank you so much. I know about the forum, but I want anyone who is helping me should get a reward :)).

Space Frame (21.5 KB)
Space fram 4x4 m.3dm (97.9 KB)

Hmm … this is not as it should be (with regard DataTree structures related with bottom, top and W members). Plus there’s no Node/Node connectivity data around (or Node/Strut).

For that type of very simple (i.e. not requiring clustering (for locating rigid collections) not random nor using a not flat Surface/BrepFace for grid deployment) truss you can compute the typical angles very easily and focus to one module since all are the same (BTW: I was talking having any random truss of any type in mind). In fact you only need to calculate angles related with the W members.

I’ll make a demo on that matter using components (not my game at all, but anyway).

This means that you know some? Very good news … because … er … you can’t actually do a real-life truss in that ugly part of life called real-life with components (you’ll see the reasons after the urgency is over and more updates on that V1 would be available ) .

So get this (a 10 minutes job, requires some more for the angles that ALWAYS are related with VV connectivity [I do hope that you know what connectivity is … in general]). (129.9 KB)

Next (soon): V1A (with angles).

Thankyou So much :)) This is getting better. Waiting for your V1A.

Also, crucial part is angles with W members for typical as well as any other surface(curved/brep). Its a hassle to calculate manually.

Well … as usual something bad happened in the practice of mine and haven’t found the 10 (in fact 20) minutes for finishing the thing without violating the strict rules about what is secret/internal and what may be public.

But for sure today is the day.

BTW: From 1 to 10 what is your experience with DataTrees AND connectivity? Because without these … well … you wouldn’t be able to understand an iota from what’s going on.

For instance (W for west, S for south etc etc):

This is classic bottom to bottom and bottom to top (W tubes) node-node connectivity (a so called BVV conn tree in truss stuff). Neighbors are ordered anti clockwise (the norm, starting from W and/or SW).

Null means:

  1. By respecting the order … there’s no W,S,E,N neighbor node (2nd dim 0) and
  2. By respecting the order … there’s no SW,SE,NE,NW neighbor node (2nd dim 1).

Having that thing on hand calculating the angles is stuff for kids. Another one Tree like that is required for top-top and top-bottom (W) connectivity.

If all these sound Greek to you … it’s because I’m Greek (life sucks)

Poof… went over my head. This does sound greek… Nope not any much with data trees and connectivity :confused:

Math.Pow(Yikes, Yikes);

1 Like

what should I doo :confused:

You uploaded this in some thread, i exactly need this for every node or in tabular form consisting the horizontal and vertical angles of nodes.

OK, I’ll post a public version of that as well.

Moral: Long is the path (and hilly).

1 Like

Wait a bit (for the Salvation or the Desperation [they are that close you know]) , what else?

1 Like

Hahaha, Thanks :))

It really shouldn’t be very difficult to get the angles at which your members are coming into your nodes. As @PeterFotiadis mentioned, if the Grasshopper definition you’ve shared is the extent of your project, you may as well do it manually and be done with it.

Other wise, yes you can code something from scratch. But it’s quite doable in Grasshopper components. Run the surface curve intersection between your truss curves and your node sphere surfaces. Then use the polar coordinate component to get the angles you need (put the coordinate space as your node’s coordinate space, or give it a plane centered on your node).

Things will get a bit more involved if you want to determine duplicate nodes, model and block up the different machined nodes… But it’s mostly just tree gymnastics.

Found that 30 (ex 20, ex 10) minutes. This is as far as I can go without exposing internal stuff (for instance closed surfaces in U/V, BrepFaces with trim, random prox trusses, cluster analysis, cirquits, various truss modes, tensegrity trusses, instance definitions, interactive on the fly node modifications, cats, dogs … blah, blah) (151.9 KB)


  1. If you haven’t master what a DataTree is … it’s most unlikely that you can control this.
  2. Bottom/Top points are sampled in Trees and Lists. In real life we use Lists and connectivity. Thus the BVV, TVV trees are connectivity stuff that relates a given node with his neighbors and the W neighbors as well.
  3. Based on these angles are computed … but I guess that you must wait for V1B that would use TextDots and make things 1000 times easier to follow.
  4. Plus V1B would indicate (visually) angles that are > than a min angle (critical for clash detection via trigonometry and the likes).
  5. A bit of pasta is added as well in order to get the gist of connectivity: is it a bird? is it a plane? is it the superman? you tell me.
  6. Delete it if you become the master of DataTree matters (no pain no gain).

As usual the whole approach has in mind general truss cases … where … er… nothing is “norma/reqular/straight/easy”.

After a while a simplified V2 would expose the true nature of the beast … and … explain why you can’t do a real-life truss with components.

And … well … some light(?):

Given a nodeIndex 0 (in the bottomList nodes):

Branch(0;0) contains the ordered neighbor indices (bottomList) and Branch (0,1) contains the ordered neighbor indices (topList) that define the truss W grid.

Meaning that the combos for the angles tree Branch (0;0) are [null, nodeIndex, null ]+ [null,i nodeIndex, 14] + [14, nodeIndex,1] + [1,nodeIndex, null].

Since only the [14, nodeIndex,1] is valid … the angle (122.06) is placed at the pos of index 14.

Meaning that the combos for the angles tree Branch (0;1) are [null, nodeIndex, null ]+ [null,i nodeIndex, 0] + [0, nodeIndex,null] + [null,nodeIndex, null].

Since there’s no valid combo the angles Branch (0,1) contains nulls. Null is not nothing mind … is something that tells you that there’s nothing there (LOL+ LOL).

etc etc

If all the above sound Greek … it’s because I’m Greek (life sucks).

And the bad news: The C# that prepares a MERO KK system (or other) for any given truss (defines the min allowed angles etc etc) is internal and removing sensitive stuff would yield a non working thingy. Sorry.