Occlusion Geometry
<div class="IPBDescription">How to go about it.</div>The new method will be comming soon but you can get started now. Creating the geometry in the group will hide it for now so dont worry about your level gettings messy before the new method goes in.
<img src="http://www.unitedworlds.co.uk/ns2/help/rockdown_occlusion.jpg" border="0" class="linked-image" />
<img src="http://www.unitedworlds.co.uk/ns2/help/rockdown_occlusion.jpg" border="0" class="linked-image" />
Comments
I must ask, doesn't using occlusion cost CPU resources? Is there diminishing returns if over used?
The current implementation uses the real geometry to cull objects (IIRC), so this should definately give a huge performance boost as long as you dont make the occlusion geometry as complicated as the map geometry.
btw.: Thank god you are revising the real-geometry based culling, I think it makes sense to make the extra work on the mapping part to save performance.
So once this is added usual geometry isn't used for occlusion culling at all or just after adding that special group in spark?
The current system is all automatic, but the performance penalty is bigger than I'd like (and probably more than the players like too). This isn't like BSP/PVS system though and the geometry doesn't have to be sealed. It's also well suited for outdoor environments.
In the future I will investigate making the generation of the occlusion geometry automatic.
So as a Custom mapper should the general population do this or just the official mappers and wait to see if it is possible to automate? Or is it to soon to tell if it's even possible or to put a time frame of how long before/after 1.0?
Personally I would rather sit on my levels and have a late release than spend the hours implementing this.
EDIT: The reasoning for rather waiting is that it may be like Collision_Geometry and be less important because of other changes.
Personally I would rather sit on my levels and have a late release than spend the hours implementing this.
EDIT: The reasoning for rather waiting is that it may be like Collision_Geometry and be less important because of other changes.<!--QuoteEnd--></div><!--QuoteEEnd-->
When I said "in the future", I meant when we have flying cars and robot butlers.
I would wait until the new system is released to start retrofitting your levels. Hopefully I will have this finished for the next patch.
This proposed future of yours is awesome, will you be the one programming our Matrix? It can only end in Max-imum win :P
Thanks for clarifying on that, It actually doesn't look to complicated to implement. Basically just a box within your textured finished box with openings at doors and vents.
Things like this put one click prefab shapes on my wish list. :) Click,place,extrude.....
For example, if I'm standing in marine start on rockdown, which parts of the map are being rendered? How is the engine determining which parts to render? Since levels don't need to be sealed, what happens if I have a big, gapping hole in my geometry that lets players see into the void/other parts of the level that they shouldn't?
Essentially, I'm looking for a comparable spark version of the example given for source here: <a href="http://rvanhoorn.ruhosting.nl/optimization.php?chapter=visleafs" target="_blank">http://rvanhoorn.ruhosting.nl/optimization...hapter=visleafs</a>
For example, if I'm standing in marine start on rockdown, which parts of the map are being rendered? How is the engine determining which parts to render? Since levels don't need to be sealed, what happens if I have a big, gapping hole in my geometry that lets players see into the void/other parts of the level that they shouldn't?
Essentially, I'm looking for a comparable spark version of the example given for source here: <a href="http://rvanhoorn.ruhosting.nl/optimization.php?chapter=visleafs" target="_blank">http://rvanhoorn.ruhosting.nl/optimization...hapter=visleafs</a><!--QuoteEnd--></div><!--QuoteEEnd-->
Try the <a href="http://www.unknownworlds.com/ns2/wiki/index.php/Console_Commands" target="_blank">wireframe console command</a> to see it's current implementation in real time
cheats 1
r_wireframe
What I am implementing is similar to what's described <a href="http://www.selfshadow.com/talks/rwc_gdc2010_v1.pdf" target="_blank">here</a>. The implementation is quite different but the setup is the same.
If I tie that geometry to the CommanderInvisible group it does a good job in blocking vis, so why not make the OcclusionGeometry group invisible to everyone, but still blocking vis like the other group?
I'm sure this is kinda the plan all along; just a suggestion in case that new system is not ready for the next patch.
(1) Do i need to open up all parts that look out to sky-buildings?
(2) How will the sky-box and sky-buildings be handled?
<img src="http://www.super-nova-team.com/ns2/clandestine/occlusiongeometry.jpg" border="0" class="linked-image" />
I had a NVidia 9800GTX+ up until it died a few weeks ago, and my performance was suffering, struggling to stay close to 30fps.
When it died I replaced it with a Readon HD 6970 (Well it's a 6950, but I unlocked the extra stream cores, so now it's a 6970) and my performance more than doubled! Now yes the 6970 is a better card, but that was a HUGE gain.
Now also a few weeks ago, I started mining Bit Coins using an OpenCL GPU miner. My old 9800GTX+ managed a respectable ~35 million hashes / second.
However my new 6970 SMASHES it out of the park with ~350 million hashes / second!!
Knowing the cards were not THAT far apart in performance (graphically), I looked into it, and NVidia cards have many fewer, but more complex stream processors, and AMD cards have much simpler, but many more stream processors.
In graphics operations they are fairly matched, but in raw compute power for general computations like OpenCL, AMD cards BLOW NVidia out of the water!
Just my 2 cents :)
What you're saying is Nvidia has a stupidly complex architecture making performance sucky for it? Where AMD made it simply and efficient and less bad?
But for general compute performance (which is relatively new), it appears, that it isn't as efficient. Sorta like the difference between RISC and CISC I believe. Though admittedly I don't know enough about the stream processors to be an authority here...
[edit] Hhhmmm... apparently I suck at putting thins in Laymans terms... [/edit]
With this new method you have heaps less geometry to do queries against would should reduce the occlusion queries and be far less taxing on the GPU..
Good read how occlusion queries work;
<a href="http://http.developer.nvidia.com/GPUGems/gpugems_ch29.html" target="_blank">http://http.developer.nvidia.com/GPUGems/gpugems_ch29.html</a>
<a href="http://www.nvidia.com/object/fermi_architecture.html" target="_blank">http://www.nvidia.com/object/fermi_architecture.html</a>
Seems that when giving a way-point to a mac/drifter they go to the top of the Occlusion geometry. This geometry is invisible but i can't way-point through it. Do i need to add this to the Commander Invisible group also?