Category: Real-Time 3D · Digital Twin · Industrial Visualization · Three.js / WebGL
Overview
WindTwin is a browser-based operational Digital Twin prototype built with Three.js, WebGL, and TypeScript.
The goal was to explore how a real-time 3D environment can become part of an operational workflow rather than functioning only as a visualization layer.
The project connects an interactive wind farm with live weather context, simulated turbine telemetry, condition monitoring, fault scenarios, prioritized maintenance work orders, an animated service vehicle, operational resources, and real-time charts.
The entire workflow is connected through shared application state:
Fault → Alert → Work Order → Dispatch → Repair → Asset Recovery
Main Features
-
Four fully interactive primary wind turbines
-
Expandable 100-turbine environment using multiple detail levels
-
Live weather context from Open-Meteo
-
Simulated turbine telemetry and condition monitoring
-
Real-time power, RPM, temperature, and vibration charts
-
Automated operational fault scenarios
-
Priority-based maintenance work-order queue
-
Animated service vehicle linked directly to work-order state
-
Operations Center with personnel, supplies, and fleet information
-
Simulated turbine inspection cameras
-
Responsive desktop and mobile interface
-
Adaptive runtime rendering quality
Technologies
Three.js · WebGL · TypeScript · Vite · Chart.js · Open-Meteo API · GLTF · HTML5 / CSS3
The application uses Vanilla TypeScript rather than a UI framework, keeping the rendering lifecycle, state synchronization, DOM interaction, and runtime behavior explicit.
Large-Scene Strategy
The initial experience loads four high-detail turbines.
The expanded farm is loaded only when requested, adding:
-
24 medium-detail turbines
-
72 low-detail turbines
This produces a total environment of 100 turbines without putting the entire farm on the initial critical loading path.
The additional farm modules are dynamically imported. Full Farm mode also adjusts camera range, fog, shadow resolution, and rendering cost depending on the device.
Performance
Performance was one of the main engineering priorities.
The project uses:
-
On-demand expanded-farm loading
-
Multiple turbine detail levels
-
Shared materials for distant assets
-
Frustum culling
-
Dynamic imports
-
Lazy-loaded camera images
-
Lazy-loaded Chart.js
-
Device pixel-ratio management
-
Reduced shadow cost in Full Farm mode
-
Adaptive runtime quality
The adaptive quality system monitors sustained runtime performance and can move between HIGH, MEDIUM, LOW, and VERY LOW profiles by adjusting pixel ratio and shadow quality.
Runtime diagnostics track FPS, draw calls, triangle count, geometries, textures, pixel ratio, GPU information, and loading time.
Across tested environments, WindTwin runs close to 60 FPS in most cases.
A Full Farm desktop diagnostic on a GTX 1060 3GB recorded approximately:
60.3 avg FPS · 39 draw calls · 214k triangles · DPR 1.25
Loading Strategy
Non-critical systems are deferred where possible.
Chart.js, expanded farm assets, Operations Center functionality, employee interfaces, analytics, and performance monitoring are dynamically loaded or initialized after the critical experience.
The main scene loads first and waits at a START state before beginning operational simulation, audio, telemetry, and fault scheduling.
In browser and network testing, initial loading has typically been around 1–2 seconds, depending on device, connection, and cache state.
Live vs. Simulated Data
WindTwin deliberately separates live context from simulated operational data.
Live — Open-Meteo
-
Wind speed
-
Wind direction
-
Air temperature
Simulated
-
Power and RPM
-
Temperature and vibration
-
Asset health and faults
-
Alerts and work orders
-
Personnel and supplies
-
Maintenance operations
-
Vehicle movement
-
Camera feeds
For demonstration stability, the turbine simulation uses a normalized wind input while the interface continues to display the actual live weather values.
Technical Challenges
One of the main challenges was keeping the 3D scene, UI, maintenance workflow, and service vehicle synchronized through the same application state rather than allowing each system to develop its own version of reality.
Another was scaling from four detailed interactive assets to 100 turbines without forcing the entire rendering and loading cost onto the initial experience.
Mobile support also required more than simply reducing UI dimensions. Panel behavior, touch interaction, camera layouts, rendering quality, shadows, and interaction targets required device-specific handling.
The project ultimately became as much an exercise in real-time application architecture and state management as in Three.js rendering.
Scope
WindTwin is an engineering and portfolio prototype, not a production SCADA system.
It is not currently connected to physical turbines, PLCs, OPC UA, or Modbus telemetry.
The operational layer is intentionally simulated, while the architecture is designed so that the current data sources can later be replaced or extended with real backend telemetry.
Case Study
The full case study covers the architecture, operational workflow, performance strategy, data model, responsive interface, maintenance system, and path toward real industrial integration.
Case Study:
Live Demo:
Developed by Nour Altinawi / Nourtin
Portfolio: