help with alternate rail trail design coding

[jonesQL]

Right now I'm trying to figure out how to make a unique rail trail; I want to have a thin rail beam with a small amount of smoke or fire to surround the rail beam that will evaporate upwards before the rail beam disappears (my railtrail is set to 1500 to mimic the rail reload).

I still cant seem to fully understand the code behind the rail trail, but here is a basic paint picture of what im talking about; the grey dots is smoke or sparks that slowly evaporate upwards while the rail beam is up.

Here are a couple pictures to help ->

My paint skills aren't that great but I think it gets to the point:



Q2 rail trail (I'm looking at the inner part of the rail trail):

www.bluesnews.com/screenshots/q2/quake2-02.jpg

This is the default code I've seen with q3mme:

weapon/rail/trail {
//Color1 gets set before calling
//The beam
size  r_railCoreWidth*0.5
shader railCore
emitter cg_railTrailTime * 0.001 {
colorFade 0
Beam
}
shader railDisc
//color2 is stored in the parent input structure, retrieve it like this
pushparent color2
pop color
if cg_oldrail {
//Do the rail rings
size r_railWidth*0.5
//Rings take their stepsize from the width variable
width r_railSegmentLength
emitter cg_railTrailTime * 0.001 {
colorFade 0.1
Rings
}
// } else {
//Do a spiral around the rail direction
//Get length in t0
t0 dir
normalize dir
//Create a perpendicular vector to the beam
perpendicular dir v0
//Radius around center
scale v0 v0 4
size 1.1
//Set the rotate around angle to start value
t1 rand*360
//Go through length of beam in repeat steps
repeat ( t0 / 5 ) {
rotatearound v0 dir v1 t1
//Slightly increase beyond regular 10 it so they don't all line up
t1 t1 + 20
addScale v1 dir origin loop * t0
add parentOrigin origin origin
emitter 0.8 {
//5 radius + 6
addScale origin v1 origin lerp * 0.8
colorFade 0.7
Sprite
}
}
}
}

[auri]

I cannot help you there man, sorry.

[jonesQL]

wolfcam 7.1 was released and it came with an example of the q2 rail trail. I did some tweaking and I've come pretty close to something I like, lemme know what you guys think:



code used - pastebin.com/6M6u2auD

quick notes:

- there is still an issue with the trail aligning from your head (rather then the weapon).
- I would like to change the color of the particles over time (0 sec = white -> 1 sec = light blue)

[phoenix]

Cool stuff. On my first watch the stuff around the rail beam looks sort of "blobbish". Idk if that's the look you're going for but I was thinking it would look cooler if it were more sparkly ... if that makes any sense heh.

EDIT: The stuff coming off the wall where the rail hits has sort of that sparkly effect I'm talking about. By blobs i mean the rest of the rail beam.

Are you able to come up with a small guide on how to change this stuff? I know shader scripts but I'm looking at the code there and none of it makes sense to me. I'm assuming this will work for q3 as well? Don't have any real interest in QL. I ask because I'm working on a new full custom look for my q3. I know how to do basic skin stuff and adding shader effects to it but when it comes into modifying stuff like rail beams and particle effects I'm lost.

[auri]

I agree on it should look more sparkly.
It looks just like a distorted beam at the moment but I see the effect you are going for. Maybe it should be like this:
The rail core beam just fades out into those particles, that might look good.

[jonesQL]

Thanks for the input.

The particles around the beam and from the impact point are the same, they are just different sizes. I would ideally like to decrease the size and increase the amount of particles around the beam, but I begin getting pretty big FPS drops (in actual combat it gets much worse) due to how CPU demanding they are.

I have some new ideas I plan on trying when I get the time, including the one with making the rail core fading out with the particles. It's just a matter of trial and error.

For tips I used the fxScript.txt file, trying my best to understand the math (I had to find an older version of q3mme, majority of it works that I've tried):

Short Guide on FX Scripting
CaNaBiS Version 0.001

The FX system is built around a set of variables and commands to modify them or use them to start an effect. Scripts get started by the engine with certain variables already set and then the script is given control.
Different events have different startup variables set so keep that in mind.

The different variable type that make up the fx system are:

float variable:
Floating point variables that can store a single number

Valid float variable names are:
size, width, angle -> Used by certain commands
t0, t1, t2, t3 -> temporary values you can use for complex calculations

Vectors:
3 floats grouped together under 1 name used for vector math
You can also access specific float by adding 0, 1, 3 to the vector name

origin, velocity, dir, angles: Used by render commands to output stuff
v0, v1, v2, v3 : Temporarary vectors you can use for calculation and storage

So origin0 will behave like a regular float
Using vectors names in math will result in the length of the vector being used

Special variables:
These can only be modified by special commands
color -> red, green, blue, alpha color
shader -> shader used by some commands
model -> model used by some commands

FX Commands:
There's a whole bunch of command to generate effects, modify variables and spawn entities and do vector math

Float math commands:
Using any float variable name a command starts a float math command
examples:
size 5*size -> Size is now 5*original size
angle 360*rand + size -> angle is now a random value * 360 + size

Vector Math Commands:
Most math command take several inputs and a final storage vector name
Sometimes also followed by additional math value

scale <src> <dst> <math> -> <scr> * <math>
add <src1> <src2> <dst> -> add <src2> to <src2>
addScale <src1> <src2> <dst> <math>-> add <src2> * <math> to <src1>
sub <src1> <src2> <dst> -> substract <src2> from <src>
subScale <src1> <src2> <dst> <math>-> substract <src2> * <math> from <src1>
copy <src> <dst> -> Copy <src>
clear <dst> -> set to 0,0,0
wobble <src> <dst> <math> Randomly move src around within cone of <math> degrees
random <dst> Create a random vector with length 1 in any direction
normalize <src> <dst> Normalize a vector so make it length 1
perpendicular <src> <dst> Create a perpendicular vector to <src>
cross <src1> <src2> <dst> Create the cross product of src1xsrc2


Render Commands:
These will render something on the screen using the current state of the variables
sprite <options> -> view aligned image -> origin, shader, color, size, angle
spark <options> -> view aligned spark -> origin, velocity, shader, color, size, width
quad -> fixed aligned sprite -> origin, dir, shader, color, size, angle
beam -> image stretched between 2 points, origin, shader

FX Math:
Fx scripts can use a fair collection of math functions
They are constructed from a number of options

Math operators:
+, -, *, / -> The regular math operans

Math test operators:
Special group of operators that return 0 or 1 depending on a test
< -> ( 0 < 2 ) returns 1 -> 2 smaller than 0
> -> ( 2 > 0 ) returns 1 -> 2 bigger than 0
! -> ( 2 ! 0 ) returns 1 -> 2 unequeal to 0
= -> ( 2 = 2 ) returns 1 -> 2 equal to 2
& -> ( 2 & 2 ) returns 1 -> 2 && 2
| -> ( 2 | 0 ) return 1 -> 2 || 0

The boolean operations only check for not equal to zero, no boolean algebra

Math numbers:
Just regular numbers like 0.112 22 12412

Math Floats:
floats variables like size, width, origin0

Math Vectors:
Vector variables like origin, velocity which will return the vector length

Math Constants:
These are readonly constants to be used in math routines

time -> Time in seconds since the beginning of a map
loop -> Goes from 0 -> 1 during any kind of repeating action in a script
red, green, blue, alpha -> specific color components value in 0,1
pi -> 3.1414155 something
rand -> random value between 0, 1
crand -> random value between -1, 1
lerp -> Goes from 0 -> 1 during the life of an emitter
life -> Amount of life in seconds that an entity got when it was emitted

Math Functions:
These functions can be nested in a math expression with their own expression
so sin( sin ( 3*pi ) ) would be a valid math expression

sqrt( value ) -> Square root
ceil( value ) -> Round values up to next integer 0.3 -> 1
floor( value ) -> Round values down to next integer 0.3 -> 0
sin( value ) -> regular sinus using degrees
cos( value ) -> regular cosinus using degrees
wave( value ) -> sinus type wave but takes 0-1 to complete compared to 0 - 2pi
clip( value ) -> returns value clipped between 0,1 so <0 becomes 0 and > 1 becomes 1

Math Cvars:
This is a special group, if the fx math parser can't find the variable name
It'll try to see if there's a regular q3 cvar with that name and then it'll use that value
So you can use cg_* values or whatever cvar you want

As far as I know all of this should be possible in q3, it might be slightly different though.

[jonesQL]

Added my 3rd rail trail, a lot more like the q2 rail.



I managed to stumble on a huge performance improvement when using particles (specifically the flareShader). Adding "entityMergable" to the .shader file.

From tr_shader.c

entityMergable, allowing sprite surfaces from multiple entities
// to be merged into one batch. This is a savings for smoke
// puffs and blood, but can't be used for anything where the
// shader calcs (not the surface function) reference the entity color or scroll

I just copied the code required for any particles I'd use and put it in the "wcq3blood.shader" file, added "entityMergable" and it greatly improved my FPS.

I added the code I used in the youtube link.

[emir4nt]

looks pretty sweet. trying to get my own style rail aswell, but I dunno anything about scripting. hopefully it wont be that hard