Comments (5)
(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.
Related Issues (20)
- few compile warnings HOT 1
- How to point to a local installation of `corrade` without using the bootstrap project? HOT 3
- undefined symbol: flextGLInit HOT 4
- Image rendered in gray since 1847c72 HOT 18
- Emscripten 3.1.21+ crashes EmscriptenApplication: "AsciiToString is not defined" HOT 4
- How to build from source on MSYS2 MINGW64? HOT 1
- keyReleaseEvent not triggered after printscreen on OSX HOT 6
- Conversion from CubicHermite to Bezier is wrong
- Mixing with raw openGL calls and Context::current().resetState() HOT 3
- C Bindings HOT 5
- WebGPU backend HOT 2
- Parallel rendering with glb files HOT 5
- Conflict with near and far Macros When Including WinSock2.h After Matrix4.h HOT 2
- emsdk compile error: typedef redefinition with different types HOT 4
- Memory leak when destroying GL::Mesh HOT 3
- Linking in Emscripten >= 3.1.52 doesn't work HOT 4
- Some trouble with LineGL3D shader when camera is close HOT 1
- Segmentation fault with nullptr instruction in AbstractShaderProgram at Cross-Compile HOT 21
- Apply MAGNUM_BUILD_STATIC_UNIQUE_GLOBALS for the flextGL globals as well HOT 4
- EmscriptenApplication keyboard handler doesn't send key event corresponding to text input events HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from magnum.