超大点云前端显示策略解析
空间分块、4D 帧过滤与 ROI 空间过滤的区别与协同
在超大点云的前端可视化中，常见的需求包括：
- 场景非常大，点数巨大，不能一次性加载
- 点云具有时间维度，需要按帧回放
- 用户希望聚焦某一小块空间进行精细观察或标注
在实际工程中，这些需求不能靠一种机制解决，而是通过多层过滤策略协同完成。
本文结合真实项目代码，系统性分析三种核心机制：
- 点云分块（Spatial Sharding）
- 4D 点云帧过滤（FrameIndex Filtering）
- ROI 空间过滤（XYZ Range Filtering）
并重点说明它们之间的区别、职责边界与配合关系。
一、三种机制解决的是“三个不同维度的问题”
可以先给出一个总览结论：
| 机制 | 解决的问题 | 维度 |
|---|---|---|
| 点云分块 | 场景太大 | 空间（宏观） |
| 4D 帧过滤 | 时间序列 | 时间 |
| ROI 空间过滤 | 精细聚焦 | 空间（微观） |
它们不是替代关系，而是分层关系。
二、点云分块：解决「场景级别」问题
1️⃣ 本质是什么？
点云分块 = 按空间区域拆分成多个 .pcd 文件
- 0.pcd：区域 A
- 1.pcd：区域 B
- 2.pcd：区域 C
每个文件体量可控，前端只加载当前需要的区域。
2️⃣ 它解决什么？
- 单个点云文件过大（下载慢、解析慢、显存爆）
- 大场景无法整体渲染
3️⃣ 关键特征
- 发生在网络层
- 切换分块 = 重新请求 .pcd 文件
- 分块之间是 互斥的（同一时间只渲染一个）
👉 这是最粗粒度的过滤。
三、4D 点云帧过滤：解决「时间维度」问题
1️⃣ 本质是什么？
4D 点云 = 空间 + 时间
- 每个分块文件（如 0.pcd）本身是融合点云
- 所有帧的点都在同一个文件里
- 每个点带有
frameIndex
2️⃣ 它解决什么？
- 时间轴回放
- 不同帧点云的切换
- 多帧区间显示（如 frame 10–20）
3️⃣ 关键特征
- 不产生网络请求
- 只在内存中根据
frameIndex修改可见性 - 可连续拖动时间轴
👉 这是时间维度的过滤，不改变数据来源。
四、ROI 空间过滤：解决「局部聚焦」问题
1️⃣ 本质是什么？
ROI = 在已加载点云中，按 XYZ 范围再做一次空间过滤
- x ∈ [-30, 30]
- y ∈ [-20, 20]
- z ∈ [-1, 3]
2️⃣ 它解决什么？
- 用户只想看一小块区域
- 标注 / 调试 / 观察细节
- 减少视觉噪音
3️⃣ 关键特征
- 完全在内存中完成
- 不加载新文件
- 在当前点云基础上进一步裁剪
👉 这是最细粒度的空间过滤。
五、三者的层级关系（非常重要）
从架构角度，它们是一个自上而下的过滤体系：
场景级（最粗）
↓ 点云分块（Spatial Sharding）
- 选择加载哪个 .pcd 文件
- 网络层操作
时间级
↓ 4D 帧过滤（FrameIndex）
- 在融合点云中选时间段
- 内存层操作
局部级（最细）
↓ ROI 空间过滤（XYZ）
- 精细裁剪显示范围
- 内存层操作
这意味着：
- 点云分块一定最先发生
- ROI 永远不会跨分块
- 帧过滤和 ROI 可以叠加
六、和「不同帧加载不同点云」方案的本质区别
很多系统会采用另一种思路：
每一帧 = 一个点云文件
对比核心差异
| 维度 | 4D 融合点云 | 每帧一个点云 |
|---|---|---|
| 网络请求 | 一次 | 多次 |
| 时间轴 | 连续 | 离散 |
| 切帧成本 | 极低 | 高 |
| 帧区间显示 | 原生支持 | 需要额外合并 |
| 前端复杂度 | 中 | 高 |
👉 你们当前方案的关键优势在于：
时间维度被“点级化”，而不是“文件级化”
这正是 4D 点云的核心价值。
七、实际工作流总结（贴近真实使用）
1️⃣ 选区域（点云分块）
renderPCD('1.pcd', { isSharding: true, shardingIndex: 1 });
- 网络请求
- 切换大场景
2️⃣ 切时间（4D 帧过滤）
filterPcd(15, 20);
- 不请求网络
- 时间轴平滑拖动
3️⃣ 调范围（ROI）
getPointsByRange({
x: [-30, 30],
y: [-20, 20],
z: [-1, 3],
});
- 精细聚焦
- 只影响显示
八、最终总结（一句话版）
点云分块解决“加载哪个世界”，
4D 帧过滤解决“看这个世界的哪个时间”，
ROI 过滤解决“在这个时间里看哪一小块”。
三者不是竞争关系，而是构成了一套完整、可扩展、性能可控的超大点云前端显示体系。
