Project on Mars: Accommodation in Jezero Crater
Our design is influenced by the relationship between the amount of energy required to dig underground vs. the amount of energy lost to heating a building above ground. The cold extreme environment on Mars is what makes building above ground a bad idea when stable temperatures are available beneath the surface. We take inspiration from Iranian Shavadun houses where occupants dwell in different parts of the house at different times of the day optimizing for thermal comfort as well as other rock-cut subtractive architectures that date back to Ancient Egypt and examples of architecture in other extreme environments. Just as NASA’s Perseverance mission of 2021 used Terrain Relative Navigation in order to find the best place to land a rover on Mars within Jezero Crater while it was on its way down to the surface, we use Terrain Relative Construction to test for hardness of the ground and then implement a script to build in the most optimal locations.
Collaborative Workflows
Our group is accommodation that is connected to all other groups in the Jezero Crater masterplan.
We divided tasks into connectors design, interior planning, and outer shell design. These three starting points were then further subdivided into more specific things to do. The three branches come back together in a buffer stage and then split up to create graphics, drawings, and other outputs that can be distributed to other groups on a weekly basis.
Ren designed the Connector, Raghad took on Interior planning, and James did our Shell design. We split up workflows into personal and speckle streams.
Individual streams show the creation of different Speckle Objects for different sized versions of our project. This is because accommodation will occur at multiple places and different sizes in the Mars masterplan. Ren’s connectors required a structural mesh, panels, and entrances.
Raghad’s stream needed to receive inputs from both the connector and the shell. Floor plans, 3D Breps and text tags could then be added to the Interiors Speckle Object for again Small(S), Medium (M), and Large (L).
James’s Shell also have S, M, L and focus on the Metaball geometry and how it needs to be split in different ways for different uses.
Our collaboration suffered as anything does from learning something new and trying to implement it elsewhere at the same time. Several branches were empty with no commits as not everyone had got used to adding components within their files to send data to Speckle. The small step of copying and pasting a Speckle workflow into other files you are working on at the end of each of the assignments is what we would recommend to future teams. Such an exercise is more about the building of a habit than the learning of further knowledge, but is crucially important.
Our team also struggled with external distractions that outside of our control. Each of us was familiar with different software before this course such as Adobe Illustrator that is not yet compatible with Speckle and two of us were learning Revit for the first time. We also wanted to share our Grasshopper files with each other not just the final geometry output from Grasshopper. That resulted in normalizing sending files elsewhere such as on Slack or Google Drive. This last point becomes the inspiration for our app.
App: .ghCloud
Architects often create complex grasshopper definitions using large segments that have already been previously created elsewhere. Our app idea is to embrace the organization that the cloud can offer with rich libraries of searchable content for grasshopper files.
Reference books have been around for decades but quickly go out of date. Dublin looked up the size of trucks in an old reference book and then spent a final cost of €750 million building a port tunnel to get trucks out of the city without causing traffic. Unfortunately, trucks had increased in size since that reference book was published and many larger trucks can’t safely fit inside Dublin’s port tunnel. Mission failed. This is one reason why cloud-based libraries are better in that they can be updated. Websites like Dimension.com offer rich libraries of 2D files with dimensions from furniture to famous architects which is another reason libraries in the cloud are better. They can specialize into every tiny niche.
We believe that a cloud-based library of grasshopper files would be a useful tool for beginners to play around with already built and tested Grasshopper definitions, so as to learn can how to assemble definitions of their own. The bridge below is a simple Grasshopper definition to learn the basics.
Many advanced users are already sharing their files online but those files are extremely difficult to find. Below is a car park definition that shouldn’t need to be individually created by every design firm on Earth. It just needs to created once or maybe a few different options catering to various regions and parking requirements. This file was found in the Grasshopper forums submitted by Ivan Grebennikov in 2021.
Architects may wish to share parts of their definitions open-source. James created the file below to parametrically control a design similar to O-14 by Reiser + Unemoto (RUR). The part that takes any 2D geometry and surface morphs that geometry onto a 3D surface could be useful to many architects around the world. It is too complex to create for some and for others it is a waste of their time to create from scratch.
For our Mars project, we are draping a mesh over another mesh. One of the other groups asked how did we do it? This became a real-world need where Ahmed wanted part of our definition and we were happy to share it with him. Their group were going to do something completely different with this definition part. The part was packaged to work with Hops so that it could be easily inserted into Ahmed’s script. But when Ahmed opened it, it had a bug! Our input meshes were aligned whereas Ahmed’s were not. So Ahmed added an align vertices component and sent it back creating V0.2 of drapeMesh.gh improving from the original version as it will now receive both aligned and not aligned vertices without producing an error.
Files in a cloud-based library benefit from being regularly updated by users and don’t need to updated by everyone individually. Once one user updates a script, other uses can positively vote the update as working and then the file is updated for all. This approach would have greatly benefited one of our previous modules where old files were used with outdated versions of that plugin. One of us was needed to update the each file, not all of us individually doing the same work.
We have many plugins installed in Grasshopper coming to the end of our second term. Most of these plugins were used for a short period of time maybe even just the one time. Should users have to learn how to use a complex plugin when their needs are not that large? A compute server in the cloud with all plugins updated to the latest version using files that would be updated by users could offer to compute parts of a definition without requiring everyone to learn a new plug-in, download it, update the file found in a forum to work with the latest version of that plugin, then give up and ask friends in slack for help and so on. We think these are problems worth solving and that is what .ghCloud would accomplish.
The last few years have seen quite a number of websites that receive a file, do a task, and then let the user download the result. These range from pdf editors that delete specific pages, video to gif convertors, or simply adding photo filters. Their popularity has even forced Adobe to compete in these arenas. These types of quick operations are just as relevant and in-demand for 3D files and .gh files.
Final Crit Presentation
The final crit included guest critics Alan Rynne (Speckle), Alfonso Melero Beviá (VisualARQ), and Jan Leenknegt (BIG) as well as faculty João Silva and Francisco Pereira.
