The engineering problem
You have a physical asset — a stadium, a factory floor, a heritage monument, an urban district — and you need to deliver an interactive, browser-native 3D experience that stakeholders can explore without installing specialized software. The experience must load fast, work on mobile, support real-time data overlays, and be traceable back to its source data.
This is different from 3D reconstruction (Part 2 of this series). Reconstruction produces geometry. Delivery turns that geometry into something people can interact with: a digital twin with live sensor data, a virtual tour with annotation layers, a WebXR training environment with physics simulation.
Why traditional approaches are insufficient
The format gap. Photogrammetry produces PLY point clouds and OBJ meshes. Browsers consume glTF and 3D Tiles. The conversion pipeline — decimation, UV mapping, texture optimization, LOD generation, tiling — is manual, fragile, and tool-specific.
Performance engineering. A raw scan of a stadium is 50 million triangles. A browser can render 2 million in real time. Someone must author the LOD hierarchy, configure progressive loading, optimize texture atlases, and test on target devices. This is engineering work, not creative work.
No provenance. When a digital twin displays a structural element, can you trace it back to the LiDAR scan that captured it? When sensor data overlays on geometry, is the alignment verified? Manual pipelines lose these connections.
How Studio executes immersive delivery
Intent: "Create a browser-native digital twin of Building A with sensor overlay (temperature, humidity, occupancy). Source: LiDAR point cloud (1.2B points) + BIM model (IFC) + IoT sensor feeds. Output: web viewer with layer controls, time-series playback, and mobile support."
A representative Studio execution plan for this workflow:
1. Point cloud processing → decimate to display-ready density, classify surfaces
2. Mesh generation → Poisson surface reconstruction, texture mapping
3. LOD authoring → generate 5-level hierarchy for progressive loading
4. 3D Tiles generation → tile mesh into streamable format (CesiumJS compatible)
5. BIM integration → align IFC geometry with scan, extract room boundaries
6. Sensor binding → map IoT feeds to spatial positions, configure update frequency
7. Viewer assembly → Three.js scene with layer controls, CesiumJS for geospatial context
8. Performance optimization → texture compression, draw call batching, mobile testing
9. Deployment → static hosting with CDN, WebSocket for live sensor data
10. Verify → hash all assets, record processing lineage
The Execution Fabric orchestrates:
- GPU provisioning for point cloud processing (billions of points)
- Parallel LOD generation across multiple workers
- Asset optimization pipeline (texture compression, mesh simplification)
- Deployment of the final viewer to hosting infrastructure
The 3D & Immersive Workbench provides:
- Point cloud processing: CloudCompare + Open3D + PDAL for filtering, classification, and decimation
- 3D visualization: Three.js for web-native rendering, CesiumJS for geospatial 3D, Potree for point cloud streaming
- Format pipeline: PLY → OBJ → glTF → 3D Tiles with automated conversion
- Immersive tools: Blender 4.0 for mesh authoring, WebXR for VR/AR delivery
- 360° panorama: HDR panorama stitching, virtual tours, WebXR viewers
- Neural rendering: Nerfstudio + 3DGS for photorealistic novel-view experiences (connects to Part 2)
Verified output: The deployed viewer carries provenance: which point cloud scan, which processing parameters, which BIM version, which sensor mapping produced this digital twin. The asset manifest is SHA-256 hashed. If the source LiDAR data changes, the verification chain breaks — ensuring the twin is always traceable to its source.
Live evidence
- Stadium Digital Twin — live sensor simulation with 3D visualization, real-time occupancy and environmental monitoring
- NexusTwin Industrial — factory equipment monitoring with predictive maintenance overlays
- Sponza Palace Viewer — heritage architecture delivered as interactive web 3D
- Nefertiti 3D Viewer — museum artifact visualization
Each of these is open source, browser-native, and demonstrates a different delivery pattern. Together, they show the types of browser-native 3D outcomes the Studio execution architecture is designed to produce.
How this connects to the series
| Part | What it produces | What this article does with it |
|---|---|---|
| Part 2 (3D Reconstruction) | Geometry from photos | Takes geometry and delivers it as interactive experience |
| Part 3 (Engineering) | CAD/BIM models | Integrates BIM data as spatial context layer |
| Part 4 (GeoAI) | Spatial intelligence | Overlays geospatial analytics on 3D terrain |
This is the delivery layer — where engineering outputs become stakeholder experiences.
Deployment relevance
Immersive experiences for sensitive facilities (military installations, nuclear plants, critical infrastructure) cannot be hosted on public CDNs. The same 3D delivery pipeline is designed to run in sovereign deployments with internal-only hosting. Digital twins of classified assets remain within the security boundary while using the same Studio execution model and verification architecture.
This is Part 7 of the How Nebula Cloud Executes Work series.
Previous: Part 6 — Executing Scientific Computing Start: Part 1 — From Prompt to Verified Artifact
Related: 3D & Immersive Workbench · Capability Packs · Execution Fabric · Demo Catalogue