I use SPE. I have a PR for fixing fog for three 104.
Best one I’ve found by far. It’s too bad squarefeet never pursued getting SPE added to the three examples before he moved on. Some other guy made a far less advanced version and got it merged. Not sure what the criteria was. Oh well, I plan to personally maintain my own SPE build, in order to keep it alive for as long as I can.
I used to use SPE, and squarefeet and I had a go at a complete rewrite with a lot more features. The scope turned out too high and we were quite busy at the time, so the project just kind of got abandoned. Fast forward to about 6 months ago and I sat down to write a good-enough particle engine for my game, since SPE was not cutting it at the time for me, as I had more requirement by that point than what SPE was intended for.
After about a week of prototyping I had the core for my new engine, that I call “particular” and after almost 3 month of refactoring and debugging I had it pretty much finished.
My particle engine does something a bit different from SPE. Where SPE is intended for rendering huge number of particles and having good flexibility over number of emitter and memory usage, my engine largely ignores particle limits, I didn’t need millions, so it was intended to be super flexible and provide very good frame rates with large number of small emitters - that’s really a more typical usecase for games.
The reason I write this is that after having worked with particle engines for a while now - I feel that my priorities of what’s important in an engine have changed a lot. I believe the following are not very important in a particle engine:
huge number of particles
complex simulation model
simulation stability and reproduceability
Instead, I believe the following are more important:
support for large number of emitters (you want to be able to add particles to whatever you see and not have to worry if your FPS will tank just because you added an emitter with 5 particles somewhere)
offer a lot of flexibility in parameterization of particles, both statically and over time
support a good render model, preferably with soft particles, lighting and shadows are a bonus.
Haha, no way, there is simply too much there. I think something way simpler might have a place in three.js. Here’s a glipse at just the Particle System classes themselves, excluding most of the spatial reasoning, math and serialization:
I found three-nebula to be the best. It’s based on Proton and has a lot of configuration options. The importing from JSON was also a huge benefit to my projects.
Downside is that the performance for it isn’t the best, sadly.
@davidpox nebula looks good, I can’t say the same for performance. Most of the examples run below stable 60 FPS on my i9. The timing for my entire game including all the systems is is below 4ms. Probably with more work performance can be improved. Still, looks really good.
At this moment I am experimenting with SPE - z-depth problems can be solved by setting renderOrder higher than the rest of you object, so the particles are rendered last.
I think node-based particle simulation is a really great way to go. Few years back, me and another guy tried to do just that, compiling various “Action” nodes to glsl, but the scope was too much for us to handle at the time. In principle - I believe it’s great, as most particle engines suffer from the same limitation: fixed function simulation pipeline. My engine is fixed function also (mentioned earlier), and fixed function imposes a lot of restrictions on artistic expression.
Restrictions can often help you be really creative, so I wouldn’t always see them negatively. And it looks like your system fulfills your game needs without adding complication, that’s a win in my book. (and your game looks awesome by the way)
And thanks! I think if I had tried to build this a few years ago, I would have struggled too. The javascript toolset has really evolved recently, and I’m not sure I would have gotten far without vuejs/typescript/webpack (and threejs of course).
I’m the three-nebula library author thanks for linking it here! Yes I’m aware of the perf issues and am working on improving these, very much open to suggestions here. I have been working with @manthrax to try and get better perf happening, @Usnul your demo seems to perform really very well.
One thing I’d like to let you know is that I’ll soon be releasing a full GUI for Nebula, you can see a little preview of what that looks like here https://www.youtube.com/watch?v=5HrbhvukSXg
This is basically done I’m just putting the final touches on it now. Will keep you all posted on how it goes.
Hi all, I’ve developed a GPURenderer class for three-nebula you can try it out now in the develop branch, I’ll be releasing this in the next major update to the lib which also includes a life cycle API for users to know when finite particle systems have started, are updating and have ended. I’ll get this stuff into master very soon and cut a proper release. Right now you can try it out by simply adding "three-nebula": "creativelifeform/three-nebula#develop" to your package.json and then running npm install
Right now I would love to get some more feedback on the perf side of things as it’s the main area I’m interested in improving as much as I can.
Hi all in this thread that are following this topic.
I’ve just released Nebula, a fully featured particle system designer for desktop. Nebula uses three-nebula as its engine and allows you to save/load particle systems via JSON.
In addition to this, three-nebula now has its own website and just been updated massively and now features a dynamic texture atlas implementation for sprite based systems rendered with the GPURenderer.