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).…
ime runs out, of unexplored planets. These masters of gravity risk their lives for the adrenaline, dodging gigantic rocks that could hit their ships crashing into planets and no hope that they can be rescued.
Requires Kangaroo and Human (and in full with Firefly).
Goal of the game
You have four minutes to get six stars and reach the goal. Or die trying.
If a satellite hits you, you will leave fired.
The game has three types of control
1 Using the keyboard (requires Firefly). 2 With an external device such as a smartphone or tablet (requires Firefly and TouchOSC app). 3 Using the mouse, from the grasshopper interface.
Download files
Gh, 3dm, touchosc and textures.
Video
http://www.grasshopper3d.com/video/space-riders…
wich is nice actually :-) But I had 2 problems that make every thing just impossible to use : DIRECTION OF STEPS :
The motor can just reach one direction (for exemple clockwise) and when comes time to switch... not possible.
Details : When I put a value in HD.SM in V input, I put for exemple 100 with a slider so i have 100 steps and it works. Then I write 200, still working. and when I put a value that is less than the last higher value, for exemple 180 in my case the motor go endless to an higher amount, i mean 201,202,203...1000 etc... Dont undestand why :-/ SPEED : The speed is really really slow.
Details : The Firefly stepmotor component use the same library as heteroduino wich is Accelstepper.h but still going way faster. I tried lot of values in the S input (speed) but is not changing the speed that much, and sometimes its even changing the steps.
If there is another place where I have to post this, let me know also and I'll do it :-)
See you soon and hope some people are interested in the same problem ^^thanks :-)…
(http://www.food4rhino.com/app/quelea-agent-based-design-grasshopper) take like 40 seconds when the toggle activates to go from one end of the ramp to another.
With proximity 3d i'm analyzing each instance the agents are closer than x units. In picture 3 we can see that in 212 instances the agent are closer than those x units.
Finally all the genes that controll the ramps are connected to the G of octopus component and one of the conflicting objectives connected to the O of octopus component is the number of instance quelea agents get close.
So the thing I need is to iterate the ramps controling the genes with octopus but activating the boolean toggle (quelea run) each time the ramps are modified so the agents take 40 seconds to perambulate the environment, analyze the instance they get close and let octopus iterate again searching for a optimized environment.
…
basic code:
Rhino5Application rhino_app = new Rhino5Application(); rhino_app.Visible = 1; rhino_app.RunScript("_Grasshopper", 0); dynamic grasshopper = rhino_app.GetPlugInObject("b45a29b1-4343-4035-989e-044e8580d9cf", "00000000-0000-0000-0000-000000000000") as dynamic; grasshopper.OpenDocument(@"C:\Temp\test1.ghx"); bool asignRes = grasshopper.AssignDataToParameter("Num", (Object)0.5); grasshopper.RunSolver(true);
On the 0.9.0006 version the asignRes gets "false" (and does not change the param of-course) while on 0.8.0066 asignRes gets "true" and everything works fine.
Am I doing something wrong? Did GH automation change? Is it a bug in 0.9.0006 ?
I added the file test1.ghx but its really trivial :)…
nd me to kill him but give him my regards anyway) is still around in BirdAir Italy ... talk with him.
3. Hope that you understand that designing the "details" means some decent MCAD app + FEA + this + that. "Fusing" this with some abstract graphic editor like GH ... is ... er ... impossible (in real-life, you know, he he ). Generative Components on the other hand may qualify but requires a lot of time in order to fully master it (approx 2-4 years).
4. FormFinder ... well ... that's utterly Academic but on the other hand ... (good luck).
http://www.formfinder.at/main/software/team/
5. http://tecno.upc.edu/cotens/software.htm
6. This is the second best (after the BirdAir internal stuff) but costs an arm and a leg
http://www.ndnsoftware.com/
7. This is a !%$!%$ in the !%$%!$:
http://www.sofistik.com/no_cache/loesungen/fem/leichte-tragwerke/
My realistic (low cost) advise:
use K1/2 (especially if you are after "parametric" exploitation(s)) ... and then diversify tasks: stuff for the structural department, stuff for whom claims that he can(?) design the "details" ... whilst be in a constant contact with the membrane provider (and in fact: the contractor for doing the real thing as well)
…
file. A TSpline made thing in fact.
2. This atroci ... er ... hmm ... I mean unspeakable beauty uses an exo-skeletal load bearing structure hence is THAT big (BTW: Apparently nobody knows what thermal bridge is nor thermal expansion nor vapor condensation ... but these are "minor" details these holly blob days, he he).
3. 2 means that some nodes of that "grid" MUST "meet" floors in order to support them and (hopefully) withstand some seismic forces. BTW: A Richter scale 9 (for an hour) is all what this building actually needs (that's acid "humor").
4. The "smarter" way to do this is to spread "some" (i.e a lot) random points (Note: David's algo yields "evenly-spaced-points" within the limits of the possible) on the guide blob (a polysurface in fact).
5. Then ... you need some algo that tests proximity AND "adjusts" the Z in order to have some node points "co-planar" (Z) with the floors.
6. Then you triangulate all that stuff (the points, that is) using some decent Ball Pivot Algorithm (NOT Delauney) and you get a triangulated mesh that "engulfs" the guide blob. If you want some quads (as shown) this is also possible.
7. So you have edges ... i.e poly lines (per mesh face) and if you offset them ... you have "drilling" profiles that you must use against a second guide "thickened" blob for creating a continuously smooth exo-skeletal LBS (as shown). Of course Rhino (being a surface modeller) could require years to do this solid difference opp (or an eternity).
8. Rounding the "lips" of that LBS Brep is out of question with Rhino or GH (but it can been done very easily using other apps). Then you must "split" the Brep (in modules? in nodes + "rodes"? you tell me) in order to make it in real-life (what about forgetting all that?, he he).
9. Then, there's the glazing thingy that is made via quads meaning planarity. This is achievable with Kangaroo2 but is a bit tricky.
Moral: WHAT a gigantic pile of worms is this thread of yours...
more soon.
…