ne diverse digital design methodologies and the use of different tools such as Autodesk Maya, Rhinoceros and Grasshopper.
Building up technical skills will provide the attendees with a solid platform from which to start rethinking and exploring innovative architectural ideas in collaboration with the team and the tutors.
URBAN FIELDS
Phase I
In the first part of the workshop attendees will be looking at field conditions and how to generate and design such fields that can help structure a possible urban condition in Florence.
We will be exploring dynamic systems, geometric systems and network theories to generate and design an abstract field condi- tion that extends the urban experience of the city onto the vertical dimensions of towers. Simple operations that would span variations from an initial state will give rise to high level of com- plexity.
The goal of this exercise is to create a rich and diversified intel- ligible urban space that can be later on subjected to local inter- ventions and zooming in to locally enhance each design.
AGENT - BODIES POLYMORPHISM
Phase II
The second part of the workshop will build upon first phase; par- ticipants will select one archetype (high rise tower) as a study model for further development.
Besides engaging with multi agent algorithms design strategies, attendees will address strategic utilisation of structurally and environmentally generated morphologies to design coherent and highly differentiated tower exo-skeletons.
Tutors will introduce agent-bodies polymorphism in order to explore the generation of structural aware and capable geom- etries through agent based formation of non-linear hierarchies and emergent patterns. These agent-bodies will operate in a complex spatial manner to form structure, partitions or enclo- sure and will operate across scales, creating a poly-scalar level of detail.
Attendees will speculate how autonomous systems can cre- ate new structures and intelligent distribution of structural elements, about new collaborative strategies of construction and the performativity they will evoke (performance, effects, responsiveness, interaction).
Fees
Early registration (before 1st June)
Students 390€ - Professionals 440€
Late registration (after 1st June)
Students 490€ - Professionals 540€
More info and Applications
https://www.ax-om.com/edu/polymorphism/
…
ugh information (whether coming from environmental analysis or any kind of database), extracting and managing informations for construction processes all require an understanding of data structures in order to build seamless design-to-construction pipelines. Through visual scripting in Grasshopper (Generative modeling plug-in for Rhinoceros) participants will learn how to build and develop parametric data structures (from basic simple lists to complex data trees), data-driven geometry and envelopes and how to extract relevant informations from such models for construction processes. Participants will also develop a personal envelope project and its full design-to-construction pipeline. [.]TopicsTheory: - Lecture: “Data Obsession” – computational designer as a new professional profile and the role of information and complexity in contemporary architectureTechnique: - Software interface - Components - Lists & Data Tree: management, manipulation, visualization - Geometry generation from data stream - Base exercises (Box morph, Image sampler, Floor sections, Attractor field, Multisection Pipe, Paneling) - Advanced exercise: Data-reactive component – data-reactive tessellation on NURBS surface. Data coming from environmental analysis or spreadsheet table - Advanced exercise: Data extraction from previous tessellation, visualization and storage in spreadsheets. - Advanced exercise: geometry optimization for construction[.]Software & skills:Basic modeling skills in Rhino are required. Participants should bring their own laptop with pre-installed software (software download links will be given after subscription).[.]Tutors:Alessio Erioli + Andrea Graziano – Co-de-iT (GH & design tutors).[.]Venue:The workshop venue will be:Polycollege WienJohannagasse 21050 Wienhttp://www.vhs.at/johannagasse.html[.]Calendar & Timetable:The workshop will have the following timetable throughout all the 4 days: 9:00-13:00 lesson+tutoring 14:00-17:00 lesson+tutoring[.]Subscription fees:For participants who register before 30/08/2012 we offer a EARLY BIRD feesE.B. – educational* : € 320 + VAT E.B. – professional: € 390 + VATafter 30/08/2012 will be in place the STANDARD fees:STANDARD fees – educational* : € 390 + VAT STANDARD fees – professional: € 490 + VAT* students, teachers, researchers & PhD (proof of status required).The deadline for registration is 06/09/2012; The workshop has a maximum of 30 places available and will be activated with a minimum number of 15 partecipants.[.]Application:To register please fill this FORM and send it via e-mail to:3ddreaming@gmail.com or ck@kkkc.at[.] Organized by:This workshop is organized by Co-de-iT in collaboration with:3d-dreaming.com – Architecture from a digital point of viewKKKC – Mediaware trading GmbH…
ariations, but each seems to lack the sophistication to generate a ‘zip’ that retains its general shape over the whole curve.
Basically I’m trying to understand the process behind this: http://www.schindlersalmeron.com/index.php?option=com_content&task=view&id=27&Itemid=29
Here is an image of the latest definition.
1. I draw a curve in Rhino, and then define it in grasshopper. I also define the point as the beginning of the curve.
2. I offset the curve to a specified depth, based on structural member
3. I generate a line from the point at a tangent to the curve, then rotate it a
defined angle.
4. I find the intersection between the rotated line and the offset curve. Then generate a tangential line from this new point
5. Line is rotated at the same angle as before.
6. Process repeated.
The idea is to then generate a circle of defined diameter at each of the intersection points, then find the intersection of the circles with the curves, which are then joined up with straight lines to create the ‘zip’. This would mean a lot of copy-pasting and list management that I’m not really capable of with my limited grasshopper experience.
I had tried generating points at intervals along the curve and then eventually generating lines from one line to another with a shifted listed to form the tooth angle, but it wouldn’t retain its shape over the entirety of the curve.
Does anyone have any advice for how to tighten up this definition? I imagine that I will need to delve into vb.net scripting to address the recursive nature of the process.
I fear that I’m going about this in entirely the wrong way...
Of course the next step is to flatten out the curve for CNC manufacture.
Any help would be greatly appreciated! The potential for using grasshopper in design is amazing, and I would love to gain a deeper understanding of it!…
edit 29/04/14 - Here is a new collection of more than 80 example files, organized by category:
KangarooExamples.zip
This zip is the most up to date collection of examples at the moment, and collects t
complicated than it seems as I have an event and a subscriber method receiving data from a serial port.
In the code below, the strings received within myReceivedLines appear when connecting with the serial port (when connecttodevice is true). However they disapear when I launch another command (when homeallis true).
As you recommended in your reply, I have added the field called myReceivedLineswithin the class so that I could use the method String.Add() to all the feedback received and commands sent.
Why does the feedback dispear when a command is sent? Is the string going to myReceivedLine disappearing because they happen within a subscriber method or is it related to the DA.SetDataList() method used to assign myReceivedLinesto the output?
Many thanks!
public class SendToPrintComponent : GH_Component { //Fields List<string> myReceivedLines = new List<string>(); SerialPort port; //subscriber method for the port.DataReceived Event private void DataReceivedHandler(object sender, System.IO.Ports.SerialDataReceivedEventArgs e) { SerialPort sp = (SerialPort)sender; while (sp.BytesToRead > 0) { try { myReceivedLines.Add(sp.ReadLine()); } catch (TimeoutException) { break; } } } protected override void SolveInstance(IGH_DataAccess DA) { //Opening the port if (port == null) { string selectedportname = default(string); DA.GetData(1, ref selectedportname); int selectedbaudrate = default(int); DA.GetData(2, ref selectedbaudrate); //Assigning an object to the field within the SolveInstance method() port = new SerialPort(selectedportname, selectedbaudrate, Parity.None, 8, StopBits.One); //Enables the data terminal ready (dtr) signal during serial communication (handshaking) port.DtrEnable = true; port.WriteTimeout = 500; port.ReadTimeout = 500; } //Event Handling Method bool connecttodevice = default(bool); DA.GetData(3, ref connecttodevice); if (connecttodevice == true) { if (!port.IsOpen) { port.DataReceived += new SerialDataReceivedEventHandler(DataReceivedHandler); DA.SetDataList(0, myReceivedLines); port.Open(); } } else if (port.IsOpen) { port.DataReceived -= new SerialDataReceivedEventHandler(DataReceivedHandler); port.Close(); } if (port.IsOpen) { DA.SetData(1, "Port Open"); } //If the port is open do all the rest if (port.IsOpen) { bool homeall = default(bool); DA.GetData(5, ref homeall); //Home all sends all the axis to the origin if (homeall == true) { port.Write("G28" + "\n"); myReceivedLines.Add("G28" + "\n"); DA.SetDataList(2, myReceivedLines); } } else { DA.SetData(1, "Port Closed"); } }}…
rtical Sky Component (VSC), and now Sky Exposure Factor (SEF). For everyone else following this post, this discussion has been ongoing in these other threads:
http://www.grasshopper3d.com/forum/topics/sky-view-factor-vs-vertical-sky-component?groupUrl=ladybug&xg_source=msg_com_gr_forum&groupId=2985220%3AGroup%3A658987&id=2985220%3ATopic%3A1377260&page=1#comments
https://github.com/mostaphaRoudsari/ladybug/issues/230
Grasshope, you have gone right to Oke, the grandfather of urban climatology, whose papers I have several times and yet I somehow I always missed the finer details of the sky view calculation. From his definition, I had always thought of Sky View Factor as a purely solid angle or "view factor" calculation in the sense of Mean Radiant Temperature. However, the numbers and formulas that you give here clearly show that Oke meant that this metric for quantifying and understanding urban heat island must refer back to the urban surfaces and their orientation in relation to the sky. It cannot simply be the view from points in space.
To clarify the distinction in simple geometric terms: The key difference is that Sky Exposure refers to the sky seen by a point in space while Sky View refers to that seen by a surface. Both of them involve the calculation of either projected rays or solid angle calculations to the sky (since they both are “view” calculations). However, while Sky Exposure treats each patch of the sky with relatively equal weight, Sky View weights these patches by their area after being projected into the plane of the surface being evaluated. In other words, the sky view calculation for a horizontal surface would give more importance to the sky patches that are directly overhead than those near the horizon because these overhead patch are “in front” of the surface (as opposed to on the side).
To express this difference in the trigonometric terms you cite here:
Wall View = 0.5(sin2 θ + cos θ – 1) / (cos θ)
Wall Exposure = θ/π
I both cases:
θ = tan-1(H / 0.5W) - ** This is the solid angle or ray-tracing calculation
SkyViewOrExposure = (1 - 2 (WallViewOrExposure))
To put this in more simpler terms for the View Analysis component, all that I actually have to do to convert sky exposure to sky view is multiply each of the traced view rays by 2cos(ϕ), where ϕ is the angle between the surface normal and the given view ray being traced.
I have done this by adding this line of code () and I have verified that I get the values from Oke’s paper that you cite above, Grasshope. Accordingly, the View Analysis component now has the option to compute either Sky Exposure or Sky View. You can see this happening in this new example file:
http://hydrashare.github.io/hydra/viewer?owner=chriswmackey&fork=hydra_2&id=Sky_Exposure,_Sky_View,_and_Sky_Component&slide=0&scale=1&offset=0,0
To (once and for all!) clearly define the difference between the three metrics at the top of my reply and to explain how to calculate each with Ladybug Honeybee:
Sky Exposure Factor - The percentage of the overlying hemispherical sky that is directly visible from a given POINT or set of POINTS. This is equivalent to a geometric solid angle calculation or ray-tracing calculation from points. It is useful for evaluating one's general visual connection to the sky at a given point and should be applied to cases where direct views to the sky are the parameter in question.
Sky exposure is calculated with the Ladybug_View Analysis component like so:
Sky View Factor – The percentage of the overlying hemispherical sky that is directly visible from a given SURFACE or set of SURFACES. While Sky Exposure treats each patch of the sky with relatively equal weight, Sky View weights these patches by their area projected into the plane of the surface being evaluated. In other words, Sky View for a horizontal surface would give more importance to the sky patches that are overhead and less to those near the horizon. Sky View is an important factor in for modelling urban heat island since the inability of warm urban surfaces to radiate heat to a cool night sky is one of the largest contributors of the heat island effect.
Sky View is calculates with either the Ladybug_View Analysis component like so:
Or with the Honeybee_Vertical Sky Component Recipe like so:
Sky Component - The portion of the daylight factor (at a surface indoors) contributed by luminance from the sky, excluding direct sunlight. This is essentially the same as Sky View Factor but it often incorporates a sky condition that is not uniform, such as a cloudy sky or sky that is more indicative of diffuse sky light. Another way of conceiving of this metric is a Daylight Factor calculation without any light bounces. It is useful for understanding the direct daylight contribution of diffuse skylight and, although many consider it an older (and perhaps outdated) daylight metric, it is still required by some codes and standards.
Sky Component can be calculated with the Honeybee_Vertical Sky Component Recipe like so:
In addition to the added capability in the view analysis component, I have revised the component description to include the definitions above. I have also corrected the Hydra example file in which I cite sky view as an urban heat island metric to use the new formula:
http://hydrashare.github.io/hydra/viewer?owner=chriswmackey&fork=hydra_2&id=Sky_View_in_an_Urban_Canyon&slide=1&scale=1&offset=0,0
Finally, all of this discussion has made me realize that the Vertical Sky Component recipe for Honeybee might not always be evaluating VERTICAL sky. The sky component might be vertical, horizontal, or in any direction that the input test surface is placed and pts vectors are oriented. Accordingly, Mostapha, I think that we should change the name of the component to simply be “Sky Component” instead of “Vertical Sky Component”. Please let me know if you agree.
Thanks again, Grasshope, for all of the great work! All of this never would have made sense without your research.
-Chris…
via MIDI controllers.
my idea is to link PureData to GH via UDP. why pure data? cause' i can relate data like GH to generate numeric relations (and link it to audio generation)
so far i got PD and Processing to talk, but i can't get to grasshopper.
i use this definitions to make pd and processing to talk http://ubaa.net/shared/processing/udp/ and this GHX to get the data to GH http://www.grasshopper3d.com/forum/attachment/download?id=2985220%3...
i got this data from this post but the GH definition doesn't work for me. i have tried LAN definitions and "the engine" as well but they both freeze, even if i send data thru processing or PD.
i have a lot of questions at this time
1.- why processing tells me that i am getting the data from diferent ports, while i'm using 6000?
2.- why in the UDP definition i get no data out, even if it should say something like "waiting fordata/port/etc.." that's defined in the C# capsule
3.- is there a direct way to get midi data (key and CC) to GH
i also tried to use firefly to get the data via COM port. i know you can do this trick in processing but i just don't know how.
well. if anyone could help me i would share the results here (since it's a magister, results shoud be very interesting)
UDP has allways been a unsolved issue on other posts. maybe we could work it out ;)
Thanks…
Added by jota aldunce at 8:43am on September 28, 2010