NS2 Particle Effects Optimization

Skie

<div class="IPBDescription">The next step for improved fps?</div>Hello,

This post is mainly aimed for the devs.

Cutting to the chase, the particle effects in NS2 really drastically reduce your fps if you are very close to them. I don't know if this is a thing you can optimize or not, because it happens in other games as well (e.g. in World of Tanks when you shoot and the smoke cloud fills your screen). The GPU somehow needs to process the stretching and alpha changes for the decals across the entire screen, if I understand at all how it's handled. Fade blink, burning effects, explosions - there's a lot of them that cause this and is the biggest thing affecting combat fps right now (I imagine).

Fade blink as an example. When you blink a short distance and walk right into the particle effect (dark cloud puffs and the electric zapping), the fps drop is huge:

<img src="http://i.imgur.com/hA2aC.jpg" border="0" class="linked-image" />

These screenshots were taken at 1920x1200 and high settings, if that helps any. Any idea if by changing graphics card settings this could be improved on the client end? I've got GTX570, for the record.

Just a heads up.
Keep up the great work team.

Obraxis

Particle effects are on Max's list of things to work on. You can be sure when he has the time he will work on them. :)

Skie

Thanks for letting us know, Obraxis.
If the framerate near particles can be improved at all, it will be great.

Soylent_green

The problem with being close to sprites is overdraw. Overdraw is roughly the number of times the average pixel on the screen has been drawn over. For opaque objects you can use the Z-buffer to quickly reject pixels that end up occluded by something in front of them(you still have the CPU overhead of sending them to the GPU in the first place, but they are quite cheap to discard on the GPU). With translucent sprites you can't do this; you end up drawing over the entire screen many times and eating up a large amount of fillrate and bandwidth(potentially, GPUs also have various caches, including texture caches, that small sprites may fit into).

The solutions to this problem usually are of the character of fading out sprites when they get too close to the player or using fewer, bigger, more opaque sprites.

In NS2 the renderer is deferred, which makes rendering anything but additive or subtractive sprites a pain and there could be pretty large gains from choosing a better/cheaper algorithm.

IronHorse

Soylent_Green i love it when you talk dirty.
so what exactly would a better algorithm look like?

Soylent_green

<!--quoteo(post=1898919:date=Feb 2 2012, 02:37 PM:name=ironhorse)--><div class='quotetop'>QUOTE (ironhorse @ Feb 2 2012, 02:37 PM) <a href="index.php?act=findpost&pid=1898919"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Soylent_Green i love it when you talk dirty. so what exactly would a better algorithm look like?<!--QuoteEnd--></div><!--QuoteEEnd-->

Those sprites with fade blink look subtractive. The wonderful thing about additive and subtractive sprites is that you can draw them in any order you want and you don't have to solve the hard problem of figuring out how to light the sprites in a deferred renderer.

If they are subtractive sprites they are already as cheap to render as they can be and the solution will be some compromise(e.g. use fewer more intense sprites(less fillrate, possibly poorer result), fade sprites out when they are too close to the viewer, or some other hack like that).

Alpha blended sprites in NS2(e.g. lerk spores) are not affected by lighting; they just assume that they are lit by average brightness, white light. This is very cheap to render and sidesteps the problem completely, but it is also very incorrect and lerk spores stick out like a sore thumb much of the time. Even in complete darkness or in red emergency lighting the spores still look like they are lit with pale white lighting.

For alpha blended transparency there is a number of algorithms that produce results of varying computational cost, memory cost, correctness, hardware compatibility(e.g. some depend on DX11 features) and other constraints. I'm not aware of any industry standard, go to method. I just know that it's a mess and understand why it's difficult to do, but I'm hardly in a position to recommend a good solution.