Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: Add particle system #50

Closed
svenstaro opened this issue Apr 22, 2014 · 5 comments
Closed

Feature request: Add particle system #50

svenstaro opened this issue Apr 22, 2014 · 5 comments
Labels

Comments

@svenstaro
Copy link

I think every decent graphics engine should have a flexible particle system. I request one of those in magnum. :)

@mosra mosra added the feature label Apr 22, 2014
@mosra
Copy link
Owner

mosra commented May 3, 2014

(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 :)

@svenstaro
Copy link
Author

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?

@mosra
Copy link
Owner

mosra commented May 4, 2014

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 :)

@mosra mosra removed the feature label Sep 26, 2018
@mosra mosra mentioned this issue Jul 5, 2019
33 tasks
@mosra
Copy link
Owner

mosra commented Jul 5, 2019

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.

@mosra mosra closed this as completed Jul 5, 2019
@mosra mosra added scrapped and removed help wanted labels Jul 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants