From computational-design-skills
Provides AEC computational design interoperability guidance: file formats encyclopedia, data exchange strategies, API patterns, Grasshopper-to-Revit pipelines, Rhino.Inside workflows, Speckle streams, schema mapping.
npx claudepluginhub amanbh997/claude-skills-for-computational-designersThis skill uses the workspace's default tool permissions.
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 mont...
Automates Revit BIM workflows via API scripting, Dynamo visual programming, pyRevit extensions, IFC/openBIM exchange, model checking, clash detection, and interoperability for AEC design.
Mandates invoking relevant skills via tools before any response in coding sessions. Covers access, priorities, and adaptations for Claude Code, Copilot CLI, Gemini CLI.
Share bugs, ideas, or general feedback.
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.
Single-Source-of-Truth (SSOT):
Federated Model Approach:
Open Standards:
Proprietary Formats:
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.
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:
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
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:
Real-time or near-real-time bidirectional connection between tools running simultaneously.
Technologies:
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.
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:
When to use: Multi-discipline teams using different tools, continuous integration for design models, when audit trail and version history are required.
A shared database (relational, graph, or document) serves as the single source of truth.
Technologies:
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.
Direct programmatic communication between tools via their APIs.
Patterns:
When to use: Custom automation pipelines, when no off-the-shelf connector exists, high-volume programmatic workflows, CI/CD for AEC.
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
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:
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:
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:
Best Practices for Rhino.Inside.Revit:
Send from Grasshopper:
Receive in Revit:
Advantages over Rhino.Inside:
When live linking is not feasible:
SAT Export Path:
DWG Export Path:
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:
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:
Supported Hosts:
Key Workflows:
Complex Geometry to BIM: Design freeform geometry in Grasshopper (SubD, NURBS lofts, panelized surfaces) -> bake as Revit floors, walls, roofs, or DirectShape elements
Parametric Facade: Define facade logic in GH (panel subdivision, attractor-based sizing, environmental response) -> create Revit curtain wall panels, mullions, and adaptive components
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
Structural Optimization: Run Karamba3D analysis in GH within Revit -> structural results inform beam/column sizing -> updated sizes pushed to Revit structural elements
Environmental Analysis: Run Ladybug/Honeybee analysis in GH within Revit -> solar access, daylight, wind results -> inform Revit design parameters (window sizes, shading depths)
Preview technology allowing Rhino geometry operations within AutoCAD:
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:
| 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 |
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.) |
| 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 |
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.
Serverless functions triggered by model changes:
Use Cases:
Architecture:
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.
| 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 |
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:
| 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 |
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
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:
| 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")
| 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 |
| 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 |
| 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 |
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 |
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:
| 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.
| 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)
| 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.
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:
Mitigation Strategies:
Step-by-step alignment procedure for Rhino ↔ Revit ↔ GIS:
Establish shared reference: Choose a physical survey marker or building corner with known real-world coordinates (UTM or State Plane)
Revit setup:
Rhino setup:
GIS setup:
Verification: