PDA

View Full Version : Phoenix particles



Andreaz
27-09-2007, 05:52 AM
I've encountered quite a few bad errors in the current engine, the allocating of systems is far from fast, and a few bits and pieces is way to slow and lacking in features.

Thus I've have some serious thoughs on rewriting it.

With this in mind I've posted this to hear what you'd like from a particle system.

I think the system/effect method in the old engine is the way to go

I've written some prototype code so far, for instance the following code attatches a particle system to a tag in a model (ie it will move with the missile, rotating translating, you name it).



with ParticleManager.AddSystem(Spark) do begin
Attatch( TPHXTag(Missile1.Tags[0]).Final );
end;



In my test the particles supports both time based and distance based particles, with burst possibilities.



EmissionMethod: TPHXEmisionMethod; // emTime, emDistance
// Delay between each emission
EmissionDelay: Single;
// Nuber of particles to emit each cycle
EmissionCount: Integer;
// Time to wait before starting the emission
EmissionStart: Single;


Also added pattern support (1x1, 2x2, 4x4 or 8x8 in size) thus it's possible to animate the particle textures, uses fixed rectangular patterns for speed.

It's possible to have various shapes of the particles, axis alinged in x,y,z (x,y are quite useless for pure 2D but it's a simple lookup anyway), billboarded and trail (a quadstrip going between each particle, like engine trails and so forth). May add a sixth wich is a spark, ie the particle is drawn as a rotated quad between the last and current position.

I've added the following emision properties for each particle to the effect, exept for texture and shape as is a system property


// Pattern
Pattern: Byte;
// Particle lifetime
LifeMin: Single;
LifeMax: Single;

// Particle size
SizeMin: Single;
SizeMax: Single;

// Particle start and end color
ColorStart: TColor4f;
ColorEnd : TColor4f;

// Emission points, each particle gets assigned one at random
EmisionPoints: TVectorList3f;

// Position variance
PositionMin: TVector3f;
PositionMax: TVector3f;

// Direction
DirectionMin: TVector3f;
DirectionMax: TVector3f;

// Spherical velocity
VelocityMin: TVector3f;
VelocityMax: TVector3f;

// Acceleration vectors
AccelerationMin: TVector3f;
AccelerationMax: TVector3f;


As you see some of the properties from the old system is gone, for instance the color lists, radial and tangential acceleration. However each effect has a list of particle affectors that may affect the particles in varius ways. So far i've written a gravity affector and a bounce affector.


Procedure TPHXParticleAffector.Affect(System: TPHXParticleSystem; const Particles: TPHXParticleList; FrameTime: Single);

On the rendering side, each particle system is no longer required to render its own particles and the systems is sorted by textures for less state changes. Also a particle system isnt disposed of until the manager is destroyed, it reuses dead ones instead, memory improvement aswell.

So now's the time for your thoughts, something i've missed that's a must ?

Huehnerschaender
27-09-2007, 07:46 AM
What about rotation and fading?

pstudio
27-09-2007, 11:57 AM
What about rotation and fading?
Fading can be done with alpha values in the colour list if I get you right. Rotation is a must. I'm missing it riht now in a small game I'm making to test Phoenix.


I've written some prototype code so far, for instance the following code attatches a particle system to a tag in a model (ie it will move with the missile, rotating translating, you name it).

Code:

with ParticleManager.AddSystem(Spark) do begin
Attatch( TPHXTag(Missile1.Tags[0]).Final );
end;


Will this attach the particle effect to a sprite?

With all the things you mention, you've covered all the improvements I could wish right now in the Particle System. Espicially rotation and animated particles sounds great to me.

Huehnerschaender
27-09-2007, 03:32 PM
with a start and an endvalue for color you can let a particle fade in or fade out... but how do you let it fade in and out? image a fire spark that fades in until its alpha is 255 and then? It should fade out again and not just vanish... know what I mean?

pstudio
27-09-2007, 07:02 PM
With 3 colours you can do it like this:
Alpha 0->255->0
Else I don't get you.

Andreaz
28-09-2007, 05:09 AM
with a start and an endvalue for color you can let a particle fade in or fade out... but how do you let it fade in and out? image a fire spark that fades in until its alpha is 255 and then? It should fade out again and not just vanish... know what I mean?

That is a work for the ParticleAffectors, the color list of the old system will be moved to a color affector, that will deal with the fading between multiple colors.

The reasoning behind this is that when it's a property that isnt used in every system, or can be implemented with small overhead, move it to an affector.



Will this attach the particle effect to a sprite?

It attatches to a TPHXMatrix, currently paths and jonts and tags in the models, but it might be an idea to add it to sprites aswell.



With all the things you mention, you've covered all the improvements I could wish right now in the Particle System. Espicially rotation and animated particles sounds great to me.
The rotating as i mentioned is just the general direction of the particle system (modulated by each particles spawn rotation) and not rotating each particle. Rotating each particle gets quite costly.

pstudio
30-09-2007, 10:23 AM
The rotating as i mentioned is just the general direction of the particle system (modulated by each particles spawn rotation) and not rotating each particle. Rotating each particle gets quite costly.
Well, I was thinking about particle individual rotation, but if it's to expensive I'll have to do without it.

User137
30-09-2007, 10:44 AM
Keep in mind having too many variables per particle can effect greatly on memory use and speed when it comes to use large amount of particles.

Haven't tested how fast/slow it would be if each particle was an object. (don't know if they already are objects in your system) In that case it would be possible to make different versions of particles and optimize using only variables that are needed; as sub object types. This would also give renderer more flexibility and options. Like when group of particles share same properties they would only be set once at renderer instead of 20000 times.

Andreaz
01-10-2007, 05:40 AM
Keep in mind having too many variables per particle can effect greatly on memory use and speed when it comes to use large amount of particles.

The particle struct is 104 bytes, so thats not that bad, even 100k particles wont take that much memory.


PPHXParticle = ^TPHXParticle;
TPHXParticle = record
// The number of seconds since the birth of the particle
Time : Single;
// The energy of the particle
Energy : Single;

// The lifetime of the particle
Life : Single;
// The size

Size : Single;
// Pattern index of the particle
Pattern : Byte;
// The color
Color : TColor4f;
// The color fade
Fade : TColor4f;

// The position
Position: TVector3f;
// The velocity
Velocity: TVector3f;
// The acceleration
Acceleration : TVector3f;

PrevPosition: TVector3f;
PrevTime : Single;
end;



Haven't tested how fast/slow it would be if each particle was an object. (don't know if they already are objects in your system) In that case it would be possible to make different versions of particles and optimize using only variables that are needed; as sub object types. This would also give renderer more flexibility and options. Like when group of particles share same properties they would only be set once at renderer instead of 20000 times.
The problem with making the particles an object, except that you have some construct overhead is that to make it any usefull you'll have to have virtual methods for the render and update function, for each particle.

In the current version the particle system manages the updating for each particle without a function call and the manager renders the particle systems using 2 function calls per system, it batches all particles and renders then per system basis (Going to test so it only calls one a system parameter is updated (texture or blending) but i'm not shure if it will bring any greater speed increases).

Andreaz
01-10-2007, 05:47 AM
The rotating as i mentioned is just the general direction of the particle system (modulated by each particles spawn rotation) and not rotating each particle. Rotating each particle gets quite costly.
Well, I was thinking about particle individual rotation, but if it's to expensive I'll have to do without it.

It sadly involves a matrix multiplication per particle, i'm afraid that it would be to much to add in software, the cpu already has alot of stuff to calculate for each particle. Would be another thing putting it into an vertex shader, but then we would be limited to quite modern gpu's.

That and you'll have to add a matrix to each particle, takes alot of memory...

The old version used the texture matrix to spin the textures of the particles per system, it's a ok compromise imo.