SimpleParticleSystem
Moderator: Moderators
SimpleParticleSystem
... is in projectiles.txt, but causes Spring to fail when called by an explosion script. Too bad... this looks exactly like what we need... a properly-generic particle generator with enough bells and whistles to create just about any FX, with directional controls, vectors, gravity, etc... only it doesn't work yet
-
esteroth12
- Posts: 501
- Joined: 18 May 2006, 21:19
you could improve it by cutting 400 lines and achieving nearly the same effect :\Argh wrote:Well, I was hoping it was done. It's going to improve the Nuke by quite a bit. Ah well
sooo much easier to maintain and resize
and you could probably use smoke2 instead of the heatcloud and it would look nicer, haven't checked myself (you have about 15 sets of smoke to change!)
and whats a CColormap?
It's available for CBitmapMuzzleFlame and CSimpleParticleSystem atm. It specifies two RGBA colours and blends one into the other.
Example: colorMap = 0.2 0.3 0.5 0.01 0.5 0.2 0.3 0.01;
This would blend from RGBA 51,77,128,1% to RGBA 128,77,51,1%
Don't mind the small alpha value, they're needed for alpha blending (the smaller the more blending).
Example: colorMap = 0.2 0.3 0.5 0.01 0.5 0.2 0.3 0.01;
This would blend from RGBA 51,77,128,1% to RGBA 128,77,51,1%
Don't mind the small alpha value, they're needed for alpha blending (the smaller the more blending).
Don't keep yourself limited to 2 colorvalues only. The color maps support any number of colors. First it interpolates the first to the second color, then the second to the third, third to fourth etc. You can make very nifty effects using this.
About the alpha, this is how I explained how it works to Argh a while ago:
About the alpha, this is how I explained how it works to Argh a while ago:
E: and it's available for more stuff btw, dont know out of my head what tho..Tobi wrote: The projectile handler code uses glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA);
In english, this means that the source color (the projectile texture) is not multiplied by any alpha at all, and the destination color (what is below the projectile when it's drawn) is multiplied by (1 - source alpha).
In formula: new color = source color + destination color * (1 - source alpha)
The rationale behind this is that, for drawing nice explosion/flame graphics, you need an additive blender. For e.g. smoke you need a way to darken what is behind the smoke. Now look at how it is defined. As you see, if alpha = 0, the formula reduces to pure additive blending (new color = source color + dest.color). Good for explosions/flares/etc. If alpha = 1, the formula reduces to pure replacement (new color = source color).
Bah, not really useful explanation
Just view the alpha as the "darkening factor". Alpha close to 0 is no darkening of the background, Alpha close to 1 reduces the background to pure black before adding the projectile texture.
To make normal translucency, (new color = source color * source alpha + destination color * (1 - source alpha)) you should pre-multiply the source color by the source alpha (in addition to setting the source alpha channel).
One pitfall to watch out for, is alpha = 0, because also a source alpha > 0 test is enabled. If this condition doesn't hold then the fragment isn't drawn at all. So in practice you want to set e.g. alpha = 0.01 for pure additive blending.
Hope you understand my explanation
"Nearly the same" is not "the same". It's that detailed because I wanted very specific controls and event timing. I didn't say that it was efficient- merely what it needs to be. It is exactly what I wanted it to be. If you can figure out another way that does exactly the same things in exactly the same order, but contains fewer lines, let's see itesteroth12 wrote:you could improve it by cutting 400 lines and achieving nearly the same effect :\
sooo much easier to maintain and resize
and you could probably use smoke2 instead of the heatcloud and it would look nicer, haven't checked myself (you have about 15 sets of smoke to change!)
The SimpleParticleSystem is going to reduce the entire length down to about 8 sets of parameters (or about 120 lines, give or take), and give me the color controls I actually need. The problem with the code previous to SimpleParticleSystem is that it doesn't do what I need it to do and I had to hack around its limitations. Once SimpleParticleSystem is available, I see no reason to use anything else, honestly. Even Smoke is expendable, since I think that the additional code for the wind-drift is less important overall than the other things it allows, and making it wind-drift in a patch should be trivial.
And smoke2 doesn't work like you think it does. Please actually do some experiments before telling me what's easy to maintain
For exhaust we need a particle system thing whatever that stays WITH the model, not getting left behind it. It's just way too performance-intensive to have a realistic looking afterburner effect with particles that have to constantly regenerate IMO. For a decent effect you need a new particle set roughly once every frame. That's particle SET - because without some random positioning and such, it'll look like crap. 3 smoke2 particles 30 times a second with even a short lifetime will reduce performance tremendously.
Also, argh's effect can be as detailed as he wants it and it will STILL use way less particles than the standard nuke explosion, if I remember right.
Anyway... am I correct in understanding that flameprojectile is also working in addition to heatcloud and smoke2? That's great news, I'll see what I can do with my pyro effect. I was told only smoke2 and heatcloud were working.
Really cool to learn that the color map thing can have any number of colors to switch through, like the above poster I was under the impression you could only use two. Maybe add a note of that in the changelog?
Also, argh's effect can be as detailed as he wants it and it will STILL use way less particles than the standard nuke explosion, if I remember right.
Anyway... am I correct in understanding that flameprojectile is also working in addition to heatcloud and smoke2? That's great news, I'll see what I can do with my pyro effect. I was told only smoke2 and heatcloud were working.
Really cool to learn that the color map thing can have any number of colors to switch through, like the above poster I was under the impression you could only use two. Maybe add a note of that in the changelog?
-
esteroth12
- Posts: 501
- Joined: 18 May 2006, 21:19
hey, i know what smoke2 does! as long as you set the glowFalloff high enough, it becomes red (instead of that neonyellow) quickly... although yeah, you would probably still want the heatcloud, now that I think about itArgh wrote:"Nearly the same" is not "the same". It's that detailed because I wanted very specific controls and event timing. I didn't say that it was efficient- merely what it needs to be. It is exactly what I wanted it to be. If you can figure out another way that does exactly the same things in exactly the same order, but contains fewer lines, let's see itesteroth12 wrote:you could improve it by cutting 400 lines and achieving nearly the same effect :\
sooo much easier to maintain and resize
and you could probably use smoke2 instead of the heatcloud and it would look nicer, haven't checked myself (you have about 15 sets of smoke to change!)
The SimpleParticleSystem is going to reduce the entire length down to about 8 sets of parameters (or about 120 lines, give or take), and give me the color controls I actually need. The problem with the code previous to SimpleParticleSystem is that it doesn't do what I need it to do and I had to hack around its limitations. Once SimpleParticleSystem is available, I see no reason to use anything else, honestly. Even Smoke is expendable, since I think that the additional code for the wind-drift is less important overall than the other things it allows, and making it wind-drift in a patch should be trivial.
And smoke2 doesn't work like you think it does. Please actually do some experiments before telling me what's easy to maintain
and I'm talking by "maintain", i mean resize to 1024, 2048, 512, 768, etc.
and yeah, the simpleparticlesystem would probably make this a lot easier on both ends... also... it seems quite similar to your flamethrower patch
e:
I'm not complaining about how it looks, im complaining that its ~550 lines and probably over 40 different styles of explosion to resize if necessary... and you should be worried about that, as its calibrated to a 512 explosion, and your nukes are 1024Caydr wrote:Also, argh's effect can be as detailed as he wants it and it will STILL use way less particles than the standard nuke explosion, if I remember right.
(although its a difference of at most 5 minutes, so... its not that important)I'm sorry, I think my response was a bit too sarcastic. My apologies- it's been a veeeeeery long week, and I'm bone-tired even though I've had plenty of sleep.and I'm talking by "maintain", i mean resize to 1024, 2048, 512, 768, etc.
and yeah, the simpleparticlesystem would probably make this a lot easier on both ends... also... it seems quite similar to your flamethrower patch
At any rate, once SimpleParticleSystem is in place, the nuke (or other uber-fancy stuff) will get a LOT easier to maintain. That's what I was getting at.
I'm quite aware that my script is huge, clumsy, and full of redundancies... redundancies that I just coudn't find clever ways to avoid without losing some of the visual effects we want in a good nuke. The big problem with everything previous to it is that it lacks these veeeery important properties:
emitVector: float3
emitSpread: float3
Even without all of the other kewl things, like airdrag and gravity, this would be super-important.
While I'd rather emitSpread was expressed as <angle> so that we could have conic sections without resorting to using four different generators per event, and ended up with nearly-ideal spheres instead of cubes... I can see why this was preferred for raw speed. Still, this is a massive improvement over the previous stuff all by itself.
With SimpleParticleSystem, though... I can make things that are so much better, with so much less sheer particle spam, that I'm really wanting to play with it- it's pretty much what I asked for, when I started describing all of this stuff, with the exception that particles do not have timer events so that we can delay them X number of ticks (still want that, really bad) and particles cannot spew other particles, which I can live without but would be more efficient than the spam that will take its place (again, I'm thinking way ahead here, towards some of the things I'd like to be able to code).