one approach. If you are doing residential or small retail I would recommend something completely different. Having been in the architectural business for 25 years I offer the following illustration of how I am using Rhino/Grasshopper, its strengths, and its weaknesses as I see them.
My current work hovers somewhere between sculpture and small commercial architecture and involves in-house design and Digital/analogue fabrication, usually metal. In the past I have also worked for large traditional A/E firms of 100 people, and smaller 10 person Architectural Design Firms also so I understand those types of practices as well. I find the Digital Design/Fab process to be a welcome change in a profession that has been due for an evolutionary leap forward.
Rhino/Grasshopper is a very intuitive (especially for users with autocad history) design tool primarily with the added feature of providing a seamless transition to digital fabrication whether in-house or not. Up until I discovered Rhino, about 7 years ago, I used AutoCad for the 10 years prior, which offered virtual 2D hand drafting with a few added CAD features. It was really still just traditional 2D drafting with a mouse instead of a pencil. During my autocad period, design did not really change much and remained a more traditional process and CDs were done in AutoCad. Once I found Rhino, my design world immediately became one anchored in 3D form.
In a nut shell, Rhino and Grasshopper are a design tool and are best utilized to design 3D form well suited for CNC fabrication. It is particularly strong when the forms start to stray very far from Euclidean geometries. That being said, it is not my tool of choice for traditional architectural Construction Documents (CDs) nor does Rhino claim to be a significant CD tool.
In my early years of Rhino, the ability to parametrically study a design solution did not exist. Each significant design iteration required the designer to pretty much start over with a new model unless the change was fairly simple. With the advent of Grasshopper, parametric variant studies are now one of its greatest strengths. Grasshopper provides the ability of any number of extremely complicated relationships to be established then instantaneously varied and studied without writing a single line of computer code. Hundreds of combinations can be studied in an extremely short period of time. This is the power of Rhino/grasshopper I value most. A great many Grasshopper users also choose to create incredibly complicated geometric forms. This is another of Grasshoppers great strengths however, many of these "over the top" theoretical forms, though very beautiful and stimulating, seem to remain theoretical or at least prohibitively expensive to actually construct at an architectural scale and with our current state of the art of construction technology. Since my work revolves around built form, I remain tethered to build-ability. Grasshopper paired with CNC fabrication re-catagorizes many complicated forms from "unbuildable" to "very buildable". But even with reality limiting my outcome, Rhino and Grasshopper are incredibly powerful tools able to manage challenging 3D forms while providing ease of virtual infinite variant study.
The bottom line of today's architectural process analysis is that there is no silver bullet in design software. The current state of the art of the architectural process utilizes many types software even within a single project. The work flow of a particular project is as highly sensitive to project constraints and opportunities as the design solution its self. If your work varies, so will your process.
And to your second point regarding industry guidelines. BIM, digital fabrication, sustainability, are all such new complexities in a profession that is changing at an unimaginable rate; never before seen in the profession. I am not aware of any guidelines to this issue but would love to hear from someone that might know of some guidelines particularly about risk and responsibilities regarding sharing digital models with the contractor.
Stan…
Added by Stan Carroll at 10:29pm on March 22, 2010
available yet on this front.
Here's a basic breakdown:
1. Galapagos populates the first generation (G[0]) with random individuals. Basically the sliders are all set at random values.
2. Now we step into the generic evolutionary loop, so G[0] becomes G[n], as this is the same for all generations.
3. For each individual in G[n] the fitness is computed. This is the most time consuming operation in the solver.
4. The individuals in G[n] must populate G[n+1], there are two ways in which this can happen:
- Individuals 'survive' the generation gap and are present in both G[n] and G[n+1]
- Individuals mate to produce offspring that populates G[n+1]
Often, fit individuals will use both vectors.
5. Creating offspring is a complex procedure and there are many factors that affect it.
5a. Coupling: this step involves picking individuals from G[n] for mating couples. Individuals can be picked isotropically (i.e. everyone has an equal chance of being picked, regardless of fitness), exclusively (i.e. only the fittest X% are allowed to mate, but they are all equally likely to mate) and biased (i.e. the fitter an individual, the higher the chance it finds a mate, but everybody has a chance)
5b. Mate selection: this step involves someone picking a mate from G[n]. When an individual has been selected to mate (step 5a), he/she needs to find a mate. Instead of picking another fit individual, mate selection happens based on genetic distance. For example, individuals could be said to prefer very similar individuals, or they could be said to prefer very different individuals, or something in between. This is called the "Inbreeding factor" in Galapagos. A high inbreeding factor will result in 'incestuous' couples, a low factor will result in 'zoophilic' couples. Neither extreme is healthy.
5c. Coalescence: Once a couple has been formed, offspring needs to be generated. Basically coalescence defines how the genomes of mommy and daddy are combined to produce little johnny. The best analogy with biological coalescence is crossover, where P out of Q genes are inherited from mom and (Q - P) genes are inherited from dad. In Galapagos, these genes are always consecutive, thus if the genome consists of 5 genes, the first 3 come from mom and the last 2 come from dad. Or the first 1 comes from mom and the last 4 come from dad. The amount of genes per parent is random. Genes can also be interpolated (there is no analogy for this in biological evolution). Since a single gene in Galapagos is nothing more than a slider position, it is quite easy to average the positions for mom and dad. Finally, genes can be created via preference blending. Very similar to interpolation, but the blending is weighted by the relative fitness of both parents.
5d. Mutations: Once the offspring genome has been created in step 5c, mutations are applied. Mutations are random events that affect gene values in random ways. Although the Galapagos engine supports several kinds of mutations, in Grasshopper it only makes sense to allow for point mutations, as it it not possible grow or shrink the number of sliders.
6. Finally, a new generation is populated and solved for fitness. There is an optional final step which can ensure that fit individuals do not get lost in the process. The "Maintain High Fitness" value controls what percentage of individuals from G[n] are allowed to displace individuals in G[n+1] provided they are fitter. By default this percentage is 10. Which basically means that the 10% fittest individuals in G[n] are compared to the 10% lamest individuals in G[n+1] and if grandpa is indeed fitter, he's allowed to bump junior off the list.
7. This process (step 2 - step 6) repeats until the maximum number of generations has been reached, until no progress has been made for a specified number of generations or until a specific fitness value has been reached.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
occur more than once in the same list, and different elements with identical values can occur more than once. Also, a list may contain lack of elements, referred to as "nulls".
Sets. Strictly speaking a Set is a mathematical construct which adheres to a strict collection of rules and limitations. Basically, a Set is the same as a List, with the exception that it cannot contain the same element more than once, or indeed two or more different elements with the same values. You see, in mathematics there is no difference between a value and an instance of that value, they are the same thing. In programming however it is possible to store the number 7 in more than one spot in the RAM. Grasshopper does not enforce this rule very strongly though, you can use a lot of Set components on lists that have multiple occurrences of the same value. The big difference between Lists and Sets in Grasshopper is that Sets are only defined for simple data types that have trivial equality comparisons. Basically: booleans, integers, numbers, complex numbers, strings, points, vectors, colours and intervals. Lists can contain all kinds of data.
Strings. Strings are text. There's nothing more to it. I don't know why early programmers chose to call them strings, but I suppose it's a better description of the memory representation of them. Strings are essentially sequences of individual characters.
Trees. Trees are the way all data is stored in Grasshopper. Even when you only have a single item, it will still be stored in a tree. A tree is a sorted collection of lists, where each list is identified by a path. A specific path can only occur once in a tree, when you merge two trees together, lists with identical paths are appended to each other. Trees are an attempt to losslessly represent not just the data itself, but also the history of that data. Imagine you have 4 curves {A,B,C,D} and you divide each into 3 points {X,Y,Z}. Then, for each of those points you create a new line segment {X',Y',Z'} and then divide each of those line segments again into 5 points each {K,L,M,N,O}. The way data is stored in trees, it should be possible to figure out whether a point M belongs to X' or to Z', and whether that X' or Z' came from A, B, C or D. This is why paths are often quite long after a while, because they encode a lot of history.
Paths. A Path is nothing more than a list of integers. It's denoted using curly brackets and semi-colons: {A;B;...;Z}. A Path should never be empty {} or have negative integers {0;-1}, but it is certainly possible to create a path like this and it probably won't even crash Grasshopper. Paths are 'grown' by components that (potentially) create more than one output value for a single input value. For example Divide Curve. It creates N points for every single input curve. In cases like this a new integer is appended to the end of the path.
In the next release the Path logic in Grasshopper is somewhat different. I fixed a number of obscure bugs (hopefully without introducing new fresh bugs) and special cased certain operations to somewhat reduce the speed at which paths grow. This may well break files that rely on a specific tree layout, but I hope the temporary sacrifice will be worth the long-term benefits.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
number of divisions on that curve as in the defintion (i.e. by 4). The offset in the def is slightly different and should cull two or three more curves as in the lists that show my aim below.
Basically I want to look into each branch of the groups of points from each closed curve . Marking in a list whether it contains a one or a zero (0= outside 1 = coincidents).
{0;0}0. 21. 22. 23. 2 {0;1} 0. 01. 22. 03. 2 {0;2}0. 01. 02. 03. 0 {0;3}0. 21. 22. 23. 2 {0;4}0. 21. 22. 23. 2 {0;5}0. 21. 22. 23. 2 {0;6}0. 01. 22. 23. 1 {0;7}0. 21. 22. 03. 0 {0;8}0. 21. 22. 23. 2 {0;9}0. 21. 22. 23. 2 {0;10}0. 21. 22. 23. 2 {0;11}0. 21. 22. 23. 2 {0;12}0. 21. 22. 23. 2 {0;13}0. 01. 22. 23. 0 {0;14}0. 21. 22. 23. 2
I want to create a list from these points. That marks each curve that pokes out, in a cull pattern as such:
20022210222202
Using a 1 where there are co-incidents in the curve points and the boundary. A 2 for true (outside points) and a 0 for containment. So I might be able to use the 1 in future developments - however if a true false list is easiest I can live with that.
So could I use F(x) function? - to look for 0 or 1's in each bunch of points and thus list as such for a cull pattern? or will Path mapper help me here? Or can I rely on simply grafting and splitting??
I am usure of the neatest solution and would love to learn. Hope you can direct me.rgrds
J.…
it works is as follows:
The GH_Document has a list of objects that have scheduled a solution (or rather, it maintains a list of callback delegates those objects have registered).
It also contains a TimeSpan field, which remembers the shortest schedule.
If the ScheduleSolution method is called during a solution, the timer won't be started until the solution finishes. So the schedule doesn't control how often the solutions will occur, it controls the delay between solutions.
Let's imagine the following scenario (with insanely scaled up time spans):
At noon exactly, a new solution starts. It doesn't matter what triggered it.
While the solution is still running at 12:01, a component (A) schedules a new solution 15 minutes later. This component registers a callback delegate along with the schedule.
While the solution is still running at 12:02, another component (B) schedules a solution with a 5 minute delay. Since 5 minutes is less than 15 minutes, the document forgets about the 15 minute schedule and instead switches to a 5 minute schedule. (B) does not register a callback.
While the solution is still running at 12:03, a third component (C) schedules a solution with a 10 minute delay. 10 minutes is further into the future than 5 minutes, so the document does not accept this new schedule. (C) does however register a callback.
At 12:05, the solution finishes. The SolutionEnd event is raised, viewports and canvasses are redrawn.
Also at 12:05, the document starts a timer that will fire an event 5 minutes from now, at 12:10.
Nothing happens in this interval, and at 12:10 the schedule timer fires.
The document notices it has a list of two callbacks (registered to A and C respectively), so it invokes them. This allows (A) and (C) to perform some sort of preparation. The most common action is to expire the component that gets the callback, so it'll get included in the imminent solution.
Once the document has invoked all schedule callbacks, it starts a new solution.
Note that (A) and (C) got called back way earlier than they requested. They scheduled solutions for 15 and 10 minutes respectively, but instead got the call only 5 minutes in. They can either play ball and accept the new schedule, or they can choose to not expire themselves and instead schedule a new solution for the future.
If at point 7 instead of nothing happening, a new solution was triggered by some other event (user dragging a slider or changing a wire), all the callbacks are still handled, but now even earlier than they expected.
-----
You can always schedule a solution, which is what makes this solution more flexible than other approaches. It doesn't matter that a solution is already running. It doesn't matter that the schedule comes from another thread*.
On the other hand, schedules are annoying because the time you request is not necessarily the time you get.
Also, if you have 50 components that all want to schedule, you must pick a delay big enough so that they all manage to register their callbacks before the new solution starts. This may be tricky.
* I'm actually not 100% sure about the threadsafety, it could be that there's bugs under rare conditions.…
Added by David Rutten at 7:00am on February 11, 2015
http://www.pilkington.com/) dominates the planar market. Charges "around" 1K Euros per m2 for a "plain" system. Personally in bespoke projects I design my own stuff but due to economies of scale ... they cost a bit more (but they look far more sexier, he he) . On the other hand only in a bespoke project I could dare to suggest such a solution (for a large scale building we are talking lots and lots of dollars).
3. Several scales below (aesthetics) you can find static alu systems (either structural or semi-structural):
Or hinged systems (either structural or semi-structural) capable to adapt in contemporary double curvature facades/roofs/envelopes/cats/dogs etc etc ... pioneered worldwide many years ago by my best friend Stefanos Tampakakis (everybody in UAE knows that genius man: http://www.alustet.gr/company.html):
4. With the exception of some paranoid things that Guru Stefanos does for Zaha these days we are talking about planar "facets" (obviously a triangle is such a planar facet). The current trend is: the more edges the better (humans excel in vanity matters). But achieving planarity in, say, quads (like yours) it adds another "restriction" on what you are doing. Until recently Evolute Tools Pro was the only answer. But right now ... well let's say that in short time you'll be greatly surprised by some WOW things in this Noble Forum, he he.
5. MERO (and obviously custom systems) can adapt (at almost no extra charge) in anything imaginable. But in a bespoke building ... well.. you know ultra rich people: they don't want MERO anymore since "everybody" does MERO solutions. Vanity, what else?
6. Smart Glass would become a must in the years to come: Eco-Architecture MUST dominate everything you do. On the other hand spending millions to do some extra WOW stuff (Vanity) ... it doesn't look to me very Eco-Friendly/Whatever ... but let's pretend so, he he.
7. I'm Architect but a bit different from the norm: for instance I smoke cigars (highly politically incorrect stuff) I always talk openly (ditto) and I ride lethal bikes (ditto).
may the Force (as always the Dark Option) be with you: go out there and kill them all.
best, Peter
…
Ladybug + Honeybee:
(Follow steps 0-4 for basic functionality and 0-9 for full functionality)
0. If you have an old version of LB+HB, download the file here (https://app.box.com/s/ds96em9l6stxpcw8kgtf)
and open it in Grasshopper to remove your old Ladybug and Honeybee version.
1. Make sure that you have a working copy of both Rhino and Grasshopper installed.
2. Open Rhino and type "Grasshopper" into the command line (without quotations). Wait for grasshopper to load.
3. Install GHPython 0.6.0.3 by downloading the file at this link (http://www.food4rhino.com/project/ghpython?ufh) and
drag the .gha file onto the Grasshopper canvas.
4. Select and drag all of the userObject files (downloaded with this instructions file) onto your Grasshopper canvas.
You should see Ladybug and Honeybee appear as tabs on the grasshopper tool bar.
(If you are reading this instruction on github you can download them from http://www.food4rhino.com/project/ladybug-honeybee)
5. Restart Rhino and Grasshopper. You now have a fully-functioning Ladybug. For Honeybee, continue to the following:
6. Install Radiance to C:\Radiance by downloading it from this link (https://github.com/NREL/Radiance/releases/download/4.2.2/radiance-4.2.2-win32.exe) and running the exe.
7. Install Daysim 4.0 for Windows to C:\DAYSIM by downloading it at this link (http://daysim.ning.com/page/download) and running the exe.
8. Install EnergyPlus 8.1 to C:\EnergyPlusV8-1-0 by going to the DOE website (http://apps1.eere.energy.gov/buildings/energyplus/energyplus_download.cfm), making an account, going to "download older
versions of EnergyPlus, selecting 8.1 and running the exe.
9. Copy falsecolor2.exe (http://pyrat.googlecode.com/files/falsecolor2.exe) and evalglare.exe (http://www.ise.fraunhofer.de/en/downloads-englisch/software/evalglare_windows.zip/at_download/file) to C:\Radiance\bin
10. You now have a fully-working version of Ladybug + Honeybee. Get started visualizing weather data with these video tutorials (https://www.youtube.com/playlist?list=PLruLh1AdY-Sj_XGz3kzHUoWmpWDXNep1O).
After I've done all the above I followed this video
https://vimeo.com/96155674
And everything works well.
…
e actual method.
Below, I descibe how they work:
1) drag "scheduleDay" onto the canvas
2) drag some Gene Pool lists onto the canvas and connect a number slider - from 0 to 3.
3) connect the Gene Pool list to _genePool input. The component change some important features of the Gene Pool list automatically. Now you have LB_GenePool!!
4) choose the template that it's suitable for you.
5) disconnect LB_GenePool and if templates are not good, you can change them manually
6) drag "Ladybug annual schedule" onto the canvas
7) Connect LB_GenePools to inputs for the days of the week, Epw file and if you want to "_holiday" (in this way you consider holidays). Now you have your simple schedule.
8) a small workflow to visualize it into Rhino..
9) Connect "Ladybug annual schedule" to "Honeybee_Create CSV Schedule" to make your csv Schedule
You could make a schedule more complex than the one in the example above.
You can do that with _analysisPeriod input.
Bests
Antonello…
nted" in space (at instance definition creation phase): indicates the obvious fact that if garbage in > garbage out (try it).
2. Load the GH thing. Task for you: Using Named Views locate the points of interest as described further and make a suitable view. That way you can navigate rather easily around (hope dies last).
3. Your attractors are controlled from here:
The slider in blue picks some attractor to play with. You can use this while the K2 is running.
4. Don't change anything here (think of it as a black box: who cares how it works? nobody actually):
5. Enable the other "black box": job done your real-life stuff is placed:
6. Enable the solver: your "real-life" things start to bounce around:
7. Go there are play with the slider. A different attractor yields an other solution:
8. With real-life things in place if you disable the C# ... they are instantly deleted and you are back in lines/points and the likes:
9. Either with instance definitions or Lines/points change ... er ... hmm ... these "simple" parameters and discover the truth out there:
10. Since these are a "few" and they affect the simulation with a variety of ways ... we need a "self calibrating" system: some mini big Brother that does the job for us. Kinda like applying safely the brakes when it rains (I hate ABS mind).
NOTE: the rod with springs requires some additional code ,more (that deals with NESTED instance definitions) in order to (b) bounce as a whole and at the same time (b) elongates or shrinks a bit.
More soon.
…
ng/702/30
EDIT: DK2 works, not with positional tracking yet (14/09/15)
Source is here:
https://github.com/provolot/RhinoRift
Steps:
1) Download these files (also attached below):
https://github.com/provolot/oculus-grasshopper/raw/master/oculus-grasshopper_v0.4.ghx
https://github.com/provolot/oculus-grasshopper/raw/master/OpenTrackRiftGrasshopperUDP.ini
https://github.com/provolot/oculus-grasshopper/raw/master/oculus-grasshopper-test_v0.1.3dm
2) Download OpenTrack - http://ananke.laggy.pk/opentrack/, and setup/install. Once installed, double-click to open.
3) In OpenTrack, load the 'OpenTrackRiftGrasshopperUDP.ini' profile. Click the 'Start' button and move your Rift around - make sure that it looks like the Yaw/Pitch/Roll data is being sent. TX/TY/TZ will all be 0, as Oculus doesn't have absolute positioning data.
4) In Rhino, open the test 3dm. You'll notice that there are two viewports - called 'LeftEye' and 'RightEye'. These have been placed to mimic where the screens should be for the Oculus Rift --- but only when Rhino is in fullscreen mode, with the command 'Fullscreen'. The placement needs to be tweaked, but should work.
If you want to use your own model, you can load your own .3dm file in Rhino, then you can right-click on the viewport name, and go to Viewport Layout > Read from File. If you then load my test file, Rhino should open my two viewports, sized correctly, onto your model.
The placement of these viewports need to be tweaked; if you find a better viewport layout, upload an empty Rhino file with your viewports, and we can share eye-layout 'templates'!
5) In Grasshopper, open the .ghx definition. Everything that is multiple-grouped is a value that can be changed. Two things here:
- IPD: Set this and convert it to the proper units for your model.
- Left/right viewport names. In this case, leave this as-is, since you're using my example file.
6) Turn on the Grasshopper Timer, if it isn't on already.
7) In the GH definition, toggle 'SyncEyes' to be True. Then, in the left viewport, try orbiting around with the mouse. The 'RightEye' viewport should move around as well, pretty much simultaneously.
8) In OpenTrack, click 'Start', then toggle 'ReadUDP' to be True. You should see the 'OpenTrackInfo' panel fill with data that's constantly changing.
9) Move around the landscape with your camera, and when you set on a starting view that's ideal, click the triangle of the Data Dam component to 'store' the data.
10) Finally, toggle 'OculusMove' to be true. If all works correctly, both viewports should move based on the Rift's movement.
Let me know if you have any problems!
Cheers,
Dan…
Added by Dan Taeyoung at 11:47pm on December 10, 2013