Visiting School Rio de Janeiro will collaborate with the Centro Carioca de Design with the support of Columbia University Studio X to investigate new possibilities for the urban infrastructure surrounding World Cup Stadiums. Nation-wide, there has been significant investment to build and renovate stadiums for the 2014 World Cup in order to meet the required standard FIFA regulations (‘Padrão FIFA’). At the same time, there has been a large public demand for equal investment into transport systems, public space, and public programs such as hospitals and schools. The Visiting School will tap into the momentum of this movement, and promote a series of interventions within and around the World Cup structures, proposing new public programs and standards for their legacy. Students can choose to focus directly on the Maracanã stadium in Rio de Janeiro, the venue for the Final match of the World Cup. The intense ten-day workshop will employ computational design and digital fabrication to introduce a design methodology that creatively automates and promotes transformation, mutation and complexity for these infrastructure interventions.
Prominent Features of the workshop
Teaching teamThe teaching team will include a mix of tutors from the Architectural Association, including Theodore Sarantoglou Lalis e Dora Sweijd (lassa-architects.com) of Diploma 17, and locally-based architects, urban-designers and experts, mediated by locally-based Visiting School directors, to promote cutting-edge innovative strategies informed by local political, economic and construction issues.
Computational skillsThe workshop will teach advanced digital modeling and parametric design skills, no previous experience is needed. A group of specialist computation tutors will conduct an initial skills workshop and continue to assist throughout the workshop to develop the individual projects of the participants.
Digital FabricationA series of physical models will be built using digital fabrication techniques that will be taught during the workshop, no previous experience is needed.
Applications
1) You can make an application by completing the online application found under ‘Links and Downloads’ on the AA Visiting School page. If you are not able to make an online application, email visitingschool@aaschool.ac.uk for instructions to pay by bank transfer.
2) Once you complete the online application and make a full payment, you are registered to the programme. A CV or a portfolio is not required.
The deadline for applications is 11thApril 2014.
All participants travelling from abroad are responsible for securing any visa required, and are advised to contact their home embassy early. After payment of fees, the AA School can provide a letter confirming participation in the workshop.
Fees
The AA Visiting School requires a fee of £695 per participant, which includes a £60 Visiting membership fee.
Fees do not include flights or accommodation, but accommodation options can be advised. Students need to bring their own laptops, digital equipment and model making tools. Please ensure this equipment is covered by your own insurance as the AA takes no responsibility for items lost or stolen at the workshop.
Eligibility
The workshop is open to current architecture and design students, phd candidates and young professionals.
…
with various protocols and applications.
One module, led by Luis E. Fraguada will focus on the communication between Processing and Grasshopper utilizing the various protocols available through the gHowl add on for Grasshopper.
The four modules include:
Processing+Grasshopper: Luis E. Fraguada (Barcelona) - http://tinyurl.com/6m49x5e
Processing+OSC: Alba Corral (Barcelona) -
Processing+Shypon: Miguel Espada (Madrid) - http://tinyurl.com/7no8egx
OpenFrameworks+Kinect: Carles Gutierrez (Barcelona) - http://tinyurl.com/79mmsnd
For registration, please email: hola@welovecode.net.
…
Added by Luis Fraguada at 4:11am on February 29, 2012
r [String Split] in version 0.9.0014)
The [Timer] prompts a component to up date at the set interval. in this case every 1 seconds.
The [Time] param is a placeholder for a time in the same way that a [Number] param can hold real numbers.
By using "Now" as the input to the [Time] param you will get the current time when the param updates. therefore every second it resets to the current time.
The [Text Split] is there to separate the output of [Time] in a string format at every colon ":"
Therefore "Monday, 13-MAY-2013 (11:23:30)" would become:
0 Monday, 13-MAY-2013 (1
1 23
2 30)
The next two components use this to convert it into the current seconds. Because we are after the last item "30)" we can use [List Item] on a reversed list to get the last item.
Now we have to remove the ")" with [Replace String] but we are replacing it with nothing so it disappears.
The Arrow is part of the Sketch Tool Functionality of the canvas.
Lastly the 3 different inputs should go into the three different Inputs of the [Stream Filter]
…
nally used on the pre-intersected multizone file, which also needed the full exterior distribution only.
Running your revised version now on these machines here, the result is identical to the one you posted above (below screenshot from run on my machine; and yes, the last GH file I sent is the one from which the previous screenshots originated)
(CMap result from your attached script ComfMap_CWM, ran on MD machine)
That is, incidentally, identical to what my script produced even before your changes!
In an earlier post, you showed a result image that comes much closer to what I would expect the output to be (so, in fact, you have already produced two different results):
(screenshot from your earlier post on July 11, 2016 at 10:05pm)
The "error" I was/am hence chasing is in the difference between these two results. The last screenshot from your earlier results shows a radiant temperature dropoff that is much more in line with the contribution of the cold glazing temperatures as evident in the E+ results. What do you think?
Apart from that, I am glad that now, at last, our outputs from the same script are identical on both machines. The usercustomLibrary has not changed, I have however attached it again. Other GH files are usually not open, no; the last results all came from single open file GH instances.
Thank you for your help again Chris- it's an interesting issue. I owe you a beer (or a few) should you stop by in Berlin one day!
Best,
Max
…
his comes in the form of an HTML page with links to every component, so you will need to view it in your web browser. (I use Chrome and it doesn't seem to be working correctly, but when opened in IE its fine.)
2) Included in each help topic for each component is the Inputs and Outputs descriptions and data types.
3) You supply the data. What you supply and how you supply it is for you to decide. There are umpteen different ways. Are you asking for a list of those ways for each input?
4) Points can either be Rhino objects or 3D co-ordinates. To create a point you can use any of these methods, but it mostly comes down to user preference. I like using Panels as this displays outside of the component.
5) Because of the nature of vectors they represent magnitude and direction but they don't have an independent location, so there is a component that will display vectors in Rhino.
6) The user.
7) There is a Primer on the front page. Here you find the Basics, but because GH is ever evolving in its current beta state you might find things that aren't relevant any more or simply don't work the same. And here is the reason why nobody is writing an update because it could be soon out of date.
8) Importing images by either dragging them from explorer onto the canvas or right click context menu Image...
9) Single line = Single Item of Data. Double line = Multiple items of data on the same Branch. Dashed Double Line = Multiple Data on Multiple Branches.
10) User preference
11) Toolbar management is probably the bane of David's life. Most things are logically placed. For example the Curve Tab, Primitives are any simple curve types that you are creating from scratch. Similarly Splines is for more complex curve types created from scratch. Analysis is where you find components that are finding answers supplied by curves, control points, curvature, parameters, end points etc. Division is a subset of this category but has a group of its own. And Utilities is where you find curve related actions that you want to perform, offsetting, rebuilding projecting, exploding etc.
12) I would image it would have been the Point On Curve component in Curve>Analysis. Why that group? You are not putting a point on a curve you are analysing a curve for the location of a point based on some parameters that you are supplying. For example "what is the mid point?"
I hope this goes some way towards answering you questions. No doubt this will have generated more so don't be afraid to ask, it took me several releases of Explicit History (aka Grasshopper) before I realised what the egg did, it never occurred to me that I could put my objects into Rhino when I was finished. Or the fact that I could use panels to 'see' data outputs.
Al the best,
Danny…
Added by Danny Boyes at 3:48am on December 9, 2010
should follow the instruction which mostapha has wrote in https://github.com/mostaphaRoudsari/ladybug/blob/master/resources/I...
Instructions for Installing Ladybug + Honeybee: (Follow steps 1-6 for basic functionality and 1-11 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 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 files in the "userObjects" folder (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. Download the files at this link (https://app.box.com/s/bh9sbpgajdtmmystv3n4), unzip them and copy the contents to both C:\ladybug and C:\Users\[yourUsername]\AppData\Roaming\Ladybug. 6. Restart Rhino and Grasshopper. You now have a fully-functioning Ladybug. For Honeybee, continue to the following: 7. Install Radiance to C:\Radiance by downloading it from this link (https://github.com/NREL/Radiance/releases/download/4.2.2/radiance-4...) and running the exe. 6. Install Daysim to C:\DAYSIM by downloading it at this link (http://daysim.ning.com/page/download) and running the exe. 8. Install Energy Plus 8.1 to C:\EnergyPlusV8-1-0 by going to the DOE website (http://apps1.eere.energy.gov/buildings/energyplus/energyplus_downlo...), 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/evalgla...) to C:\Radiance\bin 10. Download the OpenStudio Libraries (https://app.box.com/s/y2sx16k98g1lfd3r47zi) and unzip them to C:\ladybug\OpenStudio. 11. 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_XGz3kzHUoWmpWDX...).
It works for me..
Agus…
tions or components.
Participants will learn concepts of object oriented programming and essential syntax of C# to endeavour into personally extending cad toolsets. The workshop will focus on introducing the .NET language C# and the Software Development Kit (SDK) RhinoCommon.
Topics
- use of Script Component within Grasshopper
- explanation to the .NET Framework
- introduction to RhinoCommon SDK
- basics of imperative / object-oriented programming
- data types, operators, properties
- variables, arrays, lists, enumerations
- methods
- objects, classes
- control structures: conditional statements (if, else, switch)
- control structures: loops (for, foreach, while, do)
- walk-through iterative und recursive code-samples
- use of RhinoCommon Geometry class library: creation, sorting, editing of Geometry (Points, Vectors, Curves, Surfaces)
- adding (baking) geometry to the active Rhino 3DM Document, including attributes (Name, Layer, Colors etc.)
- introduction to the Integrated Development Environment MS Visual Studio Express Edition
- compiling code to dll/gha files (plug-ins) / making your own Grasshopper custom components
Grasshopper wird auf der .NET Softwareplattform entwickelt, und kann ebenso wie das CAD Programm Rhinoceros mit "RhinoCommon", einem Software Development Kit, erweitert werden.
Dieser Kurs richtet sich an Designer, Architekten, Ingenieure und Techniker, welche mit dem grafischen Algorithmus-Modellierer "Grasshopper3d" sowie dem CAD-Programm "Rhinoceros" bereits vertraut sind und einen Einstieg in die Programmierung von Geometrie erlernen möchten.
Der Kurs Grasshopper II folgende Grundlagen:
Kennenlernen der Script Componente
Erläuterung zum .NET Framework
Einführung in RhinoCommon SDK
Grundlagen d. imperativen / objektorientierten Programmierung
Datentypen, Operatoren, Eigenschaften
Variablen, Reihen, Listen, Aufzählungen
Methoden
Objekte und Klassen
Kontrollstrukturen: Bedingte Ausführung, Schleifen
praxisnahe iterative und rekursive Code-Beispiele für generatives Design unter Verwendung der RhinoCommon Geometrie Klassenbibiliothek - Punkt- und Vektorgeometrie erstellen, sortieren, bearbeiten, Flächen und Netze erstellen - Geometrie in das Rhino 3DM Dokument baken, einschließlich Attribute (Name, Layer, Color)
Einführung in die Entwicklungsumgebung MS Visual Studio Express Edition
Kompilieren von Programmerweiterungen (plug-ins) als Komponenten (custom components)
Details, Anmeldung:
www.vhs-stuttgart.de
Trainer Peter Mehrtens
Kursdauer: 3 Tage x 8 h
Freitag, 21.02.2014, 9:00-17:00 Uhr Samstag, 22.02.2014, 9:00-17:00 Uhr Sonntag, 23.02.2014, 9:00-17:00 Uhr Ort: VHS Stuttgart, Fritz-Elsas-Str. 46/48
Teilnahmegebühr 510,00 €…
ocessed once Grasshopper is done with whatever it's doing now.
3) Grasshopper tells the Slider object that the mouse moved and the slider works out the new value as implied by the new cursor position.
4) The slider then expires itself and its dependencies ([VB Step 1] in this case, but there can be any number of dependent objects).
5) When [VB Step 1] is expired by the slider, it will in turn expire its dependencies (VB Step 2), and so on, recursively until all indirect dependencies of the slider have been expired.
6) When the expiration shockwave has subsided, runtime control is returned to the slider object, which tells the parent document that stuff has changed and that a new solution is much sought after.
7) The Document class then iterates over all its objects (they are stored in View order, not from left to right), solving each one in turn. (Assuming the object needs solving, but since in your example ALL objects will be expired by a slider change, I shall assume that here).
8) It's hard to tell which object will get triggered first. You'd have to superimpose them in order to see which one is visually the bottom-most object, but let's assume for purposes of completeness that it's the [VB Step 1] object which is solved first.
9) [VB Step 1] is triggered by the document, which causes it to collect all the input data.
10) The input parameter [x] is asked to collect all its data, which in turn will trigger the Slider to solve itself (it got expired in step 4 remember?). This is not a tricky operation, it merely copies the slider value into the slider data structure and shouts "DONE!".
11) [x] then collects the number, stores it into its own data structure and returns priority to the [VB Step 1] object.
12) [VB Step 1] now has sufficient data to get started, so it will trigger the script inside of it. When the script completes, the component is all ready and it will tell the parent document it can move on to the next object (the iteration loop from step 7).
13) Let us assume that the slider object is next on the list, but since it has already been solved (it was solved because [VB Step 1] needed the value) it can be skipped right away, which leaves us with the last object in the document which is still unsolved.
14) [VB Step 2] will be triggered by the document in very much the same way as [VB Step 1] was triggered in step 9. It will also start by collecting all input data.
15) Since all the input data for [VB Step 2] is either defined locally or provided by an object which has already been solved, this process is now swift and simple.
16) Upon collecting all data and running the user script, the component will surrender priority and the document becomes active again.
17) The document triggers a redraw of the Grasshopper Canvas and the Rhino viewports and then surrenders priority again and so on and so forth all the way up the hierarchy until Grasshopper becomes idle again.
[end boring]
Pretty involved for a small 3-component setup, but there you have it.
To answer somewhat more directly your questions:
- The order in which objects are solved is the same as the order in which they are drawn. This is only the case at present, this behaviour may change in the future.
- Adding a delay will not solve anything, since the execution of all components is serial, not parallel. Adding a delay simply means putting everything on hold for N milliseconds.
- [VB Step 1] MUST be solved prior to [VB Step 2] because otherwise there'd be no data to travel from [GO] to [Activate]. The only tricky part here is that sometimes [VB Step 1] will be solved as part of the process of [VB Step 2], while at other times it may be solved purely on its own merits. This should not make a difference to you as it does not affect the order in which your scripts are called.
--
The Man from Scene 24…
Added by David Rutten at 4:43pm on December 10, 2009