Irrlicht Engine

Hi folks,

I was doing a little experimentation and ran into the fact that the particle system does not support per-particle rotation. This unfortunately makes smoke and other soft 'billowy' effects look rather patterned. As an example, I used the per pixel lighting demo to do a little experiment in making a decent smoke trail, the default particle system looks as follows:



By adding some code to allow per particle rotations:



All settings are identical except that the particles individually rotate in 2D, yes the settings are all exaggerated to make this easily visible. At the cost of 8 bytes per particle and a bit of overhead when you actually use it, I think it looks considerably better, especially in motion. Anyway, figured I'd see if there was any interest in a patch submission after I clean things up a little bit. It can also be optimized from the quick first pass I did in the last couple hours.

Regards.

Looks interesting, this certainly could be usefull for bigger "full environment" particle systems. So, is it a different particle system or have you just added this on top of the existing particle system? Could we add a randomize particles rotations bool to the existing system?

Actually, this is both an initial random orientation option and a min/max rotation rate assigned in the emitters. So you have a bool which will assign a random 2d rotation about the view vector at point of creation and as it updates it has the option to rotate at a given rate. The manner in which it is implemented means that both abilities are optional and if turned off there is no added overhead in computation beyond a comparison and branch and of course the additional 8 bytes required per particle. I figured it was a quick and simple way to get into the engine, make sure I had my understanding of the coordinate system correct and do something with a fair amount of bang for a couple hours work.

As to the usage, this is generally very useful to simply make even existing items look a bit better. The initial randomized rotation keeps the particles from lining up and making obvious visible patterns as you can see with the streaks in the first image. The animated rotation makes even trail particles look interesting since they maintain at least a little sense of motion. Of course, after poking around, this is about the only addition I would make to the existing system as it's pretty good bang for the buck, anything much more than this and I'd probably start from scratch using a flexible SOA data model so unused items don't take up space in all particle systems and they tend to update considerably faster due to less cache thrashing. But that is just a temptation for when I get further along with my little project.

It would be nice if you could post the patch to: https://sourceforge.net/tracker/?atid=5 ... unc=browse
And then just add a link in this thread to your patch and maybe also the other way round - a link in the patch-tracker to this thread.

Posted it up after cleaning up a bit: https://sourceforge.net/tracker/?func=d ... tid=540678

Huh, and I was sure my animator had different rotations for each particle

hendu wrote:Huh, and I was sure my animator had different rotations for each particle

That'd be tough since the particles were always screen space aligned, the math for anything else wasn't there. Perhaps you are talking about the rotation effector, but that doesn't change the screen orientation of the particles, just positions.

The need for some shared basic structure shows again (sorry for having to init stuff in so many places).

Anyway - I just took a quick (and tired) look, basically I like the idea, just some notes.

1. Do you need randomizeRotation? It seems to be used only for initialization - so I guess we could just say "if ( minRotationRate != 0 || maxRotationRate != 0 )" then we got automatically rotation.

2. Won't "if( particle.rotation!=0.0f )" stop particles from rotating? Not sure how often 0 is hit, but with rand%100 and a long running effect it might make particles stop rotating after a while. Or was that the purpose?

3. I think there is some serialization somewhere (probably also in every class)... that must also be done for new variables.

CuteAlien wrote:The need for some shared basic structure shows again (sorry for having to init stuff in so many places).

Yeah, it is a bit rough and goes against the grain doing copy/paste all over the place for something so simple.

CuteAlien wrote:Anyway - I just took a quick (and tired) look, basically I like the idea, just some notes.

1. Do you need randomizeRotation? It seems to be used only for initialization - so I guess we could just say "if ( minRotationRate != 0 || maxRotationRate != 0 )" then we got automatically rotation.

The intention for that is if you don't actually want animated rotation but do want the randomized orientation when emitted. I considered not bothering but in a couple cases I was experimenting with it was actually what I wanted. I.e. just emit a nice foggy set of slow white particles without rotation, but it looks fairly crappy without the initial randomized rotation.

CuteAlien wrote:2. Won't "if( particle.rotation!=0.0f )" stop particles from rotating? Not sure how often 0 is hit, but with rand%100 and a long running effect it might make particles stop rotating after a while. Or was that the purpose?

Nope, shouldn't have any effect at all. Basically if "rotation==0.0f" it just means that skip the transform modifications, it doesn't have any effect on the animation portion which is in a different location. It works out as an optimization, though I doubt it would ever actually trigger in practice with floats being what they are.

CuteAlien wrote:3. I think there is some serialization somewhere (probably also in every class)... that must also be done for new variables.

Grr, knew there was something I probably missed. I'll go poke around and find that, I'll post a new patch in a while, maybe tomorrow.

Regards.

CuteAlien wrote:The need for some shared basic structure shows again (sorry for having to init stuff in so many places).

Anyway - I just took a quick (and tired) look, basically I like the idea, just some notes.

1. Do you need randomizeRotation? It seems to be used only for initialization - so I guess we could just say "if ( minRotationRate != 0 || maxRotationRate != 0 )" then we got automatically rotation.

2. Won't "if( particle.rotation!=0.0f )" stop particles from rotating? Not sure how often 0 is hit, but with rand%100 and a long running effect it might make particles stop rotating after a while. Or was that the purpose?

3. I think there is some serialization somewhere (probably also in every class)... that must also be done for new variables.

Turned out very easy to fix. But I noticed what looks like a bug waiting to be reported. The Mesh/AnimatedMesh emitters don't contain any serialization code at all. I'll post the patch up in a minute though.