Research
How we built interoperability between Rhino, Grasshopper, and Hektar, and why preserving data structure across tools, not just geometry, is the real challenge.
Early-stage planning rarely happens in a single tool. A site might begin as a survey in CAD, move into Rhino for massing, get tested through Grasshopper definitions, and then land in a feasibility platform for analysis. Every handoff between these environments is a moment where information can be lost. Interoperability is the work of making sure it is not.
In Rhino and most CAD environments, structure is carried by layers. A designer knows that everything on one layer is a building, another is a parcel boundary, another is a road. This organization is obvious to the person who built the file, but it is fragile. The moment geometry crosses into another system, the layer logic that gave it meaning tends to fall away. What arrives on the other side is a set of surfaces and solids with no memory of what they represent.
This is the core interoperability challenge for early-stage tools. Moving a volume from Rhino into Hektar is easy. Moving the understanding that the volume is a residential building of a specific typology, sitting on a specific parcel, is much harder. When the data structure does not transfer, the receiving system cannot reason about the geometry. A massing study becomes a pile of shapes rather than a model that can be measured, compared, and generated against.
Hektar organizes a site as a hierarchy of site, roads, parcels, and buildings. Every object needs to know where it sits in that structure to be useful. When a volume is added or imported, it does not automatically inherit this context. It has to be assigned back into the model, connected to its parcel and classified as a building, before the platform can calculate areas such as GFA and coverage, test density, or run analysis on it.
This re-assignment step is the hidden cost of crossing a tool boundary. A designer who adds a single new volume in a study expects it to simply be part of the model. In practice, an unassigned volume is invisible to the logic of the platform until it is reconnected to the hierarchy. Reducing that cost, or removing it entirely, is what interoperability work is really about.
To close that gap, Parametric developed a plugin for Rhino with a dedicated set of Grasshopper components. The components let designers map their existing layer structure to Hektar's data model directly inside the environment they already work in. Instead of exporting raw geometry and rebuilding every relationship by hand, a designer defines in Grasshopper which geometry is a parcel, which is a building, and how they relate, then carries that structure across intact.
The effect is that the semantic layer survives the journey. Geometry arrives in Hektar already knowing what it is and where it belongs, so the platform can immediately measure it, compare scenarios, and generate against the same constraints. For studios that live in Rhino and Grasshopper, this means the bridge into generative feasibility no longer requires throwing away the structure they spent time building. This matters most for architecture firms whose early massing work already happens in these tools.
This work was not done in isolation. Formas, through the Smart Built Environment program, funded research and development focused specifically on interoperability and generative design in early-stage planning. The goal was not only technical plumbing between formats, but understanding how better connections between tools change the way people design.
Two effects stood out. The first is creativity. When interoperability works, designers spend less time on file conversion and manual rebuilding, and more time exploring options. Lowering the friction between idea and test means more scenarios get tried, including ones that would not survive a tedious export-and-rebuild cycle. The second is efficiency. Work that previously had to be redone at every handoff is done once and preserved. The structure a designer creates in Rhino becomes an asset that travels with the project rather than a step that is repeated. Together, these shift early-stage work from managing file transfers toward actual scenario exploration and handoff.
File-based interoperability is only the first layer. The next is conversational and agent-driven. The Model Context Protocol (MCP) is an emerging standard that lets AI agents communicate with tools and data models directly, in a shared language. Where today a designer manually maps layers to a data model, an MCP-aware agent could read the intent of a model and connect geometry to the right place in the hierarchy on its own.
This is a natural extension of the work we have already done on AI-assisted feasibility modeling. Instead of interoperability being something a person performs between tools, it becomes something agents negotiate continuously. A volume added in one environment could be classified, assigned, and analyzed without a manual reconnection step, because the agent understands both the geometry and the structure it belongs to.
Interoperability is not a feature to be checked off. It is the connective tissue between the tools that early-stage planning actually depends on. The lesson from our research is that the hard part is never moving geometry, it is moving meaning. Layers, typologies, and the relationships between parcels and buildings are what make a model worth reasoning about, and preserving them across tools is what turns a collection of shapes back into a project. As agent-driven standards like MCP mature, that connective tissue will only get stronger.
