he strip at the connection point. In fact, maybe try making the mesh along the whole strip symmetrical by splitting each rectangle into 4 triangles instead of just 2.
With just one spring between the 2 strips you have an elastic connection between their positions, but no constraint on their rotations.
I would suggest using some bending forces like this:
where the red squares represent a bending force between their 2 adjacent edges, with a rest angle of pi/2
This gives some resistance on 5 of the 6 degrees of freedom between the 2 strips, but leaves them free to rotate about the axis of the bolt, which I presume is what you want.
Alternatively, if you want the strips to actually lie on each other without any spacing, you could model it like this:
where the yellow line is a spring connected to both strips at one end and free at the other.
and there are still 4 perpendicular bending forces between this line and each strip.
This gives a hard constraint on the 3 translational degrees of freedom, elastic resistance on 2 of the rotational dofs and free on the last 1.
I hope this helps, let me know if you have any problems modelling this in Kangaroo.
As I've mentioned before - I am working on giving each node 6 degrees of freedom, which would mean you could model each strip as just a polyline, and specify directly the rotational constraints between any pair of particles.
…
Rhino plugins to work in the mac version. As I understand it, what is holding up the GH making it over (fully) to the mac version is its dependence on the graphics libraries for Windows. There is no easy direct translation here, so, this is still under development. There is info spotted around the forum, you just need to dig deep enough to find it, and see that there is development of GH for Mac, but still, we should not hold our breath as there are significant hurdles to overcome. These hurdles are just technical, and should have a solution. Below are some references that point to the graphics issue I am discussing as well as a list from David where he does state that he is working on the Mac version.
Another positive note is that in Rhino 6, GH will be along for the ride...meaning (as I understand it) that we will not need to download GH after installation, it will be part of the Rhino install. I think this is a positive note as it means that GH will be more associated with the default Rhino experience, an experience which should carry over to the Mac version.
So, to sum up:
1. GH for Mac will probably happen.
2. Seems all of the code that does not depend on the graphic part (the logic in the components, Rhinocommon) already works in the mac.
3. Other Rhino plugins are already making their way to the Mac.
4. GH is becoming part of the default Rhino experience, and should probably carry over to the Mac experience.
5. Don't hold your breath. When it will happen is not under anyone's control necessarily. The solution needs to be practical in order for it to be rolled out.
My $0.02.
References:
http://www.grasshopper3d.com/forum/topics/partial-developer-absence?commentId=2985220%3AComment%3A929795&xg_source=activity
http://www.grasshopper3d.com/forum/topics/grasshopper-for-mac-update?xg_source=activity…
...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
…
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)…
something (C# or components) that does a planer periodic nurbs - any shape imaginable in fact (shown a humble "figure of 8").
2. Imagine a capability (C# only: sorry) to create a "guide" (indicative/intermediate) surface. Basically: patch the nurbs from step 1 against a variety of user controlled curves/points/cats/dogs/you name it.
3. Imagine doing this U/v quad mesh thingy (we can fill the "gaps" [C# only: sorry] with the base boundary easily - especially when triangulating the mesh - but better work as shown):
4. Imagine calling the cavalry (Kangaroo) and instructing to do ... things on that "normalized" mesh.
5. What things? Well ... like equalize edges, "inflate", planarize the quads (extra WOW stuff that one), pull it against the "guide" surface [from step 2] or some other weird ideas of mine.
this is what V2 does (WIP).
more soon
…
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…
.
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…