存储和速度之间的权衡

以下是关于在CloudCompare中所做的技术选择的一些细节（主要是为了实现尽可能加载点数而不降低性能太多
的目标——即在存储和速度之间取得良好的平衡）：

1. 所有存储的数值和大部分计算都是用32位浮点值完成的
2. 为了防止对数组大小的限制（因为在Windows 32位上很难获得一个大的连续内存块），我们使用一个自定义容 器，它会自动将数据集切分成小块（每个块为64 Kb）。
3. 若存在正常向量，则将其压缩为16位（实际上为15位，因为量化1工作方式）
4. CloudCompare采用的特定八叉树结构需要持续占用点级内存（在32位操作系统中，每点占用8字节内
   存，最大深度10；在64位操作系统中，每点占用12字节内存，最大深度21）。该结构基于三维坐标点
   的特殊量化方式——类似于莫顿 排序方案——每个层级的八叉树网格点位都由单一整型代码表示。
   通过处理这些代码，我们实现了高效的最近邻查询操作。不过，虽然这种八叉树结构在计算距离等场
   景下效率极高，但并不适合快速显示需求（如细节层次等场景）。

上述选择的结果是，CloudCompare可以存储大约9000万个空白点/每千兆字节内存。如果添加RGB颜色、法向
量、单个标量场，并且需要计算八叉树，则可以加载多达3200万个点/每千兆字节。
在64位操作系统中，您可以加载任意数量的点（实际上最多可达40亿 ）。但是，根据您的图形卡功能，使用这么
多点可能会严重降低显示和交互性能 。使用高端图形卡时，最多可容纳1.5亿个点，同时还能保持合理的帧速率。
1 http://en.wikipedia.org/wiki/Quantization
2 http://en.wikipedia.org/wiki/Z-order_curve