返回 BIM 与 IFC 博客
点云视频和实时点云流并不是同一种产品。视频的像素是固定的，还有成熟的硬件编解码器。时序点云则包含坐标、属性、位姿和时间戳，用户可能需要逐一查看，或将其与 IFC 进行比对。这种灵活性带来了更棘手的传输和内存问题。
下面的架构把录制数据和实时数据源视为两个适配器，共同为同一个有界帧契约提供数据。这样，团队在采购或集成传感器之前，就可以先用录制数据验证回放、跳转、数据损坏处理和 GPU 更新。
浏览器接收的是有界且经过校验的帧；过滤和坐标归一化应在边缘端完成。
试用时序 IFC + LiDAR 回放
下面的实时示例会围绕对应的 IFC 展馆生成一道确定性的扫描前沿。同一帧在到达 GPU 之前，要依次经过二进制编码、CRC 校验和固定三槽的传输缓冲区。切换到完整查看器，还可以注入确定性的丢帧、乱序、数据损坏和重连窗口。
运营展馆（Operations Pavilion）：模拟时序 LiDAR
一段 16 秒、12 FPS 的模拟扫描，与内置的 IFC4 展馆模型对齐。它证明的是回放管线，并不代表接入了物理传感器。
模拟 LiDAR 播放中，拖动即可环绕查看
真实产品截图：时序数据源是确定性的模拟回放，而解析、缓冲、GPU 更新和 IFC 对齐都在真实的查看器中运行。
最小帧契约
一个传输数据包需要的不只是 XYZ 值。序列号能暴露丢帧和乱序；纳秒级时间戳让点与视频、位姿和标注对齐；声明的原点能避免大数值的世界坐标进入 Float32 GPU 顶点；属性标志则能防止界面在数据源从未提供强度或分类信息时，假装这些信息存在。
| 字段 | 作用 | 可捕获的故障 |
|---|
| sequence | 单调递增的帧标识 | 丢帧、重复或乱序 |
| timestampNs | 统一的时间参考 | 视频/位姿漂移 |
| origin + bounds | 局部精度与剔除 | 抖动或异常的内存分配 |
| pointCount + stride | 有效载荷预算 | 被截断或恶意构造的数据包 |
| 属性标志（attribute flags） | 显式语义 | 凭空捏造的 RGB/强度/分类 |
| CRC32 | 有效载荷完整性 | 存储或传输中的数据损坏 |
背压：最新有效帧优先
即使网络流很可靠，实时体验也可能很糟。如果解码需要 120 ms，而帧每 80 ms 到达一次，普通队列就会无限增长，查看器也就变成了一段延迟的录像。正确的实时策略必须是有界的：保留两到三个可复用的槽位，拒绝无效帧，丢弃已被取代的待处理任务，并向用户展示延迟和丢帧数。
无界队列
- 处理变慢时，延迟不断增长
- 旧帧占用内存和解码时间
- 界面仍显示“已连接”，展示的却是过去的画面
- 恢复所需的时间可能比故障本身还长
有界实时缓冲区
- 内存占用保持恒定
- 最新的有效帧会替换过时的任务
- 丢帧情况和帧龄始终可见
- 处理能力一恢复，画面立即恢复正常
用 MCAP 录制并实现可复现的回放
MCAP 是一种模块化容器，用于存放带时间戳、可采用任意序列化方式的发布/订阅消息。它的数据块（chunk）和索引支持按时间和主题（topic）查找，这正是回放时间轴所需要的。MCAP 格式规范介绍了该容器及其支持随机访问的摘要记录。
容器兼容并不等于消息兼容。ROS 通过 sensor_msgs/PointCloud2 发布有序或无序的点；Foxglove 则定义了自己的 PointCloud 模式（Schema）。本演示的 MCAP 使用带版本号的应用有效载荷，因此要导入其中任一生态的数据，都需要一个明确命名的适配器，而不是寄希望于直接强制转换字节。
先用录制数据
有合法授权的测试样本（fixture）能让暂停、跳转、重连和回归测试在集成硬件之前就可以复现。
再接实时适配器
WebSocket 或 WebTransport 改变的只是传输方式，而不是渲染器所使用的帧语义。
遥测必须可见
延迟、帧龄、丢帧、乱序、无效数据包和重连次数，都应该呈现在产品界面中。
故障注入
确定性的故障注入，能把会场 Wi-Fi 故障从意外变成一次事先演练过的状态切换。
如需静态的实测环境数据，请回到 IFC + 点云 Scan-to-BIM 工作流程。如果需要一种基于像素、可以利用硬件视频编解码器、同时仍能置于 3D 场景中的资源，请参阅在 3D 地形上叠加 IFC 与视频。
浏览器中的实时 LiDAR + IFC：MCAP 回放演示
