Particle system help

[suliman]

Hi
Im trying to understand the particle system. I know spark exists, but i thought maybe the inhouse system is good enough for me, however i have these questions:

1. For explosions, flashes etc, i want it to emit for (lets say) 0.02s then stop emitting new particles, but the system to remain until the effect is gone entierly (lets say 3s) and them removes itself. Any built in timers like this?
2. I want it to emit in all directions, not simply towards a single direction. Can this be done?
3. Is there any editor out there that lets me edit and see resulting particle systems in realtime? Found some old that are not available any more.
4. How do I set the update speed of the system? When the game is paused i dont want explosions etc to continue, they should freeze (so choosing to update the particle system or not is good enough, but it seems to be automatic update no matter what i do)

Thanks!
Erik

[polylux]

Hey suliman!

Not too familiar with particle systems, so some parts of my answer are just wild guesses

1. I'd say, just remove the emitter from the particle system after the specified 0.02s, and remove the particle system itself after those 3 secs
2. Use a sphere emitter and set a fitting value for maxAngleDegrees.
3. Should be fairly easy doable yourself
4. Hmmm, no good guess about that as it's updated internally in the scene management. Maybe while paused you can refrain from calling sceneManger->drawAll()?

Cheers,
p.

[suliman]

Thanks!

1. Yeah i will make a holder-class around it to sync stopping of emission and removing of the systems i create (but its wierd its not already in the particle system class)
2. Works! But actually works with pointemitter also, just set maxAngleDegrees to 360. (in an explosion its ok if all particles starts from the center point)
3. Well it will take a lot of time, i think this should exist as all users would find good use from it.
4. I cannot stop drawAll since that will stop all other things to be drawn as well. Has no irrlicht user ever used pause/slowmo/speed up in their game? This is totally needed for the particle system.

5. min/max particlesPerSecond doesnt seem to work properly.
After 100ms i stop the emission. And increasing the particlesPerSeconds (at creation) up to around 500 makes more particles spawn. But after that an increase makes no difference, even if using something like 500 000 for min/max paticlesPerSecond. I need a lot of particles directly like a blast:(
Is there a hardcoded limit? (invisible)

6. It seems each time i create a particle system its getting the texture from disk (you specify the file). Isnt this very slow to do in realtime with loads of effects going on?

[suliman]

Anyone? (question 4,5 and 6)

[CuteAlien]

4. IrrlichtDevice::getTimer(), then stop() that: http://irrlicht.sourceforge.net/docu/cl ... timer.html
5. Don't know about a limit.
6. Textures are cached.

Btw, in case you haven't seen it yet, there is also SPARK: http://irrlicht.sourceforge.net/forum/v ... ilit=SPARK

[suliman]

4. So if I stop start with the timer, particles systems will freeze? (and possible something else?) So slowmo is not possible for particle systems? It would be easier to be able to set the simulation speed of everything (just like you would do with movement, which is easy to do yourself).

5. Well there is one (around 500 per sec) and i dont understand why. The workaround is to create several systems on top of eachother but that seems stupid as it gives more overhead (each system needs to be tracked, timed for stopping and eventual removing).

6. So even if the call points to a file on disk this file is not actually fetched from disk? It seems every time i create a particle system (with the limit in 5 becomes around 13 systems per explosion or other effect) it does actually access the harddrive for the image...

(As stated i know about spark but i want to understand what im doing, at least partially:))

[CuteAlien]

4. Check the link to the timer docu. You can also slow it down. But it does set the speed for everything - not just particles.
5. You are right - there is a limit (16250 new particles per doParticleSystem call). Hardcoded magic number without documentation, I don't know what this is about. Maybe Hybrid knows?
6. All textures in Irrlicht are cached in memory. You haven't posted code which you are using - so I don't know how you set the image. But caching is the default.

[suliman]

4. Cool! Works perfectly
5. Is that once per tick? Becouse that would be much more then enough for me or anyone. My problem is that setting higher than (approx) 500 per second (which is 10 particles created per update at 50 FPS) doesnt increase the emission at all. And 500 per sec is WAY too little for explosions. I use createPointEmitter().

6. I use this line when i create each particle system in realtime (its the only reference to the harddrive). Is that the wrong way to do it?
ps->setMaterialTexture(0, gfx.driver->getTexture("gfx/particle.bmp"));

Thanks for your help!
Erik

[CuteAlien]

5. Ok, I found out 2 more things. First it's the maximum. More than 16250(???) particles are never allowed. I hope Hybrid has an idea about this, because it's just confusing me - I don't know why there would be some arbitrary limit. And then the 500... oh well... I just looked at the point emitter and it only emits one point per call (so completely depending on the framerate - if you get 500 you have a high framerate already I guess). The other emitters look different - so I suspect this is a bug.
6. This should cache the texture in memory on first time you use it.

[suliman]

5. 16250 per system or globally?
Yes, changed to sphereEmitter with zero radius scales up emission rates like it should.
The pointEmitter is effected up to some point around 500 (setting min/max emission to less like 100 or 10 per sec does indeed produce less particles)

7. Is there no way of randomizing the start speed of the particles? All particles seem to must have the same speed (angle can be randomized but not speed it seems?)

[hendu]

Hint: four verts per particle, USHRT_MAX

[CuteAlien]

@hendu: Aaargh - yeah obviously :-) I didn't think about all particles in a node being a single mesh.

5. Per node and Hendu found the reason why (but it's not the problem anyway).

7. Doesn't seem to be a parameter (just in case you're wondering - I don't know really much about this - all I do is just looking at the source & documentation right now).

[suliman]

Thanks for all the help!

8.Do you (or anybody else) understand the maxAngleDegrees? The documentation says nothing. It seems to "describe an arc" of emission from the given, static direction. Which is not always very useful. Is it possible to set an emitter to emit in the xz-plane? (along the ground in all directions but not up/down).

If min/max start speed ("direction") could be given as two vectors, this could be achieved i think, something like:
minDir = (-5,0,-5);
maxDir = (5,0,5);

But i dont think this is possible...

[CuteAlien]

My hint would be - take a quick look at the emitter code itself. If you ignore the serialization stuff it's basically just a single short function (emitt). You can probably see fast what it does: https://sourceforge.net/p/irrlicht/code ... mitter.cpp

[suliman]

There is still some things i dont fully understand:)

Why is the alpha channel of start color (and fading color) ignored? It seems making your particles go from SColor(255,255,255,255) to SColor(0,255,255,255) would fade them out to full transparency. But it does nothing. I try both this still doesnt work:
ps->setMaterialType(video::EMT_TRANSPARENT_ADD_COLOR);
ps->setMaterialType(video::EMT_TRANSPARENT_ALPHA_CHANNEL);

If i use ADD_COLOR i can make them fade by making them go to the color black (alpha channel is still ignored), but what if i want to use non-additive color? (multiply color)

Also, ive seen examples of "trails" like lines or small "comets" leaving the emitter. Is this possible with the built in particle system? (particles sprites seems to not be rotated and follow the direction in which they travel) Just using a comet-style texture obviously produces bad results (it needs to be rotated aligned with its direction even if its a 2d image).