BIM・IFCブログに戻る
デジタルツイン · 2026-08-21 · 12分
ブラウザーで動くリアルタイムLiDAR＋IFC：MCAPリプレイのデモ
実際のWebリプレイ画面を動かしながら、シミュレーションであることを明示したIFC＋LiDARストリームを支える、上限付きバッファー、バイナリフレーム、テレメトリーの仕組みを学びます。
実際のビューアーのキャプチャーに「Real-Time LiDAR and IFC」というタイトルを重ねたカバー画像。パビリオンに位置合わせしたシミュレーションの時系列リプレイが表示されている
点群の動画と、点群のライブストリームは同じものではありません。動画は画素が固定されており、成熟したハードウェアコーデックがあります。時系列の点群には座標、属性、姿勢、タイムスタンプがあり、ユーザーはそれを調べたり、IFCと比較したりします。この柔軟性があるからこそ、伝送とメモリの問題はより難しくなります。
以下のアーキテクチャーでは、記録データとライブのソースを、上限付きの共通フレーム仕様にデータを供給する2つのアダプターとして扱います。これにより、センサーを購入・統合する前に、記録データを使って再生、シーク、破損データの処理、GPUの更新を検証できます。
ブラウザーが受け取るのは、上限付きで検証済みのフレームです。フィルタリングと座標の正規化はエッジ側で行います。
時系列のIFC＋LiDARリプレイを試す
次のライブ例では、対応するIFCのパビリオンの周囲に、決定論的に動くスキャンの走査面を生成します。同じフレームがバイナリエンコード、CRC検証、固定3スロットの伝送バッファーを経てGPUに届きます。フルビューアーに切り替えると、決定論的なパケットロス、順序の入れ替わり、データ破損、再接続の時間帯を注入できます。
Operations Pavilion：シミュレーションによる時系列LiDAR
同梱のIFC4パビリオンに位置合わせした、16秒・12FPSのシミュレーションスキャンです。再生パイプラインを実証するものであり、物理的なセンサーの存在を主張するものではありません。
シミュレーションのLiDARを再生中：ドラッグで視点を回転
実際の製品画面のキャプチャーです。時系列のソースは決定論的なシミュレーションのリプレイですが、解析、バッファリング、GPUの更新、IFCとの位置合わせは本物のビューアーで動いています。
最低限のフレーム仕様
伝送パケットには、XYZの値以上のものが必要です。シーケンス番号があれば、パケットロスや順序の入れ替わりがわかります。ナノ秒単位のタイムスタンプは、点群を動画、姿勢、注釈と時間的に揃えます。原点を宣言しておけば、大きな世界座標がGPUのFloat32頂点に入り込むのを防げます。属性フラグは、ソースが提供していない強度や分類があたかも存在するかのようにUIが振る舞うのを防ぎます。
| フィールド | 存在する理由 | 検出できる不具合 |
|---|
| sequence | 単調増加するフレームの識別子 | 欠落、重複、順序の入れ替わり |
| timestampNs | 共通の時間基準 | 動画・姿勢とのずれ |
| origin + bounds | ローカルでの精度とカリング | ジッターや異常なメモリ割り当て |
| pointCount + stride | ペイロードの上限 | 途中で切れた、または悪意のあるパケット |
| 属性フラグ | 明示的なセマンティクス | 存在しないRGB・強度・分類のでっち上げ |
| CRC32 | ペイロードの完全性 | 保存時や伝送中のデータ破損 |
バックプレッシャー：最新の有効なフレームを優先
信頼性の高いネットワークストリームでも、ライブ体験が悪くなることはあります。フレームが80msごとに届くのにデコードに120msかかると、通常のキューは際限なく伸び続け、ビューアーは遅れて流れる録画になってしまいます。ライブ表示の正しい方針は、上限を設けることです。再利用できるスロットを2〜3個だけ保持し、無効なフレームは破棄し、より新しいフレームに追い越された保留中の処理は捨て、遅延とドロップ数をユーザーに提示します。
上限のないキュー
- 処理が遅い期間に遅延が膨らむ
- 古いフレームがメモリとデコーダーの時間を消費する
- 過去を表示しているのに、UIは「接続中」と表示し続ける
- 復旧に、障害そのものより長い時間がかかることがある
上限付きのライブバッファー
- メモリ使用量は一定に保たれる
- 最新の有効なフレームが古い処理を置き換える
- ドロップ数とフレームの経過時間が見え続ける
- 処理能力が戻れば即座に復旧する
記録と再現可能なリプレイのためのMCAP
MCAPは、任意のシリアライズ形式を持つ、タイムスタンプ付きのパブリッシュ／サブスクライブ型メッセージのためのモジュール式コンテナです。チャンクとインデックスによって時刻とトピックで検索でき、これはまさにリプレイのタイムラインに必要な機能です。コンテナとランダムアクセス用のサマリーレコードについては、MCAPフォーマット仕様に記載されています。
コンテナの互換性は、メッセージの互換性とは別物です。ROSは、構造化（organized）または非構造化の点群をsensor_msgs/PointCloud2で配信し、Foxgloveは独自のPointCloudスキーマを定義しています。デモのMCAPはバージョン管理されたアプリケーション独自のペイロードを使っているため、どちらのエコシステムから取り込むにも、うまくいくことを期待してバイト列をキャストするのではなく、名前の付いた専用のアダプターが必要です。
まず記録データで
利用許諾の明確なテスト用データ（フィクスチャー）を使えば、ハードウェアを統合する前に、一時停止、シーク、再接続、回帰テストを再現可能にできます。
ライブのアダプターはその次に
WebSocketやWebTransportによって変わるのは配信の方法であって、レンダラーが受け取るフレームの意味は変わりません。
テレメトリーを見える化
遅延、フレームの経過時間、欠落、順序の入れ替わり、無効なパケット、再接続は、製品のUIに表示すべき情報です。
障害の注入
決定論的な障害を注入しておけば、カンファレンス会場のWi-Fiの不調も、不意打ちではなく、リハーサル済みの状態遷移になります。
静的な実測データを背景として使う場合は、IFC＋点群によるScan-to-BIMワークフローに戻ってください。ハードウェアの動画コーデックを使いながら3Dシーンの中に配置できる、画素ベースのリソースについては、3D地形上のIFC＋動画で解説しています。
ブラウザーで動くリアルタイムLiDAR＋IFC：MCAPリプレイのデモ