Retour au blog BIM & IFC
Jumeaux numériques · 2026-08-21 · 12 min
LiDAR temps réel + IFC dans le navigateur : démo de relecture MCAP
Lancez la véritable interface web de relecture et découvrez les tampons bornés, les trames binaires et la télémétrie derrière un flux IFC + LiDAR simulé, honnêtement présenté comme tel.
Couverture intitulée LiDAR temps réel et IFC, sur une capture réelle du visionneur montrant la relecture temporelle simulée alignée sur un pavillon
Une vidéo d'un nuage de points et un flux de nuage de points en direct ne sont pas le même produit. La vidéo a des pixels fixes et des codecs matériels matures. Un nuage de points temporel a des coordonnées, des attributs, des poses et des horodatages que les utilisateurs peuvent inspecter ou comparer avec l'IFC. Cette flexibilité crée un problème de transport et de mémoire bien plus difficile.
L'architecture ci-dessous traite les enregistrements et les sources en direct comme deux adaptateurs alimentant un même contrat de trame borné. Elle permet à une équipe de valider la lecture, la recherche temporelle, la gestion de la corruption et les mises à jour GPU avec des données enregistrées, avant même d'acheter ou d'intégrer un capteur.
Le navigateur reçoit des trames bornées et validées ; le filtrage et la normalisation des coordonnées relèvent de la périphérie (edge).
Essayez la relecture temporelle IFC + LiDAR
L'exemple en direct ci-dessous génère un front de balayage déterministe autour du pavillon IFC correspondant. La même trame passe par un encodage binaire, une validation CRC et un tampon de transport fixe à trois emplacements avant d'atteindre le GPU. Passez au visionneur complet pour injecter de la perte déterministe, du réordonnancement, de la corruption et une fenêtre de reconnexion.
Pavillon des opérations — LiDAR temporel simulé
Un balayage simulé de 16 secondes à 12 im/s, aligné sur un pavillon IFC4 fourni. Ceci valide le pipeline de lecture ; ce n'est pas une prétention de capteur physique.
La relecture LiDAR simulée est en cours — faites glisser pour orbiter
Capture réelle du produit : la source temporelle est une relecture simulée déterministe, tandis que l'analyse, la mise en tampon, les mises à jour GPU et l'alignement IFC s'exécutent dans le vrai visionneur.
Le contrat de trame minimal
Un paquet de transport a besoin de plus que des valeurs XYZ. Les numéros de séquence révèlent la perte et le réordonnancement. Les horodatages en nanosecondes alignent les points avec la vidéo, la pose et les annotations. Une origine déclarée garde les grandes coordonnées mondiales hors des sommets GPU en Float32. Des indicateurs d'attributs empêchent l'interface de prétendre que l'intensité ou la classification existent alors que la source ne les a jamais fournies.
| Champ | Pourquoi il existe | Panne détectée |
|---|
| sequence | Identité monotone de la trame | Perte, doublon ou réordonnancement |
| timestampNs | Référence temporelle commune | Dérive vidéo/pose |
| origin + bounds | Précision locale et élagage (culling) | Gigue ou allocation absurde |
| pointCount + stride | Budget de charge utile | Paquet tronqué ou malveillant |
| attribute flags | Sémantique explicite | RGB / intensité / classe inventés |
| CRC32 | Intégrité de la charge utile | Corruption en stockage ou en transport |
Contre-pression : la dernière trame valide gagne
Un flux réseau fiable peut malgré tout produire une mauvaise expérience en direct. Si le décodage prend 120 ms alors que les trames arrivent toutes les 80 ms, une file d'attente normale grossit indéfiniment et le visionneur devient un enregistrement différé. La bonne politique en direct est bornée : conserver deux ou trois emplacements réutilisables, rejeter les trames invalides, écarter le travail en attente devenu obsolète, et afficher à l'utilisateur la latence et le nombre de trames perdues.
File d'attente non bornée
- La latence croît pendant un ralentissement
- Les anciennes trames consomment mémoire et temps de décodage
- L'interface affiche toujours « connecté » tout en montrant le passé
- La reprise peut durer plus longtemps que l'incident lui-même
Tampon en direct borné
- La mémoire reste constante
- La trame valide la plus récente remplace le travail obsolète
- Les pertes et l'âge des trames restent visibles
- La reprise est immédiate dès que la capacité revient
MCAP pour l'enregistrement et la relecture reproductible
MCAP est un conteneur modulaire pour des messages publish/subscribe horodatés, à sérialisation arbitraire. Ses blocs (chunks) et ses index prennent en charge la recherche par temps et par sujet (topic), exactement ce dont une chronologie de relecture a besoin. La spécification du format MCAP décrit le conteneur et les enregistrements de résumé à accès aléatoire.
La compatibilité de conteneur n'est pas la compatibilité de message. ROS publie des points organisés ou non via sensor_msgs/PointCloud2 ; Foxglove définit son propre schéma PointCloud. Le MCAP de la démo utilise une charge utile applicative versionnée : importer l'un ou l'autre écosystème nécessite donc un adaptateur nommé plutôt qu'un transtypage d'octets optimiste.
L'enregistré d'abord
Une source sous licence rend la pause, la recherche, la reconnexion et les tests de non-régression reproductibles avant toute intégration matérielle.
L'adaptateur en direct ensuite
WebSocket ou WebTransport change la livraison, pas la sémantique de trame consommée par le moteur de rendu.
Télémétrie visible
Latence, âge des trames, perte, réordonnancement, paquets invalides et reconnexions ont leur place dans l'interface du produit.
Injection de pannes
Des pannes déterministes transforment la défaillance du Wi-Fi d'un salon professionnel d'une surprise en une transition d'état répétée à l'avance.
Pour un contexte mesuré et statique, revenez au workflow Scan-to-BIM IFC + nuage de points. Pour une ressource pixel qui peut utiliser les codecs vidéo matériels tout en restant dans la scène 3D, voir IFC + vidéo sur terrain 3D.
LiDAR temps réel + IFC dans le navigateur : démo de relecture MCAP