Software interoperability for AECTech
We get diverse software packages to speak the same language.
Rhino, Grasshopper, Revit, ShapeDiver, Karamba3D, THERM, Unity, the browser, and the cloud -
ARPM connects the tools your design and engineering workflows actually run on.
SDK-level engineering, file-format reverse engineering, headless solvers, custom protocols, and parametric pipelines -
so design intent, geometry, and data flow end-to-end without losing fidelity.
Start a conversation
See deep case studies
A specialist practice for software interoperability
Most AECTech teams hand files between tools. A smaller number write scripts that automate that handoff.
ARPM works at the next tier - building the SDK-level integrations, reverse-engineered file readers, and headless orchestration layers that turn a fragmented toolchain into a single, parametric pipeline.
The work is genuinely hard: an analysis engine with no public API, a BIM platform that expects native objects, a cloud configurator that has to consume Grasshopper definitions reliably, a browser-based AR runtime that needs the same geometry the desktop modeller produced.
Every project on this page is a real production pipeline that connects two or more of those worlds.
That depth comes from working inside the toolchain for years. Our team has been a long-term contributor to the
ShapeDiver platform, shipped advanced plugins for Karamba3D , automated Lawrence Berkeley National Laboratory’s THERM for one of the world’s largest architecture practices, and authored our own visual scripting platform with native Rhinoceros interoperability and a plugin SDK - peer-reviewed at CAADRIA 2023 .
9+ packages
Connected across production pipelines
No-API tools
File formats reverse-engineered & orchestrated
Rhino → Revit
Procedural BIM families, not flat geometry
Desktop ↔ Cloud ↔ XR
Pipelines spanning native, web & immersive runtimes
What software interoperability actually is
Software interoperability is the discipline of getting independent applications to exchange geometry, data, and intent without information loss. In AECTech, that almost always means crossing boundaries that vendors did not design for: a parametric modeller talking to a BIM platform, a cloud viewer consuming a desktop definition, an analysis engine with no SDK answering questions from a Grasshopper component.
Done well, it removes the manual translation step that drains design teams. A model authored in Rhino lands in Revit as a fully scheduled facade. A detail section drawn in Grasshopper triggers a batch of headless THERM solves. A configurator definition runs identically in the desktop and in the browser. An XR runtime gets the same geometry the engineer just modelled, in real time.
Done poorly, files travel and information dies. ARPM’s remit is the former: build the connective tissue once, in the right place, so the rest of the team can stop thinking about it.
Why it matters
Real AECTech delivery rarely lives inside a single tool. Each handoff between applications is a place where geometry can drift, parameters can be lost, and design intent can be silently rewritten. Solid interoperability removes that risk at the source.
Single source of truth
One parametric model drives every downstream output - analysis, BIM delivery, configurator, and XR review. Editing in one place updates the entire pipeline.
No data lost in translation
Materials, parameters, identity data, and metadata travel with the geometry. Schedules and tags survive the move from Rhino to Revit, or from Grasshopper to the cloud.
Closed ecosystems opened
When no SDK exists, we reverse-engineer file formats, drive solvers headlessly, and wrap the result in clean components - so unsupported tools behave like first-class participants.
Cross-paradigm bridges
Dataflow and event-driven scripting, native and web, desktop and XR - we build the adapters that let parametric logic run wherever the project demands.
How we work
A complete capability for AECTech interoperability work - from SDK-level engineering down to file-format archaeology, and from cloud orchestration up into immersive runtimes.
We work primarily in C#/.NET against the Rhino, Grasshopper, and Revit SDKs, paired with TypeScript, JavaScript, Python, and native interop where the rest of the workflow demands it.
SDK-level integrations
Production-grade plugins built directly against vendor SDKs - Rhino, Grasshopper 1 and 2, Rhino.Inside.Revit, ShapeDiver, Karamba3D - with proper architecture, lifecycles, and licensing hooks.
Reverse-engineered file formats
When a tool ships without an API, we build defensive readers and writers from the file format up - validated across edge cases and stable enough to ship inside production tooling.
Headless solver orchestration
Driving desktop applications and command-line solvers without their UI - for batch sweeps, parametric studies, and reliable cloud execution that does not depend on a human at the screen.
Native ↔ BIM bridges
Rhino-to-Revit pipelines that produce procedural families with adaptive parameters, materials, identity data, and tags - not flat geometry handed across the fence.
Desktop ↔ Cloud pipelines
Grasshopper definitions and plugins authored to run identically on the desktop and in the cloud - with the file hygiene, performance shaping, and review workflow the platform demands.
Real-time messaging & web protocols
Custom protocols, RabbitMQ pipes, and WebSocket bridges that stream parametric geometry from the modeller to mobile AR, browser viewers, and configurator front ends in real time.
Native ↔ XR runtimes
Unity and WebXR runtimes fed directly from parametric authoring tools - for AR, VR, and mixed reality experiences that share geometry and data with the design model rather than a separate copy.
Plugin extensibility & SDKs
Building the interoperability layer the other way around - designing plugin SDKs, language bindings, and host applications so other developers can extend the toolchain.
Cross-paradigm scripting
Bridges between dataflow scripting (Grasshopper, Dynamo) and event-driven environments - including our own peer-reviewed VST research, with native Rhino interoperability built in.
Selected interoperability work
Nine projects that show the breadth of the practice - from automating an unsupported thermal solver, to a Rhino-to-Revit BIM pipeline, to our own visual scripting tool with native Rhinoceros interoperability and a plugin SDK.
{
{
}
}
Case study · LBNL THERM
Automating a solver that ships without an API
Lawrence Berkeley National Laboratory’s THERM is the de facto standard for two-dimensional steady-state heat-transfer analysis - especially thermal bridging in facades.
It was designed for interactive desktop use, with no public SDK and no documented file-format spec.
ARPM was brought in by HKS LINE to make it work as a callable component inside a Grasshopper-driven facade pipeline.
The interoperability challenge
No API, no SDK, no documentation. THERM’s file formats are oriented toward the GUI, not toward third-party tooling.
Geometry originates in Rhino and Revit. Detail sections drawn natively in design tools had to land as valid THERM models, every time.
Manual setup is the bottleneck. Each parametric sweep across many facade details could mean hours per iteration in THERM’s desktop UI.
Results need to come home. Solver output had to flow back into Rhino so designers could compare options inside the same parametric model that originated them.
What we engineered
Reverse-engineered file format support. Built defensive readers and writers for THERM’s native files, validated across edge cases drawn from real production details.
Geometry pipeline from Rhino. Components that translate Rhino detail sections into valid THERM input files, materials and boundary conditions included.
Headless solver orchestration. THERM is invoked from the command line with no on-screen UI - suitable for batch sweeps across many details at once.
In-Rhino result preview. Solver outputs are parsed and rendered back in the Rhino viewport, with export paths for offline review and reporting.
The outcome
Thermal-bridging analysis moved from a manual, per-detail exercise into a parametric study that runs at production project pace.
The pipeline turned an unsupported, GUI-only solver into a reliable component inside HKS’s Grasshopper toolchain - early enough in design to actually steer insulation breaks, geometry, and material decisions.
No SDK orchestration
Headless batch solving
Rhino ⇌ THERM roundtrip
HKS Facades production use
Read the project page
Case study · Rhino ↔ Revit
A Rhino-to-Revit pipeline that delivers native BIM, not imported geometry
Most Rhino-to-Revit workflows hand over “dumb” geometry - meshes and solids without parameters, schedules, or identity data.
For HKS LINE’s facade group, ARPM built a parametric pipeline that takes a Grasshopper-authored facade and writes it into Revit as fully scheduled, taggable, native families.
The interoperability challenge
Two different worldviews. Rhino is geometry-first; Revit is family- and schedule-first. The mismatch usually shows up at the worst possible moment in delivery.
BIM data has to survive the trip. Materials, parameters, identity data, tags, and dimensional metadata are non-negotiable for a production facade model.
Authoring stays in Grasshopper. Designers should be able to drive geometry parametrically while Revit treats the result as a hand-built model.
Three real, demanding projects shaped the work in parallel - with no second chances on documentation fidelity.
What we engineered
Procedural Revit families. Authored with adaptive parameters, materials, identity data, tags, and dimensional metadata appropriate to fabrication and documentation - not flat imports.
Custom Rhino.Inside.Revit tooling. Bespoke components on top of Rhino.Inside.Revit that instantiate and place native Revit family types directly from Grasshopper, with full BIM data attached.
Documentation-grade outputs. Schedules, tags, drawing extraction, and quantities all behave the way they would in a hand-modelled Revit facade.
Validated across three production facades. The pipeline matured under real delivery pressure on three demanding projects.
The outcome
A curtain-wall–class facade can be authored once in Rhino and Grasshopper, and delivered as a native, schedulable, taggable Revit production model - with the BIM depth project teams expect, and the iteration speed Grasshopper provides.
Procedural Revit families
Full BIM data preserved
Rhino.Inside.Revit custom tooling
3 production facades validated
Read the project page
Case study · ShapeDiver
Desktop, cloud, and AR - the same Grasshopper definition, everywhere
ShapeDiver is the leading cloud geometry and configurator platform for Grasshopper.
ARPM was a long-term technical partner across the development of ShapeDiver’s second-generation product (2020–2023), and is the only studio recognized as both a
Grasshopper partner
and a
Web development partner .
The interoperability challenge
One definition, three runtimes. Customer Grasshopper definitions had to behave identically on the desktop, in ShapeDiver’s cloud solver, and inside the browser viewer.
Browser-based AR. AR support had to land inside the web viewer - reliable across mobile devices, with no native app installation.
Third-party plugin onboarding. Every external plugin had to pass a manual quality gate before it could run in the cloud, and the review pipeline did not scale.
Customer delivery in parallel. Bespoke Grasshopper logic for enterprise users had to keep shipping while the platform itself was being rebuilt.
What we engineered
Next-gen Grasshopper plugin contributions. Co-developed components, contributed UI assets and icon sets, and helped land the prototype that became ShapeDiver’s second-generation Grasshopper plugin.
Browser-based AR runtime. Researched, prototyped, and shipped browser AR for the ShapeDiver viewer in TypeScript and C# - the same parametric geometry, rendered into the room.
Plugin review automation. Streamlined and partially automated the third-party plugin onboarding pipeline to reduce repetitive manual review effort while keeping quality standards intact.
Customer success delivery. Authored Grasshopper definitions and configurator logic for ShapeDiver enterprise clients, alongside platform engineering work.
The outcome
A single Grasshopper definition can now travel from the desktop into the cloud and out into a browser-based AR experience - with the same group writing the components, the AR runtime, the configurator logic, and the customer documentation.
The collaboration is on record from ShapeDiver’s leadership: the CTO and Head of Product have publicly endorsed ARPM’s contribution to the platform.
2020–2023 three-year partnership
Desktop ↔ Cloud ↔ AR parity
Dual-badge ShapeDiver partner
Endorsed by CTO & Head of Product
Read the project page
See the ShapeDiver partner page
Case study · Verse3
When interoperability runs the other way: building a host with a plugin SDK
Most of our interoperability work plugs into someone else’s platform.
With
Verse3 we did the opposite - building an event-driven visual scripting host from scratch in C#/WPF, with a plugin SDK and native Rhinoceros interoperability built in. The work was peer-reviewed at CAADRIA 2023 .
The interoperability challenge
A different scripting paradigm. Grasshopper and Dynamo are dataflow-first. Verse3 explores event-driven scripting - which means the host has to model time, signals, and state, not only graphs.
Third-party extensibility from day one. A scripting tool with no plugin story is dead on arrival. Verse3 needed an SDK, lifecycle, and component model good enough for outside developers to write against.
Real 3D, not toy geometry. Designers expect to script real geometry - meaning the host has to talk to Rhinoceros natively, not ship its own half-built modeller.
Backed by research, not just code. The work had to be defensible as research, with user studies and a methodologically clean evaluation.
What we engineered
Event-driven VST core. An MVVM C#/WPF host built on linked-list data structures, replacing the traditional dataflow execution model with an event-driven one.
Plugin SDK. A clean component and lifecycle API so third-party developers can extend Verse3 with their own nodes, panels, and behaviours.
Native Rhinoceros interoperability. Direct geometric interop with Rhino, so design scripts work on real production geometry from the start.
Peer-reviewed evaluation. User studies on students and AEC professionals, presented as “Creative Impact of an Event-Driven Visual Scripting Tool” at CAADRIA 2023.
The outcome
A working, open-source visual scripting platform that demonstrates a credible alternative to the dominant dataflow paradigm - with native interoperability into Rhinoceros and a plugin SDK that is the same kind of surface ARPM consumes elsewhere.
The same engineering muscles we use to integrate
into other tools went into building one ourselves.
Event-driven VST host
Plugin SDK shipped
Rhinoceros native interop
CAADRIA 2023 peer-reviewed
Read the project page
In their words
Direct endorsements from leadership at the platforms and products our interoperability work integrates with - ShapeDiver, Karamba3D, Supawood, and the AEC and XR community.
{
{
}
}
Have a toolchain that needs to talk to itself?
Whether it’s a Rhino-to-Revit pipeline, an analysis engine with no SDK, a desktop–to–cloud configurator, or an XR runtime that needs the same geometry the modeller just produced -
we’ll scope the integration, the dependencies, and the delivery plan together. Then we ship it.
Contact ARPM
Browse all projects