with Istanbul Technical University, will continue to rediscover verticality through novel generative design techniques and large-scale physical prototypes. Abstracted as a fusion of various sub-systems, each subsystem of the tower will be investigated in relation to their various performance criteria. The correlations between the separate sets of performance criteria and evaluation methods will be analyzed, leading to the generation of unified design alternatives for a vertical system typology. In addition to the custom-made digital design and evaluation tools supporting the core methodology, Vertical Interventions will also highlight the fabrication and assembly of a large scale working prototype integrating the performative characteristics of each system in examination.
As in 2012, the design agendas of AA Athens and AA Istanbul Visiting Schools will directly create feedback on one another, allowing participation in either one or both Programmes.
Discounts
The AA offers several discount options for participants wishing to apply as a group or participants wishing to apply for both AA Istanbul and AA Athens Visiting Schools:
1. Standard application
The AA Visiting School requires a fee of £695 per participant, which includes a £60 Visiting Membership. If you are already a member, the total fee will be reduced automatically by £60 by the online payment system. Fees are non refundable.
2. Group registration
For group applications, there will be a range of discounts depending on the number of people in the group. The discounted fee will be applied to each individual in the group.
Type A. 3-6 people group: £60 (AA Membership fee) + 635*0.75 = £536.25 (25 %) Type B. 6-15 people group: £60 + 635*0.70 = £504.5 (30%) Type C. more than 15 people group: £60 + 635*0.65 = £472.75 (35%)
3. Participants attending both AA Istanbul and AA Athens | 40% discount
For people wishing to attend both AA Istanbul 2013 and AA Athens 2013, a discount of 40% will be made for each participant. (The participant will pay the £60 membership fee only once.)
£60 (AA Membership fee) + (635*0.60)*2 = £822
For more information in discounts, please visit:
http://ai.aaschool.ac.uk/istanbul/portfolio/discounts-2013/
Applications
The deadline for applications is 21 March 2013. A portfolio or CV is not required, only the online application form and payment. The online application can be reached from:
http://www.aaschool.ac.uk/STUDY/VISITING/istanbul…
Added by elif erdine at 11:41am on December 13, 2012
ails.
Some word about the mesh... (see Image_01)
I took a flat 4 points NURBS surface as imput (very easy, it defines the total area of my pavilion) and some points (that defines the contact with the ground).
Then I extracted a grid of points from the NURBS (Surface_Util_Divide surface) and compared 'em with the contol points, in order to associate to each grid's point its own attractor (Vector_Point_Closest Point).
Than I moved the points down. I used the distance from each point to its attractor (inverted) as amplitude for the vector of the movement, in order to say: the nearer you are to the control point, the more intense your movement will be. During this operation I've passed the distances' data list into a graph mapper (Params_Special_Graph Mapper), in order to regulate in a very intuitive and interactive way the shaping of my canopy.
At the end of the process I asked GH for a simple Delaunay mesh (Mesh_Triangulation_Delaunay Mesh). It's a very cool command, I believe!!!
Ok, now some word about the component, it's design and it's repetition/adaptation to the mesh...
(see Image_02)
I took the mesh and extracted components on first and faces's information on second. Then I selected and separated the vertexes (1°, 2°, 3°) of each triangular face into threee well defined list.
Then I re-created the triangles' edges. Please pay attention because it's not the same if you use output information from Delaunay components, because here we need a justapposition of edges where triangles touches each others.
After this work I joined the edges and found their centroid. At the same time I found the mid point of each edge.
Now the component... (see Image_03)
It' a little bit longer to describe: I'll try to be synthetic.
Substantially it is a loft from a curve to a point, repeated three times for each triangle (Surface_Freeform_Extrude Point). The point is an elevation of the centroid of the triangle (you can choose if the exstrusion has a single height or it's related to an attractor. In my case it was fixed). The curve is combination of things. There's an arch, which starts on the edge (there's an offset from the corner) end terminates on the same edge (on the other side, obviously). While it's generation the arch passes through a third point which belong to another segment. This last connects the mid point of the original edge (base triangle) with the centroid. The result is a kind of polyline, with two segments and an arch. If you go back to the image of the component that I posted probably you'll understand what I'm saying better than with the definition.
The posit…
o it would cause troubles with unfolding and fabricating... that's why I used Extrude point component- it will give you similar result, but all surfaces are planar.. you can control extrusion direction with a tip point in rhino...
2)I changed tagging so every tube has 8 points form list A and 8 points from list B... first number of tag is a number of point within one tube... last number of the tag is order of tubes (I draw a little picture in GH, hope you'll understand)...I think original way of tagging wasn't really usefull.. but you can change tagging by yourself...
3) the definition is really messy, sorry about that, but it's just quite complicated task...
4)if you find some incorrect order of tagging, use the slider that controls Shift List component ... it will shift tagging..
5) if you won't be using this definition or find some better way, pleeeease don't tell me - I'll jump out the window :D ... it took me whole day to make it work :D
6)I can't guarantee you anything- I hope it works, but if not - at least I tried... so check everything (especially order of tags and points) twice before you fabricate it.. or print few tubes and make them paper first..
7)there is a part of original definition, that is not useful anymore.. I left it there, but you can delete it (I called it "UNUSED PARTS OF ORIGINAL FILE")
..good luck
Dimitri…
or create a form through code.
2) Add a public function to your component that displays this form, I recommend you use form.ShowDialog() for now to avoid weird conditions with non-modal forms.
3) Override the method Menu_AppendCustomComponentItems() on your Component and add an extra menu item that will show the form (i.e. when clicked, it will call the function defined in step [2].
4) Create a new class and derive it from Grasshopper.Kernel.Attributes.GH_ComponentAttributes. (if you don't want to offer double-click functionality, you can skip steps 4 to 6)
5) Override the RespondToMouseDoubleClick() method on the new attributes and also call the function defined in step [2]
6) Override the CreateAttributes() method on your Component class and construct an instance of the custom attributes defined in step [4] instead.
7) Once you've shown the form and the user has clicked OK, you need to assign values and invalidate the Component, then start a new Solution.
Here's some code:
Public Class MySpecialComponentAttributes
Inherits GH_ComponentAttributes
Public Sub New(ByVal comp As MySpecialComponent)
MyBase.New(comp)
End Sub
Public Overrides Function RespondToMouseDoubleClick( _
ByVal sender As GH_Canvas, _
ByVal e As GH_CanvasMouseEvent) As GH_ObjectResponse
DirectCast(Me.Owner, MySpecialComponent).DisplayForm()
Return Canvas.GH_ObjectResponse.Handled
End Function
End Class
Public Class MySpecialComponent
Inherits GH_Component
.....
.....
Protected Overrides Sub Menu_AppendCustomComponentItems( _
ByVal iMenu As ToolStripDropDown)
Menu_AppendGenericMenuItem(iMenu, "Set Values", AddressOf Menu_SetValues)
End Sub
Private Sub Menu_SetValues(ByVal sender As Object, ByVal e As EventArgs)
DisplayForm()
End Sub
Public Sub DisplayForm()
Dim frm As New MySpecialForm()
Grasshopper.GUI.GH_WindowsFormUtil.CenterFormOnCursor(frm, True)
If (frm.ShowDialog() = DialogResult.OK) Then
'Harvest values from form and assign them to local variables
Me.ExpireSolution(True)
End If
End Sub
End Class
--
David Rutten
david@mcneel.com
Turku, Finland…
sophy though, I have a rudimentary grasp of the Ancient Greeks and modern schools of thought such as Existentialism and Pragmatism, but there is certainly no depth in my understanding. However here the same rule applies. You can quote philosophy all you want, but unless you understand that which you're channelling you can be -at best- accidentally correct.
According to you, these are all vital characteristics:
Aesthetic judgement
Intuition about spatial effectiveness
Knowledge of construction materials & assembly systems
Consideration of performance-driven design properties
Mad synthesizing skillz
[1] and [2] are pretty much worthless, especially when we're dealing with students. Aesthetic judgement is not something that can be wrong or right. You can hone your aesthetic skills but you cannot cultivate better tastes. Intuition is also problematic. It's basically a stand-in for argumentation. Instead of saying "these buildings have to have 20 meters apart because of wind/sound/human perception/human psychology/light/shadow/etc. etc" is a far stronger statement than "these buildings have to have 20 meters apart because of my feelings". Who are you to be trusted? If you have a long and distinguished career backing you up, maybe your opinions carry some weight, but until that point you'd better be prepared to justify your decisions with cold hard logic and data.
[3] is certainly important for certain jobs in construction, but it can be argued that implementation details are not necessarily central to a design. One can design a good computer interface without having to be able to program, and certainly without being familiar with all the idiosyncrasies of a particular programming language. Conversely, one can design an excellent space without knowing exactly how strong certain atomic bonds are. If what you design is physically impossible, then obviously something has to change, but it doesn't mean that the design as an abstract idea was bad. Of course on the other hand one can argue that designing impossible things is not doing anyone any favours. I'm not exactly certain where I stand on this issue, probably comfortably in the middle; YES, students need to learn about what can be build in the physical world, but NO that is not part of design training.
I'm not quite sure what [4] means.
[5] is true for a lot of professions, not just Architects. I would concede that architects probably have more to take into account than most designers and that it is indeed an important skill to have.
I would say that -especially for students, who have little experience- an incredibly important skill to be able to ask yourself "why am I doing this?" about pretty much every decision you make. Basically you need to get very comfortable applying the Socratic method to everything you do.
--
David Rutten
david@mcneel.com
Tirol, Austria…
Added by David Rutten at 11:03am on August 14, 2013
ctor. I do not dispose of any IGH_Goo instances, mostly because I have no idea when an instance is truly no longer needed. If any of your fields need to be disposed, you may have to implement a destructor, but I have no experience with this.
2) should I pass those classes to other parameters by DA(0, MotherClass.Duplicate?) or it is already there by GH_Goo ?
IGH_Goo is not duplicated by default. If you use DA.GetData() and ask for IGH_Goo types, you'll get a reference to the same instance as exists. Thus, if you take in an instance of your type, modify and output it, you should duplicate it yourself. But you only need to do this if you change the state of an instance.
MyGooType data = null;
if (!DA.GetData(0, ref data)) return;
data = data.Duplicate() as MyGooType;
data.Property = newValue;
DA.SetData(0, data);
3) should I create ChildClass and MotherClass in SolveInstance, or create it once as a component's field and then change theirs properties and pass it to DA (as duplicate ?)....
It's almost always better to use variables with the lowest possible scope. So method variables are preferred to class variables, class variables are preferred to static variables.
4) if I create those classes in SolveInstance, is it necessary to Dispose them there ?
NO! Do not dispose of instances that are passed on to output parameters. Disposing objects typically makes them invalid, so if you share instances with anyone else, you should not dispose them or the other code may well crash. However I don't think your types need to be disposable so this is a moot point now.
In general, if you're dealing with disposable types, and the instances aren't shared, then you dispose them as quickly as possible. But if they are shared it's a lot more complicated.
5) finally - maybe it would be better if MotherClass inherits the ChildClass ?
Maybe. Not necessarily. Depends on the classes. …
Added by David Rutten at 12:08pm on December 31, 2014
rk and I will just clarify some of the details. I will also note that I do not know what the shadings output of the decomposeByType component is supposed to do as Mostapha put it there a long time ago and I was not sure what his intentions were. Going down a list of clarification points:
1) You are right that you should either connect up the shade breps to the EPContext component or just plug the HBObjwShades into the RunSimulation component (never do both). However, connecting the breps to the EPContext component is greatly undesirable for two reasons: It will make the simulation run much longer and the energyPlus calculation will not account for the surface temperatures of the blinds (it will assume they are the same temperature as the outdoor air, which is very wrong in a lot of cases). When you connect up the HBObjwShades to run the simulation, EnergyPlus will understand the blinds as abstract objects defined only by a numeric parameterization and not as actual geometry. This enables the calculation to run fast and is also enough of a description that E+ can calculate the temperature of the blinds, thereby accounting for the heat that can be re-radiated from the blinds to the indoors when they get hot in the sun. This more desirable way of running the blinds was how I imagined the component being run most of the time and I mostly included the shadeBreps so that you have a visual of what you are simulating.
2) When you use the more desirable HBObjWShades to approximate your blinds, you should use the blindsSchedule input in order to tell E+ when the shades are pulled (this is instead of the transShcedule on the EPContext component).
3) The zoneData inputs on the EPWindowShade component are meant to help in an entirely different workflow, which evaluates shade benefit based on energy simulation results. I apologize if it seems confusing to have two major uses of the component in one but we have so many Honeybee components right now and I did not want to make 2 separate ones when they seemed so similar. See this example file to see how to do energy shade benefit (https://app.box.com/s/oi64zoj5u1slz494grzhgmdkx7yie9jo).
Ok. I think that clears up everything that I know. Now to the part that I do not. As I said, Mostapha put in the shadings input there a long time ago and I do not know what his intentions were. Abraham, as you know, I am about to do a major revision of the EPWindowShade component to make it compatible with OpenStudio, include drapes/generic shades in addition to blinds, and I also should figure out how to do electrochromic glazing. I can easily include all of the visualized shades as output from the decomposeByType component when I do this. However, I do not want to interfere with other intentions Mostapha had when he put the input in. If he could confirm that this was in-line with his vision for the shadings output, I will implement it soon.
-Chris
…
On the other hand ... well ... we can pretend that this could be some sort of add-on dedicated for broken pieces, (and nerves if loops = a big number) he he.
Anyway:
1. If you enable the history (the yellow things) you can watch the recursion working: get a donor box and "slice" it in 2 (either via an "orthogonal" plane [the fast boxes] or a random one [the slow breps]). Then get each one and repeat until the desired "depth" of "slices" is achieved (the loops, that is). Pure recursion in terms of programming (a function does something, yields results and then calls itself to further process each result).
Double click on the C# to see the code (but don't change anything). For the record this is the function that does the main job (spot the fact that if it's not terminated it calls itself [last line]):
2. The x, xy, xyz options restrict the random plane (actually in the boxes case there's another technique used (Intervals) but never mind). For instance (case random breps) the slicing plane is defined at the brep center and using a random direction:
Vector3d dir = new Vector3d(rand.NextDouble(-1,1), rand.NextDouble(-1,1), rand.NextDouble(-1,1));
If the 3rd value is 0 then the plane's YAxis is parallel to Plane.WorldXY.ZAxis.
3. Now if the "slicing" thing was a random polyline at a random plane the pieces could be far more "elaborated" (and/or "naturally looking") ... but the thing with programming is to know(?) where/when to stop.
4. This approach could use any donor Brep (a blob for instance) or a Brep List. Notify if you want to add such an option.
5. Added some lines more for an option that allows to sample the pieces (due to the last loop) in an automated flat "layout" (it's a bit more complex than it appears on first sight).
6. The x,y restriction mode now affects the random slices as well. See what I mean:
and the same restriction using boxes:
Truth is that all that freaky stuff could be helpful for you if you had serious plans to learn C# (not something achievable without pain and tears aplenty).
best…
e point in each pair that has the lowest Z value (then later the highest Z)... The problem is the intersections are not returned sorted by Z, sometimes the lower point is first in the list, sometimes last. So I need to sort those pairs of points by Z value.I noticed the sort points component does not have any inputs for sort criteria... RhinoScript SortPoints allows you to sort by:
blnOrder
Optional. Number. The component sort order, where:
Value
Component Sort Order
0 (default)
X, Y, Z
1
X, Z, Y
2
Y, X, Z
3
Y, Z, X
4
Z, X, Y
5
Z, Y, X
Will we get something like this in GH? For now I think I can manage to analyze the Z for each and re-order the points, but a more comprehensive point sorting tool might be nice... no? Or did I miss something obvious? --Thx, --Mitch…