API and bugs

[Usnul]

So I really like the idea of putting GPU to work on those particles, so I love what this project is trying to do. That being said, I'm having mixed feelings about it's usability for anything semi-realistic in terms of use-cases. I'm writing a wrapper around this library for my purposes, and I couldn't figure out why an emitter i add to the group doesn't show up - looking into the code it's obvious now why, because the vertex buffer is modified, but threejs isn't going to find out about it, instead you have to re-generate the geometry, even then you need to set update flags. In short - just pushing vertices to the geometry in Group implementation only works until you actually pass the mesh to scene, once THREEjs gets hold of it and does it's chunky chunky magic - adding emitters to the group is about as useful as writing code in unary. Next up is the API itself, what you would want ideally is a piece of logic that removes need for "group" all together, because a "group" is something to allow texture re-use, we can create an abstraction which will keep "groups" itnernally, but it will create/destroy them on the fly, as emitters get added/removed. Just by looking at "texture" attribute of an emitter, you could assign it dynamically to one group or another if you wanted that texture re-use. Having an API which would handle the inherent dynamic behaviour that comes with use of particle systems would make it potent and useful, as it stands though - the API is arbitrarily convoluted and doesn't even do what it should. My frustration is with the API, I still respect all the work that went into this project, but as it stands - i don't really see a way forward for this code-based, without major overhaul. The only supported usecase here is pre-defined emitter pools. If your setup is not static - this library doesn't assist you directly. One can probably get around that by just spawning groups for every new emitter, but this defeats the whole idea behind them and is a workaround for what API should support via addEmitter at least.

[Usnul]

More specifically, to make this entry into a more constructive one - my use-case relies on following properties:

• particle count doesn't change often at all, so fixed number of particles is fine
• emitters are created/destroyed often
• emitters change position parameter often
• number of emitters is not fixed, at any given time there can be several hundred emitter or none at all
• emitter has 2-stage destruction, first is stops emitting anymore particles, and later once all existing particles die - it is finally removed.

I have emulated this behaviour on top of this library, but it's a very poor fit because:

• emitters are expensive to create currently as their cost is a hard O(n) in CPU space where n is particle count
• emitters are expensive to destroy as this kicks GC in the stomach, figuratively speaking - it's a garbage overhead proportional to particle count.
• emitters don't have support for destruction (looking in Group implementation this is quite prominent)

I would suggest a test-case with multiple emitters with reasonably large particle counts are beings created/destroyed.

[cihadturhan]

• emitter has 2-stage destruction, first is stops emitting anymore particles, and later once all existing particles die - it is finally removed.

This is already a problem if particles are static i.e. they won't die. Think of a galaxy which you used static emitters to produce groups of stars. If you want to remove stars, it won't possible.

[Usnul]

I guess it depends on how much granularity you want in your control, if you don't care about "which" stars you are removing - "live" property to some degree allows what you are referring to. Although it is quite infrequent that particle engines are used for persistent simulations, when you need something like that - you usually use a dedicated physics engine because you care about accuracy of simulation and if you don't - you would probably use a looped simulation and compress particles into sprite textures to save on resource usage. Common usages for particles are:

fire
snow/rain
smoke
steam
clouds
sparks

it's true that there are many more, but without support for these - it's hard to manage.

[squarefeet]

Hey guys,

Just a quick message to say that I'm still here (!) and haven't abandoned
this project. Been through a rather tough time lately so have been taking a
bit of a break from most things. I'll be hopping back on board within the
next few days, though, so I'll get around to catching up on all the
issues/bugs/improvements.

As a quick thought: I might start planning this from the ground-up again...
@Usnul, you brought up some really rather fundamental problems with this
library that I only think a rewrite would solve ;) If either you or
@cihadturhan want to be more involved in this planning and/or rewrite, then
let me know and we can see if we can schedule a real-time chat to run over
it.

On 27 May 2014 12:28, Usnul [email protected] wrote:

I guess it depends on how much granularity you want in your control, if
you don't care about "which" stars you are removing - "live" property to
some degree allows what you are referring to. Although it is quite
infrequent that particle engines are used for persistent simulations, when
you need something like that - you usually use a dedicated physics engine
because you care about accuracy of simulation and if you don't - you would
probably use a looped simulation and compress particles into sprite
textures to save on resource usage. Common usages for particles are:

fire
snow/rain
smoke
steam
clouds
sparks

it's true that there are many more, but without support for these - it's
hard to manage.

—
Reply to this email directly or view it on GitHub
#48 (comment)
.

[Usnul]

I could join a chat at some point, but i'm in UTC +5:30 for the next 3 weeks. I doubt I could do much of implementation, but I can help with design. I think the idea is really good and this has the potential of becoming the base-line particle engine for WebGL.

[cihadturhan]

Sorry, I'm late to the party. Currently, I've been busy with applying the master programs related game tech. I'm in EEST (GMT+2:00) but I guess we can find a suitable time anyway. Below, I've prepared a meeting time table, so choose a time interval best suits for you.

link

@Usnul I choose a random city for you around UTC +5:00, so please correct the link and post it here

[squarefeet]

I'm not sure what happened to my previous comment, but I'll try to recreate it:

I've been super-busy over the past few days and will be for a while so I doubt I'll be able to do a real-time chat after all, which sucks. In lieu of that, though, I've started a suggestions thread for the rewrite over in issue #50.

Just to say that I'm not expecting anything from either of you guys, but anything that you could help with would be fantastic, even if it's just a little suggestion on the thread. I'll be updating #50 with API structure ideas, bits of code, and stuff like that as and when I can. I'm making more time to spend on this in the next few weeks so it won't be inactive for long periods of time.

Thanks for your comments and ideas so far :)