点云流式传输：几百兆的模型怎么送到头显里

点云是三维内容里最「重」的一种数据。一段几十秒的扫描序列，原始体量轻易上到几百兆，而头显的显存和带宽都有限。

这篇写这条链路里我踩过的几个点。

点云为什么难传：量级和结构

它不像视频有强时间相关性，也不像网格有现成拓扑可压缩。点与点之间是散乱的，随便丢掉一部分，形状上就出现空洞。

所以压缩思路和传统媒体不一样：要么按空间分块建索引，要么按重要程度排序，让远端先拿到关键部分。

只传变化的部分

连续帧之间，大部分空间区域是静止的，真正变化的只有人、车或机械臂所在的位置。

做法是把场景分块，只对发生变化的块做增量传输。这一招在静态场景下的带宽收益非常明显。

分层传输：先给轮廓，再补细节

先把低分辨率点传过去，让用户先看到形状；再按视角逐步补密。

关键是要有明确的层次划分和退出机制：用户转头之后，原视角的细节要停止补充，否则带宽会浪费在看不见的地方。

延迟比带宽更影响体感

带宽不足表现为画面糊，延迟高表现为拖影和晕动。后者对体验的伤害大得多。

所以端上要有预测：根据头部运动趋势提前渲染，再在真实数据到达后做校正。这一步工程复杂度不低，但它决定用户能不能长时间使用。

端上的解码与渲染

解码要放到独立线程，别和渲染抢主线程；渲染要有明确的降级路径，帧率掉下来时优先保帧率、牺牲点数。

另外要提前定好点数上限，别让某个区域突然加密把所有预算吃光。

这套方案的代价

分块与分层带来的是索引和状态的复杂度。客户端要维护每块的层次和版本，服务端要跟踪每个用户的视角，出错时排查链路会更长。

所以这套做法值得上，但要提前接受它带来的运维负担，别等到线上出问题才意识到链路有多长。

带宽预算怎么估

先估静动态比例：场景里真正变化的部分占多少。实验室和现场差别很大——商场大厅这类场景变化比例低，反而好传；人多、物体频繁移动的场景，增量几乎覆盖全场景。

按最坏情况留预算，然后在这个预算下测试画质。不要反过来：先定画质再要求带宽，最后一定达不到。

另外要区分平均带宽和峰值带宽。网络设备看的是峰值，峰值撑不住，体验就是间歇性卡死。

客户端适配的隐藏成本

同一条流，在桌面头显和一体机上的表现可能完全不同：解码能力、显存、散热余量都不一样。

上线前至少要在两类设备上跑同一段内容，记录掉帧的位置。很多优化方向只有在低端设备上才看得出来。

结论

点云传输本质上是一道预算题：带宽、延迟、显存三者同时约束你。

把视角当成调度的依据，而不是把整份数据当成一次传输。

本文不构成任何技术建议，具体方案请结合自身设备与网络条件实测。