I really like the dynamic approach as well. As a former Multi-dimensional Adaptive Person Producing Environmental Realities, MAPPER, the lack of specialty compile times has a major benefit in the turnaround of level construction. In the past (read, GoldSrc and Source) you would compile, create a list of problems and to-do's, fix as many as you could and then compile again. With this style (which I really enjoyed in FarCry) you can continually modify, test, wash, rinse, and repeat.
Having said that, is it possible to get a video uploaded showing the (via wireframe mode and other statistics if possible) the occlusion in action?
Also, the other question was related to the following, Charlie,
<!--QuoteBegin-Flayra+--><div class='quotetop'>QUOTE(Flayra)</div><div class='quotemain'><!--QuoteEBegin-->One really cool side effect of doing occlusion culling this way is that it would work well for most any type of game or mod. Ie, it's not for first-person shooters - it would work well for other genres as well. So this should really benefit NS2 mod makers and help encourage them make totally different games.<!--QuoteEnd--></div><!--QuoteEEnd-->
With that being said, it's obvious (as expected) that the necessary tools and engine access will be made available to the community for modding purposes. With such a robust tool and feature set for your engine, have you yet considered licensing options for the engine as well? Obviously Decoda is operating in the same vein. Originally developed to as an in-house solution; but now a stand-alone product. What are your thoughts?
There's a rather odd error with the page you linked for the CHC++ method: When "mattausch" is in capital letters (as with your link) none of the resource links work, except for the PDF draft. I hunted around for a while, and found the link through their site, and the only difference I can see is that capital-vs-lowercase difference, but it appears to be significant.
Can I request that you update the news entry with a fixed link? <a href="http://www.cg.tuwien.ac.at/research/publications/2008/mattausch-2008-CHC/" target="_blank">http://www.cg.tuwien.ac.at/research/public...ausch-2008-CHC/</a>
That said, I'm busy devouring algorithms. The internet has too much interesting stuff >.<
If you're bound primarily by pixel shading performance, shouldn't you be using a Z-only pass(aka Z-pre-pass)? Render all opaque objects to Z-buffer and don't touch the colour buffer. When you're done render the entire scene again(with Z-culling set to less or <b>equal</b>). In this colour-pass the GPU will use early Z-culling to kill blocks of pixels that are entirely occluded before the shader gets to execute(unless you screw around with the Z-buffer in pixel shaders).
<!--quoteo(post=1703604:date=Mar 27 2009, 01:15 AM:name=Soylent_green)--><div class='quotetop'>QUOTE(Soylent_green @ Mar 27 2009, 01:15 AM) <a href="index.php?act=findpost&pid=1703604"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->If you're bound primarily by pixel shading performance, shouldn't you be using a Z-only pass(aka Z-pre-pass)? Render all opaque objects to Z-buffer and don't touch the colour buffer. When you're done render the entire scene again(with Z-culling set to less or <b>equal</b>). In this colour-pass the GPU will use early Z-culling to kill blocks of pixels that are entirely occluded before the shader gets to execute(unless you screw around with the Z-buffer in pixel shaders).<!--QuoteEnd--></div><!--QuoteEEnd--> We use a deferred renderer, so a depth pre-pass doesn't actually help (I've tried it). Also, the occlusion culling system is responsible for more than just reducing the pixel overdraw. In fact the overdraw isn't really a problem because of what you mention about the depth test. What the occlusion system does that's very important is reduces the CPU overhead of submitting draw calls and the GPU cost of rendering shadow maps. It also saves a lot of computation updating animations and other things like that.
<!--quoteo(post=1703627:date=Mar 27 2009, 11:58 AM:name=Max)--><div class='quotetop'>QUOTE(Max @ Mar 27 2009, 11:58 AM) <a href="index.php?act=findpost&pid=1703627"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->We use a deferred renderer, so a depth pre-pass doesn't actually help (I've tried it).<!--QuoteEnd--></div><!--QuoteEEnd-->
What if you do a sloppy depth pre-pass with only nearby corridors and other large, low-poly geometry? Since there are no textures involved you can just batch all triangles into one big pile and render it all in one draw-call.
If rendering the colour, specular factor and normal is cheap enough it might just be adding unecessary complexity.
<!--quoteo(post=1703627:date=Mar 27 2009, 11:58 AM:name=Max)--><div class='quotetop'>QUOTE(Max @ Mar 27 2009, 11:58 AM) <a href="index.php?act=findpost&pid=1703627"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Also, the occlusion culling system is responsible for more than just reducing the pixel overdraw. In fact the overdraw isn't really a problem because of what you mention about the depth test.<!--QuoteEnd--></div><!--QuoteEEnd-->
I never suggested that you should ditch the occlusion culling, just a common trick that might further trim overdraw if you're still bound mostly by shader throughput.
How well does the occlusion culling work with commander mode?
I recall the NS commnader view was unable to make use of the Goldosurce engines pre-compiled VIS, such that limits had to be placed on the maps so as not to overload the commander view, Now this new method is fully dynamic the commander should be able to use it, however I imagine he's still going to be seeing the void a lot of the time, presumably triggering a lot more culling passes.
<!--quoteo(post=1704480:date=Apr 8 2009, 10:42 PM:name=ChromeAngel)--><div class='quotetop'>QUOTE(ChromeAngel @ Apr 8 2009, 10:42 PM) <a href="index.php?act=findpost&pid=1704480"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->How well does the occlusion culling work with commander mode?
I recall the NS commnader view was unable to make use of the Goldosurce engines pre-compiled VIS, such that limits had to be placed on the maps so as not to overload the commander view, Now this new method is fully dynamic the commander should be able to use it, however I imagine he's still going to be seeing the void a lot of the time, presumably triggering a lot more culling passes.<!--QuoteEnd--></div><!--QuoteEEnd--> The commander doesn't need occlusion culling since there is very little occlusion when you view the map from the top. Frustum culling (where you discard things outside the viewable cone) works well.
Comments
Having said that, is it possible to get a video uploaded showing the (via wireframe mode and other statistics if possible) the occlusion in action?
Also, the other question was related to the following, Charlie,
<!--QuoteBegin-Flayra+--><div class='quotetop'>QUOTE(Flayra)</div><div class='quotemain'><!--QuoteEBegin-->One really cool side effect of doing occlusion culling this way is that it would work well for most any type of game or mod. Ie, it's not for first-person shooters - it would work well for other genres as well. So this should really benefit NS2 mod makers and help encourage them make totally different games.<!--QuoteEnd--></div><!--QuoteEEnd-->
With that being said, it's obvious (as expected) that the necessary tools and engine access will be made available to the community for modding purposes. With such a robust tool and feature set for your engine, have you yet considered licensing options for the engine as well? Obviously Decoda is operating in the same vein. Originally developed to as an in-house solution; but now a stand-alone product. What are your thoughts?
When "mattausch" is in capital letters (as with your link) none of the resource links work, except for the PDF draft. I hunted around for a while, and found the link through their site, and the only difference I can see is that capital-vs-lowercase difference, but it appears to be significant.
Can I request that you update the news entry with a fixed link?
<a href="http://www.cg.tuwien.ac.at/research/publications/2008/mattausch-2008-CHC/" target="_blank">http://www.cg.tuwien.ac.at/research/public...ausch-2008-CHC/</a>
That said, I'm busy devouring algorithms. The internet has too much interesting stuff >.<
We use a deferred renderer, so a depth pre-pass doesn't actually help (I've tried it). Also, the occlusion culling system is responsible for more than just reducing the pixel overdraw. In fact the overdraw isn't really a problem because of what you mention about the depth test. What the occlusion system does that's very important is reduces the CPU overhead of submitting draw calls and the GPU cost of rendering shadow maps. It also saves a lot of computation updating animations and other things like that.
What if you do a sloppy depth pre-pass with only nearby corridors and other large, low-poly geometry? Since there are no textures involved you can just batch all triangles into one big pile and render it all in one draw-call.
If rendering the colour, specular factor and normal is cheap enough it might just be adding unecessary complexity.
<!--quoteo(post=1703627:date=Mar 27 2009, 11:58 AM:name=Max)--><div class='quotetop'>QUOTE(Max @ Mar 27 2009, 11:58 AM) <a href="index.php?act=findpost&pid=1703627"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Also, the occlusion culling system is responsible for more than just reducing the pixel overdraw. In fact the overdraw isn't really a problem because of what you mention about the depth test.<!--QuoteEnd--></div><!--QuoteEEnd-->
I never suggested that you should ditch the occlusion culling, just a common trick that might further trim overdraw if you're still bound mostly by shader throughput.
I recall the NS commnader view was unable to make use of the Goldosurce engines pre-compiled VIS, such that limits had to be placed on the maps so as not to overload the commander view, Now this new method is fully dynamic the commander should be able to use it, however I imagine he's still going to be seeing the void a lot of the time, presumably triggering a lot more culling passes.
I recall the NS commnader view was unable to make use of the Goldosurce engines pre-compiled VIS, such that limits had to be placed on the maps so as not to overload the commander view, Now this new method is fully dynamic the commander should be able to use it, however I imagine he's still going to be seeing the void a lot of the time, presumably triggering a lot more culling passes.<!--QuoteEnd--></div><!--QuoteEEnd-->
The commander doesn't need occlusion culling since there is very little occlusion when you view the map from the top. Frustum culling (where you discard things outside the viewable cone) works well.