Performance - Awful Setting
w0dk4
Join Date: 2008-04-22 Member: 64129Members, Constellation, Reinforced - Shadow
Join Date: 2008-04-22 Member: 64129Members, Constellation, Reinforced - Shadow
<div class="IPBDescription">making the game playable</div>I know that performance has been worked on (and Im not here to doubt that) but could this really be made the number one priority as regards future patches?
I think this is a critical issue to get us to actually playtest. From what I'm seeing the majority as of now cannot play NS2 smoothly.
Smooth gameplay to me means more than 60 fps constantly, without dropping below that mark.
Now, how these 60fps are achieved I dont really care as long as crucial gameplay elements are not touched (i.e. the dynamic lighting as it seems to be a critical part of NS2). So, please try to make the "ridiculously awful" graphics setting actually look awful. I'd gladly play with "awful" graphics as long as its fluid.
A few observations:
Latest patch resulted in a slight performance drop as far as I can see. The awful setting performs almost exactly as bad as the shiny setting although having lower quality textures. Maybe this means that the CPU is the main bottleneck?
Im getting 10 to 20 fps on a Core 2 Duo E6750 (2.67 GHz) and a Nvidia Geforce 8800GT.
I think this is a critical issue to get us to actually playtest. From what I'm seeing the majority as of now cannot play NS2 smoothly.
Smooth gameplay to me means more than 60 fps constantly, without dropping below that mark.
Now, how these 60fps are achieved I dont really care as long as crucial gameplay elements are not touched (i.e. the dynamic lighting as it seems to be a critical part of NS2). So, please try to make the "ridiculously awful" graphics setting actually look awful. I'd gladly play with "awful" graphics as long as its fluid.
A few observations:
Latest patch resulted in a slight performance drop as far as I can see. The awful setting performs almost exactly as bad as the shiny setting although having lower quality textures. Maybe this means that the CPU is the main bottleneck?
Im getting 10 to 20 fps on a Core 2 Duo E6750 (2.67 GHz) and a Nvidia Geforce 8800GT.
Comments
I think a big percentage of the players are playing 640x480 awful right now. and i agree that i wouldn't mind if awful was even more awful if it means i could play it better.
but anyway, even with the lower fps in 152, it feels much smoother
<img src="http://img51.imageshack.us/img51/8244/ns2performance.jpg" border="0" class="linked-image" />
I just went ingame without models and textures and got only 35fps for a scene which only has 20k primitives.
Even more apparent:
<img src="http://img268.imageshack.us/img268/9107/ns2performance2.jpg" border="0" class="linked-image" />
About the original post, i can confirm this (atleast from my test on my machine). I dont have the latest/greatest hardware (core 2 duo 2.7, 9800GTX 1G, 4G mem)...but its not "overly outdated". I run the game at high and low res and the graphics lag is more or less the same....
I just went ingame without models and textures and got only 35fps for a scene which only has 20k primitives.
Even more apparent:<!--QuoteEnd--></div><!--QuoteEEnd-->
Maybe occlusion culling isnt actually working?
I hear your call w0dk4, that's some nice evidence you've generated there. I hadn't realised low graphics settings didn't actually improve performance.
Thing is, it takes the graphics card literally no time to render the above images, which means that the actual gpu rendering doesnt seem to be the bottleneck. That also means that the most value as regards performance optimization is actually concentrating on non-gpu related engine methods.
For example, I'm seeing this on the progess page: "Optimize shadow map generation for lights"
I dont think this will give me any more fps.
They know about all of these issues and they have access to the timing information so they know which bits of code take the most time per frame to execute, which is why I'm sure the performance is the result of debug stuff happening behind the scenes. One of these days a patch will come along with "removed the cpu bottlenecks" and the frame rate will jump 2-3 fold, we'll just have to wait for it.
For all we know right now the display framerate could be locked (or is close) to the tick rate because of debug settings as they work to improve the networking.
I guess, as sometimes the walls disappear, showing the entire map for an instance. Isn't there a gl_wireframe in the console commands... So we can see what is actually being rendered...
GAH! we really need a complete console command list on the wiki or in the mapping guidelines... I know it was posted somewhere, but I canea find it...
video memory seems like a big problem still. not sure if things like players, buildings, macs etc instanced - it seems like they're not; i built like 10 macs and it instantly reduced my fps from ~25 to ~15 in commander mode, probably down to 1-5 fps when i tried to move them (somehow it had barely any effect when looking at them in first person POV). lots of crashes related to texture memory; once you go above your card's memory, objects show up as blue-and-white checkerboard models without any textures, and then a multitude of things will cause the game to crash - resizing, going from full screen to windowed and vice versa, moving props in the map (i.e. opening a door). seems to be a bit of a memory leak going on with the textures; if a mac dies, it doesn't reduce the texture memory footprint.
also, it seems like framerate is somewhat cpu-limited; ns is maxing out one of my cores in task manager/process explorer, whereas most of the others are at ~10%. overall cpu load went from 30-40%. latency didn't seem to have a drastic effect; fps was constant no matter whether i played on LAN or a 70ping server or a 250 ping server.
another thing, changing resolutions did nothing to improve or reduce framerates. i was getting ~35 fps in the readyroom and ~20 fps ingame no matter whether i was 640x480 awful or 1680x1050 high. the one thing that did cause it to become choppy (with drops to around 5-10fps) is when there were a lot of particle effects on screen. *edit* or other players lol */edit*
Either there are bugs with their implementation of the occlusion culling algorithm, or its something else like holes through the walls or seams? (Earlier today i read read a post where someone said that viewing a certain corner of the readyroom incurred a super-heavy processing load). I just hope it's nothing more then bugs, (or maybe bad map design? I assume they have a routine that checks for map leaks?) and not a worse situation where there are few if any bugs and it will be hard, if not impossible, to optimize this thing which would mean an entirely different occlusion culling algorithm would need to be shoehorned into the engine.
Remember this reveal: <a href="http://www.unknownworlds.com/ns2/news/2009/03/occlusion_culling" target="_blank">http://www.unknownworlds.com/ns2/news/2009...clusion_culling</a>
Specifically this:
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->If you've ever done any mapping for the Quake or Half-Life engines, you're probably familiar with the "vis" tool which performs this precomputation. <u>This can be a slow process that requires a lot of tweaking and careful modeling. Because the data is precomputed, the environment can't change much at run-time</u>. And finally <u>the PVS method is not very good when it comes to outdoor scenes</u>. <u><b>To alleviate all of these problems, we've chosen to use a hardware assisted occlusion culling method that doesn't require precomputation</b></u>.
Here's what the scene looks like with the occlusion culling system enabled:
...
As expected, most of the invisible geometry has been discarded during the rendering process. <u><b>Because of way the algorithm utilizes the graphics card</b></u>, the structure of the level doesn't really affect the system. It works with outdoor environments as well as indoor environments and can handle polygons "soups" -- collections of polygons that don't really have any structure at all.
While<u><b> real-time occlusion culling has some additional performance cost over precomputed systems like PVS</b></u>, we think the benefits more than make up for it. And with clever optimizations, that cost can be reduced substantially.<!--QuoteEnd--></div><!--QuoteEEnd-->
They go on to mention their using a implementation based on this paper: <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>
The paper mentions:
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Reduction of CPU stalls. <u>The CHC algorithm does a
good job at reducing CPU stalls, however in certain scenarios
stalls still occur and cause a performance penalty.</u>
We propose a simple modification which provides further
reduction of the wait time, which at the same time integrates
well with our method for reducing state changes.<!--QuoteEnd--></div><!--QuoteEEnd-->
So ya, cool if and when it works we can look forward to outdoor maps :P
I wonder how bad company 2 does occlusion culling? xD
GAH! we really need a complete console command list on the wiki or in the mapping guidelines... I know it was posted somewhere, but I canea find it...<!--QuoteEnd--></div><!--QuoteEEnd-->
r_wireframe
Seems to be the same with player models of bots. The game runs "okay" (for an alpha) somerwhere around 20-30 FPS, after adding ten bots (which are just standing around) the FPS go down to 5, even if they are out of sight. Same with MACs.
Firstly performance differences between the 3 different settings.
Your are not going to see hardly any FPS changes here because the quality of the textures does not hinder your achivable frame rates, it only effects the loading time of them, the higher the setting the more texture data to be loaded the longer the level takes to load the longer it takes to cache new textures.
If you have 768MB or less of GPU Texture memory running on high you will get some small hitching as you move around when textures are loaded in, they are hot swapped in memory as you get near other textures, the hitching effect is much smaller than before because soft loading has been introduced but probably needs some tweeking.
<u>As for GPU users with 1GB of onboard texture memory the reason for hitching is currently unknown. If you can test between Med & high and report back that would be great.</u>
Some hitches may be cause by other things though other than the loading of textures, for example hitting the voice transmit button for the first time will cause a hitch so bare it in mind.
As for the spamming of MACS for example as mentioned, Just before the patch was uploaded to steam, Instancing was set to false by default because some last minute render problems where found with some select models, They are being investigated to find out what it is with these specific models that produces this bizar issue, Brian is fully on the case with it.
If you want to do some testing with instancing, go ahead and use <u>r_instancing true</u> and see if that changes any experiences you have had with any other issues just recently.
Problems with server performance, a fix yet to be tested has been applied and max_players limit has been fixed.
issues with culling as r_wireframe will show are being looked at, somewhere along the lines it has broken and Max is fully aware of the problems so dont worry.
About the MACs, they don't seem to have an impact on performance at all (on my local LAN server). Couldn't make out a difference between 0 and 20 on the screen. However, selecting them all at the same time almost halves my FPS from 16 to 9. Deselect and it's instantly back at 16. Funny stuff.
Live and learn.
Back onto the topic at hand....
One setting would be to have super dumbed down versions of the geometry and turn off all particles. Granted, this means generating lower poly everything, but if geometry is being a problem that's the only way to fix it.
However, it sounds like the GUI may be yet another major bottleneck, so let's hope they can get giant performance boosts from fixing it.
I was able to stick 3 million in one scene before it became a noticable problem.
The number of things that move in a scene can stack against you with CPU usage. Everything animated costs cpu time, 100's hydras will slow you down, just because there is a slow down does not mean it was actually caused by the amount of poly but it could infact be caused by the processing of the animations and shadows.
Then SgtBarlow is super correct and it's all about physics, animations, CPU shadow generation. Shouldn't shadow generation be on the GPU? I'm not as engine savvy as I'd like to be.
I think this change to the gui system will give a huge amount of performance increase 10ms is a long ass time...