Feature request: Add particle system about magnum HOT 5 CLOSED

(sorry for very late reply, I'm insanely busy right now)

Yup, I planned particle system feature since the beginning, but last time I thought about it was 2010 with vastly different requirements and hardware capabilities :)

In my opinion it is now reasonable to handle all computations on GPU only (most probably using compute shaders, which are available since GL 4.3 and GLES 3.1, although some fallback using transform feedback etc. for older HW might be feasible too) and one-batch rendering without CPU roundtrip.

List of things which would be required for the computations, from the top of my head (I'm no expert here), most of it implemented directly on the GPU:

• basic physics (gravity, force fields)
• point/sphere-based particles should be enough (storing only position and linear velocity for each, i.e. no rotation)
• collision detection with some limited domain area (point/sphere vs. other shapes might be enough for initial implementation), I don't know yet how to do this efficiently
• collision response (particle dies or gets bounced in some other direction, again no rotation/torque handling)
• emitter objects (uniform distribution over given mesh)
• good and fast randomization
• supplying also particle time to the renderer for time-based effects

Also, to stay with engine philosophy, the particle system should be available for both 2D and 3D.

The rendering itself should be preferably done with something like MultiDrawIndirect (with some fallback to pure instancing for older HW), if we limit it to points only, it might be doable also with classic point mesh and vertex buffer which would be updated each frame. Rendering features which I can think of right now:

• textured particles
• size, color and texture changes based on age or velocity (or maybe also per-particle based on some unique ID)
• maybe also motion blur in movement direction
• glow and other effects

As I already said, I'm no expert in this and I need to do further research :)

from magnum.

That's not an issue. I'm also rather busy these days.

I think compatibility shouldn't be limited to opengl 4.3 since Mesa and Android don't support that yet. As such we also need to concern ourselves with backwards compatibility at the cost of performance. For instance, my Intel card wouldn't be able to execute your proposed solution.

In fact, we could probably start with the basics, right? Doesn't have to be feature complete for now as long as the technical base is sound. I think a rather simple linear emitter without manipulators or complex physics will do fine for now.

Perhaps a bunch of issues for the subtasks for the specific features that you suggested as well as a bunch a basic features would be a good start?

What do you think?

from magnum.

Mesa guys are already working on compute shaders, but I'm not sure about hardware support. The Windows drivers seem to support them only on Haswell and not on Ivy Bridge. Is it hardware limitation or just driver laziness? All mobile hardware that already supports both OpenGL ES 3.0 and OpenCL should in theory be able to support ES 3.1 and thus also compute shaders. On the other hand ES 3.1 specification was released only in March so it will take some time until the vendors catch up.

In all cases I'd like to design the API in a way that doesn't require sending physics computation results from GPU to CPU and then back to GPU for rendering, because avoiding the roundtrip is surely the way forward. I had to do a redesign of texture binding API recently to make it future-proof for bindless textures and I'd like to avoid similar design mistakes here. Surely the backwards-compatible solution will require the roundtrip (and, compared to pure compute shaders, it will be much more complex), but that doesn't mean the API needs to be designed around these limitations.

The backward-compatible implementation could be probably done using transform feedback (not done yet, see #53) which I think is already supported on majority of hardware.

I hope I'm not too far from reality here and I really need to dig into this deeper until I can tell what is required and how it can be done :)

from magnum.

Various possibly useful links:

• http://gamedev.stackexchange.com/questions/33670/what-features-do-basic-particle-engines-have
• http://twvideo01.ubm-us.net/o1/vault/GDC2014/Presentations/Gareth_Thomas_Compute-based_GPU_Particle.pdf

from magnum.

Hmmmmm. This issue is ... dusty 😆

Would be probably best to have as an example first, then possibly extracting reusable material out of there or turning it into a library. The main processing "engine" for such a system would be some highly-data-oriented ECS system Maybe as an example at some point. Moving to #102.

from magnum.