Particle System adjusting properties

Started by
5 comments, last by rubicondev 14 years, 1 month ago
hey, I'm designing a particle system in C++ and I need help figuring out HOW im going to go about using the same code for bullets, and explosions to rain and stuff like that, I have a particle system header like,

#ifndef _Particle_Factory_H
#define _Particle_Factory_H


#include <SFML/Graphics.hpp>
#include <vector>


#include "objects.h"


//Simple Particle system
class Particle_Factory : public Objects
{
public:

//Spawn p_count # of particles at Position pos
	void Emit( int p_count, sf::Vector2f vel, sf::Vector2f pos);

//Modify Velocity
	 void Modify( sf::Vector2f new_velocity);

//Update Particle Mechanics
	 void Logic_Update();

//Destroy Particle when it is useless
	 void Destroy_Particle(Objects &p);

//Draw to screen
	 void Draw();


	 std::vector <Objects> particles;

};







//static std::vector < Objects > particles;



#endif





Now how would I be able to attach this to an ammo class and use its properties like damage when they collide with player/enemies? How would i attach this to other classes so like, Bullet class can use functions from the particle_factory, so it can call,

ammo.emit(100, velocity, position);
and it will create 100 particles at 'position' with direction and speed of 'velocity'. And when it hits the player, does a certain amount 'damage'. Now how would I turn around and include that same particle_factory class into an explosion class and call,

explosion.emit(100, velocity, position);
so that the 100 particles created have different damage, collision response, and image than those created with the ammo class. Collision Response is the biggest issue, I can hack a solution for the other properties but i just cant' figure out a way to design a system that can use different types of collision response, for different items using the same particle factory system. I'm looking for how to design this system rather than how to code it. Any help would be much appreciated, if I was not clear on something please let me know, Thanks.
-Jawshttp://uploading.com/files/eff2c24d/TGEpre.zip/
Advertisement
First off, abandon this factory crap. To make this system as fast as possible, use a structure of arrays to hold a max number of each element - position, size, etc.

Then operate directly on that on however you feel. You must get to the metal with this stuff once you start moving the particles and trying to render them.

I spawn all my particles when I start the effect and then just move them about based on elapsed time using absolute positions and ballistic trajectories.

I don't actually do any collisions, but it'd need to be swept to work effciently and even then it's not going to go well unless you use a BVH or octree or something. It's on my todo list, but it's been their a long time as I've never yet needed it tbh.
------------------------------Great Little War Game
Don't view particles as logic objects, but graphic objects. When you fire a projectile, have a projectile object obtain a reference to a particle or particle emitter. When rendering, update the particle to the position of the projectile. You can then reuse your particle for anything since the logic code will be in your object managing the particle. That will also allow you to have particles without any logic code, like fire, smoke, etc.
Developer for Novus Dawn : a [s]Flash[/s] Unity Isometric Tactical RPG - Forums - Facebook - DevLog
Quote:Original post by Rubicon
First off, abandon this factory crap. To make this system as fast as possible, use a structure of arrays to hold a max number of each element - position, size, etc.

Then operate directly on that.
QFT.

Your factory design choice forgets the very nature of the problem.

Don't forget that this is a particle system.

A particle system is a dense collection of near-uniform data. It needs to be data-cache friendly and instruction-cache friendly for processing. If your design does not incorporate those details, then the design has failed.

A particle system generally is a simple array of data, and a structure describing the operations to execute. The algorithm is picked based on the operations to run, and the array is run through a very tight loop to process as quickly as possible. The results are then passed through for rendering to draw all the instances of a single sprite or other object.

The key features are dense data and very tight loops. It should be able to process 40MB or so in a handful of milliseconds. Anything less will need rework later.
There is only a single particle container. Something like:
vector<Particle> particles;
where Particle is something like
struct Particle {  vector3d position;  vector3d velocity;  int color;  int life;  ...  Texture * t;}


On each step, update all particles, move them, decrease time-to-live, animate color/alpha blend, apply gravity, etc...

If a gun fires, it adds 20 particles to this same container (with gun_impact texture). If explosion occurs, same, but with higher velocity and different texture..

particles are usually removed when their life reaches 0. To remove a particle, use the Erase-Remove approach. Or, to delete a particle, replace it with last particle in array, and decrease the count of container.

The reason for this design has to do with arranging data in a cache friendly manner and performing a single pass over data to update.
Most of his requirements arn't about pushing as many particles as possible but rather customizing their responses to various events and reusing as much code as possible for the variants (bullets, bullet casings, rain drops, falling debris, etc..)

I can see these arn't primitive particles which are mostly used in rendering (just need texture,pos,vel), but rather more complicated objects which needs to hook into the physics engine and maybe other frameworks.

Generally from what i've seen people create a projectile base class (which is what your really asking for, and not a particle normally found in games). This projectile class has a physical representation (ie mass, bounds, velocities, etc..) and hooks into a physics engine and a logical component, usually callbacks for various events which can occur onto it. A projectile manager handles all projectiles and updates them in conjunction with the physics engine (which updates their physical instances). Most of these simple projectiles have limited lifespan and "fade" away once they are expended.

You can derive from the base projectile class to customize its behavior or use a more data driven approach or mix it up. It's up 2 u.

Also to clarify, some of the effects you want arn't done using projectiles, but are just illusions like how rain is done. It's usually non-interactive particles streaks and random drop splashing particle fx applies to the surface which could be hit by the rain.

Good Luck!

-ddn
I agree it looks like he's trying to write a more global "effects system", but in that case his terminology is off.

The whole point of a particle system is that they make big effects from small pieces, and that in turn means lots of data. If you're trying to code a lava bomb that is a model with some glow around it and a particle stream of fire behind it, the particle engine should be used for the stream, but the rest of it needs doing elsewhere.

I've often thought about trying to write an extension to my particle creator tool that combines various other stuff to make big explosions, blast waves, all of that. Each time I try to design it though, I realise that pretty much all the pieces need to come under program control so just end up coding the effects I want right there in the game.

Having said that, there's no harm in writing them as general as possible and later using the old cut and paste inheritance method in the next project! :)
------------------------------Great Little War Game

This topic is closed to new replies.

Advertisement