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.

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:

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.