Occlusion Culling Optimization
Lazurah
Join Date: 2011-06-04 Member: 102655Members
<div class="IPBDescription">pushed back again?</div>I've seen occlusion culling optimization appear on the tracker for the past couple of builds, and each time it has been pushed back. Why? Every time I see it appear on the list, it makes me look forward to the next build because NS2 might become optimized enough for me to enjoy playing it online (my framerate is a god-awful 7-15fps max).
I don't mean to say that UWE is "wasting time" on other features; many of the things that they've added to NS2 are very cool. And I get to enjoy seeing those things come into the game during a part of development that game companies rarely show off to the public. But I'd like to know why the devs haven't finished this feature since it came up on the tracker around build 179 or 178. Is it literally just taking that long to complete due to the size and complexity, or was it started and then left unfinished as more features that were deemed more important came up?
I don't mean to say that UWE is "wasting time" on other features; many of the things that they've added to NS2 are very cool. And I get to enjoy seeing those things come into the game during a part of development that game companies rarely show off to the public. But I'd like to know why the devs haven't finished this feature since it came up on the tracker around build 179 or 178. Is it literally just taking that long to complete due to the size and complexity, or was it started and then left unfinished as more features that were deemed more important came up?
Comments
If it was simple, it'd be fixed don't you think?
I don't mean to say that UWE is "wasting time" on other features; many of the things that they've added to NS2 are very cool. And I get to enjoy seeing those things come into the game during a part of development that game companies rarely show off to the public. But I'd like to know why the devs haven't finished this feature since it came up on the tracker around build 179 or 178. Is it literally just taking that long to complete due to the size and complexity, or was it started and then left unfinished as more features that were deemed more important came up?<!--QuoteEnd--></div><!--QuoteEEnd-->
On going process! It goes up every patch and it goes down every now and then due new feature.
I dont think it will ever be finished fully.
I don't mean to say that UWE is "wasting time" on other features; many of the things that they've added to NS2 are very cool. And I get to enjoy seeing those things come into the game during a part of development that game companies rarely show off to the public. But I'd like to know why the devs haven't finished this feature since it came up on the tracker around build 179 or 178. Is it literally just taking that long to complete due to the size and complexity, or was it started and then left unfinished as more features that were deemed more important came up?<!--QuoteEnd--></div><!--QuoteEEnd-->
As others mentioned here, Max, the programmer working on the new occlusion system, is just one man, unfortunately. We tried cloning him, but the first time we ended up with a lumpy, 3 armed, braindead mutant, and the second time we ended up with Brian Number 1...not much of an improvement.
It has been an ongoing process and other higher priority tasks with more dependencies have come up and interrupted his work on it, but it's close to being finished up.
I would try to lower expectations about how much the occlusion is going fix performance at this stage. It will definitely eliminate any of the occlusion related hitches, and some of the dramatic frame rate dips when large areas of the map were being rendered unnecessarily. And it should provide a more stable framerate overall. However, its not necessarily going to increase your average framerate noticeably. It's really dependent on the graphics card, so at this stage it's uncertain how much of a difference it will make for each person.
--Cory
Then again, with my cpu bottlenecking my system. It's runs medium faster than low. So who knows what will happen.
Also, I normally have a very good framerate (over 40 at worst, apart from 2 scenarios), but if this fixes my the fps-lag when I look down at the whole map as a spectator, I will be happy. Or the lag I get when I can see the source of atmospheric lighting (at least big ones). Any idea why that lags so much?
I dont think occlusion culling will help any of those issues though, but I can hope, cant I?
Wow, that is low. Even for you Cory.
<a href="http://www.youtube.com/watch?v=rza--bGIkbE" target="_blank">http://www.youtube.com/watch?v=rza--bGIkbE</a>
Someone correct me here, but this is it right?
<a href="http://lmgtfy.com/?q=occlusion+culling" target="_blank">http://lmgtfy.com/?q=occlusion+culling</a>
The game world is composed of a series of rendered triangles. A dumb game engine would draw every triangle in the entire world, every single frame. This would be SLOW, since there can be many hundreds of thousands of triangles.
So there are various categories of optimizations a game engine can perform:
1) Don't show triangles that would be out of your view (line of sight), such as those behind you
2) Don't show triangles that would be around corners, aka hidden by other triangles
3) Don't show triangles that would be effectively invisible because they are too small and too far away
Each is a different kind of math, with different benefits to performance.
Occlusion culling is optimization category #2. A triangle is not drawn if it is "occluded" (which is a fancy word for "hidden") by other triangles. The math for this is NOT trivial, so the challenge is to spend less time doing math then you would spend drawing the hidden triangles.
(To the GFX geeks, yes, this is extremely simplified. Bear with me please.)
--Cory<!--QuoteEnd--></div><!--QuoteEEnd-->
Has it helped at all specifically with Tram's framerate issues?
For some people, and I can only assume there are more people experiencing this than myself, this is <b>THE</b> reason the game runs <b>horribly</b>. At first the game runs well, within minutes it starts slowing down; after about and hour my FPS only rarely crawls above 20 and <i>most of the map is rendering most of the time</i>.
I can't imagine you can have two programmers typing code into the same line at the same time.
But then you could try merging Brian 1 and Brian 2 together to form some sort of super Briani.
The i is intentional, because the merged Brians would surely be a plural.
Yeah I've been having serious issues with this and it is pretty obvious when I look across the map my fps drops hard. Profiler tells me its garbage collection after rendering, but if the majority of the map wasn't displaying (particle systems and lighting too), GC wouldn't have to work so hard to keep up.
That's not a retarded question! I had no idea for a long time either :). I like to think it very simply as 'not rendering what the player can't see.' I'm sure there's many technical reasons why that's not a great way of putting it... But it seems too get the basic message into my head!
that is actually pretty much it, now implementing it efficiently is not simple however.
I'll promise, I'll give candy to all of you. <(^_^<)
Turn on wireframe rendering mode. You will visually see what is occluded and what is not. Here's an example of occlusion culling ###### the bed:
<img src="http://img32.imageshack.us/img32/6215/2011061600013.jpg" border="0" class="linked-image" />
Yes, that's 2.3 million primitives. 600 light sources. 2400 models. 400 occlusion queries.
<img src="http://img696.imageshack.us/img696/8238/2011061600015.jpg" border="0" class="linked-image" />
Here's the wireframe. That mess of lines near the horizon is other rooms all the way across the map.
On a more serious note, I'd love to know how Max and Co. are approaching this issue, what techniques they are planning to implement or what they have already tried (being a curious programmer myself). I wonder if they can use the current culling algorithm to build a per-map PVS (potentially visible set) - that would be pretty interesting and unique, but it might not be precise enough.