3d Prims vs Polys：它们各自的优缺点是什么？

我注意到，大多数3d游戏/渲染环境将实体表示为3d多边形的网格（通常为三角形）。但是，在一些示例中，例如或使用从一组三维基本体（立方体、球体、圆锥体、圆环体等）构建的实体，可以在这些基本体上执行各种操作以创建更复杂的形状

所以我的问题是：为什么选择一种方法来表示三维数据

我可以看出，复杂的光线跟踪操作能够将曲面描述为单个数学函数可能会有好处（就像PovRay所做的那样），但SL显然没有尝试使用其渲染引擎实现如此雄心勃勃的目标

同样，我可以想象，为广义实体而不是任意网格提供描述可能会更具带宽效率，但这真的值得SL遭受的不利影响吗（即建模工作真的很难，通常结果很难看）-这仅仅是SL开发早期做出的一个错误决策，而他们现在一直在坚持这个决策吗？或者它是OpenGL/DirectX中最容易实现的东西的产物

---

编辑： 阅读了到目前为止的答案后，我现在认为我的两个示例使用prims的原因非常不同：

• 对于PovRay，prims可能是将实体描述为数学函数的副作用，这为复杂光线跟踪带来了好处

• 《第二人生》似乎主要关注的是将其三维元素参数化（既作为基本元素，又作为参数化人体模型），以满足性能要求。。。我想这对于在线游戏来说是非常有意义的

---

根据定义，多边形可以表示任何其他几何图元。无论多边形是立方体、球体还是其他形状，对多边形的每个操作（例如查找其某个曲面的法向量）都是一样的。这种方法的缺点是，您需要专门针对边缘情况进行优化（同样，多维数据集是一个很好的示例）。使用高级技术（如法线贴图）将减少这种影响，因为可以预先计算重要的对象度量

我可以想象，PovRay是一种场景，在这种场景中，将对象表示为简单函数并针对边缘情况进行优化的能力可以产生巨大的性能提升，但代价是需要更复杂的场景设计器

使用多边形为设计师提供了更多的自由，您可以通过简单地增加或减少所涉及的多边形数量来表示任意细节级别（LoD调整）

---

我不知道SL的创建者为什么决定使用原语，我也不知道游戏的细节，但我想高端渲染是次要考虑的问题。

有两种描述和渲染3D对象的方法：

将3D对象描述为多边形（分解为三角形、三角形条带等）。然后，从对象空间到屏幕空间做几个投影，并使用一些聪明的数学来模拟照明。进入屏幕空间后，使用像素着色器进行更巧妙的数学运算，以模拟更好的照明效果。这是加速图形API（如Direct3D和OpenGL）使用的方法所有实时游戏（如《第二人生》）都使用此方法或类似方法

使用对特定对象有意义的任何形状描述对象（是的，甚至允许使用“真”曲线或无限平面）。通过跟踪光线通过图像平面中像素的路径并模拟其与虚拟对象相遇的效果，获取每个像素的颜色。这是通过模拟来完成的，模拟反映了光在现实生活中是如何与物体相互作用的。这需要很长时间，而且非常昂贵。像POVRay这样的光线跟踪器使用这种方法

SL可能会使用原语，因为它们的引擎API可能允许您执行以下操作

Sphere mySphere = engine->createSphere(x,y,z);
mySphere->moveTo(x,y,z);

但这些只是辅助函数（大多数现代引擎都具有基本功能），这并不意味着它们呈现“基本体”。他们仍然渲染三角形

所以基本上，这不是什么时候使用“对象”和“多边形”的问题。这是一个是否要光线跟踪的问题或是否要交互渲染

更高级别的“原语”（球体、立方体等）携带更多关于它们到底是什么的语义信息，以及更低的带宽/存储要求（一个球体需要两个参数-中心位置和半径-而，比方说，一个等值球体需要尽可能多的三角形来渲染球体）

使用原语还允许客户端引擎根据本地功能调整其渲染，一个客户端可以使用M个细分进行渲染，另一个客户端可以使用N个细分进行渲染；如果发送三角形，则以不同分辨率重新渲染所需的信息将丢失。此外，它还为您提供了执行操作的机会，例如在靠近对象时增加细分计数

---

我不知道Linden实验室在想什么，因为我从未使用过Second Life，但如果我在构建类似SL的东西，我可能会倾向于使用原语作为定义和传输格式，因为它们携带了更多的信息，可以用于重渲染、命中检测等。当然，最后它们将被转换为多边形进行渲染，但这是一个实现细节。

它几乎肯定与OpenGL无关，就像OpenGL（和DirectX）一样使用三角形，而不是曲面或几何图元。因此，Linden实验室不太可能使用比三角形网格更容易渲染图元的高级库

我认为这几乎完全是为了节省带宽，因为几何表示几乎总是比表示为镶嵌三角形的同一对象小（代价是制作详细的