A brief overview of our scope of work:
Our group is part of a larger aggregation cluster that establishes a colony in the lower Earth orbit. We are tasked to design modules that would house programs for living in space. So next we’ve broken down our content into three main parts. So first would be defining the team roles, second would be the process and workflows, and lastly would be our detailed processes.
Team & Roles
Almost naturally, and in the overall flow of work roles were assigned; In this manner, Mahmoud was assigned the role of the computational design: His role is to create a design system to automate the production of the modular geometry.
Erida is the BIM manager supervising the production streams on SPECKLE, designing the detailed parts as BIM objects.
Neil on the left hand as a lead architect and coordinator with other groups, he decides on the base geometries for work sharing, thus allowing him to gain micro and micro insights on the overall development of the orbital project in all of its components.
Made in the early stages, these roles allowed for fluid communication and a better workflow.
The Workflows
In the first three weeks, Speckle was used in order to familiarize ourselves with its capacities. This allows us to understand the best practices. We started by working first, all of us on only one branch, then assigned different duties to each one. In such a manner, Mahmoud and Neil worked on the exterior geometries of the living pods and also on the way they aggregate while Erida was working from the inside out to determine the interior components of the pods.
Slowly the workflow started to become more robust, building up software over another in their overall progress. This is the timeline that we followed;
- First we would have a conceptual design needed communication, so we use slack. Also, we created the system using Grasshopper scripts.
- We did the modeling and had to have a baked model, so that was the rhinoceros output.
- We then made the documentation using Revit rendering using Lumion, and then passed everything to the website to work with JavaScript and all the HTML resources to reveal the remaining blurred sections.
In this graph down below, we present the overall workflow. The first part is the one dedicated to creating the system, the second one for building the model and troubleshooting, then finally putting everything to sort in the documentation and visualization.
Following this new direction. In the first part, we worked on the grasshopper scripts that would generate our main geometry, the pod, and the prefabricated compartments using Speckle and sometimes “Hops”. When needed, we transferred the outputs to each other.
Once the script was ready, we moved to the building and troubleshooting part.
Erida:
“So since I was also working on detailing, further detailing, I was working on the microscale. My job was also to merge the scripts that Neil and Mahmoud were working on together and produce the final model. Of course, during this, there were cases where I had to detect clashes or different issues and I, of course, gave feedback to Mahmoud and Neil and it mostly happened to Slack since our group is also not very big, so it was possible to do it that way. And as an end result, we were able to produce this way our final Rhino model, which we then also use for further processes such as visualizing it through Blue on, but also going along and producing documentation to reinvent sites, which we will further explain in the further side.”
Speckle Repository
So after all of this, what we’ve done for the larger group, which is the overall Orbit group, we’ve created a Speckle stream that would be a repository for all of the geometry that we would want to and as part of the Living group, we constantly coordinated with the other groups how we’re going to aggregate and how the connections of the different modules would be.
Then we developed the main web app for our project and this would be in turn placed in a final model and aggregated and would be the output for the final project of the Orbit. So initially, part of the role of the architect is to send the preliminary design concepts and set up objectives and design criteria for subdividing our geometry into modular fragments, and the base geometry is where other members will be working on.
We then set up our main Speckle stream for our group named the Living Orbit Central, which would be our main repository for aggregated work.
For this stream, we tried as much as possible to not create different branches on this stream and recall all geometries on the latest commit of the mainstream. And to maintain this workflow, we started to work on our local documents and we always needed to call I received from Speckle first to see all updates and to avoid overriding all the geometries when we send updates to the stream.
Documentation
And then of course documentation was also part of our project. It was not a final step since we had to produce it in the Integrative Modeling course along with the design development. So we had to figure out a way how to do that; Speckle was very helpful in that direction. We created a new branch called Rhinoinside and then -also understanding the way Rhinoinside works- We figured that the best way would be to explode our model into isolated components in a way that everyone concerning, also saving up time. Everyone would have the possibility to update certain objects and then send them to the stream. We use Speckle objects for that in order also to be able to convey data along with the geometry.
</p>
Speckle Collaborative Workflows – Orbit + Living Group. is a project of IAAC, Institute for Advanced Architecture of Catalonia developed at MaCAD – Master in Advanced Computation for Architecture & Design in 2021/22 by :
Neil John Bersabe, Mahmoud Ramdane, Erida Bendo.
Faculty: Alan Rynne, Joao Silva