Day 26 [24/03/17]: Grasshopper script from Flux to Rhinoceros/Grasshopper

Part 1: Figuring out CODE3100 and the Flux Flow

CODE3100 Design Studio — Building Information Modelling

Week 4 — Day 26: FRI 24 MAR 2017

Having spent a few hours trying to figure out the method of Flux in practice, I managed to create a logical connection between all groups which would be able to take part in using Flux as a platform for collaborating on the same project at the same time.

But I must warn that this example is more relevant when designing a building with multiple floors — I have yet to associate this process to our pavilion. Nevertheless, the logic still applies.

Day 26 [24/03/17]: Grasshopper script explaining how to import geometry from Flux to Rhinoceros/Grasshopper

1. Create a preliminary site model in Rhino/Revit (BIM Group) — or even justify using the Flux Site Extractor
2. Send that to Flux as geometries (Building mass models and streets / boundary lines) which will constantly be updated on Flux (Level of Detail — LOD)
3. All groups should now have access to Flux — where they use the given script (Flux to Grasshopper) to generate the site model for use on their desktop. The script can be found here: https://community.flux.io/articles/2316/access-data-in-grasshopper.html
4. All groups can propose building foot prints or designs / forms / massing models. Using the key “Design/Forms/MassingModels_GroupName”, they send this geometry back to Flux. (The naming system is something I made up — assuming that there will be a LOT of updates from groups to create their own input/layer into the Flux project file. Therefore we would know what the additional layer is and who created it). Sending the geometry back to flux through grasshopper can be found here: https://community.flux.io/articles/2315/send-data-from-grasshopper-to-flux.html
5. BIM group can bring the site model + proposed footprint into their desktop. Generate a script to create floor levels as well as collect floor areas — essentially collect data which can be scheduled for data visualisation within the design process. Create a script to send the data back to Flux using the key “FloorAreas/ ‘X’ Data_GroupName”, they send this as a table format (excel) for other groups to see as well as future updating.
6. Digital Making group can bring the site model + proposed floor levels / form / massing models into their desktop. Generate a script to propose and design a facade system based on the geometries. Send the data back to flux using the key “Facade_GroupName”, they send this geometry back to Flux for other groups to see and make suggestions.
7. Digital Fabrication group can bring the site model + proposed floor levels into their desktop. Generate a script to propose and design a structure based on the given floor levels and facade design. Send the data back to flux using the key “Structure_GroupName”, they send this geometry back to Flux for other groups to see and make suggestions.
8. BIM group can bring the facade geometry and structure geometry to compare for any problems. Report back to those groups with feedback / overall group discussion.
9. As geometries are starting to finalise, BIM group will organise groups to reallocate / extract geometries for floor, structure, facade and facade parameters — this will be brought into Dynamo for associating with general or custom BIM objects/families.
10. This will then follow up with BIM group generating a script for a schedule for all elements of the structure for fabrication / purchasing of parts.
11. BIM group create workflow script to export iterations (site model + geometry) into specific file formats for digital fabrication, AR, VR, etc.
12. VR/AR/Digital Fabrication/IOT groups have roles to organise and generate the physical and digital models for site.

These steps are constantly being undertaken throughout the whole process — iterations between each group will be contributed to design as well as visualized by the VR group. During this entire process, BIM group will also keep updating the site model for reissuing on Flux but more importantly, our role is to keep up to date with everyone’s contribution — therefore, every other group that sends geometry / data back to flux should post on Medium their scripts and written logic for us to understand. Therefore if problems do occur, we are able to figure this part of the process out TOGETHER.

Ultimately, this process when written this way, may seem like a linear process, but the idea of using Flux is to overlap the workflows constantly in order to continue to make progress between each group as smooth as possible — and parametric as possible too.