algorithmic modeling for Rhino
I want to develop a space frame structure based on the surface that I designed. But I tried a lot of ways to write the grasshopper scripts. All of them do not catch the geometry since most of them are using UV to control the space frame web. For such a irregular surface, they will not work. I really don't know how to do it, if someone knows how to write the script, could you please help me? I upload my geometry here. Many thanks!
It's hard to give you a suggestion without knowing what the requirements for the spaceframe are. You could give meshing algorithms a try. For example MeshMachine or Cocoon should be able to break that surface up into a bunch of triangles and use shorter pieces where the curvature is tighter.
You could also rebuild the top as a single surface to use your standard UV tools and then build your columns another way.
Thank you! If I build the surface individually, the spaceframe will not contimue from the surface to the column. Let's say I want to build the spaceframe a 5'*5'*5' triangles grid. The depeth is also 5'. I tried the mesh suggestion before, but it didn't work. Since some pieces are just too small and some pieces are too large. But space frame is eventually a grid.
I think it could be helpful to try and clarify a bit exactly what are the properties of the solution you are after.
Maybe make some sketches of what you are imagining.
At the moment the question is very open, and we'd just be guessing if we try and propose detailed solutions.
Some generic guidelines:
1. It's far easier to convert your Brep (i.e. a list of BrepFaces) to some mesh and then attempt to make a truss out of this. You can use Mesh Machine or some external subdivision app (Modo, Z Brush etc) in order to get "as equal" as possible mesh faces.
For instance ... see a W depth truss (tri mesh > meaning that the "out" grid is hexagons) out from a Kangaroo "inflated" mesh:
2. A space frame is NOT a collection of abstract lines ... meaning that clash members detection (via trigonometry and NOT by checking boolean intersections) is far more important than the "concept" it self. If "live" alterations are required for addressing local clash issues ... well ... that's 100% impossible with native components.
3. A truss without proper connectivity Data Trees means nothing in real-life (vertices to edges, vertex to vertex, edges to vertices).
4. Each "standard" truss member (say: sleeves, cones and the likes) should be an instance definition placed in space according appropriate orienting planes. That way you may be able to handle thousands of components that in real-life participate in any truss of a certain size.
All the above are far easier to do with code (V4 is impossible with components).
PS: A sequel of screenshots related to the "blob to truss" task: