前端页面如何渲染上亿点云
背景
随着4D场景在公司业务中的占比越来越大，点云的量级也变得水涨船高。之前可以通过前处理、稠密度等方式变相达到一些大数量级的数据加载，但并不是长久之计。因此参考potree实现，在前端部分实现了理论上不限制量级的点云加载。废话不多说，我们直接开始吧。
三个问题
简单介绍一下点云，上图是在浏览器渲染的3D场景，里面的物体由一个个的点组成。但是当点云数量比较大的时候，点云本身的加载、存储以及对点云的操作（比如如何判断鼠标在哪个点上）都会带来巨大的性能负担。
渲染全部的点云？
一般遇到性能问题的时候，我们一般想到的都是分片，这里也是一样。对于点云场景来说，隐藏在后面的点其实是不需要渲染的。而大部分的场景其实也不需要渲染全部的点云，所以渲染全部的点云其实是一种资源浪费。那么怎么去判断点和点的关系，一个一个判断的方式显然也不合理。
切分点云的魔法octree
我们对原始的点云进行预处理，采用octree的算法将点云分块。如上图，我们将整个空间当成一个巨大的正方体，然后将整个正方体划分成8个。小的正方体再分成8块。用数据结构表示就是一棵八叉树，每个节点代表划分空间内的一个点云节点。如果某个正方体内没有点云，那么该树节点即为空。
上面举例的点云场景的八叉树划分如上图显示。这样我们将点是否被遮挡的问题变成了里面的分块是否被遮挡。这样在固定场景时，根据相机视椎就可以判断出哪些分块需要渲染，从而只需要渲染部分点云分块。
针对树节点，判断是否节点的包围盒是否和相机视椎体相交
如果相交，再递归子节点，判断子节点的像素占比，根据占比优先级去渲染子节点
加载全部的点云？
点云中的点，即包括点云点的位置（x,y,z）,也包括rgb颜色等其他信息。以千万级的点云数据举例，本身的点云文件大概在600MB左右。前端下载需要的时间，下载完之后在内存中生成的临时变量，最后常驻在内存里面的点云数据。在点云数据只有上千万的时候，还可以通过一些策略进行优化（这里暂不阐述），但是点云量级到上亿时，这些问题每一个都变得非常棘手了。
http天然的分片加载魔法
这里讲一下potree的实现。potree有两个版本，在版本1的时候，potree把所有分块处理成一个文件，在前端请求的时候根据当前的场景的计算结果去请求多个点云分块文件。
在v2的时候，potree把所有的分块点云放在一个bin文件中octree.bin中，在另外一个hierarchy.bin文件中记录分块的具体位置。在前端请求文件的时候，对octree.bin的不同位置多次请求，就可以得到对应的点云分块数据了。大概的请求如下
稍微一评估（其实也没咋评估），我们果断选择了第二种方案。这样我们只需要将点云二进制文件放在我们自己的云端，就可以做到分片下载我们想要的点云分块了。
至此无论多少量级的点云都变成了一个个的分块，实际上点云场景需要渲染的分块也远远小于实际总的分块数。前端加载的时间、内存存储的大小也得到了解决。
操作全部的点云？
经过以上的分片操作，在前端就只对得到的分块点云进行操作了。因此大部分性能问题也得到了解决。这里也做了缓存，在前端缓存了大概1kw的点云，通过lru算法对点云分块进行更新淘汰。
总结
参考potree，我们改进了目前的渲染流程，做到了理论上不限制量级的点云加载、渲染。但由于前端不会获取到全部的点云数据，因此无法完全的应对全量语义分割模式。语义分割模式还需要按全量加载的方式去处理，当然对于上亿的点云全量分割，即使使用位图存储，最后导出的结果文件也是非常巨大的，本身需求也不大。
后续也会再介绍一下在全量加载模式下，为了性能和用户体验，做了哪些努力和优化。