algorithmic modeling for Rhino
I am reasonably new to grasshopper and want to make a 3 dimensional truss/grid/scaffold system from topography.
I am able to make a 3 dimensional grid system quite easily, but am struggling to map it to my landscape/mountain/contours
Attached are images of an example.
Any help or push i the right direction would be greatly appreciated
Tags:
Hmm ...
I have code for doing this type of truss but it's entirely in C# (thus potentially totally useless to you unless you are familiar with the language).
Anyway post your definition
this is what im working with so far.
very basic
i basically want something like that to be able to map to a form, somewhat like a voxel, but have a truss system. and i have no idea how to go about it
OK, I'll prepare a "simple" demo (not sure if I should finally use components or C#).
Here's what it does:
1. Creates a given collection of "entities" in 3d space (say: sampled truss modules in a proper datatree).
2. Then tests if these have any relation with a given collection of surfaces and removes them from the datatree. By relation: think, say, IF a surface intersects the relative bbox > cull that ... or a variety of other "culling" logic.
This requirement of yours brings me in a delicate point: To tell you the truth ... well... my C# scripts they do work rather faultlessly ... but they are solely written without components (at all).
I'll try to translate some stuff in the component language.
In the mean time get this (requires Daniel's MeshMachine: the best thing that GH has to offer VS meshes before switching to MeshLab): put any closed brep to the left and ... er ... have faith. Some small C# stuff here and there are retained .. but no pain no gain, he he. In fact this is also 100% doable solely with components.
Note: The thing that controls what you get (mini BBoxes or "trusses") is this gate:
Note: Load Rhino file first for the test cases.
Note: Mesh.IsPointInside is 10 times faster than Brep.IsPointInside thus use the MeshMachine to "approximate" your brep.
more soon, best Peter
Thankyou for your help, it is much appreciated.
I was wondering if you would be able to help me with something else related to this.
I want to change the definition so that it has an element of subdivision. This being that the trusses/voxels increase in resolution closer to the edges/areas closer to the exterior of the cliff/where the cliff changes in form. I was also hoping it would be possible that if i set a point the trusses/voxels would be largest at this point, and reduce in size from this.
I have attempted to muck around with an oct tree component, however this causes disarray, and i would still like there to be a noticeable grid
OK, I'll make some changes (but they'll carried over solely with C# code - not components).
In the mean time get the trad update (V3, V2 is very complex: we can skip it for the moment) that does a lot of things more:
1. DataTrees are used (sampling 3d data in Lists is ultra amateurish). This allows (as well) to check the truss rigidity [at least 2 "voxels" must "share" a common "face" in X.Y.Z etc etc etc] - this check IS NOT included mind.
2. Skin mode is added (that's rather cool).
3. BBoxes are created either in WorldXY plane or with respect any user defined plane.
Keep in mind that this is INDICATIVE: without a robust connectivity data structure (nodes to nodes indices AND nodes to struts indices) ANY truss definition is 100% academic (meaning: useless). Not to mention drilling axis data and clash detection (via trigonometry NOT physical "bool" type of checks).
more soon.
Variable min trusses case:
I was thinking that (easy but read further on).
1. You need (a) either a collection of push/pull attractors to influence the size of BBozes or (b) an algo that calculates the distances [ say: VS the Centroid of the brep/mesh acting as a pull/push attractor] from the reference skin BBoxes pts (kinda like the skin mode in V3) and then applies a gradual effect to the rest. But this IS not actually a gradual effect at all ...
2. ... because the issue is that the modular/stepped (say: 1>1/2>1/4>1/8>1/16>...> end of story) subdivision(s) ... in relation with the mini truss struts could certainly cause havoc (Imagine a 1 size mini truss being neighbor to a 1/2 size truss > very messy if you ask me).
more soon.
another question, out of interest how is it that you make a basic blob, such as the ones you have made in the rhino model?
im working with a landscape topography map/ which has come out similar to a drape after ive patched it. And i beleive the definition would work more naturally on a blob of some sorts.
the reason i am asking about an attractor is because i want the defition to grow from a point, and also stop at a point (random) that appears natural and is simply in relation to a distance where it sometimes doesnt produce a voxel/truss
1. Blobs supplied are made (manually) via TSplines (and then converted to Rhino polysurfaces == Breps).
2. Finally a variable size "volume" truss grows on me (at least theoretically). This needs some recursion kinda like solving fractals (it's a programming "method" where Thomas calls Thomas ... who's calling Thomas ... etc etc).
3. Recursion is also the way to go when going from ugly cube like mini trusses to some pyramid like ones.
But the bad news (as I said from the very beginning) are that any similar solution provided it would be only in C# ... thus making it kinda a "black box" if you are not familiar with these freaky things.
BTW: Is this case academic?
more soon
yeah its academic, rules and regulations dont apply!
and yeah i understand what you mean, going to have to spend alot of time reading up on all these things haha
im having trouble mapping it to these 2 solids. is there a way this can be fixed?
Welcome to
Grasshopper
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
© 2024 Created by Scott Davidson. Powered by