Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: DaBrain on January 20, 2006, 10:50:26 am
-
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)
-
^All that, but i'd also like to see the ability to make particles (fire) spew from debris chunks.
-
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.
-
It looks simple enough. I'll try and extend something into the scripting system for you guys to play with.
-
Cool. :D :yes:
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?
-
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.
-
Just to be asinine, what's the difference between paletted 8-bit DDS and 8-bit PCX? Compression?
-
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.
-
Build with particle function should be up in a few min. (Barring errors)
-
http://fs2source.warpcore.org/temp/particled.zip
-
Pretend I'm stupid... what does it do?
-
It gives you this function:
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
#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:
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.
-
This is great. Looks a bit complex but I'll give it a try. :)
-
What are the different particle types for?
Especially 'debug'. ;)
-
^read what WMC said, he outlines all of em
-
Ah... sorry... :nervous:
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?
-
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 :p).
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:
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.
-
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.
-
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
ts.createParticle(weapon.Position,somevec,2,10,"bitmap",-1,false,gr.loadTexture("somebitmap"))
-
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?
-
Well (IMO & IIRC) position is just the starting position of the particle and velocity only moves it so its 'sort of relative'.. So do not add the position to the velocity.
-
Do we have to do everything by scripts now? What about making TBP's shadow ships bleed black blood when they're shot instead of those glowing firey bits?
-
and why does lua crash when you try to multiply vectors?
Dunno this one.. i have changed all my vector multiplications into divisions (a * vec == vec / (1 / a) ). Its real pita like the 'plr' issue is from time to time.
Do we have to do everything by scripts now? What about making TBP's shadow ships bleed black blood when they're shot instead of those glowing firey bits?
Scripts are usefull when there is no code support for certain features like animated (2D-bitmap) secondaries or flaks or othersome such things. So we can sort of expand the game a bit in certain areas with scripts.
Making shadow ships bleed black blood isnt that simple (for me atleast)... As i'm not sure that i can get the hit position with 100 % accuracy using current variables and functions. However we can disable the normal spewed particles (firey bits)... Replacing those it not so simple...
http://www.hard-light.net/wiki/index.php/Ships.tbl#.24Impact_Spew:
http://www.hard-light.net/wiki/index.php/Ships.tbl#.24Damage_Spew:
-
i finally realised why my thing didnt work, when i had the particles spawned with a loop i just set their positions relitative to the objects coords (cause it was linked), but now im just using the wepons position and velocity , which are in world coordinates. because its in world coordinates it will no longer accept my fairly 2d coords, while looking right at the same time. the effect would appear correct when you fire it right down the world z axis. but if you durn and fire it in an arbitrary axis it would look whack. so i just need to generate my effect and rotate the coords so that theyre along the axis of motion. i could use a crash corse in 3d vector math. anyone know an online resource, something with code examples. ive looked but most the sites i found werent very helpfull or confused me completely, or had notation that i just couldnt comprehend.
-
create a vector that defines the rotation and then use weapon.Orientation:unrotateVector(vector)
-
hey thanks that works now. still needs some tweaking. throwing out a particle every frame still doesnt make enough of them for the ffect to look good. gotta use smaller particles, more of them, and more than a few per frame.
-
ok this is crude, but cool. its for my mod but i tweaked it to work with a maxim. use the attached jpeg texture, because the game doiesnt have one that looks good with the effect.
#Global Hooks
$GameInit:
[
hypacstex = gr.loadTexture("hypacs")
nullvec = ma.newVector(0,0,0)
]
$Simulation:
[
ft = ba.getFrametime()
for i=1, mn.getNumWeapons() do
weapon = mn.getWeaponByIndex(i)
local name = weapon.Class.Name
if name == "Maxim" then
for i=1, 20 do
local vel = weapon.Orientation:unrotateVector(ma.newVector(math.sin(i*18*0.01745)*0.5,math.cos(i*18*0.01745)*0.5,100))
local zadd = weapon.Orientation:unrotateVector(ma.newVector(0,0,i*1.6-1))
ts.createParticle(weapon.Position+zadd,vel,2,0.4,"Bitmap",-1,false,hypacstex)
end
end
end
]
#End
anyway its a crude rip of the q2 railgun effect. its slow and not quite smooth. what i want to know is if the effect can done in c code (better than mine of course). it could fairly easily be added as an option for particle spew as it can run on the same basic parameters. maybe add a new $type: paramater as an option to the existing particle spew where you can specify string valuse for optional effects, like this spiral and maybe others as well. it could use the same $count: $time: $velocity: $radius: $life: and $bitmap: parameters. $scale, which usually determines the scatter of particles, could designate the radius of the spiral. perhaps other special paramaters, such as $helix length: could designate how long a full 360 is. plus it could set the groundwork for additional pspew types.
*edit* added my texture cause the maxim one makes my effect suck. btw why cant we attach dds files?
[attachment deleted by admin]
-
Hey...
for i=1, mn.getNumWeapons() do
...
for i=1, 20 do
...
Are you sure that works (as it should, that is)? I would swap the second i to j or something.. I had troubles earlier with a bit similar script
-
i assumed that variables defined on a for or function line are considered local. and it would apear so in this case, as the effect looks the same whether i replace all the is in the second for with js or not. i like the effect, but it doesnt look dence enough without running a loop every frame to create a few particles, of course then you get that stuttering you see if you use the effect at anything other than 60 fps (and it will slice it in half with use). the q2 railgun just ran a single loop to generate all the particles in one pass, as it was pretty much an insti hit weapon. my script actually spawns a helix segment at each frame, and im still trying to figure out how to properly scale it to match the space covered by the weapon during the frame (wepon speed * ba.frametime()) unfortunately all i managed to do is get the effect to look even more whack. even if they are scaled correctly im defining there velocity not their position so the segments seldom lign up. but no mater what i do it causes anything from a minor stutter to a complete slowdows. i cant make the effect playable wi6thout severly sucking the life out of the game. i think if the code was handeled in c, it could be done without severely crippling the performance.