Some reflections on performance
Soylent_green
Join Date: 2002-12-20 Member: 11220Members, Reinforced - Shadow
Join Date: 2002-12-20 Member: 11220Members, Reinforced - Shadow
I've noticed a big performance differential between spectator and any lifeform. If you float around in spec it is a good 50% faster rendering the same thing for no apparent reason. The only visible difference I can think off is the GUI and the view model. My suspicion is on the GUI(tell me it's not still using flash? Ugh).
I've also been toying around with r_wireframe. The occlusion culling is badly broken and I suspect the game would be very much more playable if it can be fixed. I'm not sure if its an issue on all system configurations, because it's not even consistent on mine.
For example, on ns2_summit in the ready room; if you stand anywhere near the ramp leading to join team random and look vaguely in the direction of the random sign it will sometimes render half the map and tank performance to about 10 FPS. Other times you cannot get it to behave this way; you can muck about all you want and you'll have well in excess of 100 FPS because it's just rendering a simple wall. So what has changed between first joining the server and getting back into the RR after winning a round that would affect occlusion culling so remarkably?
The occlusion culling appears to behave inconsistently between your own listen server and online games. Again an example from summit; in the alien spawn, looking out into the right-side corridor towards crevice my framerate will be fine on my own listen server, but joining someone elses server it will be about 10-20 FPS every time. Enabling wireframe(why am I allowed to do this in multiplayer?) I can see that it's rendering a huge chunk of the map in multiplayer, but not on my own listen server.
It is <b>frequently</b> rendering many areas that in no way need to be rendered and my performance is very erratic. If occlusion culling and whatever causes a framerate differential between spec and ingame can be fixed, I would expect at least a factor of two performance jump for average FPS and a much greater improvement for min fps(which occassionally goes below 10).
---
After some more playing around, occlusion culling appears to deteriorate markedly with time. Here's my most pathological case to date, after several rounds I fired up tram. 8000 draw calls, 2 million primitives, 600 lights, 2400 models with 140 unique meshes, 400 occlusion queries; <b>jikes!</b> Tram doesn't even run badly when you first start the game.
<img src="http://img32.imageshack.us/img32/6215/2011061600013.jpg" border="0" class="linked-image" />
I've also been toying around with r_wireframe. The occlusion culling is badly broken and I suspect the game would be very much more playable if it can be fixed. I'm not sure if its an issue on all system configurations, because it's not even consistent on mine.
For example, on ns2_summit in the ready room; if you stand anywhere near the ramp leading to join team random and look vaguely in the direction of the random sign it will sometimes render half the map and tank performance to about 10 FPS. Other times you cannot get it to behave this way; you can muck about all you want and you'll have well in excess of 100 FPS because it's just rendering a simple wall. So what has changed between first joining the server and getting back into the RR after winning a round that would affect occlusion culling so remarkably?
The occlusion culling appears to behave inconsistently between your own listen server and online games. Again an example from summit; in the alien spawn, looking out into the right-side corridor towards crevice my framerate will be fine on my own listen server, but joining someone elses server it will be about 10-20 FPS every time. Enabling wireframe(why am I allowed to do this in multiplayer?) I can see that it's rendering a huge chunk of the map in multiplayer, but not on my own listen server.
It is <b>frequently</b> rendering many areas that in no way need to be rendered and my performance is very erratic. If occlusion culling and whatever causes a framerate differential between spec and ingame can be fixed, I would expect at least a factor of two performance jump for average FPS and a much greater improvement for min fps(which occassionally goes below 10).
---
After some more playing around, occlusion culling appears to deteriorate markedly with time. Here's my most pathological case to date, after several rounds I fired up tram. 8000 draw calls, 2 million primitives, 600 lights, 2400 models with 140 unique meshes, 400 occlusion queries; <b>jikes!</b> Tram doesn't even run badly when you first start the game.
<img src="http://img32.imageshack.us/img32/6215/2011061600013.jpg" border="0" class="linked-image" />
Comments
Try profile 1.
It's in the process of being "optimized", but I want it to be "fixed", because at least on my system it is broken(I'm in no rush, I just want it to be looked at and add some useful data points if I can).
As soon as I bump up to native res the game also take a major hit, much more so than most others.
Something is hogging that CPU ; )
As soon as I bump up to native res the game also take a major hit, much more so than most others.
Something is hogging that CPU ; )<!--QuoteEnd--></div><!--QuoteEEnd-->
keep in mind the editor performance differs from in game, the editors biggest cripple is the lights. make sure you keep them in their own layer and hidden when possible.
I can't speak for the game it's self as Even though it shows low frame rate and stutters every now and then,overall it plays pretty smooth on my system but the editor lights kill my gt220.
The occlusion system that is being worked on, is an entirely different way of doing it from the currently implemented occlusion system. So, in theory, it should "fix" the issue, in the sense that it will behave much more consistently, and really only render what is actually visible. Whether this ends up having a big improvement on FPS is still up in the air, since there are still many other things in the game bringing down the performance that may counter any improvements from the better occlusion.
The difference in performance from spectator to actual FPS mode is likely do to the physics and onprocessmove stuff, which is one of the biggest culprits contributing to poor performance, and next on the list for Max to start working with.
--Cory
The difference in performance from spectator to actual FPS mode is likely do to the physics and onprocessmove stuff, which is one of the biggest culprits contributing to poor performance, and next on the list for Max to start working with.
--Cory<!--QuoteEnd--></div><!--QuoteEEnd-->
I know this isn't a simple question, but what is your target for recommended system specs? What would you be satisfied with? I know the actual outcomes may vary but it would be interesting to know what you're shooting for.
I'd presume what is written on the buy page. <a href="http://www.naturalselection2.com/buy" target="_blank">http://www.naturalselection2.com/buy</a>
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->1.2 GHz Processor (SSE2 required), 256MB RAM, a DirectX 9 level graphics card, Windows Vista/2000/XP, Steam, mouse, keyboard and an internet connection.<!--c2--></div><!--ec2-->
Edit: Also, much of the current performance bottleneck is on the server-side. However, I'm skeptical that they'd be able to hit those specs. For comparison, HL2 had a min of 1.7GHz and 512MB of RAM. I'd say something on the order of 2.0GHz and 1GB of RAM would be more reasonable.
Further edit: Taking a look at Steam's hardware survey, its clear that the buy page's sys req are likely far too low. Only 0.33% of systems had less than a 1.4GHz CPU (thats the lowest category they gave) and 0.08% had less than 512MB of RAM. In fact, UWE could considerably up the min sys reqs to 2.0GHz CPU, 2GB RAM, and 256MB VRAM and still cover >90% of computers steam has surveyed (91.77%, 94.96%, and 94.21%, respectively). I'd rather UWE spend more time on making very good server performance (so modders could produce mods with 64 or even 128 players) than try to optimize for the 10% of clients whose computers are rapidly becoming obsolete.
Is there anything majorly wrong with the current approach, except for bugs?
Any clue as to what is causing occlusion culling to gradually deteriorate with play time(preserved across map and server boundaries)? That's a really weird bug and I'm very curious how that came to be.
<!--quoteo(post=1853315:date=Jun 15 2011, 07:32 PM:name=Squeal_Like_A_Pig)--><div class='quotetop'>QUOTE (Squeal_Like_A_Pig @ Jun 15 2011, 07:32 PM) <a href="index.php?act=findpost&pid=1853315"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Whether this ends up having a big improvement on FPS is still up in the air, since there are still many other things in the game bringing down the performance that may counter any improvements from the better occlusion.<!--QuoteEnd--></div><!--QuoteEEnd-->
I understand why you want to avoid making promisess whenever possible, but I know it will.
My framerate is fairly playable when I first start the game, and even then there's quite a bit of overdraw; within minutes the framerate goes pretty bad and within an hour or so it is completely unplayable. That's related in a major way to occlusion culling. Tram is actually playable when I first fire it up; check the screenshot in my first post, tram frequently dips into the single digit FPS after an hour, because it renders HUGE chunks of the map.
Performance is perhaps 2x better on summit than tram, but that doesn't actually matter much; the problem isn't average FPS, which deteriorates much less. The problem is min FPS; min FPS defines playability, not average FPS; and the min FPS is absolutely awful on both maps when the occlusion culling fails.
Within an hour the occlusion culling is failing all over the place, and I get framerate dips into the low teens when I happen to look in the wrong direction. I've seen crossroads, heli and crevice all at once from alien start, where I am meant to see neither.
Like Cory said. When you move as a life form it has to go through all kinds of tricky movement code for collision detection, friction, your class' movement abilities and whatnot, where as a spectator you just float in the direction you choose.
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->1.2 GHz Processor (SSE2 required), 256MB RAM, a DirectX 9 level graphics card, Windows Vista/2000/XP, Steam, mouse, keyboard and an internet connection.<!--c2--></div><!--ec2--><!--QuoteEnd--></div><!--QuoteEEnd-->
I believe that's a relic from early development. One of the devs(not Charlie, possibly max, not sure) responded to one of my posts years ago, stating they were not planning to use normal maps extensively other than on player and building models. Now almost everything has a normal and spec map; technological progress obsoleted their targeted GPU and memory requirements. It's difficult to even find a 1.2 GHz CPU in low-power laptops from a few years back.