Even More Particles

I got to work over particles some, finally removing the geometry shader from them, which gives a small but consistently measurable performance boost.  That's interesting, and confirms that using a geometry shader for this kind of drawing adds a certain overhead that is often not worth it - yes, you do save some in certain areas, but you also lose some in others, and you generally don't come out of that tradeoff on a good side.

In order to reduce the vertex submission to one vertex per-particle I've used instancing instead, which works out well.  I'd previously done this with OpenGL, and was interested in comparing OpenGL instancing with D3D11 instancing.  In D3D9 it was quite obviously crudely grafted onto the original Draw APIs but both OpenGL and D3D11 do it in a much nicer and cleaner manner.

It was also a good opportunity to explore some CPU vs GPU tradeoffs - with particles there are certain things that must be calculated for each particle - position updates owing to velocity/gravity/etc and a distance scaling factor to prevent them from disappearing when they get too far away.

On one hand these are much faster to calculate using the GPU (as it's much better at this kind of thing) but the same figures need to be calculated 4 times - once for each vertex.  On the other hand, while the CPU is slower it only needs to calculate them once for each particle.

It came out roughly equal for me, but I'm leaving in the option to switch between the two (via r_gpuparticles), as it may be beneficial for some.  This opens the interesting possibility of looking for other areas where a similar tradeoff can be made and exposing options for those, but that's all future.

The one thing I don't recall mentioning about particles yet is that some time ago I managed to successfully get position/velocity updates completely framerate-independent.  It's quite a small, simple and nice piece of code that's easily portable to other engines, so I might write it up more fully at a later date.