I'd like an FX argument called attachedToObject. Basically, it'd work like this:
Any FX with this argument needs to be generated via COB callouts (1024+1, 2048+1, 4096+1).
When this argument is TRUE, then the originating Piece is the source of the FX objects from the first frame until it terminates. Each frame, the FX needs to re-normalize itself with the Piece's angular rotation, and move to the origin of the Piece.
Obviously, this isn't going to be something we want to use all the time- it's going to be expensive to pass all that stuff around and update it every frame. However, it'd be downright awesome.
Dir, with arguments.
Dir needs to accept some basic arguments. You cannot pass arguments to dir (i.e., no -dir, no, "use X, Y, and dir(Z)"). Just having a -dir argument for vector would make ExplosionGenerators capable of much more realistic behavior.
AnimatedParticleGenerator(Fast, Medium, Slow, Muzzle, GroundFlash)
We still need an animated particle generator that does the same animation setup as the Smoke, but can do more complex behaviors. I'd like to propose that we have three:
1. Fast would basically just be a clone of CHeatCloudProjectile, except it would be able to accept an argument "folder=", in place of the current argument "Texture" that would point to the appropriate animation collection, and run all files in that folder (obviously, within bitmaps, or a relative path from root, whatever) in the order of their filenames.
2. Medium would be a clone of CSimpleParticleSystem.
3. Slow "" CSphereParticleSpawner.
4. Muzzle "" CBitmapMuzzleFlame, accepting "folder" parameters in place of sideTexture/frontTexture.
5. GroundFlash... duh.
The only thing that needs to be done is that in the Resources, we need to be able to define the folders / bitmaps, and have them assignable. The actual code to display the animated frames is actually pretty trivial:
Code: Select all
int frame=textureNum;
float xmod=0.125+(float(int(frame%6)))/16;
float ymod=(int(frame/6))/16.0;
va->AddVertexTC(interPos-pos2,xmod,ymod,col);
va->AddVertexTC(interPos+pos1,xmod+1.0/16,ymod,col);
va->AddVertexTC(interPos+pos2,xmod+1.0/16,ymod+1.0/16,col);
va->AddVertexTC(interPos-pos1,xmod,ymod+1.0/16,col);I think I can write the above into the actual projectiles, make new names, make sure they're in explosion_alias, etc., in a very basic patch. I'm not at all sure about how the names get populated and usable via Resources.tdf, however, and I'd appreciate some help.
Having animated particle generators for these 5 types would pretty much complete Spring's particle system and make it as modern as just about anything else out there, for basic functionality.
windDrift
Basically, all major particle generators should be able to use winddrift. If we had that, and the ability to animate particles, as outlined above, I think we could actually eliminate several existing categories from Spring entirely, because they'd be redundant.
All we need is to change the existing generators so that they have something like this:
if(windDrift=1)
{
pos+=wind.curWind*age*0.05;
}
Which could run after the current lines defining pos for the generators we already have. In fact, the only real differences between HeatCloud and SmokeProjectile have to do with how pos is updated, and the fact that SmokeProjectile can access animations. With an animated HeatCloud that can accept the argument windDrift, we can get rid of both SmokeProjectile and Smokejectile2.
Bounce
Wouldn't it be ultra-kewl, for large explosions, if some particles could bounce off of the ground and Units? I think so :)
Now, I'm not even going to try to claim that this would be fun, or fast code. It won't be either. You won't want to use this unless you really need to crank up the Awesome for a given FX. But just giving particles the ability to interact in a basic way with world objects would be really, really kewl.
To have a proper bounce, particles would need to have two factors:
1. bounceLevel: basically, how much velocity to scrub, per bounce. If set to 0, then the only factor that would eventually halt the projectile would be airDrag or gravity. Realistic objects lose more energy than that, so people should be able to adjust this, even past 1.0 (i.e., it could gain MORE velocity per bounce- which might be interesting)
2. bounceVariance: how much variance, in degrees can the particles have from a "perfect" bounce trajectory? It should always be more than 0, for realism's sake, but obviously it really depends on what you're trying to depict- a cannonball might be pretty close to 0, but a random chunk of rubble should probably be somewhere in the 10-15 degree range (all of those random edges, random compressibility, etc.).
