17th June 2023

A Distributed Model Example

A Distributed Model Example

The distributed data model (DDM) serves as an effective method for managing and handling sizable Grasshopper projects, particularly in team-based environments. As the name implies, this approach involves distributing data and models across multiple smaller Grasshopper scripts and Rhino files, instead of using a single large file.

Using multiple files means that your other team members can work on different aspects of the project simultaneously. By using Rhino Worksessions, changes from different segments of the project can be incorporated easily to the rest of the project, ensuring that you are always working with the latest data.

While I've written about the DDM before (You can read that here), I haven't shown in detail how to implement this model in projects. Therefore, I'd like to guide you through a simplified example, demonstrating how the DDM functions in practice and illustrating how it simplifies the management of large Grasshopper projects.

DDM is very useful for large complex projects with a lot of moving pieces but this means that it can be quite hard to show how useful the DDM is because it requires contextual understanding of the project. So, I am hoping that this simplified "project" is simple enough to understand but complicated enough to show the value of using the DDM.


Before we dive in, I wanted to note that Grasshopper has a variety of plugins that help in implementing the DDM. Although doing this without any plugins is possible, plugins will greatly simplify and bolster the process.


The most crucial plugin in this process is EleFront, it let's you programmatically exchange data between Grasshopper and Rhino in a structured and predictable manner. You can opt for exchanging data manually but you risk losing consistency and introducing manual errors along the way.

If you wanted to know more about EleFront, I have written about how the plugin works here.

Other Plugins

I am using several other plugins to help me build this model. All of them are not necessary, but they do make the scripting process easier. Here are the plugins that I am using

  • Pufferfish (for easy domain creation)
  • TreeSloth (for easier handling of patterns)

Creating the Model

In this example, we'll focus on modelling a building, specifically a typical commercial building in Australia (where I currently live). A building usually has three parts: a podium, a low rise, and a tower.

Pasted image 20230718145409.png
Being a structural engineer by training, I tend to use buildings for examples

And similar to the traditional way of constructing a building, we start from the bottom. We start at the podium, then the low rise and finally the tower. Here's how the logic will flow:

With that in mind, we'll start by modelling the Podium.

Modelling the Podium

The process begins with the creation of the base floor outline. We can define some parameters to control the shape of the outline.

Here, I am using the 2WayDomain component from pufferfish but you can easily manually specify a domain too.

Domain vs 2WayDomain

Pasted image 20230718145015.png

After creating the floor outline, we can create the core of the podium.

The building's core is like it's skeleton, typically positioned at the building's center and occupying about 10-20% of the total area.

Using the core outline, we can then generate grid lines from it. The grid lines inform us where to position the columns and are created by extending and moving the individual segments of the core outline.

Pasted image 20230718145022.png
I am using the Unweave component from TreeSloth but you can also use a Dispatch component with alternating true and false values

Using Dispatch instead of Unweave

Pasted image 20230718145031.png

The intersection of these grid lines give us the location of the columns.

I am also verifying that these column points fall inside the floor outline by using the PointInCurve component. Once, we have the base floorcolumn, and core geometry, all we have to do now is duplicate and move them upwards to create more levels.

I use a x-1 component here from Pufferfish but you just need -1 to exclude columns on the highest floor.

With all our elements modelled, we can bake them into the Rhino file to be used in the Low Rise portion later. I also will save this Rhino file as Podium.3dm.

Modelling the Low Rise

We start like we did with the Podium, an empty Rhino and Grasshopper file but this time since we need to use the Podium's geometry, we can bring that into our Rhino instance by using worksessions.

By typing "worksession" into the command bar or using the file tab, we can attach the Podium.3dm into the current working Rhino session.

Then, in Grasshopper, we can reference this geometry using the Reference by Layer component in EleFront. We only need the highest floor and core outline to start working on the Low Rise.

Knowing that the core extends throughout the entire building, we can create the Low Rise floor outline around the same center, taking care not to exceed the limits of the Podium floor outline.

Since, the Low Rise is quite simple, we just need to duplicate and move the floor and core outline upwards by the number of floors.

and like before, the geometry is baked and saved to the Rhino file as "LowRise.3dm".

Modelling the Tower

Like with the Low Rise, we again start with both a blank Rhino and Grasshopper file and use Rhino's Worksessions to attach the Low Rise geometry. Here, we can also attach the Podium's geometry, just to have more context on what we are working with.

Despite only needing the Low Rise geometry to model the Tower, I am also loading in the Podium geometry because it's relatively small. I am also saving this worksesson as "WorkingWorksession.rws", that way Rhino remembers all the files I need at any given time.

As before, we can use Elefront to reference in the Low Rise geometry, then move the geometry upwards by a number of floors.

Adding the Taper Effect

Then to add the tapering affect of the tower, we are going to introduce a pattern-based scaling method to the floors. To do this, we must first divide the floors into modules and then apply a linear scaling factor in the x-axis.

We can use a list to control the direction of scale for each module. We can use something like :

  • N - normal (Scale up along the list)
  • R - Reverse (Scale down along the list)

By default, scaling always happens from the origin but we want a scale that will only cause the floors to grow/shrink from one side. This means, we need to change the point of scale so that it only affects one side at a time.

Because the scaling will be "side" dependent, we can also control this in a list on a per module basis. We can use a pattern of :

o - opposite side
n - normal side

Then if we plug everything into a ScaleNU component, which let's us control the scale in multiple directions, we should get something like this.

With that, most of our building is complete. Although it might not look like much yet because we've only created working geometry. To make these elements presentable, we could turn them into surfaces and apply materials to them. But, to avoid making an already lengthy process longer, I am not going to dive into that here as it doesn't add to the value of the DDM.

Incorporating Changes

This is what the current flow of logic looks like :

It tells a linear story that with each new part, it relies on the data and geometry of the part that came before. With the use of worksessions, this means changes made to any portion should propagate to the rest of the model. i.e. if I make a change to the Podium, I can easily update the Low Rise and Tower portions of the model.

To do this, either reload the worksession in rhino or navigate to the layer system and use the right-click menu to update the model.

A more realistic Example

The nature of this example was to show a simple yet realistic process of using the distributed data model. Extending this model to include more parts will further demonstrate how effective using the DDM is for large Grasshopper projects, but it could also potentially add confusion to this tutorial.

So, to give you a glimpse of what a more complex DDM might look like, consider this

By adding more portions to the model like a Street Model and a Piles portion, we would end up with 3 work sessions and a flow that looks something like this:

Hopefully this diagram illustrates how the model's complexity can scale while still maintaining manageability, as any updates made will be taken into account downstream of the project.

Final Thoughts

While this tutorial demonstrated the application of DDM with a relatively simple building model, remember that its real strength shines in much more complex projects. By distributing data and models across multiple Grasshopper scripts and Rhino files, teams can tackle individual components simultaneously, while maintaining coherence and unity in the overall project.

As with any tool, mastery of DDM comes with practice. The more you experiment with it and apply it to your projects, the more you'll see how it can simplify your workflow.

Thanks for reading, until the next one.