ir surroundings. Our built environment continues to evolve, into an interconnected hyperspace where architecture can be fluid, flexible and vivid. In 2017, AA Athens Visiting School, will address architectural themes involving active engagement and participatory design through prototypes that are characterized by action.
Action-designed structures enabled by technology today, begin to timidly move beyond the utopian proposals of the 20th century’s manifestos and hold a place in the world of realized designs. The AA Athens Visiting School incorporates in the design process, materials and scientific devices as vital parts of the end-creations. The research aims at bringing closer the user with the built environment via space animation and animate and in its’ methodology, it rethinks habits of designing, building and experiencing space through materiality. In “SYMMETRY SENTIENCE”, materiality and form are considered as a “unified whole”. The programme will investigate how membranes can reshape our architectural understanding by bringing curvature and translucency. The design teams will focus on the flexible nature of tensile fabric that can be energized by motion and real-time reaction to various parameters. In this world of “living” structures and interactive formations, the design language includes Processing, Arduino, Rhino Modelling, and Grasshopper. The architecture programme, integrates manufacturing techniques that enable the design teams to actively experience the aspect of fabrication in 1:1 scale. A set of lectures and tutorials by experts from internationally renowned academics and practitioners, from the Architectural Association, Zaha Hadid Architects and others, form the theoretical background based on aspects of computational space, machinic control as well as responsive and kinetic design.
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 29 May 2017. No portfolio or CV, only requirement is the online application form and fees. The online application can be reached from:
https://www.aaschool.ac.uk/STUDY/ONLINEAPPLICATION/visitingApplication.php?schoolID=467
For more information, please visit:
http://www.aaschool.ac.uk/STUDY/VISITING/athens
Contact details:
Alexandros Kallegias (Programme Head): alexandros.kallegias@aaschool.ac.uk…
and you'll probably fall in love. Mesh morphing, remeshing, smooth curves evaluation (see group image), 3d convex hull and last but not least - slFastMesh - which will enable you to stop thinking about meshing parameters and start playing.
What's that all about ? Mesh is embedded to planar form (or spherical), with respect to topology. You draw point on this planar (or spherical) mesh representation and it automatically finds it's place on original mesh.
So lets introduce some "new" words : Mesh-map. Components that create a mesh-map (planar or spherical mesh embedding) are located in the "Cartographers" category.
This is the first step in mesh parameterization. Then you can use slGuide2D (Guides category) to draw some points on the map - guide will lead them to the original mesh at proper position.
The remaining components can be considered as utilities. For me the two most helpful are :
slFastMesh is a really simple, tiny component. It will take any genus 0 intersecting BReps, union and mesh them - so you dont have to choose all the parameters manually. What is so special about it ? Just reference some BReps from Rhino and give it a try. Basic idea for this component comes from Michael Pryor.
slHull3D is incremental 3d hull implementation which I made some time ago and published as vb script component. It takes a bunch of points and creates a mesh hull, which will match perfectly to slSphere embedding.
Special thanks to : Michael Pryor for constant help&support and David Rutten for great advices.
DOWNLOAD (after joining the group)
or
DOWNLOAD from food4rhino.com
Examples avaible to download from group discussions or food4rhino.com
It's highly recommended to use Starling with Weaverbird and [uto] MeshEdit.…
ed four workshops, each featuring a partnership of a creator of hardware technology and a software developer. The outcomes of the four workshops will form a single structure.
Workshops:
1. Facade panels with RoboFold & Kangaroo/Lobster
2. Cantilever CNC wooden lattice with Archiwaste & SMART Form by BuroHappold
3. Corian freeform surfaces by Cutting Edge & Evolute Tools
4. Milled foam and cast concrete with Cordek & Galapagos/David Rutten
Book on the Shape To Fabrication website or via SimplyRhino on 0208 498 9900. Tickets are limited to 10 per workshop at £500+VAT (professional) and £400+VAT (student).…
Added by Gregory Epps at 5:15am on September 29, 2011
arm, controlled with a variety of sensory inputs. The project will be developed in Grasshopper and Firefly, using the Arduino microcontroller. No previous experience is required.
Workshop overview:
1 – Sensing and Actuating - Brief Introduction to Grasshopper - Brief Introduction to Arduino - Introduction to Firefly
2 – Arm simulation - Introduction to Vector Math in Grasshopper - Simulation of the multi-axis Arm
3 – Fabrication - Brief introduction to laser cutting - Laser cutting the arm components
4 – Motion Tracking to Actuation - Introduction to Motion tracking (Kinect, Leap Motion, iPhone) - Controlling the arm with various motion inputs
Please refer to this link for further information about the workshop series and registration specifics.
…
step-sizes. It starts out with large jumps, then as it cools the jumps get smaller and smaller as does the likelihood of a retrograde jump being accepted as a valid new state.
Most fitness landscapes have more than one dimension and therefore a 'jump' could include any number between 1 and N, where N is the dimensionality of the landscape. The Drift Rate setting —which may well be poorly named— controls the odds that a jump includes an additional dimension. All jumps must be at least one-dimensional, but 25 percent of them (on average) will include another dimension. 25% of those will include a third dimension and 25 percent of those a fourth and so on and so forth until the dimensionality of the landscape has been reached. Here's a list for 1000 jumps:
Drift Rate: 25%
1D jumps: 750
2D jumps: 187
3D jumps: 47
4D jumps: 12
5D jumps: 3
6D jumps: 1
A good question to ask would be; "Why would you want a jump to include more than one dimension?" and the answer is that the more genes are related, the higher the changes that a multi-dimensional jump will yield an improvement. It's not difficult to imagine that you cannot improve your current state by only modifying a single gene. Sometimes you need to change two in unison in order to reach a better solution. If your genes are highly related (which is bad practice to begin with) then you may need to adjust the Drift Rate to a higher value.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
Added by David Rutten at 11:09am on April 17, 2012
eedback. To go down the list:
Theodore, The PMV indoor comfort analysis is unfortunately much more computationally intensive than the adaptive comfort analysis. In my experience, an annual adaptive comfort map analysis of 3 zones took about 12 minutes to run in parallel on my system. Running the same analysis with PMV took about an hour. I would suggest either running the PMV case with analysis periods of typical/extreme weeks (use the "Import Stat" component to get these from the weather file) or run an annual analysis with the Adaptive comfort map. Alternatively, you could just let the PMV run overnight and I am confident that you should have something by morning.
Grasshope, The text looks like that because your Rhino model tolerance is not fine enough to capture all of the details of the text. Type "Units" into the Rhino command bar and drop your tolerance down to a smaller value. Then re-compute or re-open the GH file.
Oleksii, my initial reaction is to say that you can set up GH files with LB+HB components that allow you to do all of those things but the way that you have phrased the questions are a little vague (especially the last one there). I would recommend checking out this tutorial playlist that shows you how to set up an energy model with HB and this should help address the first two questions (https://www.youtube.com/playlist?list=PLruLh1AdY-SgW4uDtNSMLeiUmA8YXEHT_). I am still having an issue understanding what you mean by the last one but maybe the comfort tutorials might be in the vein of what you are looking for (https://www.youtube.com/playlist?list=PLruLh1AdY-Sho45_D4BV1HKcIz7oVmZ8v). If you want to re-phrase the questions more specifically, please post them as a discussion.
Thank you all,
-Chris…
s the "Surface Populating" definition: I manage to populate my geometry over the surface, but after I bake it, I have to delete the boxes that define my components limits as well! Is there any way of populating and baking only the chosen component, without having to delete the boxes afterwards?
Secondly:
Basically: I am trying to cover a surface with two types of components [ an open one and a closed one] , which will be proliferated over my tubular surface according to the main sunlight direction.
1. I introduce the surface component.
2. I use "Divide Interval2" in order to have division into U and V.
3. i generate the target boxes [ "surfaceBox"] .
4. I use "Isotrim" ( same intervals) and "BRepArea" to find centroid of each area.
5. My "Curve" component introduces sun angle, with its "End Points".
6. I use "Vector 2Pt" to specify sun-light direction.
7. I want to measure the angle between sun-light and the surface normals, at the position of each component; after generating the centre points, I need the normals of each centre point to get the surface's points' UV, and "Evaluate" the srf at points.
8."Angle" and "Vector" components: I use them in order to evaluate the angle between the sun direction and the srf.
9. I convert this angle to degree by using a "Function" [ to see if the angle is bigger from the max.angle or not...]
10. Function "x,y" gives me boolean data.
11. Data become "Dispatch"ed...
12. Two "Morph" components , each one linked to one part of the "Dispatch" data, generate "closed" and "open" components over the srf.
The result should have been different types of components, based on the surface's curvature, diraction and sun-light direction...
I do not understand where the mistake is in this definition...
Thx in advance1
Spyros K.…
e length from center point to each vertex related to time, and make them roll on ground under gravity.
I have created the model with 1 center point and 12 vertex points using GH, however when I convert particles for Kangaroo and apply gravity, I faced several problems and have several questions related to that.
Problems are:
1. 13 particles does not keep the shape of icosahedron and just fall flat on the floor.
2. I have managed to keep the shape using multiple "Tetrahedral Element" component, however this component determines its shape by its starting point so I do not get to control the length from center point to vertex later.
Questions are:
1. Is there any way that I can restrain the relative coordinate of vertex particle from central particle using its angle and distance?
2. Is there any way that I can control the parameter for distance relative to time?
3. Is there any other component I can use or any advise you can give me about how my simulation can be achieved?
Regards.
Judai
…
hat said, the processes that would benefit most from it in Rhino and Grasshopper actually lend themselves remarkably well to multi-threading. Things like Intersections, Meshing, operations on individual items in arrays would all benefit since they involve a lot of repetition where one iteration does not depend on the previous one.
Rhino4 was not designed to be threadsafe, and there were places where it was not possible to thread certain tasks. For example, imagine the Contour command. You'd think that it would be a piece of cake to thread that, you assign the first 25 contour intersections to core 1, the next 25 to core 2, the next 25 to core 3 and so on and so forth. But as it turns out intersecting a Brep and a Plane requires Rhino to build a spatial tree of the Brep first (assuming it doesn't exist yet). These trees vastly speed up a lot of operations and they are created lazily, meaning they get created the first time they are needed. Now we suddenly have four threads all trying to run a Brep Plane intersection and all trying to build the same spatial tree at the same time. This cannot end well. So in Rhino5 we made sure that when the spatial tree is getting build, every other thread that tries to access the Brep gets put on hold until the tree is done.
Then there's problems that the Intersection function might store temporary data on the Brep during the intersection, which makes threading intersections on the same Brep an absolute impossibility.
Then there's the even worse problem that the Intersection function might store temporary data in a static cache, which means you cannot run the function more than once at a time, even if it's on different Breps.
In Rhino5 we tried to rectify all of these problems. I think we got most of them by now.
When Grasshopper switches to Rhino5 for good, we'll start looking into threading a lot more seriously, not in the least because we'll also switch to .NET 4, which has some pretty cool mechanisms for writing decent MT code.
Until then, we'll have to stick to good old fashioned optimization. Christoph's problem was that it takes 12 minutes to open a file. Even if you thread that and you get 100% efficiency (which you won't, there's always additional overhead when threading) it would still take 3 minutes if you have 4 cores. It's an improvement sure, but not much of one. I'd like to know exactly where all that time is spend, then maybe we can remove specific bottlenecks.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…