[DaBrain]

I hope I'm not requesting too much, but I think these two things will have a big effect.


First: Random impact effects. Did you watch Omniscaper's new BSG preview? (http://www.game-warden.com/forum/showthread.php?t=1509)

While it works pretty well for laser impacts, having only one effect for explosive impacts looks cheap. I think allowing random sets of impact effects would help BSG and many other mods too.

Second: I know there already is an 'debris' feature, but I want to extend that. I'd like to add big debris chunks to the explosions and some special impact effects, which move away spherical from the blast.

I'd also love to see particle trail support for the explosions and some impact effects. - Fire trails that move away from the blast spherical. (ParticleSmoke01)

[FireCrack]

^All that, but i'd also like to see the ability to make particles (fire) spew from debris chunks.

[Fineus]

Is there any way to refine the particle system we currently have?

I'm being picky... and I've not tried to tweak anything myself yet... but I'd rather see short but detailed particle spews than a big bright obscuring and undetailed spew.

[WMCoolmon]

It looks simple enough. I'll try and extend something into the scripting system for you guys to play with.

[Grug]

Cool.

BTW as a sidenote, when using dds files for weapon effects, does the FS engine use mipmaps?
What's the best count of mipmaps to have?
I've been putting 4, so primary one and 3 smaller ones.

Also, does it matter what format the dds are in?
dds 8:8:8 RGB (no alpha) keeps the detail and is only 128kb (inc the mipmaps desc above). [Size: 256x128 pixels]
Is this okay?

[taylor]

Yes it will use mipmaps (newer builds do fully, older ones do partially).  The best count is up to you but generally I'd say to try and get down to something like 16x16 (or that general size if not square).  Of course going all the way to 1x1 would add almost no size at that point anyway.

Currently supported DDS formats:
DXT1a   (compressed)    (1-bit alpha, I generally say skip this and go with DXT3 or DXT5 if you need alpha)
DXT1c   (compressed)    (24-bit, no alpha, what you should try to use for most images)
DXT3   (compressed)    (4-bit alpha, not good for alpha gradients, has pretty much the same image quality as DXT1)
DXT5   (compressed)    (32-bit, 8-bit alpha, image quality from compression could be worse than DXT1/DXT3)
uncompressed 1555   (16-bit, 1-bit being alpha)
uncompressed 8888   (32-bit, 8-bit alpha)
uncompressed 888   (24-bit, no alpha)

... and soon ...
paletted 8-bit      (256 colors)
cube/volume maps   (for pre-generated envmaps, this is already supported by the DDS loader but not the texture code, yet)

All of the above formats offer full mipmaps in the same file (except for cube/volume maps which can't have mipmap levels).  DXT1a offers a 6:1 compression ratio, DXT1c offers a 8:1 compression ratio, DXT3 and DXT5 offer a 4:1 compression ratio.  So basically, if you don't need an alpha channel, just use DXT1c.

Edited: for a little clarity and extra info.

[StratComm]

Just to be asinine, what's the difference between paletted 8-bit DDS and 8-bit PCX?  Compression?

[taylor]

Just to be asinine, what's the difference between paletted 8-bit DDS and 8-bit PCX?  Compression?

Pretty much nothing.  It's just that the DDS file is already in a basically usable format by the video card (since DDS is basically just a video surface dumped to a file with a header on it).  8-bit DDS would be usable by almost nothing (a DXT1 image would have more colors and use less memory) but it could be a useful option for things like heightmaps or something like that which only need to be a greyscale image and would suffer greatly from compression.

[WMCoolmon]

Build with particle function should be up in a few min. (Barring errors)

[WMCoolmon]

http://fs2source.warpcore.org/temp/particled.zip

[Fineus]

Pretend I'm stupid... what does it do?

[WMCoolmon]

It gives you this function:

Code: [Select]

createParticle(vector Position, vector Velocity, number Lifetime, number Radius, string Type, [number Tracer length=-1, boolean Reverse=false, texture Texture=Nil, object Attached Object=Nil])
    Creates a particle. Types are 'Debug', 'Bitmap', 'Fire', 'Smoke', 'Smoke2', and 'Persistent Bitmap'.Reverse reverse animation, if one is specifiedAttached object specifies object that Position will be (and always be) relative to.
    Return values: None
So you can create a particle. Uh, my test code was something like this:
scripting.tbl

Code: [Select]

#Global Hooks
$HUD: [
  ts.createParticle(ma.newVector(0, 0, 0), ma.newVector(0, 0, 30), 2000, 5, "Debug")
]
#End
Which will create 1 particle every frame, at position (0, 0, 0) (That being in (x, y, z)), with a velocity of forward at 30 m/s, will last for 2000 seconds, will be 5 meters wide, and the "Debug" type is basically a red dot particle. Texture is used with the two 'bitmap' types, and it seems that the particle will display either an image or an animation. The 'fire' and 'smoke' types just seem to be hardcoded versions of the bitmap functions, that allow them to be batched and then rendered in one big group.

There's also a particle emitter thingy, but all that does is spit out a bunch of randomized particles of the same type, given a bunch of parameters. It would've been such an atrociously large function that I didn't put it in.

Still if you're curious, here's the list of values for the particle emitter. It's used for things like flak:

Code: [Select]

int num_low; // Lowest number of particles to create
int num_high; // Highest number of particles to create
vec3d pos; // Where the particles emit from
vec3d vel; // Initial velocity of all the particles
float min_life; // How long the particles live
float max_life; // How long the particles live
vec3d normal; // What normal the particle emit arond
float normal_variance; // How close they stick to that normal 0=good, 1=360 degree
float min_vel; // How fast the slowest particle can move
float max_vel; // How fast the fastest particle can move
float min_rad; // Min radius
float max_rad; // Max radius

Mostly the function is there to play around with to see if you can do anything interesting with it, I'm not sure if I want to put stuff like particles and models under the "Graphics" library, or under a separate "3D Graphics" library.

Dunno if that's what you meant, all this is sort of a level above anything else in scripting right now.

[DaBrain]

This is great.  Looks a bit complex but I'll give it a try.

[DaBrain]

What are the different particle types for?

Especially 'debug'.

[FireCrack]

^read what WMC said, he outlines all of em

[DaBrain]

Ah... sorry... 


Using the 'Bitmap' type, how can I define the name of the bitmap?

And how can I define what my new spew is used for?

[WMCoolmon]

It's not a spew, it'll just make a single particle. To make a spew, you'll have to use a series of random number generators (unless you just want a long line of particles ).

You'll need to get a texture-handle for the bitmap particle. gr.loadTexture() should do this. Then you just stick the variable into the function like:

Code: [Select]

if not tex then
tex = gr.loadTexture("myparticle")
end
ts.createParticle(..., tex, ...)
Replacing the "..."s with the other things like position, velocity, etc.

It won't actually be used for anything, the function itself will make a single particle that will move from position at a velocity of velocity for lifetime seconds. So you'd need a hook into the function that usually does the ship particle spew for that, though this is something that should really behandled by a set of variables rather than a full script each frame.

Note that once you call loadTexture(), the texture should stay in memory until you call the :unload() function. ("tex:unload()"). Taylor probably knows what will happen with it better than I do; it's basically a 'safe' abstraction of fs2_open's "bm_load" function. For larger images, you should try and unload them once they're done with.

[Nuke]

im working on a weapon effect and im having trouble getting my particle to display for longer than a single frame. i want the weapon to throw off a particle every frame. vie set my life to 10, attached it to the weapon object, i set the initial position to 0'0'0 and ive given the particle a motion vector. however the particle seems to only last one frame. im thinking that its trying to treat my texture as an animation and only showing the first frame.

[Wanderer]

I saw your script..

Did you try not attaching the particle to the weapon effect and giving instead it just a similar position vector as the weapon has?

Like

Code: [Select]

ts.createParticle(weapon.Position,somevec,2,10,"bitmap",-1,false,gr.loadTexture("somebitmap"))

[Nuke]

good idea, il try than. and it works if i could get my velocity right. is the velocity always relative to position or should i have to add it to the position? and why does lua crash when you try to multiply vectors?