Table of Contents

It’s been one year since the first posts about my particle system: a demo in March and then an introduction in April. Last time I wrote about renderer updates and this was the last planned post for the series. I think most of requirements were achieved and I can be quite happy about the results. Now, it’s time to close the project - or at least - close this version, use the experience and move on!

What have I learnt over that time?

The Series  

The most recent repo: particles/renderer_opt @github

Is this system useful?  

The first question I should ask is if this particle library is actually useful? Is it doing its job?

The answer: I think so! :)

I am aware that my code is not yet production ready, but still, it has quite a good base. It would be possible to extend it, write some kind of an editor on top, or use in a real game (a small game, not AAA! :)

From time to time I try to play with the system and create some new effects. Recently, I’ve experimented with adding trials:

First experiments with adding particle trials. #opengl #programming #graphics pic.twitter.com/Shf4KtFZUt

— Bartlomiej Filipek (@fenbf) March 12, 2015

Trials required work in the internal logic and some updates in the renderer. However, the classes built on top of the core system (updaters and generators) were untouched. Maybe in some time I’ll be able to write more about it…

For a new effect you just have to combine existing pieces (or write new small parts).

Want some rain?

  • use BoxPosGen, BasicColorGen, BasicVelGen, BasicTimeGen generators
  • add EulerUpdater (set good gravity factor), time & color updaters
  • optionally write custom updated that kills particle when it reaches the ground.

Want some stars?

  • use SphereVelGen, BasicColorGen, BasicTimeGen
  • Euler or Attractor Updaters
  • …

This is the flexibility I was aiming for. Currently the number of generators and updaters is limited, but its relatively easy to add more. Then, creating more complicated effects could be even simpler.

Todo: maybe add some triggers system? like when doing explosions?

The renderer is still quite a simple thing. It hasn’t changed much over the time. I figured out that there is not much sense investing time into that when it was obvious the whole system needs to be rewritten to GPU code. On the other hand, if you want to stay just on the CPU side, then updating the current state of the renderer might be quite easy. Probably more texture management stuff needs to be done. Right now you just set a texture and all the particles are drawn using it.

But as a summary: the system mostly do it’s intended job and it’s not that complicated to use and update.

Experience  

The other “requirement” for the system was that I would learn something. And this time it was also achieved.

Tech

  • How to effectively move data computed on CPU into GPU: I even made quite a long post about moving data and the benchmark for it.
    • One nice technique from OpenGL 4.4: Persistent Mapped Buffers (from ARB_buffer_storage). It was eventually used in the renderer.
  • SSE instructions:
    • In the post about code optimizations I, unfortunately, failed to create faster code than my compiler could produce + code used in glm::simdVec4:) That’s OK, we can simply rely on the tools and third party libraries.
  • How to do better benchmarking
    • ”Theory” was described in How to start with Software Optimization
    • You can just run your app and use a stopwatch. But if you have different options, configurations, etc… soon you will need a lot of time to measure everything. Good automation is the key in this process. I’ve created batch scripts, internal code logic that enables me to just start the app and then wait. At the end I’ll have a txt or even nice csv file.
  • Optimization techniques
    • I’ve read a lot of good stuff in The Software Optimization Cookbook and Video Game Optimization books.
    • Still, some of best practices are hard to implement in a real scenario. Or even if you do, you got little improvement.

“Organizational”
Actually it was not easy to publish all those posts. I did not expect to finish everything in two or three months, but still - one year… quite too much! On the other hand, this is my side project, so you cannot make a good estimate in that scenario.

  • Writing code is easy, but writing good description, with teaching purpose… is not.
  • Persistence: without having a clear goal - “write the full series” - I would have probably given up at some point. Just stick to your original plan and it should be fine.
  • Managing git: creating branches for each optimization track or bigger feature… next time I’ll probably know how to do it better :)

What’s Next  

Maybe next project!? Particles are nice, but working on that for too long can be boring :) I have lots of different ideas and maybe next time you will read about them. Then, after some time, I’ll probably return to my particle system and rewrite it (again) :)

Here is a video showing the running system