Instead of creating and animating particles on the CPU, I'm using a set of 3 texture buffers that I rotate around in the fashion not dissimilar to the way triple buffering works. Each pixel in these buffers represent a single particle or to be more precise its location in world space and a life counter. I don't need to store the velocity of particles as I always have the position of them in the last two frames. With some shader magic and a few extra textures as input I can do all the physic simulation needed to animate the particles in the fragment shader - and it's a pretty simple fragment shader (computation wise).
For this particular project I will need about 40 000 particles at most, because I don't want too many flashing, disorienting fountains of colour all over the place as in some other game, and the particles will only be used for fire effects and some other generic magic spells. I can squeeze all the particles I need into a 256x256 texture (well textures and most of them 16 or 32 bit float) and still have over 25k particles to spare.
If at some point ovedraw will be a problem I can render the particles to a half size buffer before composing them with the rest of the scene (and that's the default for lower graphic settings).
Because I'm using deferred shading it would be a sin not to render the particles as soft particles, I got the depth buffer anyway... but there is also a downside. The original implementation of the particle system was made to render some of the particles using additive blending and some using alpha testing, but since I'm composing the particles and the rest of the scene at different times it's kind of hard to use both additive and alpha blend ... so I got rid of the alpha testing and just add all of them in the same way. I won't be able to render black smoke or blood splatters but I didn't want them anyway.
Making all the textures and emitter properties will most likely take me a week or two, so have a early proof of concept render of some fire:
No comments:
Post a Comment