Results 1 to 10 of 10

Thread: Phoenix particles

  1. #1

    Phoenix particles

    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).

    Code:
            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.

    Code:
      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
    Code:
     
      // 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.

    Code:
    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 ?
    Amnoxx

    Oh, and this code appears to be an approximate replacement for return(random() & 0x01);

    Phoenix Wiki
    http://www.phoenixlib.net/

    Phoenix Forum
    http://www.pascalgamedevelopment.com/viewforum.php?f=71

  2. #2

    Phoenix particles

    What about rotation and fading?
    <a href="http://www.greatgamesexperiment.com/game/Valgard/?utm_source=gge&amp;utm_medium=badge_game"><img border="0" alt="GGE" title="GGE" src="http://static.greatgamesexperiment.com/badge/game/valgard/gge400x56.png"></a>

  3. #3

    Phoenix particles

    Quote Originally Posted by Huehnerschaender
    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:

    [pascal]with ParticleManager.AddSystem(Spark) do begin
    Attatch( TPHXTag(Missile1.Tags[0]).Final );
    end;[/pascal]
    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.
    Imagine I've written something clever here inspiring you to make something awesome. If that happens give me credits

  4. #4

    Phoenix particles

    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?
    <a href="http://www.greatgamesexperiment.com/game/Valgard/?utm_source=gge&amp;utm_medium=badge_game"><img border="0" alt="GGE" title="GGE" src="http://static.greatgamesexperiment.com/badge/game/valgard/gge400x56.png"></a>

  5. #5

    Phoenix particles

    With 3 colours you can do it like this:
    Alpha 0->255->0
    Else I don't get you.
    Imagine I've written something clever here inspiring you to make something awesome. If that happens give me credits

  6. #6

    Phoenix particles

    Quote Originally Posted by Huehnerschaender
    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.

    Quote Originally Posted by pstudio
    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.

    Quote Originally Posted by pstudio
    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.
    Amnoxx

    Oh, and this code appears to be an approximate replacement for return(random() & 0x01);

    Phoenix Wiki
    http://www.phoenixlib.net/

    Phoenix Forum
    http://www.pascalgamedevelopment.com/viewforum.php?f=71

  7. #7

    Phoenix particles

    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.
    Imagine I've written something clever here inspiring you to make something awesome. If that happens give me credits

  8. #8

    Phoenix particles

    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.

  9. #9

    Phoenix particles

    Quote Originally Posted by User137
    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.

    Code:
    PPHXParticle = ^TPHXParticle;
    TPHXParticle = record
      // The number of seconds since the birth of the particle
      Time        &#58; Single;
      // The energy of the particle
      Energy       &#58; Single;
    
      // The lifetime of the particle
      Life         &#58; Single;
      // The size
    
      Size         &#58; Single;
      // Pattern index of the particle
      Pattern      &#58; Byte;
      // The color
      Color        &#58; TColor4f;
      // The color fade
      Fade         &#58; TColor4f;
    
      // The position
      Position&#58; TVector3f;
      // The velocity
      Velocity&#58; TVector3f;
      // The acceleration
      Acceleration &#58; TVector3f;
    
      PrevPosition&#58; TVector3f;
      PrevTime    &#58; Single;
    end;
    Quote Originally Posted by User137
    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).
    Amnoxx

    Oh, and this code appears to be an approximate replacement for return(random() & 0x01);

    Phoenix Wiki
    http://www.phoenixlib.net/

    Phoenix Forum
    http://www.pascalgamedevelopment.com/viewforum.php?f=71

  10. #10

    Phoenix particles

    Quote Originally Posted by pstudio
    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.
    Amnoxx

    Oh, and this code appears to be an approximate replacement for return(random() & 0x01);

    Phoenix Wiki
    http://www.phoenixlib.net/

    Phoenix Forum
    http://www.pascalgamedevelopment.com/viewforum.php?f=71

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Comodo SSL