Week 07: The Parametric Grid System Component
This post built on from the previous post — Week 06: Looking into JSON
Considering the design of the pavilion may include a grid system for construction, I decided to explore the possibilities of developing this model in Grasshopper as a custom component.
This process would continue into looking into other software programs, branching off into a solid workflow for documenting this simple structure via live inputs all at the same time.
So the first step was to derive this custom component. I used Grasshopper to start this process, due to my confidence and familiarity with the program. Of course I could definitely replicate this logic into a script in Dynamo at a later stage.
One of the first problems was figuring out how to remove the overlapping curves created by boxes.
This is the link I used to solve the overlapping duplicate curves:
Then I needed to figure out how to create a cluster/user object from the derived script, which proved to be a success.
So the image below shows the custom component created. Here, you can see the only required inputs to generate the grid system are:
- X, Y and Z values for each individual module
- X, Y and Z values for array in those directions
- The script inside had to have a parametric relationship between each module
Result.
From here, I wanted to collect the points required to generate the data for each level of the modules vertically. This proved to be the most challenging aspect of the whole process — because I wanted to not only revert it back into the initial custom component I made in grasshopper, but that fact that I wanted it to work perfectly parametrically. The next link helped me resolve this issue.
Above is the link for how to obtain the specific nth item of a list so that I could generate levels in my grid system component.
Once I was able to extract the points for the elevations, I needed to label each level of the module for documentation. I never really needed to use the 3D text tag tool before, so this was another component/tool I picked up on the way.
Above is the link for how to add two lists of texts together. This allowed me to figure out how to label the levels and it’s elevations easily together without having to manually choose and determine what to name each point. The two images below weren’t the final labeling system I wanted to use as ‘Level 1’ is not actually the correct name for ‘Ground’. Therefore I needed to shift the list up and replace the first input.
To make the process and easier for me to work things out, I actually went back into the original script I generated before ‘clustering’ it. So the resulting script for the newly updated custom component grew in size. Below is the overall script prior to becoming a component (as seen in the image below that).
Therefore the new input and outputs are:
Input:
- X, Y and Z values lengths for each of the modules
- X, Y and Z values for arrays in those directions
Output:
- The grid system geometry
- Level location points
- Level names for tagging
I was also able to rotate the tag if I wanted to make it readable in certain situations. This was achievable through this forum post:
After developing the custom component for the grid system, I stumbled upon a tutorial from flux about importing a DFX into flux to be sent over through to Revit and adding custom components (such as a pipe Revit family) onto it without having to touch Dynamo. The reason as to why I wanted to look into it, was because it was an option to sending the geometry without having to recreating it through scripting in Dynamo.
But would this lose the ‘intelligence’ of the model?
I have yet to answer that question. So far, I’ve been able to successfully send the exported geometry from Rhino to Flux without problems and read it as a JSON file. Below is the imported DFX file from Rhino on the Flux Uploader Lab App.
The process taken was the resulting geometry was baked in Rhino from Grasshopper — this allowed me to test whether the resulting geometry wasn’t having duplicate lines and then exporting it from Rhino to a DFX for uploading to Flux 3D Model Uploader.
From here, the geometry can be stored in a Flux project for connecting to other softwares such as Dynamo/Revit, but also it has the ability to be written out as a JSON file. Here is the data in Flux as both the 3D model and it written as JSON below the 3D preview.
I didn’t touch the geometry again because I wanted to start looking into connecting Excel with Flux and then transfer the data into Grasshopper for live updating.
This started out with going back into the tutorial of the Intermediate Flux Flow Tutorial [https://www.youtube.com/watch?v=UoDp7leljrY]. I followed through by creating my own Excel spreadsheet and determining the input values required to generate the grid system in my custom component. This is shown here:
So basically in the Excel spreadsheet, I created two tables which determined the input values — the same ones used to determine the custom component inputs.
These tables were separately sent to Flux. I then extracted the data from the two tables which had their own individual keys in Flux:
What I found out was that when the tables were separated into separated into keys, this made extracting the information/data much easier. Also, the way in which the nodes were labelled was different to GH and Dynamo, but had the same sort of logic to extract the right information — which was then resulting with sending back into a new key in Flux.
The information was passed through to Grasshopper via the Flux components. They came through via two sets of data — because there were two separate data keys. I then extracted from the resulting lists as individual inputs for the custom component. By keeping the flow on ‘Constant’, I was able to adjust the input dimensions and number of arrays in the Excel file, where the change in the model would be generated almost instantaneously through Flux. This is seen in the GIF below.
The next part required me to look into creating a relationship between Excel, Grasshopper, Flux and Dynamo/Revit.
Using this tutorial [https://www.youtube.com/watch?v=UoDp7leljrY] I was able to resolve how to connect between both Grasshopper and Revit directly through flux. This allowed me to have a main space to control the level creation for the modules almost instantaneously if dimensions or amount of arrays are required.
What I stumbled upon, was the fact that the inputs I created wasn’t actually correct the first time. This was because what I fed into Dynamo was the wrong data. What I fed initially was the XYZ height, width and length (3 inputs) for the modules themselves, rather than the resulting heights from Grasshopper. This was resolved later on by sending the resulting information from Grasshopper (the height of the module as well as the name of the levels) to Flux, then received back to Dynamo to feed into Revit.
The data that needed to be sent to Flux from Grasshopper was:
- The names/labels for the levels created
- The resulting heights for the points/positions of the tags and levels for each module
Below is the resulting script to receiving the data from flux into the custom component, then the resulting data sent back to Flux for Dynamo to use in Revit documentation.
Once that data was sent to Flux, the data key input was changed in Dynamo and allowed the creation of the levels in Revit be made correctly. I had to adjust the data in the Dynamo script for the Level names by flattening it as shown below.
The default creation of levels in Revit was a little difficult to work with when generating the new levels, because they would overlap and show ‘(1)’ next to the duplicated level.
Regardless, this development of the workflow proved to be very successful. Seen below is the interconnected relationships between Excel, Grasshopper/Rhino and Dynamo made possible by Flux.
