Wednesday, 28 November 2012

Curved Folding Paper

I was recently involved in a 2-day workshop with Ankon Mitra in New Delhi, India, exploring curved folding as a means of lending structural stiffness to paper. After having worked on the ZHA Venice Biennale installation with the rest of the ZHA Code Group, I was keen on taking the idea further and Ankon, having extensively worked with Origami tessellations and straight-line folding for several years, was an excellent person to have on board with all his experience and expertise. A really big thanks to him for organizing this and getting everything together on such short notice, the hosts, Amit and Monika Gulati, and all the participants for making this happen.

Being an intensive 2-day workshop, the first day involved developing an intuitive understanding of material behaviour and basic thumb-rule principles of curved folding. Participants started with folding some known tessellation patterns by Jeannine Mosely, Andrea Russo and Richard Sweeney, and then went on to draw up their own patterns, learning what could fold and what could not. The first half of day-2 involved folding hypars (hyperbolic paraboloids) and corrupting, distorting and modifying them to create derivatives and satiate curiosity of what will or will not fold. Below is a small selection of the work done by the participants.



The second half of day-2 involved collectively making a 5 feet tall installation out of 210gsm (ivory) card paper to test if curved folding was strong enough to make it stand with such thin paper. The design process (illustrated below) started with a dodecahedron whose faces were further subdivided into smaller pentagons and planarized. The entire process of evolution is best explained by the illustration below:



This process gave us developable surfaces that were flattened into 6 modules and mass produced by a combination of hand cutting and using a digital vinyl cutter. Each of these building blocks was hand folded and stuck together using thin strips of paper as backing-plates and ordinary glue. Below an image sequence and time-lapse video of the assembly process.



I have to admit that before we started assembly, I was quite nervous if it this would stand: I was expecting the cap to collapse towards the centre like a bean-bag. But much to our amusement, not only did it stand, it was decently resilient to bending and external forces.



Having completed this and being pleasantly surprised by how well paper behaved, now I almost wish we had made this out of ordinary copier paper. Perhaps in some ways, I secretly did want to find the point where it would fail :)

Thursday, 17 November 2011

Mirror, Mirror on the Wall...


This post errs on the technical side of coding. There's many language related questions that often get asked around, but this post attempts to answer one of them:


"...which is the fastest of them all?"


The idea was initially tossed at me by Shajay Bhooshan and Mostafa El-Sayed at ZHA Co|de: to test the time taken to make 1 million random mesh cubes. We further refined it into 1, 3, 6, 12 and 24 million mesh faces, and we developed 2 ways of doing the same thing. The Spontaneous Array meant that sets of 4 random points and 1face would be computed and added to the mesh immediately, while the Ordered Array would generate all points and store them in an array first, and then append them all in one shot to the mesh and then generate the faces. I tried to be scientific about it, and here's the results:

*all times are best of 4 runs. Note that Rhino4 is 32-bit only.


Observations:
  1. In the defense of Rhino 4, may I add that the proceedure that adds geometry to viewport also seems handle the viewport redrawing. So all Rhino 4 solvingTimes add in the time taken to re-draw viewport. This seems to have improved in Rhino 5, where  adding geometry to the session and drawing it seem to have been split into seperate proceedures. This was easily noticeable when Grasshopper would become responsive and publish solvingTimes in Rhino 5 while viewports were still being drawn. But in Rhino 4, everything was solved and drawn first, and only then did anything start responding again. Yes Rhino 4 did run out memory and crash twice.
  2. The ordered and spontaneous arrays don't seem to affect Rhino 5 much, but they seem to affect Rhino 4 where the ordered arrays almost always seem to be faster by about 5%.
  3. This is not scientific, but on most runs C# seems to achieve its best time on the first run while VB does it in the 2nd or 3rd (almost never the 1st). And C# did seem very slightly marginally faster as array sizes grew.



Disclaimers:
My home ground is VB.NET. So it is highly likely that code I wrote in VB.NET is very optimized, while in C# a bit less so (less likely because it's nearly a direct translation of VB code) and very poorly written in Python (which is likely because I haven't worked too heavily on Python). It's a Grasshopper 0.80052 definition, and uses Giulio Piacentino's Python component for Grasshopper.


The Grasshopper definition can be downloaded here.

Update: Added in the Maya 2011 times as well, courtesy: Shajay & Mostafa.

Wednesday, 19 October 2011

Fabrication Oriented Parametrics


I was recently invited to the city of Changsha, China to conduct a 2 week workshop with Architecture students from Hunan University and also build a pavilion within certain cost/size/material/fabrication/time constraints. We were 3 tutors: Yu Du (Zaha Hadid Beijing), Shuojoing Zhang (UN Studio Shanghai) and myself, along with support from the Hunan University staff. This post is a documentation of what we built and how we got there.

Conceptual Design

The design brief was to design a pavilion outside the main DAL (Digital Architecture Lab) studio space with some seating within volume constrains of 6m x 3m x 3m, but mostly act as a sculptural piece that demonstrates a parametric design-to-fabrication process. The form we came up with was a single sculputral doubly curved surface that formed seating and a notional canopy.

Initial shape making: some exercises in basic aesthetics







Panellization

Once the base surface was frozen, a series of panellization exercises followed with the constants being that the in-house laser cutters were the only fabrication technique available, and plywood would be the most feasible material to procure and fabricate. So keeping in mind that planar panels out of plywood was the only way to go, we zeroed in on skewed hexagonal panels that formed gaps between them everytime the curvature was too high.


Flattening the panels achieved dual objectives: easier fabrication and a porous structure










Custom Detailing

Figuring out the panellization is one thing, figuring out how they're suspended in space is quite another. It was decided that the panels would be held by a triangular meshed network of thin steel cables, which in turn would be supported by laser cut wooden profiles fixed to a steel frame -- so far so good. Now came the part where we had to manage to fix panels to this cable network with a joint that allowed flexibility to move/rotate panels in all 3 axes. We 'invented' a custom detail that did exactly this:

Prototypes of the 'flower detail' being tested


The elongated slots in the plywood panels allowed transverse movement, while the circular slots in the steel discs allowed for lateral movement. Each hexagonal panel was to be fixed at 3 alternating corners, forming the 'plane' of that panel. Based on this information, three elongated slots were modelled into each panel and a numbering sequence was deviced to minimize chaos during fabrication. The production of laser cut drawing was automated from the model, so the script laid out the panels in an orderly manner which made it easy to stock them after they were cut.

Generating a fool-proof numbering sequence in a hex-grid is tricky




Fabrication Optimization

The laser cutters that we were working with had a bit of a problem: they were exceptionally slow at cutting curves, and even if we gave them segmented polylines, they would take a significant amount of time stopping at each junction and starting on the new segment. While the panels were all straight lines, the text became the killer. So we ended up inventing our own font that minimized the number of turns it takes to write a number, and obviously there were no curves. It's not the prettiest, but it saved about five minutes of laser cut time per panel, and there were 650 panels in total.


The machine friendly font setup in Grasshopper

The most labour intensive task in the entire assembly process was that of getting the cable mesh right. Cables ran in 3 direction (being a triangular grid), but each length segment on every cable was different. All our coding expertise could only go so far as to automatically generating excel files in correct sequence marking each cable name and segment length. We color coded and tagged each direction differently, but that only helped to some degree.

Patterns in numbers: a screenshot of the excel file containing cable lengths.

The cables had to be manually marked, cut and piled, and then clamped to the structure. The photos below should illustrate what a process this was.
A carpenter making post-it tags from the excel files


The good ol' T-square. Cables being measured and tagged


Nobody wanted to be the one unrolling this back into straight lengths.


So far so clean: adding alternate cables in 1 direction looks fairly clean and simple


But it starts getting complicated fairly quickly


Reaching a point of near-incomprehensibility when done




 The single biggest lesson learnt during the cabling process was to never repeat such an elaborate 'every-length-is-unique' setup, and adapt quickly to the skill of the workmen working on it. Finally, below's a slide show of the completed canopy.


Here's some sequential shots of the fabrication process.
Construction Sequence 1: Never assumes the walls to be vertical


Construction Sequence 2: Never assume the ground to be horizontal

There's also a short video of the Rhino+Grasshopper setup that generated all the final design geometry and construction data:


Tuesday, 18 October 2011

algorithmic Play+

As a part of the co|de group at ZHA, I've spent a significant amount of time in the past couple of years exploring  algorithm based form finding. Here's just a short quick compilation of some of the things I've been upto.








Sunday, 26 April 2009

The Lightbox - Art Fund Pavilion Competition

This is our (Saif Almasri, Suryansh Chandra) entry for the recent Art Fund Pavilion competition. It was quite a thing to shift to a 35 square metre pavilion after doing a 12 square kilometer city, but then the difference was also 3 days of rapidfire design over 16 months of intensive exploration and research. The brief was to cater to the following requirements:
  1. The pavilion was to be assemblable within 72 hours,
  2. The only material to use was 18mm or 25mm thick plywood. With cables/nuts/bolts/etc. for joinery,
  3. The pavilion needed to be collapsed, transported in its compact form, and reassembled in another location (for exhibitions, etc.),
  4. It needed to accommodate 30 sitting people in a presentation scenario with wall mounting space for A0 panels; accommodate 6 shelf display units and 4 floor standing display units for an exhibition scenario; and covert to an informal gathering space for a party scenario.
Having experienced the design and construction of the DRL 10 pavilion which took over a month to construct, we knew that having several different sectional profiles that needed to assembled together in a particular sequence was not going to work with the 72 hour deadline – it was way too complex and confusing for people on site just to figure out the sequencing right, let alone the assembly.

So we set up one of our primary objective to having the least possible variety of sections: something like standardized lego blocks of the same size so there is no confusion of which piece goes where – all pieces are 4 standard sizes, anyone can go anywhere as long as they are the same size. This, in my opinion is a very useful application of parametric design techniques where top-down form generation meets bottom-up component assembly logic – parametrics working towards minimizing costs and assembly times.





This system was setup in Rhino+Grasshopper in which we controlled the entire form with just 5 splines, and the computational system always maintained lengths and assembly constraints and provided the closest matching form. The final form consisted of 50 sectional profiles, each made up of 4 different sizes of members connected in the same sequence.

The final design was made up of 4 different sizes of members, linked up in series with hinged joints, which makes them collapsible into a very small size. The planned assembly was as follows:
  1. All 50 sets of sectional profiles will be assembled off-site as they are being CNC milled.
  2. All these profiles will easily fit in a mini-truck in their collapsed state, and transported to site.
  3. The profiles will be placed next to each other and the joints secured by running cables through them.
  4. The profiles will be opened up from their collapsed state, tuning the hinged joints until the final shape is achieved.
The seating was designed in the same manner with 2 different sizes of components. Due to the flexibility of a hinged joint, the seating was designed to be easily adjustable to become a bar counter in a party scenario or a display unit in the exhibition scenario.



Thursday, 23 April 2009

Urban Programmatic Distribution System - The 3d version

This video is an earlier version of the Urban Distribution System that was finally used in denCity. This version could do a 3d representation of the FAR & height maps which made better eye-candy, but didn't have features like the coastline change, pedestrian walkability zones, street patterns, etc. that was finally coded into the final version. It ultimately became so complicated and processing intensive that we had to discard the 3d ability just for the sake of sanity.

Sunday, 19 April 2009

denCity

denCity is a Masters level research project by Sahra (Peter Sovinc, Saif Almasri, Suryansh Chandra) at the Design Research Lab, Architectural Association, London.

denCity is a critique of modern day urbanization and city planning methodologies that are based on 20-year masterplans of linear city growth and are incapable of dealing with the pace of change of modern economic landscapes, societal conditions and life styles. It researches new interactive systems of master planning and urban design, that are capable of coping with completely different economic scenarios within a matter of seconds, producing relevant FAR and height regulation maps, programmatic distribution information and street networks.
At the architectural scale, denCity critiques modern day urbanization that is shaped by an assumed unending abundance of energy sources and the short sighted reliance on private vehicular transportation. The research is focussed on developing super high density 20 FAR pedestrian ladscapes and addressing issues of natural light penetration and ground association observed in contemporary high density cities.

Below is the online version of the final project with voice over:

Part 1/2



Part 2/2


Please feel free to leave you feedback/suggestions/etc.