thor::ParticleSystem not supporting multiple affectors.

[somnambulism_]

I'm working a project that uses SFML, Thor and Artemis, and I've been working Thor's particle system into my design over the last few hours, but I've come up against some unexpected behaviour.

The Thor Particles Tutorial states that In every frame, the particle system invokes each of the attached affectors and lets it modify the particles. However, when I create a simple example with a ColorAnimation affector as well as a FadeAnimation affector, the fading is ignored and only the colour is adjusted.

thor::ParticleSystem system;

emitter.setEmissionRate(1);
emitter.setParticleLifetime(thor::Distributions::uniform(sf::seconds(0.9), sf::seconds(1.1)));
system.addEmitter(emitter);

thor::FadeAnimation fader(0.5, 0,5);
system.addAffector(thor::AnimationAffector(fader));

thor::ColorGradient gradient;
gradient[0.0] = sf::Color::Red;
gradient[1.0] = sf::Color::Blue;
thor::ColorAnimation colorer(gradient);
system.addAffector(thor::AnimationAffector(colorer));

 

Each frame, I call update on the system, and pass it to my sf::RenderWindow to be drawn. I've successfully tested fade and colour individually, they just don't seem to work in conjunction with eachother. Is this a known bug, or am I forgetting to do something / doing something incorrectly?

[Nexus]

The documentation of thor::ParticleSystem::addAffector() states:

Be aware that multiple affectors can interfere with each other. The affectors are applied in the order they were added to the system, therefore affectors at the end may overwrite particle states set by earlier affectors. To completely avoid the issue, only add orthogonal affectors (e.g. one for color, one for acceleration...).

which is exactly your issue

Thus, either change the order of adding the affectors, or make them orthogonal (i.e. write an affector that only modifies R, G, B but not A color components).

[somnambulism_]

Exactly as you said, swapping the order fixed the issue, though I'm not sure what exactly the reason is.  Does the colorAnimation overwrite the alpha value set by the fadeAnimation?

[Nexus]

Yes, exactly.

The color animation basically samples the gradient from 0 to 1, that is, over the lifetime of the affector, a color between red and blue is computed. This color (RGBA) is then assigned to the particle, so what the affector does is basically:

particle.color = gradient.getColor(/* depends on particle lifetime */)

The fade animation however sets the alpha value of the particle, i.e.

particle.color.a = /* depends on particle lifetime */

So if the former affector is applied after the latter, the color's alpha value will be overwritten.

A more robust solution (that doesn't lead to strange bugs if you change the order or introduce new affectors) would be an affector that only sets the color's RGB components. Tell me if you need help writing one, maybe you could have a look at existing ones in Thor.

[somnambulism_]

I think writing my own affectors is definitely an upcoming step, especially considering I'm using artemis to add flexibility, I don't want affectors stepping on each others' toes. I'll check out how the provided ones are implemented and see what I can do from there.

Nexus, thanks for the help. Generally, I really like looking at Thor's source as I'm not incredibly familiar with a lot  of C++11's features.