t ... have a close look on these weird "slots" in the base mount plate - allow the struts to "follow" some base "auto" arrangement (up to a point).
2. After various ... er ... hmm... "communications" with a variety of apps.(some of them are not for public eyes) ...here's a concept demo about what could be done and fool the academics (that's the bit that I like the most)
In plain English (work in GH):
1. Create some wires that represent the struts and PAY attention on their limits of adjustability.
2. Create a nurbs curve through the points indicated with "balls" in the demo. Patch the nurbs.
3. Trim the nurbs surface with some "indicative" profiles OR use Kangaroo by applying a minimum possible relax state (if the latter add the rhomboid cables as well - they deform by pulling the membrane downwards).
4. Optionally put the real things in place (quite GPU taxing that one - do some Viz control).
best, Peter
…
quite know where I'm going wrong. I can say that I have successfully put together a separate file which will send data directly to the Arduino (switch on a boolean toggle and watch an LED light up... how fun:) but receiving the data is a bit more complicated. For a long time, I was getting a continuous loop error, which would freeze my app. I've changed around the code (see attached file), but I'm still not receiving any data from my COM port (which I know is definitely working because I can turn on the Serial Monitor from the Arduino IDE and see the data coming in). I did have one question: Can you call different routines inside the script class (from Grasshopper), or do you have to always call the run script subroutine? If you guys have any suggestions I would greatly appreciate it. I understand it's a bit tricky to trouble shoot this issue since you may or may not have an Arduino handy to stream the data to your computer... but let me know if you see any glaring issues with the code.
Cheers,
Andy…
ion of surfaces and/or "solids" : it's a very complex assembly of "components" either bespoke or widely available in the market. This demo combo summarizes the "common" cases (but the insulation for the opaque parts is WRONG 100%):
2. Contemporary trends (a bit of nonsense) point towards "liquid" forms. These ARE NOT made via "classic" linear systems. Very few actually can do it (I mean: do it yielding a building that doesn't leak]). Here's a totally wrong take on that matter from a very reputable Swiss facade maker:
And er ... hmm ... this :
3. Facade systems (curtain walls, that is) are classified in 4 classes: (a) the good old known humble stuff like the one shown in the first image (b) semi structural [yes], (c) structural [NO] and (d) planar frame-less systems.
4. Designing any proper facade is impossible with Rhino/GH: you'll need totally different software apps to do it - in real life - despite what most people believe/hope/wish.
5. Designing anything without a proper bottom-top approach (I.e. : first do the pistons then the engine) is the best recipe for not becoming (ever) a pro .…
OSC are just simple horizontal sliders.
The problem I'm facing is that additional toggle items in OSC, which write only 0 or 1, don't get through properly. They do without problems as long as the timer on the FireFly is off. I also can write to the OSC app via gHowl to turn LEDs on or off.
As soon the FireFly timer is back on the toggle get lost in 8 of 10 attempts. The sliders still get through correct.
Any idea if this is because of a timing problem between gHowl and FireFly? I played around with different GH timer settings but that didn’t change much.
Cheers,
Peter…
simple, there are many symetries in 3 main planes. So I used arcs rotated 45° from the main planes and I generate a pentagon which was mirrored and rotated many times.
At the end there are 24 pentagons and 8 hexagons so 32 faces, 54 points/vertex and 84 edges.
It could generate some others tessalation styles
…
need more code) AND in closed ones (see warnings).
2. The real stuff that I have in practice use solely C# code (even for Kangaroo2) and I have a strong feeling that this is not what you want (if you don't speak the language). It does that because GH is just a part (~10%) of the whole AEC arsenal (that is managed via C#) ... so everything must "fit" within the "general" production pipeline (code from some app "goes" to another with the fewer possible changes blah, blah).
So ... this attached could serve as an indicative guideline about the relaxation that Daniel does with his wonder thingy (Kangaroo, that is).
…
le] demo):
1. A transformation Matrix is a 4*4 collection of 16 values that "deform" 3d things according the values in the cells. The orthodox way is to deploy "cells" left to right and top to bottom. Rhino does the opposite (why?) hence we need the transpose method.
2. Since "translate" and "perspective" are "symmetrical" the transpose boolean toggle (within the C#) "flips" rows with columns ... so we get perspective or move.
3. When in perspective "mode" the vanishing points are computed internally within a min/max limit (per X/Y/Z axis) thus avoiding the usual havoc with "extreme" perspective angles (very common "glitz" in pretty much every CAD app - CATIA excluded). Vanishing points (and limits) are oriented with respect the pos/neg value of a given control slider.
Note: slider values are percentages between min/max (mode: perspective) and/or actual values*100 (mode: move).
4.In order to start mastering the whole thing: don't change anything: just play with these 4 sliders selected:
5. The 123 sardine cans challenge: even with DeusExMachine = true (see inside C#: that one redirects the transformation per BrepFace and then joins the breps instead of applying it on a brep basis)... odd things (and/or invalid breps) occur ... thus what is required in order to make things working 100% ??.
he, he
best, Lord of Darkness …
work in both versions. I've tested them in Rhino 5 and they work on my machine. If your screen looks like CarloMaria's, can you double check that all of the .gha files and .dll's have been unblocked. To do this, right-click on each of those files (included in the installation folder) and select Properties. On the pop-up menu, at the bottom of the page, you should see a button that says Unblock (this only appears if they are currently being blocked). For some reason, downloading files off the internet causes some of the files to get blocked... and Rhino 5.0 is more picky about loading them in that instance. Let me know if that helps. Also (and I found this out recently from another user)... it's better if you don't have both 32-bit and 64-bit versions installed on your machine at the same time. It seems that sometimes this can cause a conflict too. When the other user uninstalled the 64-bit version, everything loaded fine in the 32-bit application.
There' haven't been any major changes to the OSC components. I did add a couple of features mainly to parse up some of the messages sent from other applications... notably from GyrOSC (http://www.grasshopper3d.com/video/gyrosc-kangaroo). Some of the messages are sent as lists of 4 values (like the quaternions sent in that app) or lists of 9 values (like the matrices sent using that app). Anyway, other than adding datatype parsers for these, I didn't change anything else about the component... so it should work as before. Let me know if you're still having trouble.
Cheers,
Andy …
some weird engine, you know, he he) IS NOT like designing plain vanilla AEC things.
Therefore features/calculation methods/capabilities as found in MCAD apps (considered off topic by many in our trade) are mandatory for certain types of designs.
Anyway and if we forget FEA stuff, currently I have 3 C# goals:
(1) master the art of controlling the placement of existed blocks in GH defined topology(done),
(2) master the art of baking blocks(done) and
(3) master the art of baking heavily nested blocks that NX/Catia can understand (progress is slow).
…
hy? because instead of doing N*2 "cones", N balls and N rodes ... you should use instance definitions (blocks in plain English): ONE cone, ONE ball ... and unfortunately N rods (Rhino is not a feature driven CAD app, sorry). Complexity (and file size) increases "exponentially" if you want to mimic a real MERO system.
Recently a friend of mine send me (for inspection) a "big" canopy type of W MERO truss with 2300 nodes that was 500Mb (baked). After the "magic" treatment it become 1.2Mb (when baked).
Notify if you need such a C# based solution: (a) for solving any truss on any collection of surface Lists AND (b) putting "real" stuff (exact MERO members) on that (but is a "bit" complex).…