Footbridge Render (Image courtesy DVVD)

Following up with our showcase of the use of computational tools on real projects, this time, we feature a complete breakdown of the workflows and strategies employed in the design, rationalization and construction of the Footbridge at ZAC Claude Bernard by DVVD Architects
Azhar Khan shares with us how did he together with his team at ELIOTH acted as consultants for this project and walk you through the whole process and problems they had to solve to build it.
Introducing Azhar Khan:
For most students and architecture firms, Rhino plays a significant role in the early stages of design where we can quickly develop ideas and test multiple iterations. Add Grasshopper to this and you have an intuitive visual-programming environment that allows you further flexibility.
If like myself you have been using Grasshopper in a firm, then you have most probably used it more in the project at the beginning, found a working geometry, developed it further in Rhino and then either handed it to CAD or Revit for final drawings.
This workflow is typical as Rhino models to produce a 3D drawing can only go so far until AutoCAD is needed to clean up and produce the ‘real’ drawings.
So when the opportunity came to detail a bridge entirely in Grasshopper, I jumped on it, curious to see if it was even possible to take a project from conception all the way to a set of fabrication drawings by using just Rhino and Grasshopper. In the end we able to use Grasshopper to check clashes and clearances, rationalize geometry, detail each and every joint, and produce a model comprehensive enough (down to the bolts) that we made drawings from (with help from Tekla)!
PROJECT BACKGROUND
None of this would have been possible without the architects DVVD and their project, the footbridge at ZAC Claude Bernard. Our firm served as consultants, primarily as the team to figure out the geometry issues and help produce the drawings, particularly the steelwork. The project is a footbridge, the first I believe to cross the Peripherique, the circular highway that bounds the city of Paris. It connects the city to the Aubervilliers area to the North that has undergone some major renovation recently.
I was very fortunate to be able to participate in this one a kind project, the success of which could promote further footbridges connecting the city to its suburbs.

Footbridge Render (Image courtesy DVVD)

FOOTBRIDGE ARCHITECTURE
Several challenges were facing us from the start. The bridge follows a twisting nature from beginning to end and has no symmetry. The cross section of the bridge is continuously changing which means that each member of the deck is unique in dimension. Also, as you traverse the bridge, no two members of any segment are parallel and, therefore, there are no planar surfaces inherent in the model.
The overall shape of the footbridge was frozen and, therefore, was not going to be modified. What was going to change were the type of certain joints and member sizes/shapes. Adding, subtracting and modified elements at this scale would be enormous task if done by hand. The team asked to set up a Grasshopper model that represented the bridge’s primary elements.

Rhino Model base for Grasshopper (image courtesy Elioth)

I took the Rhino model from the architects as the base model that serves as all reference geometry for Grasshopper. The model consisted six free-form curves that define the structural trusses and lines that represent the segmentation of the footbridge. The typical cross section shows the architectural intention of the footbridge, a pair of triangular steel trusses that support a deck in between, all clad in wooden slats.

Initial Grasshopper Model (image courtesy Elioth)

I was able to take the geometry and produce a simple model of the bridge’s primary steel structure. It was apparent that several issues needed to be addressed.
1) Planarization: For economy, it was important that we use only planar panels for all the deck and cladding surfaces. This was not inherent in the architect’s design and we used Grasshopper to best approximate planar working surfaces for each segment of the bridge (in turn developing sets of work planes, edges and center points as well).
2) Joint variation: Due to the shifting geometry of the bridge across its length, the deck structure intersects at different parts of the truss structure at each segment. These connections take on various forms depending on their relative location and we have to design a set of typical details that are applied automatically across the bridge and adapt to the changing geometry.
3) Rationalization: The form of the bridge was generated through a set of six free-form curves. To fabricate this truss, we would have to rationalize those curves somehow.
4) Drawings: In the end, even if we were able to generate a sufficiently detailed model of the bridge, how were we going to produce drawings from them? Use Rhino? Export to CAD?
I was convinced that Grasshopper could effectively address all these issues, except for the last one, I will get to that later.
Model Development
The Grasshopper script grew as we modeled more elements into the parametric logic. We were at a stage where we could change element section profiles as needed, create custom joints for each intersection, and check clashes between our members. We even set up an algorithm that read a DWG file exported from GSA (a structural analysis program used by the engineers) and directly applied the engineering section profiles automatically to our Grasshopper model. This way any changes by the engineering team could be reflected quickly and accurately in our model.

Developing steel and wood elements from the wireframe model (image courtesy Elioth)

Organizing the model into bays, segments, members etc. The organizational strategies evolved as the project requirements increased (image courtesy Elioth)

Arc Rationalization
One of our challenges was figuring out a way to fabricate the truss as it followed a free form 3d geometry. The original intention was to convert the curves to polylines and construct them out of linear segments, but this meant that was an enormous amount of welding to be done. A suggestion was made to build the curves out of simple arcs, and I was asked to develop an algorithm to find the minimum best fitting arcs for each free-form curve to minimize welds and simplify construction.
I used Grasshopper’s built-in evolutionary solver, Galapagos, to achieve this. Each curve was broken down into smaller parts and converted to arcs. The deviation between the arcs and original curves were measured, and Galapagos had the job of finding the optimal arc configuration for each truss.

The original intention was to split the truss curves into linear segments and weld them together (above). In order to economize the project we found the best fitting arcs for each curve and minimized the number of welds (below) (image courtesy Elioth)

Box Section Optimization
You may notice from the image above that the trusses seem incomplete, that each truss appears to have a section missing. This is because near the ends of the trusses the members are so close together that they are consolidated into a box section. The box section is essentially a lofted surface comprising the remainder of segments and thus forms a doubly curved surface that again posed a construction challenge.
In order to rationalize this volume into a set of planar surfaces I once again used Galapagos. The box volume is formed by a series of triangles of different dimensions and angles. The idea was to choose one of the triangles and copy it over to the other section locations. We then adjust the scale of these sections to best match the original triangles and we make a new lofted surface. This surface now consists of planar surfaces as it is a lofted surface made from similar triangles. In order to find the right section to copy and the correct scaling values we ran Galapagos for each side of the truss.

The original lofted form is doubly curved (left). The form was optimized by lofting a set of similar triangles to obtain surfaces comprising planar quads (right). Galapagos was used to determine the correct section size and scaling factors to minimize the deviation between the original and final forms. (image courtesy Elioth)

Clashes and Measurements
Grasshopper was also used in checking for clashes and for taking quick, accurate measurements across the bridge. We used it to constantly measure the bridges impact over the highway to ensure that the allowable height for vehicles was clear and maintained. When it was breached, Grasshopper was used to make adjustments to the geometry to clear up some more space under the bridge.
Another task that Grasshopper proved useful was checking the distance between the wooden slats that clad the footbridge. The required spacing was a maximum of 11cm for safety purposes and to prevent littering. With Grasshopper not only could we measure the distance between the slats but also show the results visually. This was useful as we can then make live changes to the slat density and see the impact on the spacing.

The script was used to check measurements such as those between the wooden slats for safety purposes. It was easy to visualize the gaps and make changes to the slat density. (image courtesy Elioth)

TEKLA
So we can see where Grasshopper was useful in the modeling of the bridge. But what about the drawings? So far Grasshopper had worked extremely well on its own, and we had it synced up with GSA as well. So for the drawings we used Tekla, a program specializing in producing drawings from a 3D model, particularly for steel structures.
To accomplish this, we used GeometryGym, a plugin for Grasshopper that allows transfer of data between multiple platforms, including Tekla. The transfer was only one-way (Grasshopper to Tekla) and could be done live with the two programs open on the same computer. All we had to do was code our Grasshopper geometry into a set of lines, planes, points and vectors for Tekla to turn into plates, beams, and bolts, all at the click of a button.
This presented an interesting workflow challenge. In essence, we were now creating two models in Grasshopper. The first model was using standard Grasshopper definitions that allowed us to preview the geometry in Rhino. At the same time, each of these geometries had an equivalent Tekla definition in terms of planes, lines, points, and vectors and some text that also had to be created. One model was to view in Rhino and verify everything before the other model was sent to Tekla. It was quite difficult at first, but I developed a template that made my job a little easier. The result is that we were able to model almost the entire bridge, down to the bolts, in Grasshopper and send over the equivalent geometry to Tekla to construct the drawings. Below are a few of the screenshots from this process.

The image on the left shows the Rhino view of the joint. This is then transferred to Tekla via GeometryGym to make the drawing package (right) (image courtesy Elioth)

Due to the complexity of the bridge and the unique dimensions and orientations of each member, it was easier to model it entirely in Rhino (right) including the bolts and then transfer thegeometry to Tekla (left) (image courtesy Elioth)

A section view of the Tekla model showing the various components that were developed in Grasshopper and transferred to Tekla (image courtesy Elioth)

A Tekla screenshot of the model as it nears completion (image courtesy Elioth)

Conclusion
In the end, I feel the entire team was impressed that we had taken the script this far. It was intended to help with the process but ended up playing a significant role in the modeling and the geometry transfer to Tekla. Not all of the bridge was made in Grasshopper of course, only the parametric parts, the main stretch of the bridge. The ramps and other areas were done by hand in Tekla. In an office where Grasshopper was used primarily to perform energy analyzes and to model parametric forms, I was glad that I had the opportunity to design a script that took it to a level that I had not seen myself before; one that dealt with constructability and real geometries. The entire process took around 8 months from start of the script to the last geometry transfer. Less than a year later the bridge was erected!

The exposed steel and wood structure as built from the Tekla model drawings that were initially modeled in Grasshopper (image courtesy Adrien Escoffier)
The Peripherique closed for the installation of the bridge (image courtesy Adrien Escoffier)

The Box Section that was optimized with Galapagos (image coutesy Adrien Escoffier)

The post Using Grasshopper and Tekla to construct a pedestrian footbridge in Paris. appeared first on Designplaygrounds.