this workshop is to materialize a chair designed with help of generative algorithms via robotic fabrication. To design the form of the chair we will go through an intensive course of generative design techniques, k-means clustering, structural analysis and optimization done with the help of Anemone, Galapagos, Millipede and other plugins. Finally we will employ a 6-axis robot with custom tooling to fabricate the chair via robotic rod bending. No prior experience with Grasshopper or robotic fabrication is required, although basic knowledge in 3d modelling would be an asset. // APPLICATION The deadline for application is 13.03.2017 Apply by sending email titled ‘workshop_chair’ to workshops@aan1.net // INFO If you have any more questions check the www.aan1.net website or contact us with email workshops@aan1.net // FEE We have special pricing for students, as well as an early bird offer. Check the Eventbrite list to get more details. Please bear in mind that a limited amount of seats is available (minimum 8 people, maximum 16). ORGANIZERS: Maria Smigielska, Mateusz Zwierzycki, AAn+1 TUTORS: Maria Smigielska, Mateusz Zwierzycki PRICES: Early Bird Student 280 E Early Bird Pro 320 E Regular Student 300 E Regular Pro 350 E…
p 10 "Scripting Reality – Integrating 3D Point Clouds in parametric design workflows".
This research-based workshop will introduce participants to thegeometrical class of point clouds and ways to handle, manipulate, analyse and script with them. Participants will as well have the chance to get first-hand knowledge in the handling of 3d capturing devices and to link their outputs directly into a design environment.
The workshop poses especially the question of how changes on architectural scale can be tracked over time. Related algorithmic concepts and the Volvox plugin, allow for the first time to directly access and manipulate point clouds in a parametric design environment, will be introduced to the workshop participants. A 1:1 experiment on the ETH campus will provide a testbed. Participants will learn point cloud processing and learn to track objects solely on the base of point cloud analysis, find deviations against the planned and visualise the results.
The workshop is led by Mateusz Zwierzycki, Martin Tamke and Henrik Leander Evers. FARO provides several 3d scanners with helical adapters and acccess to the FARO SDK for the workshop. The workshop is modestly priced with 160CHF.
register now.
http://www.aag2016.ch/workshop-10/
…
d object1. Traceback: line 96, in join, "c:\Program Files\Rhinoceros 5 (64-bit)\Plug-ins\IronPython\Lib\ntpath.py" line 102, in openStudioPath, "C:\Users\Jurrijn\AppData\Roaming\McNeel\Rhinoceros\5.0\scripts\honeybee\config.py" line 247, in <module>, "C:\Users\Jurrijn\AppData\Roaming\McNeel\Rhinoceros\5.0\scripts\honeybee\config.py" line 2, in <module>, "C:\Users\Jurrijn\AppData\Roaming\McNeel\Rhinoceros\5.0\scripts\honeybee\radiance\command\_commandbase.py" line 2, in <module>, "C:\Users\Jurrijn\AppData\Roaming\McNeel\Rhinoceros\5.0\scripts\honeybee\radiance\command\gendaymtx.py" line 3, in <module>, "C:\Users\Jurrijn\AppData\Roaming\McNeel\Rhinoceros\5.0\scripts\honeybee\radiance\command\__init__.py" line 7, in <module>, "C:\Users\Jurrijn\AppData\Roaming\McNeel\Rhinoceros\5.0\scripts\honeybee\radiance\__init__.py" line 3, in <module>, "C:\Users\Jurrijn\AppData\Roaming\McNeel\Rhinoceros\5.0\scripts\honeybee\_hbanalysissurface.py" line 1, in <module>, "C:\Users\Jurrijn\AppData\Roaming\McNeel\Rhinoceros\5.0\scripts\honeybee\hbsurface.py" line 1, in <module>, "C:\Users\Jurrijn\AppData\Roaming\McNeel\Rhinoceros\5.0\scripts\honeybee_grasshopper\hbsurface.py" line 44, in script line 53, in __init__, "C:\Users\Jurrijn\AppData\Roaming\McNeel\Rhinoceros\5.0\scripts\honeybee\config.py"
It seems a problem with python.. Thanks in advance for any help.…
(tree info, relationships to certain other objects, etc.) after it's been baked, so that our team can hand tool some of the results, delete certain objects, etc. I'm using the doc.objects.find(guid) function right now - which works fine when I feed a string into the VB component and set the input as a GUID, but am having a hard time casting my strings from Excel into the GUID directly in the VB component. Hopefully it's easy to do and I can whack my palm on my face, as often I do. Here's my script...I get the "specified cast is not valid" error at: Dim obj As Guid = xlSheet.Range(strGUIDColumn & I).Value.
If activate = True Then
Dim xlApp, xlSheet As Object
xlApp = System.Runtime.InteropServices.Marshal.GetActiveObject("Excel.Application")Dim strSheet As String = "MEM_6"
Dim strGUIDColumn As String = "C"
Dim strDeleteColumn As String = "F"
Dim intCheck As Int16 = xlApp.Worksheets("META").Range("B4").Value
Dim I As Int16
xlSheet = xlApp.Worksheets(strSheet)
For I = 2 To intCheck + 1
Dim obj As Guid = xlSheet.Range(strGUIDColumn & I).Value <- returns my casting error
If doc.Objects.Find(obj) Is Nothing Then
xlSheet.Range(strDeleteColumn & I).Value = "X"
End If
Next
End If
thanks!…
Added by David Stasiuk at 8:05am on December 15, 2010
ions are probably reflective of the prevailing humidity conditions (I just had a chat about this with my advisor, who incidentally also happens to be on the committee for LM-83).
The Tregenza sky patches considered in daylighting calculations don't do a good job of incorporating the correct size of the sun into calculations. In the figure below, the sun on the right is the one considered for calculations in Daysim. You can get a more accurate answer by considering a more discretized sky, however, I am not aware if that is possible with Daysim (and therefore HB) right now. Therefore, your direct sun calculations are likely to be off somewhat depending on how much of it there is(I'd say overestimated).
The calculations with humid sky, which are on account of the sky itself (and not the sun alone) are likely to be more relevant.
Regarding your questions about studying weathering effects with LB/HB, I have no idea as that is something that I haven't looked into before. I am sure someone else on this list has a more informed opinion on this issue than I do.
Your project, and your approach to it, seems really interesting and I am glad to be having this discussion :).
Sarith
…
at 0.85m above the floor.
I copy paste from the Appendix E:Rights to Light of the book "Paul Littlefair, Site Layout Planning for Daylight and Sunlight, A good practice, BRE Press, p.60" which is the primary guide for evaluating the impact of new construction to the Rights to Light of the existing adjustment buildings:
"The accepted way of calculating the loss of light is to compute the sky factor at a series of points on the working plane. In dwellings, the working plane height is usually taken to be 0.85 m (two feet nine inches). The sky factor is the ratio of the illuminance directly received from a uniform sky at the point indoors, to the illuminance outdoors under an unobstructed hemisphere of this sky. No allowance is made for glass losses or light blocked by glazed bars and (usually) window frames; nor is reflected light included, either from interior surfaces or obstructions outside. Thus the sky factor is not the same as the CIE daylight factor (see Appendix C). The sky factor is often calculated using a Waldram diagram, but this is a different Waldram diagram to Figure B1 in Appendix B, which should not be used for this purpose."
Thought couldn't find the specific Waldram diagram for this case from the references, I assume contemporary analytical tools should exist to calculate it.
I used your Vertical Sky Component process and culled the mesh faces lower than 0.2% but I believe because of they type of the radiance analysis as you have explained it before (stochastic method) it doesn't create one continuous edge, as you can see in the attached image.
Thanks,
Dimitris…
button to generate such complicated and unruled geometry. Seriously, if you don't understand a geometry, how can you solve the structural needs and the bloody fabrication. Giant fast prototyping machines doesn't exist!
In a era where ressources and energy is getting scarce, I don't understand this trend of fancy no sence look like organic buildings. They just look organic in our human perception. Nature builds things with define physical and biochemicals rules, and this is why when they grow, they look like that. You should study Frei Otto publication from the 80's.. the IL publications. They were using physical models to generate physical structures that would be build in the physical world. Computers and softwares are dangerous as we distach from reality.
We put all this effort to generate these fancy forms, but no brain is put in structural optimization, energy efficiency (for instance in relation with the sun, or other natural elements)
IT technology goes faster than the time we have to reflect about it. (not talking about the technics).
As Frei Otto told me personally in our last discussion (talking about philosophy and architecture): " We have to define the OPEN QUESTIONS. Once these questions will be defined, you'll get answers".
I think we are getting to a question here: " How to use this technology to solve problems in Architecture?" Before that " What are the real problems in architecture?"
Maybe David should make a component for that? For instance, a button that could solve the loging and infrastructure problems for these millions of people living in the slums of Mumbai...
What about that Krish Raj?…