确定多边形是否在视锥内

这里是我的问题。我听说opengl忽略了视锥之外的顶点，并没有考虑渲染管道中的顶点。最近我遇到了一个帖子，说你应该检查你的自我，如果一个点不在里面，你有责任找出不是opengl的！现在，确定多边形是否在视锥内

这是真的关于opengl吗？它是否理解一个点是否不在里面，而不是渲染它？
我正在开发一个草场景，在矩形上有大约4000棵草。我有非常糟糕的FPS，而我提出的唯一解决方案是确定哪些草在视口内，然后只渲染它们！我的问题在于，哪种解决方案最适合我找出哪个矩形不在里面或哪个是？

请认为我的问题不是关于点，而是关于矩形。此外，我需要根据它们的距离对草进行排序，因此，如果在客户端内存上使用native，则会更好。

请让我知道是否有任何有效和实时的方法来查明给定的网格是否在平截头体内部或外部。谢谢。

2011-06-16 Amir Zadeh

有没有理由不能使用Z-buffer来避免基于距离的排序？ – phkahler 2011-06-16 15:20:16

如果Z缓冲区真的可以帮助我，我没有得到很好的结果。但我确实使用ALPHA_TEST。 – 2011-06-16 15:31:34

即使这是真的，OpenGL也不会显示截锥外的多边形（与任何其他3d引擎一样），它必须考虑检查它们是否存在或不存在，然后fps减速。通常需要一些智能优化算法来避免用不可见物体泛滥。检查例如BSP树+ PVS或门户作为起点。要检查应用程序中是否存在瓶颈，可以使用gDebugger来尝试。如果没有任何合理的错误优化来绘制PVS（可能的可见集合）是要走的路。

来源

2011-06-16 15:21:47

为什么这样的操作会减慢我的工作？我只有4000棵草，有16000个顶点！ – 2011-06-16 15:32:57

尽可能快地适应管线。如果你的fps不满意，你必须优化。另一个想法是：纹理总是一样的？如果不是，你绘制的矩形排序，以尽可能减少纹理变化...？ – 2011-06-16 15:36:24

所有相同的纹理，相同的坐标，固定功能，照明关闭，静态草，使用的VBOs，STATIC_DRAW！每件事似乎都是合乎逻辑的，但我没有FPS！ – 2011-06-16 15:49:10

的OpenGL不会呈现像素（ “碎片”）屏幕之外，因此它必须以某种方式夹...

更确切地说：

您提交几何
你让绘制调用（glDrawArrays或glDrawElements）
每个顶点都经过顶点着色器，顶点着色器计算相机空间中顶点的最终位置。如果你没有写一个顶点着色器（= old opengl），驱动程序会为你创建一个。
透视除法在标准化设备坐标中转换这些坐标。粗略地说，它的意思是相机的平截头体被变形以适应[-1,1] x [-1,1] x [-1,1]方块
这个方框外的所有东西都会被裁剪掉。这可能意味着完全抛弃三角形，或细分它，如果它是横跨剪裁平面
剩余的每个三角形光栅化为碎片
每个片段经过片段着色器

所以基本上，OpenGL的知道如何以剪辑，但每个顶点仍然必须穿过顶点着色器。因此，当然，提交整个世界将会奏效，但如果您可以找到方法而不是来提交所有内容，那么您的GPU会更加快乐。

当然，这是一个折衷。如果您花费10ms时间检查CPU上的每一块草地，以便GPU只能绘制最少量的数据，但这也不是一个好的解决方案。

如果你想优化草地，我建议剔除大块（5米×5米左右）。这是标准的AABB-平截头体测试。

如果你想优化一个更通用的模型，你可以研究四叉树的“扁平”模型，八叉树和bsp树的更复杂的对象。

来源

2011-06-16 15:35:28 Calvin1602

谢谢。还有另一个问题出现在我的脑海里。我曾经在一个场景中绘制了20000个顶点，而我的FPS大约是60！这次大约是20！多次使用这种纹理！如果您需要查看，我可以发布我的代码！ – 2011-06-16 15:41:06

请做，但在另一个问题。并且包含更多细节（之前/之后） – Calvin1602 2011-06-16 15:45:13

代码实际上是非常大和多个文件，我不知道如何发布它！请让我知道我可以通过邮件发送给你。 – 2011-06-16 15:47:16

是的，OpenGL不能栅格化三角形使得观看截屏过于庞大。但是，这并不意味着这对于应用程序来说是最佳的：OpenGL实现应该转换顶点坐标（通过使用固定的管线或顶点着色器），然后，使用规范化的坐标，它最终知道三角形是否位于观看截止点内。

这意味着在这种情况下没有像素被光栅化，但顶点数据处理完全相同;根本不会产生从不可见三角形派生的碎片！

OpenGL扩展ARB_occlusion_query可以帮助你，但在讨论部分讲清楚：

做遮挡查询进行其他的知名度算法过时了吗？

No. 

    Occlusion queries are helpful, but they are not a cure-all. They 
    should be only one of many items in your bag of tricks to decide 
    whether objects are visible or invisible. They are not an excuse 
    to skip frustum culling, or precomputing visibility using portals 
    for static environments, or other standard visibility techniques.

有关网格深度排序的问题，您应该使用的深度缓冲本质网片段有效地渲染只有从视其距离小于在相同的位置上一片段。这使您意识到排序网格。这个缓冲区基本上是免费的，它可以让你提高性能，因为它丢弃了更多的碎片。

来源

2011-06-16 15:35:47 Luca

是的。像其他人指出的那样，OpenGL必须执行大量的每个顶点操作才能确定它是否在视锥中。它必须为您发送的每个顶点执行此操作。除了必须发生的处理开销之外，请记住，从CPU到GPU传输这些顶点还有额外的开销。您希望避免将信息发送给不会使用的GPU。尽管在现代硬件上CPU和GPU之间的带宽相当不错，但仍然有限制。
你想要的是一个Scene Graph。场景图通常以某种空间分区方案实现，例如，Quadtrees,Octrees,BSPTrees等。空间分区允许您智能地确定哪些几何图形可见。而不是在每个顶点基础上做这件事（就像OpenGL被迫做的那样），它可以一次消除巨大的几何空间子集。渲染复杂场景时，性能节省可能非常高。

来源

2011-06-16 16:19:36 luke

确定多边形是否在视锥内

回答

相关问题