of Crete. Chania can be divided in two parts: the old town and the modern city which is the larger one. The Visiting School will revisit the way by which the built environment has been put together and will explore design possibilities which can be applied in order to improve connectivity and functionality in the city. Interactive design coupled with generative form-finding techniques towards the fabrication and assembly of a 1-to-1 scale prototype will be investigated.
Each year a series of software tutorial sessions takes place in order to allow participants develop their basic skills on controlling models parametrically and on producing interactive presentations. These sessions also embody manufacturing techniques enabling a hands‐on experience on the realization of an architectural design. In addition, a set of lectures and special events are carried out to enable the participants advance their understanding in matters of new design anatomies and begin developing a theoretical background on topics including machinic control, computational space, and complexity in systems, and innovative urban design approaches.
Prominent Features of the workshop/ skills developed
• Participants become part of an active learning environment where the large tutor to student ratio allows for personalized tutorials and debates.
• The toolset of AA Greece includes but is not limited to Maya, Rhinoceros, and Grasshopper.
• Design seminars and lecture series support the key objectives of the programme, disseminating fundamental design techniques and relevant critical thinking methodologies.
Eligibility
The workshop is open to architecture and design students and professionals worldwide.
Accreditation
Participants receive the AA Visiting School Certificate with the completion of the Programme.
Applications
The deadline for applications is 20 September 2016.. No portfolio or CV, only requirement is the online application form and fees. Online application link:
https://www.aaschool.ac.uk/STUDY/ONLINEAPPLICATION/visitingApplication.php?schoolID=377
For more information:
http://greece.aaschool.ac.uk/
Contact:
Alexandros Kallegias (Programme Director):
Alexandros.Kallegias@aaschool.ac.uk…
t the maximum potential with the bridge BIM+PARAMETRIC DESIGN ;D
During this Intense Week, we will learn about the power of Rhino + Grasshopper + ArchiCAD with Professional and Useful examples for our Normal Working day :D
You will get Advanced Library Files + Personal Web + Knowledge and Skills to start using this incredible Methodology ;D
Also, the week is having Lectures from different Experts sharing their Computational Working Experiences ;D And Jam Sessions! opening the door to 5 interesting topics to research, learn and experiment together :D
2020 is your YEAR ;D !!!
Complete details and registration……
r visual programming tools in the games world. MS's Kodu, looks interesting. Kismet and Visual3d look even more interesting..... mainly because they are more 'interactive' or 'reactive', rather than DAG-based.
Seems like the evolution path for GH-similar apps is:
1. base 3d or CAD app based on C/C++ code.
2. Add scripting language interface
3. Add some kind of visual interface
4. Add graph sorting / propagation engine
5. Re-jig base 3d or CADD app to make managed/interpreted scripts run faster, multi-threaded.
6. Add dynamic typed language, DLR stuff
6. ....
6. Add constraints solver...?
7. Rebuild CAD display engine to be procedural at the GPU level?
Seems like there are available tools for converting scripts into some kind of flowchart. There are even visual debuggers. MS even has something called the 'Debugger Canvas'. Spreadsheet constraints.
Seems like the time is ripe for lots of new apps like GH.
…
llet Distance]
[Slider=0..1..10]-->[D][Fillet Distance]
[Slider=1..5..20]-->[F][Unit Z]
[Fillet Distance][C]-->[B][Extrude]
[Unit Z][V]-->[D][Extrude]
This still leaves the problem of having more than one of a single component on the canvas. Referral can be made unambiguous by simply picking the most recent component with the same name. But how do you indicate you want a second Polyline component?
Possible solutions:
Separators in the text:[Point=SetMultiplePoints]-->[V][Polyline]----------------------------------[Point=SetMultiplePoints]-->[V][Polyline]
Keywords or symbols to indicate the creation of a new component rather than the re-use of an existing one:new [Point=SetMultiplePoints]--> new [V][Polyline]new [Point=SetMultiplePoints]--> new [V][Polyline]
(2) is a lot more flexible and (1) may not work at all as it will prevent any reuse above and below the separator.
--
David Rutten
david@mcneel.com…
l design.
2/ Optimization
2.1/ in prefabrication
2.2/ combinatorial
2.3/ approach comparisons (i.e. deterministic vs stochastic)
2.4/ share your research
2.5/ ... etc. the list goes on and on
3/ Share you design rationale and how computation fits in
4/ Need help with this problem...
5/ Challenges and workshops announcements
6/ CD News
7/ Share computational design projects under construction or built (akin to skyscrapercity)
8/ and so many other categories and sub-categories...
Just my first thoughts. That breakdown in optimization is just an example. Maybe 'sections' is an old-school way of seeing things, I just wanted to share some thoughts on the kind of content I look forward to seeing. It can be pragmatic topics, but also theoretical, and allow folks to share their projects and research. Some categories are specific, others broad. I suppose I'm interested in community building with regards to computational design. I think SmartGeometry attempted to accomplish this at some point in the past, to some degree. However their focus appears to be in the workshops and challenges.
I recall the silly flame wars that the CG industry had 20 years ago (lame). I'd avoid that, even if it meant forbidding the mention of any specific software in certain areas or in the entire forum. Which would be tricky, but the endless flame wars and silly comparisons were such a waste of everyone's time in CG.
Without dwelling on this too much yet, I think that the software specific questions belong in software specific forums. If we already had a common language for computational design, you'd just need to add the right description as a meta-tag to any Dynamo or Grasshopper forum post, and you'd be able to find analogous solutions in either forum effortlessly, right?
The Dynamo and Grasshopper forums lack design-centric content. The emphasis is generally on the tools and workflow. Computational design is hybrid in essence, it involves both design and computer programming (be it visual or textual). We could really use a forum for knowledge exchange where the expectation is that both are discussed with equal status.
I disagree that such a forum ought to exclude professional programmers. It should include professional programmers whom have an interest in design, and also include professional designers whom have an interest in computer programming, and everyone in between, and enthusiasts, and artists whom are curious about algorithms as a creative medium, and academics, and students, and etc etc. As long as there is rich content and activity on design as well, not only the computational bit, then the crowd will be diverse and we'll all have more to learn from one another.…
d. If what you say is correct about the small difference between the global horizontal and direct/diffuse calculations in the MENEX model, than the discrepancy likely has more to do with the difference between the approximation of human geometry in the MENEX model (plane or cylinder) and the human geometry approximation in the SolarCal model (some coefficients derived from radiation studies of mannequins). I noticed some fairly large differences between using a suggested global horizontal method and a direct/diffuse method with the SolarCal model (differences on the order of 20%) but I imagine that this is because a mannequin human geometry is more sensitive to changes in solar orientation than a cylinder or plane. All of this is very good to know.
Yes, I guess this might be the case: the sensitivity of the SolarCal model to different parts of human body surfaces and surfaces areas.
Am I correct in understanding that you recently corrected the grey-body assumption about sky temperature in the Thermal Comfort Indices component with this commit? https://github.com/mostaphaRoudsari/ladybug/commit/a2a37b6dccc4e750...
The previous incoming long-wave radiation was derived by Ångström for clear sky conditions. The added correction "(1 + 0.22*((N/10)**2.75))" is a fractional cloudiness factor by Maykut and Church (I attached the publication below which mentions it).
So the emissivity coefficient of the (cloudy) sky is now:
epsilon_sky = (0.82 - 0.25*(10**(-0.094*0.75*e))) * (1 + 0.22*((N/10)**2.75))
I do not think that you could use the same value to calculate the sky temperature with Stefan-Boltzmann law, as the incoming long-wave radiation has been derived from the air temperature (2 meters above the ground), not the sky temperature. So by:
skyTemp = (La / [epsilon_sky * sigma])^0.25 - 273.15
One would get the air temperature from which La is derived, not skyTemp.The possible reason why SolCal Mean radiant temperature is currently getting similar values to Thermal Comfort Indices Mean radiant temperature could be that fact your epsilon_sky is almost equal to 1 (0.95), so it depends solely on La.I spoke with Dr. Blazejczyk, and got a publication on different sky temperature models. Apart from upper mentioned Swinbank, Berdahl-Martin, Melchor it has a lot more methods with mutual comparison of their resulting values. I attached it below.…
d react in length to the variation of their respective angle deviation from the sun.
For the moment I have established a way that depending on Bigger than/Smaller than X value, there is a dispatch of data to produce to types of panel lenghts. As you can see on the image.
But I would be interested to find the way to organize the list of all angles and classify them in groups like 5 packages of 20 degrees deviation. So, the panels deviated 16,3 and 27,9 degrees would go in the package of 15-35º, for example, and the 33,1 would go in the 35-45º...etc..
And the question would be to assign the different groups of angles, to given positions for the vectors that define the panel surfaces.
I am confused at how I should tackle this problem. Is it a question of dividing domains? Or creating sublists? But then, how can I assign the data to a set of positions? Dispatch only works with A/B..
And if so, how could I limit the positions of the vectors that define the surfaces, to a min and max length that would not overlap out of the base pattern?
These are huge questions, eh? But I'm sure that someone has tackled this problem before...
Looks like an accumulation of pretty standard problems,..but all together!
Thanks a million for any examples or hints on how this could work!
M.A.
StepStudies_20100815.3dm
StepStudies_20100815.ghx
…
eps are represented by multiple surfaces so the discussed techniques are not fully workable.
the attached files include my test gh and a solid file to input. I have been able to map a suitable voronoi latticework onto the brep surface - but then I'm stuck. I cannot offset the curves on the brep and create a useable strut surface that way. I cannot intersect swept pipes with the brep surface to create surface patches that could then be joined.
I need some elegant ideas; I seem to be going down a rabbit hole at the moment where I am doing ever more complex workarounds for the grasshopper capabilities. (A case in point; the rail sweep is not working for me for closed 3D polylines, so I am having to cut them up and sweep and cap the segments. Ugh).
Example input brep
Curves on brep - but no simple offset / trim mechanism
Potential rail defining strut trim - but no way to do so...
Brep / rail intersect - but no way to turn this into a surface...
Programme
Voronoi%20strut%20on%20brep%20test.3dm
Voronoi%20struts%20-%20volume%202.gh
…
an Architecture or Engineering degree and a passion for design and coding.
You must have advanced skills in computational programming, experience in software development and creating language dependent API and class definitions. You will be fluent coding in C# and a strong math’s background is essential. The ability to translate syntax in object-oriented languages is required along with an advanced understanding of data structures and algorithms in the CAD or graphics domain. You will have excellent communication skills and be a strong team player.
In return you will work in a highly creative environment, take your shoes off at the door every morning and take advantage of our special office culture.
Hours: Usually 9am to 6pm (with one hour lunch), Mon - Fri. Salary: £30,000 dependent on experience. Benefits: 20 days annual leave per year, plus bank holidays.
To apply please send your portfolio, CV and covering letter to work@ala.uk.com.
No agencies please.
…