algorithmic modeling for Rhino
Hello everyone,
I would like to get some advice how to generate a roof structure based on a surface created in rhino. I have already created a draft roof structure in Rhino - but as it was just a grid projected on the plane it doesn't look very accurate (especially where the surface sinks).
I have attached some screen shoots and an example of how more or less I would like the structure to look like.
Any help would be much appreciated!
Thanks!
Tags:
Hmm ... this is tricky (but not for the obvious reasons):
Ideally you should apply the following steps to that:
But ... well ... for doing it is not that simple (I have C# code that does this but is rather very complex).
Anyway ... let's forget the quad mesh for the moment:
1. Create some patched brep (i.e. a "surface" with trimming info: this [a bit confusingly, he he] is NOT a surface ... because it's ... er ... a brep).
2. GH Patch is very temperamental and frequently omits trimming the brep especially against the inner loop curves. Nothing too serious mind (I have a C# that deals with this issue).
3. Using MeshMachine create the simplest tri-mesh possible.
4. Use K1 (or K2) for "relaxing" the mesh.
Note: steps 3-4 are covered with this very simple demo case attached (load R file first).
5.Now ... the yielding mesh is a tri-mesh ... and that's not what we want: Quadrangulate (what a word) the mesh (THIS is very tricky - I use also C# for that) and using mesh connectivity data (mesh faces/vertices are NOT following the "divide-a-surface" ordered way of doing business) make some geodetic truss.
more soon.
Hi Peter,
Thanks a lot for your tips. Will try them out tomorrow ans see how it goes...
Unless you just want Peter to do the work for you, or are comfortable working in C#, you will learn nothing about Grasshopper from Peter's code.
On the other hand (and IF we are after quads "well organized" in the sense that the divide a surface pts DataTree is "well organized") ... we don't need meshes at all.
Here's a very old case miraculously escaped from the massacre (I've replaced all my old defs that use components with ones with C#). This case has a certain potential for 2 reasons:
1. If (with some changes in the def) we make a quad mesh (instead of that Delanuey thingy used) we can get rid of all the issues related with tri-meshing. If we replace quad mesh with a grid (see 2) ...
Here's another very simple test with regard grids:
2. If we can get rid of the mesh completely (and deform a grid > see def) ... then things start having a rather purposeful meaning.
In fact I have stuff that does exactly this but is solely via C# code (including K stuff since K2 is open sourced). Bad news: It's rather tedious to the max to "translate" them using native components.
Welcome to
Grasshopper
© 2025 Created by Scott Davidson.
Powered by