More fade / size step options for particles

[Caligari87]

Currently particles can only fadestep and sizestep in one direction, meaning they can only grow or shrink (never both) and only fade in or out (never both). Additionally, stepping can only be linear (added or subtracted).

This unfortunately puts some limitations on some useful cases. For example, a smoke particle pops into existence fully opaque (since fading out over time is more important) looks kinda bad. One way around this is having an actor track which particles it has spawned and "replace" a particle with a new visual when a particle would reach end of life, but this can add considerable overhead.

A useful solution to this could be allowing predefined formulas entry for size/fade stepping, based on the age of the particle. An example pseudocode implementation:

Code: Select all

// Some actor function
{
	FSpawnParticleParams SmokeParticle;
	SmokeParticle.Color1 = "Gray";
	SmokeParticle.Lifetime = 35;
	SmokeParticle.StartAlpha = 0;
	SmokeParticle.Size = 0;
	SmokeParticle.FadeFormula = SPFF_FADEINOUT;
	SmokeParticle.SizeFormula = SPSF_GROWSHRINK;
	Level.SpawnParticle (SmokeParticle);
}

// Engine particle code
{
	if (FadeFormula = SPFF_FADEINOUT) { particle.alpha = sin(age/lifetime); }
	
	if (SizeFormula = SPSF_GROWSHRINK) { particle.size = sin(age/lifetime); }
	else { particle.size += particle.sizestep; } // revert to the regular one if nothing set
}

[Rachael]

While I agree these additions could be really useful, the main consideration for particles is that particle code has to remain extremely simplistic in order to retain its value for being a highly performant rendering-only device. The moment too much complexity gets introduced, they gradually scale to the point of being as slow as using actors, themselves. Another huge consideration is, every PC will handle every addition differently whether these get used or not. Just because the "if"s turn up null does not mean that the "if" statements themselves do not consume precious processor cycles.

I think test cases would have to be made where hundreds of thousands of particles would need to appear on a scene in order to evaluate how impactful these changes would be.

And before you argue "this is only one thing" - don't forget that the paradigm of GZDoom development is once a useful feature gets expanded, it's absolutely a slippery slope with how many more requests are made to expand it even further. (We're up to what, 9 flag fields in actors now? That are all nearly full? And let's not even talk about the actual actor property fields themselves) - Accepting such a feature would unavoidably open the flood gates, even if this particular one turns out to be harmless.

[Caligari87]

Yes, I've been around for a while so I know how the slippery slope of performance vs features works The question is whether the usefulness is enough to justify it, and we won't know until we ask/try right? The point of a feature request is to have that discussion (otherwise we might as well close this subforum).

An alternative to the cost of conditionals/flags might be passing some kind of static formula directly, sort of like how the damage property is handled for projectiles. Something like:

Code: Select all

SmokeParticle.FadeFormula = sin();

I'm curious to know how possible that might be from a technical standpoint, if at all.

----

Additionally, I found this conditional which seems to imply it's not even possible to fade in particles (using negative fadestep), since the particle gets destroyed if the alpha value is above the old alpha value.

Code: Select all

auto oldtrans = particle->alpha;
particle->alpha -= particle->fadestep;
particle->size += particle->sizestep;
if (particle->alpha <= 0 || oldtrans < particle->alpha || --particle->ttl <= 0 || (particle->size <= 0))

Would there be any downside to removing that part of the conditional? I can't imagine it would break any mods, since particles are visually only, and any mod author trying to use a negative fadestep (like me) to this point would have seen that their particles weren't working with it. I do know that particles with an alpha high above 1.0 cause weird visual effects, but the fact that alpha already isn't clamped anyway means that going above 1.0 would just need to be something the author is aware of when spawning particles with certain lifespan/fadestep combinations.

[Rachael]

No no, you're right, it's good to discuss it - and the biggest reason I didn't close this is because there is indeed merit in doing so. If it seemed like I was trying to shut this down, I am not - I was just expressing a huge concern that this feature brings for me.