Spatial Truss on triangular surfaces/mesh

Hi everyone! I’m having troubles regarding the following issue:

Basically, what i’m trying to create is a spatial truss on a faceted mesh (composed of several trimmed surfaces with different angles). I subdivided the mesh on more triangles, got the central points of it and extruded the mesh. After this, i tried to connect the resulting points through the component Delaunay Edges. The problem is that the connections only work properly on the roof points, while the lateral parts of the mesh become a mess. Any ideas of how to solve it? thanks very much!!

I do not understand why you use delaunay as in 3d it will be a mess as it is a 2d function.

Why don’t you simply offset mesh and work with that pair of offset and original mesh? As there are many topologies of spatial trusses

For us it help to get a file and at least a sketch what you expecting to get?

Hi Petras, thanks very much for your answer! I tried to offset the mesh, but then i don’t know how to triangulate the offset mesh through the central points of the mesh faces instead of the same triangulation of the original mesh, as i want to create a truss between the two of them. Here are the files, i just used Weaverbird:

Spatial Truss problem.3dm (40.9 KB)
Spatial Truss problem.gh (7.4 KB)

If I got(?) it correctly(?) given a Mesh you want to create a W type of truss where:

  • base nodes/struts are the Mesh vertices/edges,
  • W Height (steady or random) is the amplitude of Mesh faces centers normals,
  • W struts are the connections from any W point to the face vertices
  • and top nodes/struts are the W points/their connections to neighbor W points.

Kinda:

If so, here’s some hints:

  1. I have no idea if this is doable without code (see 2, 4, 5)
  2. You should FULLY master Mesh connectivity matters. I.e. the 9 DataTrees derived from V, E, F combos (i.e. VV, VE, VF … FF). A connectivity for 2 Lists is a tree where branches are indices from List A and items indices from List B. That way you know what thing is “related” with what other (VE, VF, EV, EF, FV, FE). Same for connectivity for one List (VV, EE, FF). That said Sandbox does some of them (but is useless for Lists of meshes).
  3. You shoud NEVER offset a Mesh for that type of job - most notably if is a “random” mesh
  4. You should FULLY master ways to deal with clash issues (nodes: via trigonometry, struts to struts via Curve.ClosestPoints) and most propably modifying nodes on the fly
  5. If you go from abstract axis (Lines) to some sort of “solids” (with respect some existed system) you should use instance definitions.
  6. You should provide connectivity trees for the truss.In fact in real-life we describe things like these ONLY via connectivity trees refering to nodes, struts, node angles and some other things as well.
  7. You should check for min length struts (case random mesh).

BTW: With regard 2 here’s the 9 connectivity trees (for Mesh Lists, meaning that branches have 2 dimensions [first: index of Mesh in meshList]):

3 Likes

Hi Peter! Thank you very much for your help and tips! The images that you’ve put are exactly what i want to do. It seems much more complicated that i thought haha but i’ll try to study those topics to make it possible.

More Tips:

  1. A mesh is a mini database that contains connectivity info with regard Vertices, Edges and Faces (V, E, F). Thus one can directly or indirectly extract the 9 trees mentioned.
  2. After making the List of W points and given FV, VF connectivity trees … connecting the W points (“top” layer) is easy. Why? Because for a given face you can get all the “surround”: faces (not just the neighbor ones). With code that’s elementary: integer Lists intersection stuff (since any conn Tree deals only with integers [indices]). Have in mind that a W point is related with any other with the exact same way that the corresponding face is related to the surround faces.
  3. Assume that you do a help Data Ttree named usedTopNodes. For each W (of index i) get the surround indices (j) as above and add the axis W to W strut if and only if the usedTopNodes path at i and the used path at j doesn’t exist (then add ro the usedTopNodes the paths i,j).
  4. Notice that if you access the edges/strut axis via a VV connectivity type (or VE) you’ll end up with 2 times the amount of edges (for obvious reasons). This is the reason that we NEVER inspect members of the base/top layers via a List. We use connectivity stuff instead.

BEFORE starting any truss adventure decide the real-life type (commercially available, that is) that you want to use and study the nuts, the bolts and the limitations/levels of freedom of the system (in order to figure out ways to manage clash issues etc etc). AVOID at any cost Planet Utopia thinking when dealing with trusses.

BTW: That’s the Ducati of truss systems:

https://www.mero.de/

Screen%20Shot%20088

2 Likes

Hi Peter! I’ve tried to do what you said: Got the topology of the connected faces and used this to connect each W point. As a result, i got a series of polygons. I think i’m almost getting what I want! What i need now, i think, is to get the tree containg a path for each hexagon (6 points) and create lines between them based on the lowest distance between one and another, thus creating triangular connections. What do you think? Do you know how can i make this next step?

Spatial Truss problem.gh (21.2 KB)
Spatial Truss problem.3dm (40.9 KB)

I’m far and away from some proper Internet access right now (Some project in the mountains, that is). Until things get (?) better (???):

  1. NEVER sample your truss axis in polylines (polygons) because … well … we are talking struts here
  2. Goal is to sample nodes and edges in trees and access them indirectly via connectivity.
  3. For the W edges truth is that you can do a tree (W points index = branch) with 3 items per branch … but why bother?

Moral:

Close computer. mastermind FIRST a data organization schema: what exactly Lists of things you’ll need (Nodes and Edges) meaning in fact: A tree with regard Nodes since we have 2 classes of Nodes: base (say at branch 0) and top (say at branch 1) AND a tree with regard Edges since we have 3 classes of Edges: base (say at branch 0) , W (say at branch 1) and top (say at branch 2).

With computer still off: mastermind SECOND a data connectivity schema : what connectivity trees you need in order to describe what’s happening. Post here your schema.

Then open the computer and walk the walk (don’t forget the strut to strut angles for clash issues).

Tip: Assume that a German at MERO receives some data from you: what he needs in order to make the %#%$ thing in real-life? Does he need any drawing? (No) A 3d thing? (No) How he drills the holes in the balls? What sort of data tell him what to do? That’s your guideline.

Tip: Assume that the German does the job (well … they always do that Sir). What sort of data you need in order to do it on site?

Tip: In real-life engineering geometry is nothing. Connectivity is everything (and assembly/component modelling meaning: nested instance definitions)

2 Likes

And here’s come the pain (no pain => no gain, mind).

Let’s talk about clash matters … meaning in fact strut to strut angles matters. Imagine a base vertex (i.e. a OEM mesh vertex) and the neighbor vertices (we always deal with indices NOT the Point3d thingy). Depending on the valence (from 2 to … you name it) is kinda like a star with center the vertex in question and rays to the neighbor vertices. VV connectivity means a branch of index i containing indices of the neighbor vertices.

Indices in VV connectivity NEED to be sorted (for calculating the strut clash angles [struts at base layer]).

But … each vertex is engulfed with faces as well. Now … the 1M question: do we need the face indices sorted in a similar way as the neighbor vertices indices? Yes we need that since the top layer indexing system derives from a VF base indexing system [ struts from a vertex to the neighbor W top layer nodes]. Problem is that I have no idea how to do that without code (forget sort points along curve: takes a million years to finish):

See results with and without face indices sorted (VF connectivity).

Note: this def is NOT suitable for you: the thingy does buisiness strictly via C# code.

For branch (0,0) the angle vector test goes:

(7-0, 41-0), (41-0, 8-0), (8-0, 386-0), (386-0, 3-0) …

For branch (0,0) the angle vector test goes (yields bananas anyway):

(7-0, 41-0), (41-0, 8-0), (8-0, 45-0), (45-0, 3-0) …

Moral: I’m not sure that you can even touch reality on truss matters without code. Not to mention that clash issues are just the tip of the iceberg (lots more are required).

Such a simple case eh?

And the freaky/ugly part of the story: the code that does all these sorted tasks:

1 Like

I’ve been wondering lately which of the two, faces or vertices, follow firsthand when travering meshes. It seems you prefer following vertices (and edges) and from them figure out the rest. Is that correct? (I’m not very “deep” into meshes yet, but I plan to do some nasty stuff as soon as I have the time to dig into it).

// Rolf

Depends on what you need to do.

In real-life trusses and due to the critical clash check thingy sorted VV (or sorted VF for the top layer) is the way to go.

That said a random real-life truss is by far the most challenging parametric thingy imaginable (even for pros). Of course having always in mind that talking with that merciless German (the MERO man, that is).

That said … oher than doing the classic mesh 9 connectivity trees (that’s the first thing to do of course) … this is a good starting point on mesh Lists, Mesh.Vertices VS Mesh.TopologyVertices, some connectivity matters, sorted indices, faces, cats and dogs. Try to do it (do the disjoined pieces first):

2 Likes

Yes, seems sensible. I’ve tried following vertices so far, and sorting adjacent vertices and trying to follow a straight path, avoiding already visited edges. My path tend to turn and come back though… :slight_smile:

Well, I guess that’s why meshes are so “interesting” to learn to master.

// Rolf

1 Like

Hey Peter! I finally got what I wanted!! Unfortunately i didn’t have time to master all these subjects, cause i have few time to finish all this for my graduation thesis. However, all those topology tips were really useful for me to understand everything and manage the data that i got from topology tools like M+ and Sandbox. Now i’m using just the lines to analyse the trusses in Karamba, and the plug-in itself can understand the connectives. Thanks for everything!!!


1 Like

Good news.

When the thesis is done provide your e-mail: I could send to you the real-deal (code only, mind) as a guideline for the future: Given any mesh List do the full solution meaning the truss axis, the angles, the clash checks (on nodes and struts), the visual indication of issues (lot’s in a case like yours), the connectivity AND the “solid” members (sleeves, cones, tubes) as instance definitions (1000 times faster than the other way [i.e. copy and orient something from Plane.WorldXY to some plane]).

Then comes the real pain: the envelope (that doesn’t leak)

Screen%20Shot%20105

Since the case is resolved(?) I did a pass on your mesh using a strictly internal C# : you’ll encounter LOTS of no-no edge angles for that type of topology (solvable only with var R tubes/balls, a thing that does the whole task far more challenging [index wise]). On the other hand this is a thesis … meaning that a truss without edge angles clash checks is kinda a pink Ducati.

BTW: Are you after a more rational(?) Dalian ICC design?

Hey Peter! It seems your code is really powerful and gives really nice results! I’d be glad to study and learn all the things that you’ve said based on it! If you don’t mind to send me the guidelines, my email is joaopbvalente@outlook.com. About the envelope system: yeesss! definitely it would be a great challenge haha. I’m thinking about using a type of system provided by a company named Zahner (although i can’t find deeper details about it): https://www.azahner.com/creations/inverted-seam
Now, my thesis is about the collaborative process between structural engineers and architects on the conception and analysis of parametric structures. I’m working with 2 architects in 2 different projects. In this one in question, we’re creating this system around a theater. In this case, we’ve defined some parameters that can originate different Forms similar to this one of my file. Then, i’m using Karamba and Galapagos so I can choose the best geometry, level of triangulation and truss high that results in lower values of total mass and displacements, if that’s what you mean with a rational design haha

thanks a lot!

Zahner 's stuff is good (but not perfect). However system’s level of adaptability is not the biggest imaginable.

I’ll try to add some lines of code more in order to viz things more easilty - as it is (for internal use) it’s a bit cryptic …

… plus I must remove internal/sensitive stuff. Then I’ll mail you the simplest (?) possible C# that cuts the mustard on that matter. But … if you are not a Jedi Master of DataTrees and the likes be prepared for the mother of all nightmares (if we forget that code only part of the story).

BTW: By Dalian I mean the Dalian International Conference Center (level of rationalism: 0.001).

1 Like

BTW: If you had an ugly blob (where face dihedrals are unique on a per FF conn basis) on hand like these:

… then Zahner MAY be one of your options.

BUT your stuff is in fact a collection of planar faces assemblies and things are only challenging in the proximity of the OEM (prior subdivision) mesh edges. Meaning that Reynaers (get the cases and study the Aspire Tower) …

https://www.reynaers.com/sites/default/files/public/media/element_facades_lr.pdf

… is by far the most rational solution. Meaning that you only need the special elastic inserts per OEM mesh edges (few in comparison).

So do a classic flat semistructural panelling : W negative (hex like struts inside) + panels = base mesh faces … and just bridge the gaps where needed.

DO NOT use columns like the ones you posted (pig ugly stuff).

Case closed.

BTW: Have some fun(?) with the attached where flat collections of mesh faces meet other flat collections (like your thing). Pay attention to the W and Top truss edges where change of normals occur: see the havoc? Meaning … other things none of them is doable via components (life sucks).

Mesh_ToTruss_LongIsThePathAndHilly.3dm (1.6 MB)

Notice that Rhino needs 1.6Mb to store some lines. Imagine what happens when solids (MERO etc) are around (Mama mia). See why instance definitions is the only way to go?

Moral: Long is the path (and hilly)

This is an abstract concept (I don’t have any ready C# for that one, mind) that I would highly recommend for cases like these (i.e. using a “spine” [foreach clothed mesh edge] and then decrease the W towards the center of the OEM face) :

Really nice file Peter! I’m sorry for the late, your comment came as spam on my email and i only saw it now! haha thanks again for all your help

Best Regards,

João Pedro B Valente