Drag[en]gine Wiki

User Tools

Site Tools

Trace:
dragengine:modules:opengl:occtest

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision		Previous revision
dragengine:modules:opengl:occtest [2012/12/04 18:25] – created dragonlorddragengine:modules:opengl:occtest [2013/02/26 00:38] (current) – [The OpenGL Graphic Module Culling System] dragonlord
Line 53: Line 53:
 In contrary to HOM and similar algorithms though the testing is done not on the CPU but **on the GPU itself**. All objects where culling could be useful (right now these are all objects) are then asked to submit their culling test parameters. Depending on the capabilities of the hardware these parameters are either placed in a **texture** or in a **VBO stream** (required EXT_transform_feedback or similar). Then all parameters are rendered with **one full screen quad**. This is the beauty of this technique. You can **occlusion test thousands of objects** with one single quadrilateral rendered. The shader simply reads the test parameters from the texture or the stream, picks the occlusion map layer covering the object in screen space in at most **16 pixels** and tests if at least one of them are visible. 16 pixels provides a good sampling resolution while still being fast. With decreasing sampling density the number of objects classified as visible although they are invisible increases. This is though a neglectable problem compared to the massive processing throughput. The result is written as a single component color. In contrary to HOM and similar algorithms though the testing is done not on the CPU but **on the GPU itself**. All objects where culling could be useful (right now these are all objects) are then asked to submit their culling test parameters. Depending on the capabilities of the hardware these parameters are either placed in a **texture** or in a **VBO stream** (required EXT_transform_feedback or similar). Then all parameters are rendered with **one full screen quad**. This is the beauty of this technique. You can **occlusion test thousands of objects** with one single quadrilateral rendered. The shader simply reads the test parameters from the texture or the stream, picks the occlusion map layer covering the object in screen space in at most **16 pixels** and tests if at least one of them are visible. 16 pixels provides a good sampling resolution while still being fast. With decreasing sampling density the number of objects classified as visible although they are invisible increases. This is though a neglectable problem compared to the massive processing throughput. The result is written as a single component color.
  
-Now the result is **read back to the CPU**. In contrary to HOM and similar techniques we read back the actual results not the occlusion image. The advantage of this is that we have to read back a lot less data. For each result we read back **only a single color value**, hence an 8-bit value. This is very fast and produces next to no stalling compared to occlusion queries. With this technique **10'000 objects** can be tested in **4-5ms**. In the same time with occlusion queries you can test maybe a handful of objects. Here though you can test entire cities if this is what you need.+Now the result is **read back to the CPU**. In contrary to HOM and similar techniques we read back the actual results not the occlusion image. The advantage of this is that we have to read back a lot less data. For each result we read back **only a single color value**, hence an 8-bit value. This is very fast and produces next to no stalling compared to occlusion queries. With this technique **10'000 objects** can be tested in **3-4ms** (on an ATI Radeon 4870 HD, nVidia is faster on this technique but slower at other parts). In the same time with occlusion queries you can test maybe a handful of objects. Here though you can test entire cities if this is what you need.
  
 This technique is so wonderful because it needs no fancy graphic card abilities or extensions nor complex and error prone calculations. All you need is filling a texture, use some nifty shaders and reading the texture back to the CPU. This technique is so wonderful because it needs no fancy graphic card abilities or extensions nor complex and error prone calculations. All you need is filling a texture, use some nifty shaders and reading the texture back to the CPU.
Line 61: Line 61:
 <WRAP center box 850px> <WRAP center box 850px>
 {{ :dragengine:modules:opengl:occlusion_testing.jpg |Occlusion testing with occlusion map shown}} {{ :dragengine:modules:opengl:occlusion_testing.jpg |Occlusion testing with occlusion map shown}}
-<WRAP centeralign>Occlusion testing with occlusion map shown. Every next level reduces the image size by factor 2 in both directions.. In this scene **1020 objects** have been simultanously tested in **2ms**. **68%** of the all objects and **62%** of all triangles have been culled during this time.</WRAP>+<WRAP centeralign>Occlusion testing with occlusion map shown. Every next level reduces the image size by factor 2 in both directions.. In this scene **1020 objects** have been simultanously tested in **3ms**. **68%** of the all objects and **62%** of all triangles have been culled during this time.</WRAP>
 </WRAP> </WRAP>
 </WRAP> </WRAP>
  
dragengine/modules/opengl/occtest.1354645532.txt.gz · Last modified: 2012/12/04 18:25 (external edit)

Page Tools

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International
CC Attribution-Noncommercial-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki