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:

Loss Type	Description	Example	Impact
Geometry Loss	Shape information degraded or missing	NURBS surface exported to STL loses curvature continuity	Visible faceting, dimensional inaccuracy
Metadata Loss	Properties, parameters, classifications stripped	Revit wall type info lost when exporting to OBJ	Downstream tools lack decision-critical data
Relationship Loss	Connections, hosting, spatial hierarchy broken	Wall-floor join lost in IFC export	Manual rework to re-establish element logic
Appearance Loss	Materials, textures, colors not transferred	PBR materials from Blender not mapping to Revit	Re-application of visual properties in target tool

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)

Property	Value
Extension	.obj (geometry), .mtl (materials)
Version	Originally 1992, no formal versioning
Geometry	Polygonal mesh, free-form curves/surfaces
Metadata	Minimal -- group names, material references
Max Size	No hard limit; practical ~500 MB
Typical Use	Mesh exchange, visualization, 3D printing prep
Read/Write	Rhino, Blender, 3ds Max, SketchUp, Unity, Unreal, MeshLab, CloudCompare
Strengths	Human-readable ASCII, universal support, simple specification
Limitations	No BIM data, no solid topology, no units, large file sizes for complex models

STL (Stereolithography)

Property	Value
Extension	.stl
Version	Original (1987), no updates
Geometry	Triangulated mesh only
Metadata	None (only triangle normals and vertices)
Max Size	No limit; practical ~200 MB for ASCII, larger for binary
Typical Use	3D printing, CNC machining, rapid prototyping
Read/Write	Every CAD tool, every slicer, every mesh editor
Strengths	Universal 3D printing standard, trivial to parse
Limitations	No color, no materials, no units, no metadata, triangles only, redundant vertex storage

3MF (3D Manufacturing Format)

Property	Value
Extension	.3mf
Version	1.2.3 (current)
Geometry	Triangle mesh with manifold validation
Metadata	Color, materials, print tickets, textures, build platform layout
Max Size	ZIP-compressed, efficient for large models
Typical Use	Advanced 3D printing with color/material, digital fabrication
Read/Write	Rhino, PrusaSlicer, Cura, Windows 3D Viewer, Materialise
Strengths	Modern replacement for STL, supports multi-material, compact
Limitations	Not yet universal, limited AEC adoption, no parametric data

PLY (Polygon File Format / Stanford Triangle Format)

Property	Value
Extension	.ply
Version	1.0 (1994)
Geometry	Point cloud and/or polygonal mesh
Metadata	Per-vertex color, normals, custom properties
Max Size	Binary format handles billions of points
Typical Use	Point cloud storage, 3D scanning output, research
Read/Write	CloudCompare, MeshLab, Blender, Open3D, PCL
Strengths	Flexible schema, binary efficiency, extensible vertex properties
Limitations	No materials/textures in standard spec, no BIM data

3DM (Rhino 3D Model)

Property	Value
Extension	.3dm
Version	openNURBS 8.x (Rhino 8)
Geometry	NURBS surfaces, curves, meshes, SubD, extrusions, points, annotations
Metadata	Layers, object attributes, user text, render materials, named views
Max Size	No hard limit; practical ~2 GB
Typical Use	Rhino native authoring, computational design output
Read/Write	Rhino, Grasshopper, openNURBS SDK (C++, .NET), Speckle, many viewers
Strengths	Full NURBS fidelity, open SDK (openNURBS), rich layer/attribute system
Limitations	No BIM semantics, limited structural metadata, Rhino-centric ecosystem

DWG / DXF (AutoCAD Drawing / Drawing Exchange Format)

Property	Value
Extension	.dwg, .dxf
Version	DWG 2018 (R2018), DXF tracks DWG versions
Geometry	2D entities (lines, arcs, polylines, hatches), 3D solids (ACIS), meshes, surfaces
Metadata	Layers, blocks, attributes, extended data (XDATA), object properties
Max Size	Practical ~500 MB
Typical Use	2D drafting, CAD exchange, legacy drawing archives
Read/Write	AutoCAD, BricsCAD, Rhino, Revit (import), QGIS, LibreCAD, FreeCAD
Strengths	Industry standard for 2D, massive legacy archive, block/attribute system
Limitations	DWG is proprietary (ODA reverse-engineers), DXF is verbose, 3D support limited

SKP (SketchUp)

Property	Value
Extension	.skp
Version	SKP 2024
Geometry	Polygonal mesh, groups, components
Metadata	Layers (tags), component definitions, material assignments, geolocation
Max Size	Practical ~300 MB
Typical Use	Conceptual design, massing studies, early-stage visualization
Read/Write	SketchUp, Trimble Connect, various importers (Rhino, Blender via plugins)
Strengths	Intuitive modeling paradigm, large 3D Warehouse library, geolocation
Limitations	Imprecise geometry, no NURBS, no parametric constraints, limited BIM

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

Property	Value
Extension	.step, .stp, .iges, .igs
Version	STEP AP214/AP242 (ISO 10303), IGES 5.3
Geometry	NURBS surfaces, B-rep solids, curves, wireframe
Metadata	Product structure, material (limited), PMI (AP242), assembly hierarchy
Max Size	Multi-GB for complex assemblies
Typical Use	Mechanical CAD exchange, manufacturing, CNC toolpath input
Read/Write	SolidWorks, CATIA, NX, Rhino, FreeCAD, Inventor, Fusion 360
Strengths	Neutral CAD exchange, precise B-rep, ISO standard, AP242 adds PMI
Limitations	Large files, slow parsing, IGES is legacy (use STEP), limited AEC adoption

SAT (ACIS Save As Text)

Property	Value
Extension	.sat, .sab (binary)
Version	ACIS R2024
Geometry	B-rep solids, NURBS surfaces, curves, sheets
Metadata	Minimal (body names, attributes)
Max Size	Practical ~500 MB
Typical Use	Solid geometry exchange between ACIS-kernel tools, Revit mass import
Read/Write	AutoCAD, Revit (import), SpaceClaim, Fusion 360, BricsCAD
Strengths	Exact B-rep, Revit can import as mass/generic model, clean geometry
Limitations	Proprietary kernel (Spatial Corp), no BIM semantics, limited ecosystem

2.2 BIM Formats

RVT / RFA (Revit Project / Family)

Property	Value
Extension	.rvt (project), .rfa (family), .rte (template)
Version	Revit 2025
Geometry	Parametric solids, extrusions, sweeps, blends, voids, meshes (limited)
Metadata	Rich: categories, families, types, instances, parameters, schedules, phases, worksets
Max Size	Practical ~500 MB (workshared models can exceed)
Typical Use	BIM authoring, construction documentation, coordination
Read/Write	Revit only (native), IFC export, various viewers (Navisworks, BIM360/ACC)
Strengths	Full BIM fidelity, parametric families, scheduling, documentation
Limitations	Completely proprietary, requires Revit license to edit, large file size

IFC (Industry Foundation Classes)

Property	Value
Extension	.ifc (STEP), .ifcXML, .ifcZIP, .ifcJSON
Version	IFC4.3 (ISO 16739-1:2024), IFC4x3 ADD2
Geometry	B-rep, CSG, swept solids, tessellated (triangulated), curves, point clouds
Metadata	Complete BIM: spatial structure, element types, property sets, quantities, materials, classifications, relationships, cost, time
Max Size	Multi-GB for large projects (IFC4 has improved efficiency)
Typical Use	OpenBIM exchange, regulatory submissions, archival, coordination
Read/Write	Revit, ArchiCAD, Tekla, Solibri, BIMcollab, Navisworks, FreeCAD, BlenderBIM, xBIM, IfcOpenShell
Strengths	Only true open BIM standard, ISO-certified, rich semantic model, vendor-neutral
Limitations	Inconsistent export quality across tools, complex schema, geometry fidelity varies, round-trip editing unreliable

NWD / NWC (Navisworks)

Property	Value
Extension	.nwd (full), .nwc (cache), .nwf (reference)
Version	Navisworks 2025
Geometry	Tessellated mesh (view-only, no editable geometry)
Metadata	Aggregated from source models, clash results, timeliner schedules, viewpoints
Max Size	Multi-GB (designed for large federated models)
Typical Use	Clash detection, 4D simulation, model review, coordination
Read/Write	Navisworks (native), BIM360/ACC viewer, Freedom (free viewer)
Strengths	Handles massive models, clash detection engine, 4D timeliner
Limitations	View-only (no editing), proprietary, Autodesk ecosystem only

gbXML (Green Building XML)

Property	Value
Extension	.xml (with gbXML schema)
Version	7.03
Geometry	Simplified planar surfaces (walls, floors, roofs as polygons), zones
Metadata	Thermal properties, construction assemblies, schedules, HVAC zones, location/climate
Max Size	Typically <50 MB
Typical Use	Energy simulation input (EnergyPlus, eQUEST, IES VE, Honeybee)
Read/Write	Revit (export), ArchiCAD, Trace 700, Honeybee, OpenStudio, IES VE
Strengths	Purpose-built for energy, widely supported by simulation tools
Limitations	Simplified geometry (no curved surfaces), inconsistent exports from Revit, limited to thermal model

COBie (Construction Operations Building Information Exchange)

Property	Value
Extension	.xlsx, .xml, .ifc (as MVD)
Version	COBie 2.4
Geometry	None (tabular data only)
Metadata	Facility, floors, spaces, zones, types, components, systems, assemblies, connections, documents, attributes, coordinates
Max Size	Typically <10 MB (spreadsheet)
Typical Use	Facility management handover, asset data delivery
Read/Write	Excel, COBie plugins for Revit, Solibri, BIMcollab, custom tools
Strengths	Simple tabular format, clear data structure, FM integration
Limitations	No geometry, manual population often required, limited adoption outside UK/US government

2.3 Visualization Formats

glTF / GLB (GL Transmission Format)

Property	Value
Extension	.gltf (JSON + binary), .glb (single binary)
Version	2.0 (Khronos Group)
Geometry	Triangle mesh, morph targets, skinning
Metadata	Node hierarchy, PBR materials, textures, animations, cameras, lights (KHR extensions)
Max Size	Practical ~500 MB (web delivery optimized)
Typical Use	Web 3D visualization, AR/VR, digital twins, model viewers
Read/Write	Three.js, Babylon.js, Blender, Rhino 8, Speckle viewer, Cesium, Unity, Unreal
Strengths	Web-native, PBR materials, compact binary, Draco compression, universal viewer support
Limitations	Triangle mesh only (no NURBS), no BIM semantics in base spec, limited AEC tool support

USD / USDZ (Universal Scene Description)

Property	Value
Extension	.usd, .usda (ASCII), .usdc (binary crate), .usdz (package)
Version	USD 24.x (Pixar)
Geometry	Mesh, NURBS (limited), curves, points, volumes, subdivision surfaces
Metadata	Scene hierarchy, materials (MaterialX/UsdPreviewSurface), variants, layers, composition arcs
Max Size	Designed for film-scale scenes (multi-GB)
Typical Use	Film/VFX pipelines, Apple AR (USDZ), emerging AEC visualization, NVIDIA Omniverse
Read/Write	Blender, Houdini, Maya, Omniverse, Apple ecosystem, Unity, Unreal
Strengths	Composition engine (layers, variants, references), scalable, industry momentum
Limitations	Complex specification, early AEC adoption, limited BIM tool support

FBX (Filmbox)

Property	Value
Extension	.fbx
Version	FBX 2020.3.4 (Autodesk)
Geometry	Polygon mesh, NURBS, curves, cameras, lights
Metadata	Materials, textures, animation, skeleton/bones, blend shapes, scene hierarchy
Max Size	Multi-GB
Typical Use	Game engine exchange, animation, Revit→Unity/Unreal visualization
Read/Write	3ds Max, Maya, Blender, Unity, Unreal, Revit (export), SketchUp
Strengths	Animation support, game engine standard, Autodesk ecosystem integration
Limitations	Proprietary (Autodesk SDK), inconsistent third-party support, no BIM data

E57 (ASTM E57 3D File Format)

Property	Value
Extension	.e57
Version	ASTM E2807-11
Geometry	Point clouds (structured/unstructured), meshes (optional), images (panoramic)
Metadata	Scan positions, sensor info, intensity, color, normals, cartesian/spherical coordinates
Max Size	Multi-GB (billions of points)
Typical Use	Laser scanning data exchange, as-built documentation, heritage recording
Read/Write	CloudCompare, ReCap, Cyclone, FARO Scene, Rhino (plugin), Revit (point cloud)
Strengths	Open standard for point clouds, lossless compression, multi-scan support
Limitations	Large files, limited mesh support, no semantic classification in base spec

2.4 Data Formats for AEC

Format	Extension	Use in AEC	Key Tools
CSV	.csv	Schedule data, sensor readings, analysis results	Excel, Python, Grasshopper
JSON	.json	API payloads, configuration, BHoM objects, Speckle	Everything
XML	.xml	gbXML, IFC-XML, configuration, legacy integrations	Everything
GeoJSON	.geojson	GIS features, site boundaries, zoning overlays	QGIS, Mapbox, Leaflet, Grasshopper
Shapefile	.shp/.dbf/.shx	GIS vector data, cadastral, infrastructure	ArcGIS, QGIS, FME, Grasshopper (Heron)
GeoTIFF	.tif	Elevation (DEM/DSM), satellite imagery, analysis rasters	QGIS, ArcGIS, GDAL, Grasshopper
LAS/LAZ	.las/.laz	LiDAR point clouds (LAZ = compressed)	CloudCompare, PDAL, QGIS, ReCap
CityGML	.gml	Urban 3D models (LOD 0-4), smart city data	FME, 3DCityDB, QGIS, cesium
CityJSON	.json	Lightweight CityGML alternative	cjio, QGIS, ninja viewer

---

3. Data Exchange Strategies

3.1 Strategy Overview

Strategy	Latency	Fidelity	Complexity	Best For
Direct File Exchange	Minutes-hours	Medium	Low	One-time transfers, legacy tools
Live Linking	Real-time	High	Medium	Iterative design, parametric-to-BIM
Data Streaming	Seconds	High	Medium	Multi-user collaboration, CI/CD
Database-Mediated	Seconds-minutes	High	High	Enterprise, large teams, audit trails
API-to-API	Seconds	Variable	High	Custom workflows, automation
Manual Mapping	Hours-days	Variable	Low	Non-standard conversions, one-offs

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:

Category	Components	Purpose
Revit Primitives	Category, Family, Type, Element	Reference existing Revit objects
Host Elements	Add Wall, Add Floor, Add Roof, Add Ceiling	Create hosted building elements
Structure	Add Beam, Add Column, Add Brace, Add Foundation	Create structural elements
Curtain Wall	Add Curtain Grid, Add Mullion, Add Panel	Parametric facade elements
MEP	Add Duct, Add Pipe, Add Fitting	MEP element creation
Site	Add Topography, Add Building Pad	Site modeling
Annotation	Add Dimension, Add Tag, Add Text Note	Documentation elements
Parameters	Get Parameter, Set Parameter, Add Parameter	Revit parameter read/write
Geometry	DirectShape, FormIt Geometry	Freeform geometry to Revit

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.

Aspect	Rhino	Revit
Up axis	Z-up	Z-up (internal), but Y-up in some exports
Origin	World 0,0,0 (arbitrary)	Project Base Point or Survey Point
Units	Set per file (typically mm or m)	Set per project (typically mm or ft)
Precision	Double precision throughout	Double precision, but UI rounds to project units

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

Factor	Impact	Mitigation
Memory	Rhino adds ~500 MB to host process	Close unused Rhino viewports
Startup	10-30 seconds to initialize Rhino kernel	Acceptable for session-based workflows
Large models	GH solving blocks Revit UI thread	Use async solving where possible
Element count	>5000 Revit elements from GH causes slowdown	Batch creation, disable preview during baking
Plugins	Not all GH plugins work inside Revit	Test critical plugins before committing to pipeline

---

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:

Concept	Description
Server	Central hub hosting all data (speckle.xyz cloud or self-hosted)
Stream (Project)	Container for related data, like a Git repository
Branch (Model)	Named line of development within a stream (e.g., "architecture", "structure")
Commit (Version)	Immutable snapshot of data sent to a branch
Object	Individual data entity with unique ID, properties, and optional geometry
Transport	Mechanism for moving objects (server, SQLite, memory, disk)
Connector	Plugin for a specific tool (Revit Connector, Rhino Connector, etc.)

6.2 Connectors

Tool	Connector Maturity	Send	Receive	Object Types
Rhino	Stable	Full geometry	Full geometry	Points, curves, surfaces, meshes, SubD, blocks
Grasshopper	Stable	Any data	Any data	Geometry + custom objects
Revit	Stable	Elements + params	Native elements	Walls, floors, beams, columns, MEP, rooms, views
Dynamo	Stable	Any data	Any data	Geometry + Revit elements
Blender	Stable	Full scene	Full scene	Meshes, curves, empties, materials
Unity	Stable	Limited	Full scene	GameObjects, meshes, materials
Unreal	Stable	Limited	Full scene	Actors, static meshes
AutoCAD	Stable	2D/3D entities	2D/3D entities	Lines, polylines, blocks, solids
ArchiCAD	Stable	BIM elements	BIM elements	Walls, slabs, columns, beams, zones
Excel	Stable	Tabular data	Tabular data	Rows/columns as Speckle objects
Power BI	Stable	N/A	Read only	Data visualization of Speckle data
QGIS	Beta	GIS features	GIS features	Vector layers, attributes
Tekla	Beta	Structural elements	Limited	Beams, columns, plates
ETABS/SAP2000	Community	Structural model	Limited	Frames, shells, loads
Bentley	Community	Limited	Limited	Varies

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

Factor	Speckle Cloud (speckle.xyz)	Self-Hosted
Setup	Instant	Docker Compose deployment
Cost	Free tier + paid plans	Infrastructure cost only
Data residency	EU (Speckle servers)	Your servers, your jurisdiction
Compliance	SOC2 in progress	Full control
Maintenance	Managed	Your responsibility
Scaling	Automatic	Manual (Kubernetes recommended)
Custom domain	No	Yes
Best for	Small-medium teams	Enterprise, government, regulated industries

---

7. API Integration Patterns

7.1 REST API Fundamentals for AEC

Most AEC platform APIs follow REST conventions:

Verb	Action	AEC Example
GET	Read	Fetch model metadata, list elements, get parameters
POST	Create	Create new element, upload model, trigger analysis
PUT	Update	Modify element properties, update model version
PATCH	Partial update	Update specific parameters without replacing entire element
DELETE	Remove	Delete element, remove model version

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

Pattern	Use Case	AEC Tools Using It
API Key	Server-to-server, scripts	Mapbox, OpenWeatherMap, most utility APIs
OAuth 2.0 (3-legged)	User-authorized access	Autodesk Platform Services, Trimble Connect
OAuth 2.0 (2-legged)	App-only access (no user)	APS for backend processing
Personal Access Token	Developer/scripting use	Speckle, GitHub, GitLab
Service Account	Automated pipelines	Google Cloud, Azure, AWS

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:

API	Purpose	Typical Use
Model Derivative	Translate RVT/DWG/IFC to SVF2 for viewing, extract metadata	Web viewer, model interrogation
Data Management	Manage files in BIM360/ACC hubs, projects, folders	Automated upload/download, file management
Viewer	Embed 3D viewer in web applications	Design review portals, client presentations
Design Automation	Run Revit/AutoCAD/Inventor headlessly in the cloud	Automated drawing generation, batch parameter updates
Webhooks	Event notifications for model changes	Trigger downstream processes on model update
Reality Capture	Process photos into 3D models (photogrammetry)	Site documentation, as-built capture
BIM360/ACC	Project management, issues, RFIs, sheets	Construction management integration

Authentication Flow (2-Legged):

POST https://developer.api.autodesk.com/authentication/v2/token
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&client_id=YOUR_ID&client_secret=YOUR_SECRET&scope=data:read

7.4 Webhook Patterns for Event-Driven AEC

Model Updated in BIM360/ACC
  -> Webhook fires to your server
    -> Server fetches updated model via APS API
      -> Server runs clash detection / compliance check
        -> Results posted back as BIM360 issue
          -> Team notified via Slack/Teams

Implementation considerations:

• Webhook endpoints must be publicly accessible (use ngrok for development)
• Implement idempotency (same event delivered twice should not cause duplicate actions)
• Queue events for processing (don't block the webhook response)
• Validate webhook signatures to prevent spoofing
• Set up retry logic for failed processing

7.5 Rate Limiting and Error Handling

Platform	Rate Limit	Strategy
APS/Forge	100-500 req/min depending on API	Exponential backoff, request queuing
Speckle	100 req/min (cloud)	Batch operations, GraphQL to reduce calls
Mapbox	100,000 req/month (free)	Cache tiles locally, use vector tiles
BIM360	Varies by endpoint	Respect Retry-After header

Error Handling Pattern:

import time
import requests

def api_call_with_retry(url, headers, max_retries=3):
    for attempt in range(max_retries):
        response = requests.get(url, headers=headers)
        if response.status_code == 200:
            return response.json()
        elif response.status_code == 429:  # Rate limited
            wait = int(response.headers.get('Retry-After', 2 ** attempt))
            time.sleep(wait)
        elif response.status_code >= 500:  # Server error
            time.sleep(2 ** attempt)
        else:
            response.raise_for_status()
    raise Exception(f"Failed after {max_retries} retries")

---

8. Schema Mapping

8.1 Revit Category to IFC Entity Mapping

Revit Category	IFC Entity (IFC4)	Notes
Walls	IfcWall / IfcWallStandardCase	StandardCase for straight, uniform walls
Floors	IfcSlab (FLOOR)	PredefinedType = FLOOR
Roofs	IfcSlab (ROOF) / IfcRoof	IfcRoof for compound, IfcSlab for simple
Ceilings	IfcCovering (CEILING)	PredefinedType = CEILING
Columns	IfcColumn	Architectural and structural
Beams	IfcBeam	Structural framing
Structural Foundations	IfcFooting	Various PredefinedTypes
Doors	IfcDoor	Hosted in IfcWall via IfcOpeningElement
Windows	IfcWindow	Hosted in IfcWall via IfcOpeningElement
Stairs	IfcStairFlight / IfcStair	IfcStair as container
Ramps	IfcRamp / IfcRampFlight	Similar to stairs
Railings	IfcRailing	PredefinedTypes: HANDRAIL, GUARDRAIL
Curtain Walls	IfcCurtainWall	Contains IfcPlate (panels) and IfcMember (mullions)
Curtain Panels	IfcPlate	PredefinedType = CURTAIN_PANEL
Curtain Mullions	IfcMember	PredefinedType = MULLION
Generic Models	IfcBuildingElementProxy	Catch-all for unmapped elements
Furniture	IfcFurniture	In IfcFurnishingElement hierarchy
Mechanical Equipment	IfcDistributionElement	Various subtypes
Plumbing Fixtures	IfcSanitaryTerminal	IfcFlowTerminal subtypes
Electrical Equipment	IfcElectricDistributionBoard	Various IfcDistribution subtypes
Ducts	IfcDuctSegment	IfcFlowSegment subtypes
Pipes	IfcPipeSegment	IfcFlowSegment subtypes
Rooms	IfcSpace	Spatial element
Areas	IfcZone	Spatial zone (less common)
Topography	IfcGeographicElement	New in IFC4
Site	IfcSite	Spatial structure element

8.2 Revit Parameter to IFC Property Set Mapping

Revit Parameter	IFC Property Set	IFC Property	Type
Mark	Pset_WallCommon (etc.)	Reference	IfcIdentifier
Comments	Pset_WallCommon (etc.)	Description	IfcText
Phase Created	Custom / Pset	PhaseCreated	IfcLabel
Fire Rating	Pset_WallCommon	FireRating	IfcLabel
Thermal Resistance	Pset_WallCommon	ThermalTransmittance	IfcThermalTransmittanceMeasure
Structural	Pset_WallCommon	LoadBearing	IfcBoolean
Top Constraint	Mapped to geometry	N/A (geometric)	--
Base Offset	Mapped to geometry	N/A (geometric)	--
Area	BaseQuantities	NetSideArea	IfcAreaMeasure
Volume	BaseQuantities	NetVolume	IfcVolumeMeasure

8.3 Classification Systems

System	Jurisdiction	Use	Example Code
OmniClass	USA/Canada	General AEC classification	23-13 21 00 (Curtain Walls)
UniClass 2015	UK	Unified classification (UK BIM mandate)	Ss_25_10_30 (Curtain walling systems)
Uniclass	International	ISO 12006-2 based	EF_25_10 (Wall and barrier elements)
MasterFormat	USA/Canada	Specification divisions	08 44 00 (Curtain Wall and Glazed Assemblies)
UniFormat	USA/Canada	Building systems	B2010 (Exterior Walls)
IFC Classification	International	BuildingSMART	IfcClassificationReference linking to any system

8.4 COBie Data Drops

COBie (Construction Operations Building Information Exchange) defines structured handover data at key project milestones:

Drop	Stage	Data Required
COBie Drop 1	Design	Facility, floors, spaces, zones (spatial structure)
COBie Drop 2	Construction Docs	Add types, components (major equipment), systems
COBie Drop 3	Construction	Add documents, warranties, spare parts, job data
COBie Drop 4	Commissioning	Add test results, commissioning data
COBie Drop 5	Handover	Complete dataset for facility management

---

9. Coordinate System Management

9.1 Revit Coordinate Systems

Revit maintains three coordinate reference points:

Reference	Purpose	Visibility
Internal Origin	Absolute 0,0,0 (never moves)	Not directly visible; use "Startup Location" in newer versions
Project Base Point	Defines project coordinate system, shown as circle with cross	Visible in site plan, can be clipped (pinned) or unclipped (moved)
Survey Point	Real-world survey coordinates, shown as triangle	Visible in site plan, typically set to survey marker or GPS coordinate

Shared Coordinates: Revit's mechanism for aligning multiple linked models. Each linked model acquires its position relative to the host model's shared coordinate system.

Workflow for Multi-Model Coordination:

1. Establish survey point in host model matching real-world coordinates
2. Link discipline models
3. Use "Acquire Coordinates" from linked model or "Publish Coordinates" to linked model
4. All models now share a common coordinate system for clash detection and coordination

9.2 Rhino Coordinate Systems

Concept	Description
World Origin	Absolute 0,0,0 (always exists)
World XY	Default construction plane at Z=0
CPlane	Active construction plane (per viewport, can be set to any orientation)
Named CPlanes	Saved construction planes for repeated use
Block Origin	Local origin for block definitions

Best Practice: Model with the World Origin at a project-meaningful location (building corner, site survey marker). This simplifies exchange with Revit and GIS tools.

9.3 Geographic Coordinate Systems

System	Type	Use	Precision
WGS84	Geographic (lat/lon)	GPS, global mapping, web maps	~1 cm with full decimal degrees
UTM	Projected (meters)	Regional mapping, large sites	Sub-millimeter within zone
State Plane (NAD83)	Projected (ft or m)	US survey, local government	Sub-millimeter within zone
OSGB36	Projected (meters)	UK Ordnance Survey	Sub-millimeter within UK
Local Grid	Project-specific	Construction, site layout	Arbitrary precision

Coordinate Transformation Chain:

GPS (WGS84 lat/lon/alt)
  -> Projected (UTM/State Plane, meters or feet)
    -> Local Site Grid (rotate/translate to align with site)
      -> Revit Shared Coordinates (survey point = local grid origin)
        -> Revit Internal (project base point offset)
          -> Rhino World (match Revit internal or shared)

9.4 Common Unit Conversions

From	To	Factor
mm	m	0.001
mm	ft	0.00328084
mm	in	0.0393701
m	ft	3.28084
m	in	39.3701
ft	m	0.3048
ft	mm	304.8
in	mm	25.4
in	m	0.0254
cm	in	0.393701

Critical Rule: Always verify units at every exchange boundary. The Mars Climate Orbiter was lost because of a metric/imperial unit mismatch. AEC projects regularly suffer coordinate/dimension errors from the same root cause.

9.5 Large Coordinate Handling

When working with real-world coordinates (e.g., UTM easting 500,000+ meters), floating-point precision issues arise:

Problem: IEEE 754 double-precision floats have ~15 significant digits. At UTM easting 500,000 m, sub-millimeter precision requires 9 digits (500000.000), leaving only 6 digits for the fractional part. This is sufficient for most AEC work, but:

• Geometry operations (intersection, Boolean) accumulate error
• Display rendering at large coordinates causes "jittering" (Z-fighting equivalent)
• Some tools use single-precision floats (7 significant digits), causing visible drift

Mitigation Strategies:

1. Translate to local origin: Subtract a large offset to bring coordinates near origin
2. Use project-relative coordinates: Define a project origin near the site center
3. Double-precision everywhere: Ensure all tools in the pipeline use double-precision
4. Round-trip validation: After coordinate transformations, validate against known survey points
5. Revit approach: The Project Base Point provides this translation; model near internal origin, survey point handles real-world mapping

9.6 Coordinate Alignment Between Tools

Step-by-step alignment procedure for Rhino ↔ Revit ↔ GIS:

1. Establish shared reference: Choose a physical survey marker or building corner with known real-world coordinates (UTM or State Plane)

2. Revit setup:

   • Move Survey Point to the known real-world coordinate
   • Set Project Base Point to a convenient location near the building (e.g., grid intersection A-1)
   • Note the offset between Survey Point and Project Base Point

3. Rhino setup:

   • Set Rhino World Origin to match Revit's Project Base Point (for modeling convenience)
   • Document the offset to real-world coordinates
   • Alternatively, model at real-world coordinates if precision allows

4. GIS setup:

   • Use the same projection (UTM zone, State Plane) as the survey
   • Import building footprint at real-world coordinates
   • Verify alignment with aerial imagery or cadastral data

5. Verification:

   • Export a known point from each tool
   • Compare coordinates in a spreadsheet
   • Acceptable tolerance: <5 mm for building scale, <50 mm for site scale

---

Quick Reference: Interoperability Decision Checklist

1. What data needs to move? Geometry only, geometry + metadata, metadata only, or relationships?
2. What tools are involved? Check the format compatibility matrix in the reference file.
3. How often? One-time -> file exchange. Iterative -> live linking. Continuous -> streaming.
4. What fidelity is required? Exact NURBS -> STEP/3DM. Visual mesh -> glTF/OBJ. Full BIM -> IFC/native.
5. Who needs access? Licensed users -> native format. Everyone -> web viewer (Speckle, APS Viewer). Fabricators -> DXF/STEP.
6. What can be lost? Accept geometry simplification? Lose parametric constraints? Lose material appearance?
7. What coordinate system? Align on shared origin, units, and projection before any exchange.
8. What is the fallback? If the primary pipeline fails, what manual workaround exists?