A lot of time has passed since the last feature I implemented, a ragdoll, which I'll have to write a little more about how I restored the charactedr in ragdoll mode to be back in animation state.
I want to talk a bit about particles, which are a key feature in videogames, they are used to represent almost any effect such as simulation natural elements like watter, fire waterfalls, also to emphasize hits in fights with blood or some less gore effect like done in our videogame.
I've seen two main approaches to particle systems, the ones used to try to simulate some natural effect in a realistic way and a more cinematic/fake ones which are the most widely used as the effect is totally controlled.
In our game engine in the master's degree I've used the second approach because this way artists can use all their skills to make the effect exactly the way the want and fine-tweak it as much as they want. This way a particle is made by the combination of n particle systems that are player together, some of them can have a delay. Moreover the particle engine has the ability to detect particle colisions and react physically to it, also react to the presence of the player near to the particle to generate turbulence and also it support collision callbacks which allow spwaning new particles when a event occur, the events supported currently are collision, floor collision which check that the normal of very close to the vector [ 0, 1, 0 ] and also particle dead.
Technically particle systems can have some impact in performance in render time but also in update time as they are used to have a lot of parameters, in our cae, there're a LOT of parameters to let artists to have as fun as possible doing the most exciting effects.
The optimizations made in the engine in the update part was to run every particle system as a separate task, using the C++ library TBB Threading building blocks, tasks are scheduled in as cpu threads as we have in the computer, so this way it is guaranteed that we're taking full advantage of the last hardware we have.
In the render part I've done the next things. First is to have a main buffer to load all particles, instead of having a lot of little buffers around. Second I've added tripple buffer to avoid waitting to render while we're loading new particles to the vertex buffer of waitting to finish rendering previous particles, the third optimizations is to have a single render callback for all particles systems of the same type, so if we have 500 candles to be drawn the engine would just make a single draw call to render the part of the buffer that contains all the 500 particles which is really cool, more more step would be to have a SINGLE draw call for all particles but that would imply some restrictions such as all particles should share the same mesh and could be some problems with uv animations. The last optimization is to use instancing, a single mesh is uploaded and then in a separate stream we upload the particle render data such as world position, rotation, uv animation, color etc..
I've also implemented which I've named "render stages" like pre_dof, post_dof and gui. The pre/post dof stages were needed for particles that could be affected by dof as everything rendered before dof would be affected by this effect. The gui render stage is used to render 2D particles after all 3D has been rendered and also a orthogonal camera is used for this stage.
You can see a bit about how to use the Particle editor I made in the next video:
