...hmm... points across the facade edges are not included (or may be some) and thus the whole thing is the art of pointless.
2. See the 1a unfinished part ... that defines internal boundaries for that purpose - then you need to create points across the edges, random reduce them and merging the list with the other points...blah blah.
3. That way each facade could yield structural members that touch the edges (where the biggest HEB/columns are expected to be). Obviously nodes are shared between facades with a common edge - the best logical approach for obvious real-life reasons.
4. The whole approach is stupid : here we need some Hoop snake "loop" control (that could take into account the critical connection angle constrain) in order to achieve a "progressive" deployment of the diagonal members in order to satisfy structural requirements and ... hmm...aesthetics. Free espresso for everyone is an added bonus.
5. Bottom to top design mentality is urgently required here: mastermind some 3d conceptual arrangement of nodes keeping in mind ... well...just 345,67 different real-life factors (but you could combine insulation and fireproofing if you use my favorite material: Foamglas - name with with one "s"). That way you can define the critical deployment planes : i.e. diagonal rigidity members, some facade aluminum system and floor main perimeter I-Beams MUST be in different planes.
I'll be back with a more stupid version of that thing.
may the Force ...blah blah
…
for any new mesh faces derived from that particular sampling tetrahedron. And it looks to me like it's correctly cycling through each tetrahedron in each cube:
triangles.extend(PolygoniseTri(grid,isolevel,0,2,3,7))
triangles.extend(PolygoniseTri(grid,isolevel,0,2,6,7))
triangles.extend(PolygoniseTri(grid,isolevel,0,4,6,7))
triangles.extend(PolygoniseTri(grid,isolevel,0,6,1,2))
triangles.extend(PolygoniseTri(grid,isolevel,0,6,1,4))
triangles.extend(PolygoniseTri(grid,isolevel,5,6,1,4))
So in grasshopper, this is where you would define a new mesh face, using the points indicated from this function (looks like they return either one or two triangles depending on the intersection state of the tetrahedron, which is right). By iterating through your entire sample grid, you'll create your continuous mesh.
I have found that the easiest way to do it is to create a new Mesh for each sample tetrahedron, and then to append them to a complete mesh as you go along. Hope this helps...it'll be cool to make a Python implementation for GH!…
Added by David Stasiuk at 4:43am on February 4, 2015
ncluded 3) using a freaky thing that "makes" Planes in order to do ramps (spot the Vodka option = Mobius + antigraviity OFF).
Don't touch the freaky things: for the moment just go and play with this palatable portion (GH components, nothing to fear he he):
depending on choice in gates: Paranoid (Mobius "shifted in Z")
sane (using corrected Planes):
not so sane:
What we have learned so far? Well ramps (and most of other things) ... it's about Planes (coordinate systems) you know.
Again: this is for fun/demo ONLY. I'll prepare a dedicated def for your case soon.
have fun, be brave
…
he past Architecture was the art of sketching: some "idea" with pencils/crayons + vellum paper (or with some computer) > then "others" trying to make this happen. This in general is known as top-to-bottom approach. Naive and dangerous (for the reputation/reception/acceptance of Architects/Architecture) to the max.
2. These days we work both ways: whilst some work on some "idea" (called it: "assembly") others (in sync mode) resolve the bits and nuts of that "idea" - up to 1:1 level of detail (called it "components"). This is the bottom-to-top approach. Make this your way: NEVER proceed in something whist's not EVERY bit of that something is well addressed (with at least 3-5 ways).
3. The emergence of parametric (GH, Generative Components, Dynamo) in AEC (an approach well known in MCAD word many years ago, mind) made things ... worst: the tremendous topology exploitation capabilities blinded people's mind and they are completely sucked up by the forest forgetting/by passing the critical fact that there's no forest without trees.
4. That's expected: is in the human nature to follow/admire the blink/glam and omit/skip the humble. It's the easy way you know, he he.
5. The tremendous growth of countries the likes of UAE/China/Russia made AEC things ... even worst: lot's of cash available > make us some encomium to Vanity, forget Modesty. You can replace "Vanity" with "New Frontiers" ... if you like fooling yourself.
Some Academics are not capable to understand all that: if they could they would potentially operate in the field (where the pink color is rarely used) and not in fishbowl(s). Some Academics believe that an "idea" is the 99% of the whole whilst actually is less than 1%. But on the other hand anyone can do Architecture (even Architects, he he).
That said (Vanity crisis) you want some other "component" options for this case of yours? (starting with "some" dollars more and ending with the mortgage the house/sell wife+kids option).
take care (and kill them all)…
th a graphic editor (GH) hosted in a CAD app that has primitive assembly/component capabilities and/or feature driven ops (Rhino). Did I've mentioned that Rhino is a surface modeler? (meaning the obvious).
3. Imagine a "seed" collection of assemblies related with various membrane components made in SW. Say: geometry (prior solid ops) and parameters (the feature driven part of the equation, in most of cases managed with some RDBMS). You should port these to GH (a variety of ways exist for that) and create the bare minimum of "solids" in GH as instance definitions. There's 2 main reasons to do that: (a) effectively communicating back on an assemply/component schema (via STEP) and ... (b) achieving manageable collections when in GH. These are critical for clash detection (when outlining some topology in GH, therefore NEVER work just with "curves") and "variation" control of some sort (up to a point). Of course for high class designs (where the devil hides in the details) this is NOT the best imaginable solution ... you'll need CATIA for such an integrated (all in one) procedure. On the other hand many could (wrongly) argue that CATIA is expensive (rather naive argument if a company has a certain turnover).
4. So, in general I would strongly suggest to use instance definitions of items in some sort of "intermediate state" of detail (an 100% undoable task without code) structured in such a way (classic assembly/component MCAD mentality blah, blah) that SW could take benefit of a possible modified "base topology" and proceed by finishing variations of the given assembly (feature driven stuff as usual).
5. Then export (STEP 214) back portions of the assemblies (and parameters used) to R/GH if and when this is required (for instance for BIM disciplines ... but Rhino is not a BIM app, nor it would ever be).
6. If you are familiar with code matters ... start thinking the whole puzzle that way, if not my advise is to find someone to design such a "procedure" (say an "app") using solely code, but this is not a task for the inexperienced by any means.
best, Peter…
release.
2. Of course, I agree the support is woeful for this at present. Find attached an example of trying to find a completely new definition for a target geometry. Using galapagos with these inputs help the machine get quite close. Obviously, its a combinatorial problem so bloat is an issue.
3. It's a great idea, and a thought I've had on the todo list. It's trickier than you think though due to the way you have to instantiate a component on the canvas. In addition, persistent data in the ingredient components that exists in the generated ones is possible.
4. Again, yes options for the inputs is a good idea and one I'm working on.
5. Indeed. Ideally, you should be able to put clusters in the ingredients. This is where things start to get very tricky without the help of David :) . If I can get user objects to work, then that's a step in the right direction. At present, you need to compile new components to get Embryo to include them.
6. Because it was the easiest to implement with the gene pools. Revising this to make it more efficient is a good idea, because at the moment it aint.
7. Good idea. I can include that in the options component.
Finally, just to say implementation in Grasshopper has its pros and cons, it's obviously not built for this kind of thing. In the future, I'd like to build an independent plug-in for Rhino that will handle GP better.
Anyway, thanks for having a go! I still intend to make the repository public.
As to what I do, I used to lead the Ramboll Computational Design team in London but we've all gone our separate ways now. I'm now a lecturer in Computational Design at the University of West of England (UWE) in the UK.
…
.
2. If "full" AND "thin" organic is what you are after the only way (doable with components) is to handle this via meshes ("rounded" lips in breps as in V2 requires code that is out of question for you at present time). BTW: I can easily do it using C# that yields individual "organic" struts and joints (as Breps not meshes) ... but ... go to previous sentence.
3. Theoretically you can do it (and avoid meshes) using TSplines 4.x ... but they work when they work ... meaning ... avoid (but test some connected lines in Rhino just for the fun of it). TSplines could revolutionize the organic business ... but only if AutoDesk could seriously invest on that approach.
4. ExoW is a way to "thicken" a bunch of lines (i.e. the mesh edges in this occasion) but is very tricky and IMHO has some bugs: yields odd results frequently by reporting "engulfing" type of issues. Anyway make a search on this Forum about ExoW (ex Exoskeleton) and have some fun (or "fun" depending on your luck with that temperamental thingy).
Note: the picture above is not due to triangulation ... but triangulation yields far more meaningful topology (if structural "beauty" rings any bell to you).
5. The big challenge here is: (a) either address this kinda like a MERO modular geodetic envelope (meaning: organic joints and struts) or (b) either use self supporting panels ... but if this type of "thin" structure pictured above is your goal this is NOT the way.
6. The other big challenge is to design a real-life approach for filling the gaps (obviously via poly carbonate/lexan) but this is waaaaaay out of what you can do at present time (1 week experience, he he). Don't confuse theoretical examples/cases with real-life ones. For instance you can design joints and struts in 2 "clicking" parts in such a way that "engulf" the panel content (the transparent thingy).
Ill be back with some ExoW demos ... but the bad news are that this type of stuff (especially doing it in real-life) ... is waaay out of what a 1 week novice can do.
Moral: another pile of worms case, what else?
he he…
e "amusing") - but all the intelligence is lost + the assembly hierarchy is lost + my dog is MIA as well.
2. This relates ONLY with some members of a given XFrame (meaning that you need a zillion things [or some "abstract" ones] for a relatively "large" scale tensegrity truss).
Meaning: instance definitions ... or Armageddon.
Meaning: some "adjustments" in a given definition having in mind similar systems (Plan B: abandon ship).
3. The fact that the 4 (ex single "tube") members are NOT planar (while ones in the previous example) AND their angles are variable as well (blue in the previous example) makes things hideously complex: we need ways to achieve levels of freedom AND some rigidity: the other way is to machine custom MERO type of stuff (balls, that is) that could host the adapters (but this means 1 zillion DIFFERENT balls). So in this variant shown the angles are managed by a "fixing" ring and rigidity by double tube [MERO type] members. Cables shown are classic Norseman stuff (Plan B: abandon ship).
4. So it's not a mystery why nobody uses that type of nonsense stuff for real-life AEC projects (other than smallish decorative things with a very limited load bearing capacity).
5. All that ... BEFORE the ultra complex system that supports the roof.
STEP mailed but ... well ... what about doing some nice tensile membrane? I have a zillion "simple" defs that do that sort of stuff.
best, Lord of Darkness (ex SardineLand Lord)…
posted rather testifies that. Randomness is the virtue here NOT equality. BTW: forget completely "optimization" of the mount points et all.
2. The thing in pic is airy (quality Numero Uno on that type of stuff, especially for things with no real load bearing capability) meaning minimum profiles ... meaning FORGET wood. Use aluminum tubes (rather cheaper than wood) as follows: screw the Captain Hook "node" in some kind of machined tube end (a humble massif cylinder that is screwed or clued [Araldide 2 part Epoxy] to the tube AND machined with threads for the hook).
NOTE: I could make a simple tube "adjustment" system that could allow you to build that on-the-fly WITHOUT any GH/K or anything: just start connecting variable length tubes ... er ... hmm ... randomly. This is the recommended way to do it anyway: we can't emulate art with software and even if we could: it's the art of pointless.
3. Additionally the whole conceptual aesthetics BEG for some kind of metal instead of wood. The fact that wood is aplenty in Russia doesn't justify killing trees (for any scope), anyway.
4. Using rings to "attach" the hooks ... well that could yield a highly unstable structure for more than obvious reasons. I could provide to you dozens of highly sophisticated bespoke solutions on that matter ... but they are unsuitable for this DIY occasion: I must think on a zero basis on that puzzle - allow me some time to propose the best "adapter" (easy, cheap, stable and allowing some liberties).
5. A Connectivity tree (see for instance Sandbox) can resolve with easy the equal axis worry of yours (thus: FORGET equality, just buy a hack-saw [ aluminum is very easy to "cut", he he]).
All in all: I like that a lot. I'll post soon some examples related with the all overall approach (including the node, he he). You don't need Kangaroo for that (and dare I say no structural analysis IF the structure to be is "similar" in size with the one pictured).
more soon, best, Lord of Darkness…
is Radius = (size+40)/(2*Pi), where "size" is the value to give, it's usually used in countries like Spain, Italy, Netherlands, Switzerland... The next release will have 6 ways (5 regional system + diameter) to give it the size in different regional systems with just two clicks, in fact, the rings of the next release are already developed, but will have to wait...
Knowing that:
ISO (International Organization for Standardization). mm of internal circunference. Austria, France, Germany, Belgium, Scandinavia...
radii = Size / (2 * Math.PI)
European Size. Spain, Italy, Netherlands, Switzerland...radii = (Size + 40) / (2 * Math.PI)
British Size. United Kingdom, Ireland, Australia, New Zealand, South Africa...radii = ((Size * 0.4) + 11.5) / 2
American Size. United States, Canada, Mexico...radii = ((Size * 0.83) + 11.54) / 2
Japanese Size. Japan, China, India, South America...radii = ((Size / 3) + 12.67) / 2
Diameter Size. Many goldsmiths anywhere.
radii = Size / 2
Source: http://www.18carat.co.uk/ringsizes.html
and since this release are UserObject componentes, you can remplace if you want the Size component with one new. For example, right clicking size_param, going to Expresion and setting x*pi-40, the size input will be the diameter of the resulting circle, if you give it a value of 14, the circle will have a radius of 7. Then save the userobject (File>Create User Object) and remove the other.
Or create a new one, since this component is just a rotated circle and a cylinder.
Hope this helps.…