Interoperability

Interoperability for AEC Computational Design

1. The Interoperability Challenge in AEC

1.1 Why Interoperability Matters

Interoperability -- the ability to exchange data between software tools without loss of meaning, geometry, or relationships -- is the single most critical infrastructure problem in the AEC industry. Every building project involves dozens of software tools, hundreds of files, and thousands of data exchanges. When those exchanges fail, the consequences are measured in millions of dollars and months of delay.

The AEC industry loses an estimated $15.8 billion annually in the United States alone due to inadequate interoperability (NIST GCR 04-867). This figure accounts for redundant data entry, manual format conversion, error correction from data loss, and delayed decision-making caused by information silos.

Unlike the manufacturing or aerospace industries, which converged on STEP/IGES decades ago, the AEC sector remains fragmented across proprietary ecosystems. Autodesk, Bentley, Trimble, Nemetschek, and dozens of smaller vendors each maintain walled gardens with varying degrees of openness. The result is a landscape where a single design decision may need to be re-entered into five or more tools before it reaches a construction site.

1.2 Single-Source-of-Truth vs. Federated Model Approaches

Single-Source-of-Truth (SSOT):

• One authoritative model from which all views and deliverables derive
• Revit-centric workflows often attempt this, with one central model containing architecture, structure, and MEP
• Advantages: no synchronization burden, clear ownership, simpler version control
• Disadvantages: tool lock-in, performance limits at scale, inability to leverage best-of-breed tools
• Practical limit: SSOT breaks down beyond approximately 200-300 MB models or when disciplines require specialized solvers

Federated Model Approach:

• Multiple discipline-specific models linked through coordination mechanisms
• Each discipline uses its optimal tool (Revit for documentation, Rhino for complex geometry, Tekla for steel detailing, ETABS for structural analysis)
• Coordination via shared coordinates, reference planes, and clash detection (Navisworks, Solibri, BIMcollab)
• Advantages: best-of-breed tooling, team autonomy, distributed workload
• Disadvantages: synchronization overhead, version mismatch risk, coordinate alignment complexity
• Industry trend: federated approaches are winning, especially with Speckle and IFC enabling richer exchange

1.3 Open Standards vs. Proprietary Formats

Open Standards:

• IFC (Industry Foundation Classes) -- ISO 16739, the only truly open BIM exchange standard
• gbXML (Green Building XML) -- energy simulation exchange
• CityGML / CityJSON -- urban-scale 3D models
• LandXML -- civil engineering survey and design data
• BCF (BIM Collaboration Format) -- issue tracking tied to model viewpoints
• Governed by buildingSMART International, OGC, and other standards bodies

Proprietary Formats:

• RVT/RFA (Revit), DWG (AutoCAD), 3DM (Rhino), SKP (SketchUp), PLA/PLN (ArchiCAD)
• Offer full fidelity within their ecosystem
• Risk: vendor lock-in, obsolescence, licensing dependencies
• Some are partially documented (DWG via Open Design Alliance) but reverse-engineered support is always incomplete

Pragmatic Reality: Most production workflows use a hybrid. Native formats for authoring, open formats for exchange, and lightweight formats (glTF, PDF) for communication. The goal is not eliminating proprietary formats but creating robust translation layers.

1.4 Data Loss Taxonomy

When data moves between tools, losses occur in four categories:

Additional nuanced losses:

• Precision loss: floating-point truncation at large coordinates
• Semantic loss: a "wall" becomes a generic "extrusion" in target tool
• Topological loss: solid body becomes disjoint surfaces
• Behavioral loss: parametric constraints become fixed geometry
• Unit loss: implicit unit assumptions cause scaling errors (mm vs. ft is a classic)

2. File Format Encyclopedia

2.1 Geometry Formats

OBJ (Wavefront Object)

STL (Stereolithography)

3MF (3D Manufacturing Format)

PLY (Polygon File Format / Stanford Triangle Format)

3DM (Rhino 3D Model)

DWG / DXF (AutoCAD Drawing / Drawing Exchange Format)

SKP (SketchUp)

STEP / IGES (Standard for Exchange of Product Data / Initial Graphics Exchange Specification)

SAT (ACIS Save As Text)

2.2 BIM Formats

RVT / RFA (Revit Project / Family)

IFC (Industry Foundation Classes)

NWD / NWC (Navisworks)

gbXML (Green Building XML)

COBie (Construction Operations Building Information Exchange)

2.3 Visualization Formats

glTF / GLB (GL Transmission Format)

USD / USDZ (Universal Scene Description)

FBX (Filmbox)

E57 (ASTM E57 3D File Format)

2.4 Data Formats for AEC

3. Data Exchange Strategies

3.1 Strategy Overview

3.2 Direct File Exchange

The simplest and most common approach: export from Tool A, import into Tool B.

Workflow: Author model in source tool -> Export to intermediate format (IFC, DXF, SAT, OBJ, etc.) -> Import into target tool -> Manual cleanup and re-association.

When to use: One-time or infrequent transfers, when live linking is not available, when tools are on different machines/networks, when a frozen snapshot is needed.

Key considerations:

• Always verify export settings (version, units, coordinate system, included categories)
• Document the conversion path for reproducibility
• Validate geometry and metadata in the target tool immediately after import
• Maintain a log of known data losses for your specific tool combination

3.3 Live Linking

Real-time or near-real-time bidirectional connection between tools running simultaneously.

Technologies:

• Rhino.Inside.Revit: Rhino and Grasshopper running inside Revit's process, sharing geometry and data live
• Dynamo ↔ Revit: Dynamo scripting within Revit, direct access to Revit API
• Grasshopper ↔ Tekla Live Link: Real-time structural model exchange
• Revit ↔ Robot Structural Link: Analytical model exchange for structural analysis
• Excel ↔ Revit (Dynamo): Live parameter read/write via Dynamo Excel nodes

When to use: Iterative design exploration requiring immediate BIM feedback, parametric facade design that must update Revit curtain panels, structural optimization with real-time analysis results.

3.4 Data Streaming (Speckle and Similar)

Continuous, version-controlled data flow between tools via a cloud or self-hosted intermediary.

Speckle is the leading open-source platform for AEC data streaming. It provides:

• Object-level versioning (not file-level)
• Connectors for 15+ AEC tools
• GraphQL API for custom integrations
• Web-based 3D viewer for review
• Automation triggers on model changes

When to use: Multi-discipline teams using different tools, continuous integration for design models, when audit trail and version history are required.

3.5 Database-Mediated Exchange

A shared database (relational, graph, or document) serves as the single source of truth.

Technologies:

• BIMserver (open-source, IFC-based model server)
• PostgreSQL + PostGIS (spatial database for GIS-BIM integration)
• MongoDB (document store for flexible BIM data)
• Neo4j (graph database for relationship-heavy BIM queries)
• Autodesk Construction Cloud (ACC) / BIM 360 (proprietary cloud platform)
• Trimble Connect (cloud collaboration for Tekla, SketchUp ecosystem)

When to use: Large enterprise projects, regulatory compliance requiring audit trails, when multiple tools need read/write access to the same data, asset management and operations phase.

3.6 API-to-API Integration

Direct programmatic communication between tools via their APIs.

Patterns:

• REST APIs for CRUD operations on model data
• GraphQL for flexible queries (Speckle, custom servers)
• Webhooks for event-driven workflows (model updated -> trigger analysis -> post results)
• WebSocket for real-time streaming (live sensor data into digital twins)

When to use: Custom automation pipelines, when no off-the-shelf connector exists, high-volume programmatic workflows, CI/CD for AEC.

3.7 Decision Matrix

Need real-time feedback during design?
  YES -> Live Linking (Rhino.Inside, Dynamo)
  NO ->
    Need version history and collaboration?
      YES -> Data Streaming (Speckle)
      NO ->
        Need programmatic automation?
          YES -> API-to-API
          NO ->
            One-time transfer?
              YES -> Direct File Exchange
              NO -> Database-Mediated

4. Grasshopper to Revit Pipelines

4.1 Rhino.Inside.Revit (Primary Method)

Rhino.Inside.Revit embeds the Rhino/Grasshopper runtime directly inside the Revit process. This enables Grasshopper definitions to read from and write to the active Revit document in real time, with full access to the Revit API through Grasshopper components.

Setup:

1. Install Rhino 8 (or 7) and Revit 2022+ on the same machine
2. Install the Rhino.Inside.Revit plugin from the McNeel website or Food4Rhino
3. In Revit, navigate to the Add-Ins tab -> Rhinoceros panel -> click the Rhino icon
4. Rhino and Grasshopper launch within Revit's process space
5. Grasshopper definitions can now reference Revit elements and create new ones

Core Component Categories:

Geometry Baking Workflow:

1. Create geometry in Grasshopper (curves, surfaces, meshes, solids)
2. Use element-creation components (Add Wall by Curve, Add Floor by Outline, etc.) to convert GH geometry into native Revit elements
3. Map Grasshopper data to Revit parameters using Set Parameter components
4. Elements are created in the active Revit document and update when GH inputs change

Parameter Mapping Pattern:

GH Number Slider -> Revit Parameter "Height"
GH Panel (text) -> Revit Parameter "Mark"
GH Boolean -> Revit Parameter "Is Structural"
GH Color -> Not directly mappable (use Dynamo or filters)

Element Tracking: Rhino.Inside.Revit tracks which GH components created which Revit elements. When the GH definition is re-run:

• Existing elements are updated in place (geometry and parameters)
• Deleted GH outputs result in deleted Revit elements
• New GH outputs create new Revit elements
• Element IDs persist across updates for reliable referencing

Best Practices for Rhino.Inside.Revit:

• Always set your Revit project units before running GH definitions
• Use Revit levels, grids, and reference planes as inputs to GH for alignment
• Internalize GH data for settings that shouldn't change (material assignments, category overrides)
• Use the "Tracking Mode" to prevent element duplication on re-run
• Keep GH definitions modular: separate geometry generation from Revit element creation
• Transaction management: Rhino.Inside batches changes into single Revit transactions for undo support

4.2 Speckle Pipeline

Send from Grasshopper:

1. Install Speckle Grasshopper connector from package manager
2. Add "Send" component to canvas
3. Connect geometry and data to input
4. Specify Speckle stream URL and branch
5. Data is serialized, converted to Speckle objects, and pushed to server

Receive in Revit:

1. Install Speckle Revit connector
2. Open Speckle Desktop Manager, select stream and branch
3. Click "Receive" -- objects are converted to native Revit elements
4. Conversion mapping: Speckle wall -> Revit wall, Speckle beam -> Revit structural framing, etc.
5. Non-mappable geometry arrives as DirectShape elements

Advantages over Rhino.Inside:

• Tools don't need to run on the same machine
• Full version history of every send
• Web viewer for non-licensed team members
• Automation triggers for CI/CD pipelines
• Works across Rhino, Revit, ArchiCAD, Blender, Unity, and more

4.3 Manual Exchange Methods

When live linking is not feasible:

SAT Export Path:

1. Bake Grasshopper geometry to Rhino
2. Export as SAT (ACIS solid) -- Revit reads this natively
3. In Revit: Insert -> Import CAD -> select SAT file
4. Geometry arrives as ImportInstance (limited editability)
5. Optionally convert to Mass or Generic Model family in-place

DWG Export Path:

1. Export from Rhino as DWG (2D for plans, 3D for massing)
2. In Revit: Link CAD or Import CAD
3. Use linked geometry as reference for tracing Revit elements
4. Suitable for complex curves that will become Revit floor/roof sketches

4.4 Coordinate System Alignment

Critical: Rhino and Revit use different coordinate conventions.

Alignment Procedure:

1. Establish a shared origin point (e.g., site survey marker)
2. In Revit: set Project Base Point coordinates to match
3. In Rhino: model relative to the same origin
4. When using Rhino.Inside, coordinate systems align automatically (same process)
5. For file-based exchange: verify unit conversion (mm in Rhino -> mm in Revit, not mm -> ft)

5. Rhino.Inside Workflows

5.1 Rhino.Inside.Revit -- Complete Guide

Architecture: Rhino.Inside uses Microsoft's COM interop and the .NET runtime to embed Rhino's geometry kernel (openNURBS + RhinoCommon) inside the host application's process. This means:

• Rhino geometry operations execute in-process (fast, no file I/O)
• Grasshopper can access the host API directly (Revit API via RhinoInside.Revit.GH)
• Both tools share the same memory space (no serialization overhead)

Supported Hosts:

• Revit 2019-2025+
• AutoCAD 2023+ (preview)
• Unity 2020+
• Custom .NET applications via RhinoInside NuGet package

Key Workflows:

1. Complex Geometry to BIM: Design freeform geometry in Grasshopper (SubD, NURBS lofts, panelized surfaces) -> bake as Revit floors, walls, roofs, or DirectShape elements

2. Parametric Facade: Define facade logic in GH (panel subdivision, attractor-based sizing, environmental response) -> create Revit curtain wall panels, mullions, and adaptive components

3. Site Analysis to Massing: Import terrain data in GH (Heron plugin for GIS, or direct point cloud) -> generate site-responsive massing -> bake as Revit masses for area calculations

4. Structural Optimization: Run Karamba3D analysis in GH within Revit -> structural results inform beam/column sizing -> updated sizes pushed to Revit structural elements

5. Environmental Analysis: Run Ladybug/Honeybee analysis in GH within Revit -> solar access, daylight, wind results -> inform Revit design parameters (window sizes, shading depths)

5.2 Rhino.Inside.AutoCAD

Preview technology allowing Rhino geometry operations within AutoCAD:

• Access to RhinoCommon geometry library from AutoCAD .NET plugins
• Use NURBS, SubD, and mesh operations not available natively in AutoCAD
• Potential for Grasshopper-driven AutoCAD automation
• Currently limited compared to Revit integration

5.3 Rhino.Inside Custom Applications

Using the RhinoInside NuGet package, developers can embed Rhino's geometry kernel in any .NET application:

// Initialize RhinoInside in a custom .NET application
RhinoInside.Resolver.Initialize();
using var rhinoCore = new RhinoCore(new string[] { "-appmode" });

// Now use RhinoCommon geometry:
var sphere = new Rhino.Geometry.Sphere(Point3d.Origin, 5.0);
var brep = sphere.ToBrep();
var mesh = Rhino.Geometry.Mesh.CreateFromBrep(brep, MeshingParameters.Default);

Use Cases:

• Custom design tools with Rhino-quality NURBS geometry
• Headless geometry processing servers (web APIs that perform NURBS operations)
• Automated file conversion services
• Batch geometry analysis pipelines

5.4 Performance Considerations

6. Speckle Platform

6.1 Architecture

Speckle is an open-source data infrastructure for AEC that provides version control, real-time collaboration, and automation for 3D models.

Core Concepts:

6.2 Connectors

6.3 Object Model and Conversion

Speckle uses a neutral object model that serves as the intermediary between tools. When you send a Revit wall, it becomes a Speckle Objects.BuiltElements.Wall with:

• baseLine (Speckle Line geometry)
• height (number)
• type (string)
• parameters (dictionary of Revit parameters)
• displayValue (mesh for visualization)
• units (string)

When received in Rhino, the wall's displayValue mesh is used for visualization, and its baseLine creates a Rhino curve.

When received in Revit, the converter attempts to find a matching wall type and creates a native Revit wall from the baseline and height.

Key Conversion Principle: Speckle always carries both the semantic object (with properties) and a display mesh. If the target tool can create the native element, it does. If not, it falls back to the display mesh.

6.4 Speckle Automate

Serverless functions triggered by model changes:

Use Cases:

• Model checking: Validate that all walls have fire ratings assigned
• Quantity extraction: Calculate material quantities on every commit
• Clash detection: Check for spatial conflicts between branches
• Report generation: Create PDF reports from model data
• Notification: Alert team members when specific elements change
• Analysis triggering: Run energy or structural analysis on model update

Architecture:

1. User sends data to Speckle stream
2. Automation trigger fires based on stream/branch/event
3. Serverless function (Docker container) executes
4. Function reads commit data via Speckle SDK
5. Function processes data (check, analyze, transform)
6. Function posts results back to Speckle (as new commit, report, or status)

6.5 GraphQL API

Speckle exposes a full GraphQL API for custom integrations:

# Query streams (projects) accessible to the authenticated user
query {
  streams(limit: 10) {
    items {
      id
      name
      branches {
        items {
          name
          commits(limit: 5) {
            items {
              id
              message
              createdAt
              referencedObject
            }
          }
        }
      }
    }
  }
}

# Get a specific object by ID
query {
  stream(id: "stream-id") {
    object(id: "object-id") {
      data
      children(limit: 100) {
        objects {
          data
        }
      }
    }
  }
}

Authentication: Personal access tokens or OAuth2 for applications.

6.6 Self-Hosting vs. Cloud

7. API Integration Patterns

7.1 REST API Fundamentals for AEC

Most AEC platform APIs follow REST conventions:

Common Response Patterns:

• Pagination for large result sets (offset/limit or cursor-based)
• Filtering by element category, parameter value, spatial query
• Expansion of related resources (include linked elements in response)

7.2 Authentication Patterns

7.3 Autodesk Platform Services (APS / Forge)

The Autodesk Platform Services (formerly Forge) API provides cloud-based access to Autodesk's design and construction data.

Key APIs:

…(truncated)