More flexible Particle Systems ?

[Max Power]

I would like to make a humble request to get more direct access to particle system data, namely the particle array itself. I am syncing Irrlicht particles with PhysX particles and using affectors that are bound to the rendering process is a bit restrictive. I have to read PhysX-particle data inside the affector now, check irr-particle life-time and delete PhysX particles in exactly the same way (order) that the Irrlicht particle system handles particle deletion... I wish the particle system would just take care of the rendering and leave the rest to me (at least optionally), including particle deletion.

Maybe a bit too much, but I'd also like to get direct access to the buffer and work with texture coordinates etc., and not be restricted to the predefined particle/emitter properties. Being able to use different vertex-types, like with other mesh buffers, would be nice too, for custom materials.

Since I am not nearly familiar enough with the engine, open source projects or graphics programming in general, I can only make this suggestion.

[CuteAlien]

I recommend to create your own particlesystemscenenode in this case. Start by copying&renaming CParticleSystemSceneNode.cpp/.h - then you have all the existing features + complete freedom for any modifications in your application.

Making particle deleting more flexible while keeping the speed is not so easy. Particle deletion is one of the few places in the engine where speed really matters (it was less optimal in the past and that had caused noticable lags).

Btw, in case anyone wants to play around testing the current particle system, I've just checked-in some test-app for that a few hours ago (particles.cpp at https://code.google.com/p/irr-playgroun ... e/checkout). But will need newest svn trunk (and might get more changes today unless I fall asleep on my keyboard soon).

[Max Power]

Actually, I did just that some time ago. Since there was no way to derive from any existing Particle System node, I copied the code from the source files, derived from ISceneNode and stripped it of everything I didn't need. I didn't add or change anything, just remove stuff, including the use of emitters/affectors. Everything essential was handled the same. If anything, the result should have been faster, but instead it was a lot slower and I couldn't figure out why. So after a day or two I gave up and went with custom emitters and affectors instead, even though it requires a lot of "working around".

The key to the speed of particle deletion, if I'm not mistaken, is just the switching of deleted/last element inside the array, and deleting the last, no? Seems like the only reasonable thing to do. It's just the way that the loop works, that both simulates (moves) and deletes the particles. In PhysX I can only read or change particle data (needs locking, unlocking) at a given time, so I have to do some minor adjustments when deleting to keep track of where a particle will be after deleting several in one frame. But I don't want to bore you with the details. It's not really a problem. What's worse is that I have to do it all inside the affector onRender and can't read any irr-particle data in my main-simulation loop.

edit: I mean, I could call doParticleSystem() manually before the render, but there's no way I know of to get the particle-data (reading or writing) outside the affector. That's pretty restrictive in my opinion.

[CuteAlien]

Not sure if making the updating/deleting customizable is a good idea as it exposes then a lot of implementation details. When you have to dig so deep into internals a custom scenenode is probably the better idea.

Maybe your node was slower because the engine is compiled in release by default and your project still in debug (just guessing - even best programmers miss sometimes simple stuff...)? Copying the code and using it in your application should be just as fast otherwise.

Is your problem more or less that you have to figure out which particles Irrlicht deleted so you can remove the same ones in your physics engine?

[Max Power]

You're right. I am using debug settings for compiling. I am far from being a professional. I think I am beginning to get good with C++, OOP etc., but there's lots of stuff I know nothing about. Compiler settings are one of these things

Thanks for the hint. I will try it again soon. Luckily I kept the code somewhere.

[Max Power]

Is your problem more or less that you have to figure out which particles Irrlicht deleted so you can remove the same ones in your physics engine?

Not really, it's more of an inconvinience. It's just that I do other things with my particles as well, like applying forces or destroying on impact. I guess all of this is possible, but it would be much easier if I could access the particle data from anywhere within the program.
For deleting a particle on impact, the easiest thing to do would probably be to set the particle-timer to expired, but there's no way I can do that directly. I would have to let the affector know, that particle N is marked for deletion and let it handle it later. I also can't know, which particles are going to expire *before* running the affector, unless I keep an extra array of timers outside the particle system. And if I alt-tabbed out of the running simulation and the rendering has stopped, I have to manually call doParticleSystem() to keep the syncing intact. It's all possible, but it could be easier. Nevermind though, I will try with the custom scene node again. I still think at least some kind of getPosition(index), getVector(index), getTimer(index) functionality, like done with mesh buffers, wouldn't be a bad idea.

[CuteAlien]

You can change the endTime for the SParticle in the affector to enforce deletion (setting it to 0 should always work). Also in your affector you can already check if "now" is > endTime and so you know if the particle will be deleted. You can prevent position updates by setting "vector" to 0,0,0.

If you need a unique identifier that's currently impossible. There is one thing I could maybe do for that: adding a UserData field to SParticle. A UserData field might be usable to keep around a pointer to a physics engine object for example. If that helps you I'll check with other team-members if adding that is fine. UserData is for some reason often not welcome in the engine, but in this case there is no other way to identify a particle, so I think it will be ok. We just have to decide on a type (I guess either size_t or a new Irrlicht typedef which is then size_t).

[Max Power]

Well, I did find a way of creating a 1:1 relationship between PhysX and Irrlicht particles. Deletion works too, although I haven't implemented deletion on impact yet. Like I said, it will all be possible. Only it would be more flexible, if you could read, or maybe even wright particle data outside the affector call.

Basically, I just have to simulate the loop-iteration, where the last element gets simulated next after any element has been erased from the array, even though I am not looping when deleting PhysX-particles (due to the exclusive read/write states), instead I have to remember the indices inside an array for deletion. Inconvinient, but not a big problem.

[CuteAlien]

Note that there is also an alternative particles system called SPARK which works with Irrlicht: http://irrlicht.sourceforge.net/forum/v ... k+particle
I've not worked with SPARK myself yet.
edit: Ow... spark engine links lead to some french website now where I'm not sure if it still has to do anything with spark :-(

But I have worked with the Irrlicht particle system the last 2-3 days for the first time in years - and currently frustrated myself because I find so many (old) problems. Node-rotations disregarded for the particle-movement (but for some reason which I can't figure out it's updated for the SParticle::startVector), particles can't rotate and undocumented #if 0 stuff (I guess someone has started working on allowing non-billboard particles but stopped mid-way and still checked it in for some reason). This whole node looks rather unfinished and is now hard to fix as any changes will break existing user-applications. Can't decide right now if I should spend another day on it and try fixing it (already spend more time on it than I can afford...) or give up myself and use a custom node which does what I need.

[Escen]

SPARK is still alive and works with Irrlicht 1.8
It's hard to find but well made, still supported and has some nice features
https://svn.code.sf.net/p/sparkengine/code/
http://spark.forum0.net/
http://www.youtube.com/watch?v=F1sTQ2oMdSM

[Max Power]

Well, I just put the custom particle system code back into my project, compiled for release and it seems to be just as fast now as the standard irr particle system node... I'm such an amateure
I had thought there were some hidden optimizations for particle system nodes that I just couldn't find.

So I guess I won't be using the standard particles anymore, now that I can have independence of particle-"descriptors", emitters and affectors, and complete control over both particles and mesh buffer, vertex types etc. I was also planning on adding mesh-particles eventually, but mine will probably just be used for small randomly deformed pieces of debris with constant number of vertices & faces per particle. At least that's the plan.

I took a quick look at SPARK, but I prefer having as much direct control over the particles as possible.

[CuteAlien]

@Escen: Thanks. Glad to see that project is still alive!

[Darktib]

Hello there, I'm one of the devs of SPARK, and the project is still alive . The forum is english / french (2 sections), and is the main communication platform. Note that the link in the Irrlicht forum post is dead and points to a french website (about computer science though).

For your problem, what are your needs regarding physX particles ? If it is only for collision, then you should only use one particle system. For example, with SPARK, you can add obstacles to particles or do particle-particle collisions. It will be much faster, as you would not need to copy particles from one system to another.
However, if you want to move objects with particles (ex: throw fast particles on a cube), then you have 2 choices:
- use PhysX particles, and maintain a render buffer for the rendering, and each frame you update this buffer based on the physx particle data.
- (SPARK) use a modifier to copy the system each frame (a modifier act on each particle, enabling you to control particles the way you want). That way you can still have high-level material control.