確定多邊形是否在視錐內

這裏是我的問題。我聽說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

確定多邊形是否在視錐內

回答

相關問題