Zurück zum BIM- & IFC-Blog
Digitale Zwillinge · 2026-08-21 · 12 Min.
Echtzeit-LiDAR + IFC im Browser: MCAP-Replay-Demo
Testen Sie die echte Web-Replay-Oberfläche und lernen Sie die begrenzten Puffer, binären Frames und die Telemetrie hinter einem ehrlich als simuliert gekennzeichneten IFC-plus-LiDAR-Stream kennen.
Cover mit dem Titel Echtzeit-LiDAR und IFC über einem echten Viewer-Screenshot, der die simulierte zeitliche Wiedergabe ausgerichtet auf einen Pavillon zeigt
Ein Video einer Punktwolke und ein Live-Punktwolken-Stream sind nicht dasselbe Produkt. Video hat feste Pixel und ausgereifte Hardware-Codecs. Eine zeitliche Punktwolke hat Koordinaten, Attribute, Posen und Zeitstempel, die Nutzer inspizieren oder mit IFC vergleichen können. Diese Flexibilität schafft ein deutlich schwierigeres Transport- und Speicherproblem.
Die folgende Architektur behandelt Aufzeichnungen und Live-Quellen als zwei Adapter, die denselben begrenzten Frame-Vertrag speisen. Damit kann ein Team Wiedergabe, Sprünge in der Zeitachse, die Behandlung von Beschädigungen und GPU-Updates mit aufgezeichneten Daten validieren, bevor ein Sensor gekauft oder integriert wird.
Der Browser empfängt begrenzte, validierte Frames; Filterung und Koordinatennormalisierung gehören an den Rand (Edge).
Testen Sie das zeitliche IFC + LiDAR Replay
Das folgende Live-Beispiel erzeugt eine deterministische Scanfront rund um den passenden IFC-Pavillon. Dasselbe Frame durchläuft eine binäre Kodierung, eine CRC-Validierung und einen festen Transportpuffer mit drei Plätzen, bevor es die GPU erreicht. Wechseln Sie zum vollständigen Viewer, um deterministischen Verlust, Umsortierung, Beschädigung und ein Reconnect-Fenster gezielt auszulösen.
Operations Pavilion – simuliertes zeitliches LiDAR
Ein 16 Sekunden langer, simulierter Scan mit 12 FPS, ausgerichtet auf einen mitgelieferten IFC4-Pavillon. Das belegt die Wiedergabe-Pipeline; es ist keine Aussage über einen physischen Sensor.
Simuliertes LiDAR läuft – ziehen zum Umkreisen
Echter Produkt-Screenshot: Die zeitliche Quelle ist ein deterministisches, simuliertes Replay, während Parsing, Pufferung, GPU-Updates und IFC-Ausrichtung im echten Viewer laufen.
Der minimale Frame-Vertrag
Ein Transportpaket braucht mehr als XYZ-Werte. Sequenznummern zeigen Verluste und Umsortierungen auf. Zeitstempel in Nanosekunden richten Punkte an Video, Pose und Annotationen aus. Ein deklarierter Ursprung hält große Weltkoordinaten aus Float32-GPU-Vertizes heraus. Attribut-Flags verhindern, dass die Oberfläche Intensität oder Klassifizierung vortäuscht, die die Quelle nie geliefert hat.
| Feld | Warum es existiert | Erkannter Fehler |
|---|
| sequence | Monoton steigende Frame-Kennung | Verlust, Duplikat oder Umsortierung |
| timestampNs | Gemeinsame zeitliche Referenz | Drift zwischen Video und Pose |
| origin + bounds | Lokale Präzision und Culling | Jitter oder absurde Allokation |
| pointCount + stride | Payload-Budget | Abgeschnittenes oder manipuliertes Paket |
| attribute flags | Explizite Semantik | Erfundenes RGB/Intensität/Klasse |
| CRC32 | Integrität der Payload | Beschädigung bei Speicherung oder Transport |
Backpressure: das neueste gültige Frame gewinnt
Auch ein zuverlässiger Netzwerk-Stream kann ein schlechtes Live-Erlebnis erzeugen. Wenn das Decodieren 120 ms dauert, während alle 80 ms ein neues Frame eintrifft, wächst eine normale Warteschlange unbegrenzt, und der Viewer wird zu einer verzögerten Aufzeichnung. Die richtige Live-Strategie ist begrenzt: zwei oder drei wiederverwendbare Plätze vorhalten, ungültige Frames verwerfen, überholte anstehende Arbeit verwerfen und Latenz sowie Verlustzahlen dem Nutzer anzeigen.
Unbegrenzte Warteschlange
- Latenz wächst in einer langsamen Phase
- Alte Frames verbrauchen Speicher und Decoder-Zeit
- Die Oberfläche zeigt weiterhin „verbunden“ an, während sie die Vergangenheit darstellt
- Die Erholung kann länger dauern als der Vorfall selbst
Begrenzter Live-Puffer
- Speicherverbrauch bleibt konstant
- Das aktuellste gültige Frame ersetzt veraltete Arbeit
- Verluste und Alter bleiben sichtbar
- Die Erholung erfolgt sofort, sobald wieder Kapazität vorhanden ist
MCAP für Aufzeichnung und reproduzierbares Replay
MCAP ist ein modularer Container für zeitgestempelte Publish/Subscribe-Nachrichten mit beliebiger Serialisierung. Seine Chunks und Indizes unterstützen das Nachschlagen nach Zeit und Topic – genau das, was eine Replay-Zeitleiste braucht. Die MCAP-Formatspezifikation beschreibt den Container und die Zusammenfassungsdatensätze für den wahlfreien Zugriff.
Container-Kompatibilität ist keine Nachrichtenkompatibilität. ROS veröffentlicht geordnete oder ungeordnete Punkte über sensor_msgs/PointCloud2; Foxglove definiert ein eigenes PointCloud-Schema. Die Demo-MCAP verwendet eine versionierte anwendungseigene Payload – der Import in eines der beiden Ökosysteme erfordert daher einen benannten Adapter statt eines hoffnungsvollen Byte-Castings.
Zuerst aufgezeichnet
Ein lizenziertes Testset macht Pause, Sprung in der Zeitachse, Reconnect und Regressionstests reproduzierbar, noch bevor die Hardware integriert ist.
Live-Adapter erst danach
WebSocket oder WebTransport ändern die Zustellung, nicht die Frame-Semantik, die der Renderer konsumiert.
Sichtbare Telemetrie
Latenz, Frame-Alter, Verlust, Umsortierung, ungültige Pakete und Reconnects gehören in die Produktoberfläche.
Fehlerinjektion
Deterministisch ausgelöste Fehler machen den Ausfall des Konferenz-WLANs statt zu einer Überraschung zu einem geübten Zustandswechsel.
Für statischen, vermessenen Kontext siehe den Scan-to-BIM-Workflow mit IFC + Punktwolke. Für eine pixelbasierte Ressource, die Hardware-Video-Codecs nutzen kann und trotzdem in der 3D-Szene sitzt, siehe IFC + Video auf 3D-Gelände.
Echtzeit-LiDAR + IFC im Browser: MCAP-Replay-Demo