Gosh I hardly know where to begin - Sabrina needs better smoke, and by golly she came to the right place - my web site.

I think I hear the FBI knocking down my door already.

Ok so straight to the meat of it - your implementation as it stands doesn't include the complexity of the original implementation - which was written in (omigod) Pascal. Although you have a good start, you need some addtional components to make, ahem, better smoke.

Here is the original update function for each particle:

Note that anything past // characters are comments...

procedure Particle.reset;
begin
F := 0;
PreDelay := random(100);
SubFrame := 0;
X := (Random(1000)-500)/10000;
Y := (Random(1000)-500)/10000+1;
Z := (Random(1000)-500)/10000;
//RiseRate := (Random(250+round(MaxVel))+20)/4000;
Vx := (Random(round(250+MaxVel))-(175+MaxVel/2))/100000;
Vz := (Random(round(250+MaxVel))-(175+MaxVel/2))/100000;
Vy := (Random(250)+45+MaxVel)/40000;
Al := (Random(100))/100*Alp;
Rate := (Random(200)+10)/5000;
RiseRate := ((Random(200)/5000)+Rate*2)/3;
Size := Random(2000)/1600;
Frame := 0;
NextFrame := 1;
Col := ((Random * 20)+80)/100;
Dec(UsedP);
Used := false;
end;



Procedure Particle.Tick;
begin
if F < Al Then F := F + 0.001*T;
X := X + Vx*T;
Y := Y + Vy*T;
Z := Z + Vz*T;
Vx := Vx *(0.997-(0.001*T));//+Sin(ElapsedTime/9000*Random)*0.0002-Random*Sin(ElapsedTime/5000)*0.0001;
Vy := Vy *(0.997-(0.001*T));//+Sin(ElapsedTime/10000*Random)*0.0002-Random*Sin(ElapsedTime/4000)*0.0001;
Vz := Vz *(0.997-(0.001*T));//+Sin(ElapsedTime/8000*Random)*0.0002-Random*Sin(ElapsedTime/6000)*0.0001;
//R := (R+(Random(1000))/50)/2;
Vy := Vy + RiseRate/900*T;

if RiseRate > 0.00 then
RiseRate := RiseRate-(VY*0.01*T*(1-RiseRate));
if RiseRate < 0 then RiseRate := RiseRate + 0.01;

SubFrame := SubFrame+ Rate*T;
Size := Size+0.01*((1-Rate)*0.07)*T;
if SubFrame >= 1 then
begin
inc(Frame);
NextFrame := Frame+1;
if Frame >= maxframes-1 then begin Frame := MaxFrames; {Size := 1;} reset; end;
if NextFrame > maxframes then begin NextFrame := 0; {Size := 1;} end;
SubFrame := Subframe-1;
end;
end;

Here's some comments I have about what the original programmer did that you haven't done (yet):

1. Used an actual elapsed time component instead of incrementing the movement based on loop count
   
2. Added some clamps to make sure the random components didn't make smoke particles sink to the ground
   
3. Added some random components to the original data, such as velocity, position, rise rate, and size
   [/list=1]
   
   But, basically you've got it - just add some random components to the mix and you should have some great smoke any time you want it.
   
   Now - knowing what I know about the people that read these posts, I'll be completely amazed if this thread stays on topic.

The one thing i never understood about particle physics in games is why doesnt it kill your frame rate? You are doing complex math on a large number of objects that has to recur on every loop. What keeps this from taking all your processor time?

Well - patricles CAN kill your framerate - just like everything else.

Particles aren't usually physically present, and they tend to share many of the same attributes (such as orientation, texture, etc.). This attribute sharing means you can simplify the systems that process their behavior - in a way they are treated as a single, complex object rather than multitudes of generic objects.

Trust me i'm not 3d expert i cant even get a stupid UI to show up on my screen yet without the resourcemanager blowing up in my face or something...

Used an actual elapsed time component instead of incrementing the movement based on loop count

When i read this it made me think about the fTime and fElapsedTime which are passed into your Render callback function. I could be wrong.

and as far as

p = vt + 1/2at2

position, velocity, rise rate

theres your position, velocity and acceleration (rise rate). Also you now have the newly added component of time to help you compute it.

Oh - one more thing!

Put all of these crazy hardcoded numbers in a text file, and be able to re-read them and alter your simulation by pressing the space bar or something.

Particles are a tweakfest - and the best way to dial them in is to make your parameters data driven. If you don't have to compile each time you change something, you'll get a lot more work done!

Well i downloaded it yesterday but since then its been removed i dont remember exactly how it looked but i'll give you my opinion from what i can remember.

First thing that comes to mind is that its very predictable. It seems to me like its got a loop it runs through or something. I noticed that every 15-20 seconds or something it would flair up and make a cute little smoke puff, which i might add is a nice feature. However, i shouldnt be able to notice a pattern like that.

If you eventually want to add a flame beneath the smoke is it set up where the smoke will go with the flow of the tips of the flame. Or is it still going to be a column of smoke comming from the base of the flame. If not, then you need to think of a way to make your smoke where its base doesnt have to be a circle and it doesnt have to be on a flat plane. Also the area that is generating the smoke would normally not exist, something burning would generate smoke not the ground.

Well thats all i can think of for now, hope it gives you some ideas on stuff you can change.

Hi Sabrina,

I'm having trouble viewing your movie. I think the whole internet is downloading it, right now.... plus Quicktime is complaining about something, and I don't know how to use the internets to fix it.

I don't really have much to add that hasn't already been said. Particle are one of the most expensive graphical components, so if you had to cut anything for performance reasons, cut acceleration. You can pretty much assume that smoke rises at a constant velocity making (pNew = pOld + v*deltaT) a perfectly valid way to go.

I'm also assuming that all of your particles are sharing the same instance of texture data, yes?

Along the lines of performance, stick with the raw array, no vector, list, or smart pointers. Those are to be used when you're going to be passing around dynamic things a lot, but they cost an extra CPU instruction to access. Since you want your particles working as speedy as possible, and since your particles are going to be a self-contained system with a well-defined problem space, you're probably safe from yourself with a simple raw array.

Assuming 'v' is a three-dimensional vector, the minor random factor is a great idea. Particles that randomly change direction can be visually awkward, so try incorporating either sine or cosine into your random fluctuations so that your particles have a wavy behavior to them. The random parts of each particle's behavior can come in the form of randomizing the amplitude of the motion variation (clamped between reasonable values), period of the wave (clamped between reason), and starting angle between 0 and 2*pi that gets passed into the sine or cosine function. This oughta be a fun math exercise for ya. And it doesn't have to really be random as in the use of rand(). You can apply some kind of deterministic algorithm that guarantees a sensible spread of particles so that you can spawn less particles and still get a fuller effect.

Hmmm... alpha upon spawning? I think it would be better to just have a particle size of zero upon spawning. As the lifetime increases, size increases and alpha becomes more translucent... that seems natural to me. Apologies in advance if you are already doing this. Have you considered posting your movies on a googlepage or something... or maybe YouTube? Anything but Myspace.

Very cool.

Originally posted by Sabrina
(I think MrMike handed it out for an assignment.)

You should make him grade it! Very cool on the scanner/parser. Did you use anything like Lex and Yacc, or did you write it all from scratch?

-Rez

Eesh, I can't imagine not using Lex and Yacc. Well, maybe Antler or something, but still. Writing it from scratch is just . . . painful. Either way, you get mad props, Sabrina.

Sabrina congrats, I love doing this kind of thing, creating mini languages and so forth. It's harder for me to come up with excuses to do anymore now that LUA and embedded Python (yuck).
are around. Are you using a yacc parser to do this? Personally I think it's overkill for a syntax as simple as this? a switch block would handle this short a state set simply enough.
What does the parser return to your system a vector of maps?

cool stuff

gb

Sabrina,

When i was talking about the vector or maps i was thinking more about the output of the configuration file module to the particle system.

You don't lex the entire file and then parse it
I see a top do down parsing structure.

C++ ish psuedo code:

in this getToken returns one token at a time
and can signal EOF and disk i/o errors

while (true)
{
lookForStartOfDefinition()
if (found start of definition)
{
if (opening of particle definition found)
{
parseParticleDefinition()
}
else
{
error message - start of particle definition expected
}
}
else
{
break out of parse loop end of file
}
}

parseParticleDefinition()
{
do
{
getToken()
if (EOF)
error message - unexpected end of file

if (token is close-brace)
return - end of definition found

if (token is ident)
{
getToken()
if (token is asign-op)
getLiteral and do assignment
else
error message unexpected token
}
else
error message - identifer expected
} while ()
}

lookForStartOfDefinition()
{
getToken()
if (EOF)
do something to signal done to exit the master parse loop

if (token is ident)
{
getToken();
if (token is open-brace)
signal found a definition start
else
error message - unexpected token found
}
else
error message - identifer expected
}

Hope this helps a more than it hurts

gb