Development Blog Update - Occlusion Culling
Max
Technical Director, Unknown Worlds Entertainment Join Date: 2002-03-15 Member: 318Super Administrators, Retired Developer, NS1 Playtester, Forum Moderators, NS2 Developer, Constellation, Subnautica Developer, Pistachionauts, Future Perfect Developer
Technical Director, Unknown Worlds Entertainment Join Date: 2002-03-15 Member: 318Super Administrators, Retired Developer, NS1 Playtester, Forum Moderators, NS2 Developer, Constellation, Subnautica Developer, Pistachionauts, Future Perfect Developer
Comments
Thanks
By the way, are you guys going to deal with the missing end of the latest podcast? I'd love to hear how the twitter feed has impacted your development process, unless of course it's proprietary information. I don't mind if it was just written up and edited into the news post or whatever.
*edit*
And one more thing, you vaguely mention other tricks you are using to speed up occlusion culling, are you willing to divulge them,<strike> like for instance, are you doing a quick view frustrum culling before you use this CHC++ algorithm</strike>?
Ignore that last part, according to the pdf, this algorithm is even faster than View frustrum, which is impressive. I'm really excited to see this engine in action.
What happens when the player gets to the end of the corridor and turns the corner? Does occlusion-culling anticipate this and gradually shows whats going to come up next (so there's no burst of polygons to render), or are we (as mappers) still encouraged to use visibility hacks (like several bends, u-turns and so on) to ease the work of occlusion-culling?
All in all does it affect the way maps are designed?
Nice to see the engine evolving. I foresee great mapping moments.*....mmmmm.....nstr2....*
it seems like yes mappers will have to use 'hacks' like bends and whatnot, but that's just good mapping, to prevent too much from being rendered. what this means team me is that mappers no longer need to worry about little hacks like making sure a floor brush is broken up in the right places to prevent a tri from extending too far.
i believe in hl2 maps the VIS mentioned was calculated from a triangle, so if i'm standing in a specific triangle then everything visible from any part that triangle should be rendered. this caused a problem if someone was standing on a large triangle that saw where the player couldn't, unnecessary areas of the map would be drawn by the engine.
one thing i notice about this, is that calculating this on the fly would be much more calculation intensive than precalculating it, and if it is going to be taking up a bunch of processing power i'm sure the team has a good reason to do it this way as opposed to precalculating it since they already expressed their desires to have this playable on a wide array of machines.
now they've mentioned having changeable environments, but there hasn't been any detail on what that means. with a feature like this, it could mean as much as completely destructible terrain, similar to red faction. it opens up a lot of possibilities, and i'm excited to see where they take it.
I'm guessing the occlusion culling is done each frame or every few frames at most. Am I right Max?
<!--quoteo--><div class='quotetop'>QUOTE</div><div class='quotemain'><!--quotec-->or are we (as mappers) still encouraged to use visibility hacks (like several bends, u-turns and so on) to ease the work of occlusion-culling?
All in all does it affect the way maps are designed?<!--QuoteEnd--></div><!--QuoteEEnd-->
Well you'll still be wanting to use visibility blocks and doughnut hallways to prevent having lots of those dynamically lit polys in view. However this should mean movable things like, players, physics objects, infestation goo and doors will occlude what's behind them, unlike in HL, where such entities were not occluding. So you can just use a hallway with doors at each end to separate two hi-poly areas.
<!--quoteo--><div class='quotetop'>QUOTE</div><div class='quotemain'><!--quotec-->we've chosen to use a hardware assisted occlusion culling method<!--QuoteEnd--></div><!--QuoteEEnd-->
Interesting... That's a feature that is standard on all hardware of the previously mentioned minimum NS2 spec its it? It's not going to ties NS2 players to a particular chip set or brand is it?
<!--quoteo--><div class='quotetop'>QUOTE</div><div class='quotemain'><!--quotec-->And finally the PVS method is not very good when it comes to outdoor scenes<!--QuoteEnd--></div><!--QuoteEEnd-->
Still no plans for outdoor NS maps to take advantage of this though?
Does it cope with transparent or partially transparent polys like glass OK?
Also, you say that the new occlusion system takes up resources, but that'd be <b>much</b> less than actually rendering all the occluded poly's, right?
I'm probably being a total idiot not getting the point. <img src="style_emoticons/<#EMO_DIR#>/wink-fix.gif" style="vertical-align:middle" emoid=";)" border="0" alt="wink-fix.gif" /> Anyway, if this works properly it'd greatly increase the engine's performance, so keep it up!
But it's precomputed, their implementation is dynamic (hope I got that right).
That's exactly it. With GoldSrc (NS1) PVS is a precalcuated data set that basically says when the player is standing here, only render these triangles. What they are doing here is the same concept, just on the fly as the player moves through the level instead of calculated before hand.
Good luck, i hope you can release it this year.
There are some question about the engine developpement:
Is there a possibility to enable a ground grid ? For those who are moding: Some kind of Unreal of FarCry terraforming.
Indoor map won't need it, so a systeme that enable / disable it would do the trick. And it won't require huge loads of code. Beside modder could explore more possibilities. Even in a indoor map like a remake of MineShaft that would require some smothly curved area.
Is there a possibility to have occluder areas? (A simple paralepiped that forbid rendering polygon that are behind) Ok the selected system is dynamic but sometimes, help the system is really cool. Example : Farcry. I remember pushing up FPS by a factor 2 with some well located occuders. Despite the Cryengine was also dynamic, helping it was good for gameplay.
I got designs (based on natural selection of course); how can i make sure they fit the engine needs and possibilities ?
Thanks for reading.
wheres my cookie
Pretty sure they're referring to the difficulty of engines to render outdoor environments, specifically large, primarily uncovered expanses of land, as in such a situation there are very few walls or separations of the space, and therefor very few visleafs, which means the engine is rendering the entire area. No easy feat for engines specifically optimized for indoor scenes, or older engines in general.
There are some question about the engine developpement:
Is there a possibility to enable a ground grid ? For those who are moding: Some kind of Unreal of FarCry terraforming.
Indoor map won't need it, so a systeme that enable / disable it would do the trick. And it won't require huge loads of code. Beside modder could explore more possibilities. Even in a indoor map like a remake of MineShaft that would require some smothly curved area.
Is there a possibility to have occluder areas? (A simple paralepiped that forbid rendering polygon that are behind) Ok the selected system is dynamic but sometimes, help the system is really cool. Example : Farcry. I remember pushing up FPS by a factor 2 with some well located occuders. Despite the Cryengine was also dynamic, helping it was good for gameplay.
I got designs (based on natural selection of course); how can i make sure they fit the engine needs and possibilities ?
Thanks for reading.<!--QuoteEnd--></div><!--QuoteEEnd-->
Technology-wise outdoor and indoor maps are very different. With indoor maps you see occlusion culling where large sections of the map are simply not rendered for individual players. For outdoor maps you either have to limit field of view artificially(old school thick fog) and/or render things with much less detail at a distance(the current preferred option). It's not that you can't do both outdoor and indoor maps, and Max mentions that this occlusion tech will work well with outdoor maps, it's that coding to render outdoor maps efficiently is non-trivial. This is especially true when you have interesting features like dynamic lighting and procedural textures/objects(the DI). NS2 is going to be a primarily indoor game. This isn't to say that it won't allow their engine to do outdoor levels, because it seems like they want the engine their building to do both well, but that's just what NS2's play style is and the engine will likely be optimised for. Unfortunately it's not as easy as slapping a sky texture on a big room.
I hope this dynamic occlusion means faster map compiling.
although light was always the ######.
-kingmob
I hope this dynamic occlusion means faster map compiling.
although light was always the ######.
-kingmob<!--QuoteEnd--></div><!--QuoteEEnd-->
You know of course that the maxx0r engine has real time lighting, so will be no RAD compile time either.