Jump to content
  • Advertisement
Sign in to follow this  
Juliean

Opinions on particle system

This topic is 2586 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi,

I'd like to hear your opinions on my particle system. Not so much the rendering (basic directx instanced particles, cpu side for now, I'll move everything to gpu soon), but more about the idea behind spawning, movement, and physics.

My first particle system was crappy and hard to use, so I decided that I want a modular, easy to use particle system that allows me to render everything from smoke to snow to dust without having to create unique classes for different types of particles. What I came up with is a particle system that, aside from different parameters like position and texture, has 4 components:

- SPAWN: These components, all structs that inherit from the struct SPAWN, are used for spawning particles in certain volumes. SPAWN has a virtual GetPosition()-method that returns a random point inside that given volume. Volumes are point, AABB, sphere, cone, etc... On particle creation & resetting (no complete erasure & reallocation of particles) that method is called and the particle is placed.

- MOVE: The MOVE-structs all have a method called GetDirection(), inherited just like the spawn-components. They determine in which direction and how fast the particles move on creation and resetting. Some types are line, sphere, cone. The GetDirection()-method doesn't return a random point inside the volume as the movement-vector, but determines a direction from a random point inside the volume, and then caluclates a random strenght between two given values StrenghtMin and StrenghtMax.

- VOLUME: These structs, restrict particle movement. If particle exits the volume, it gets reset, therefor these structs only have a method GetInside(Point) which tests if a particle is inside. These are just 3d shapes while SPAWN and MOVE can also be 2d like circle..

- FORCE_FIELD: These are very experimentual. I'm trying to have different force field types like point, plane, etc, that adds forces to particles. Each field has 3 components on its own:

- VOLUME: Same as for the emitters volume, but here its used to determine if a particle should be affected by the force field.

- STRENGHT: Used to determine the strenght of the force based on the particles distance to the force field. For now there is only one struct, STRENGHT_LINEAR, which interpolates the distance between ForceMin and ForceMax given DistMin (lower dist always return ForceMax) and DistMax (greater dist always returns ForceMin). Has the method GetStrenght().

- DIRECTION: Determines the direction of the force. For now there is just DIRECTION_LINE and DIRECTION_LINEFROM (which uses the direction from the volume to the particle as force direction), but I am not really restricted. I could have sinus waves, turbulence, etc.. The method for this component is GetDirection().

Based on these 3 components, the forcefield generates a force for a particle. If it is inside the volume, strenght and direction are multiplyed and returned.

So, what do you say? I'm really satisfied with that, because it works just as I expected. Although my physics handling is very primitive, I managed to have explosions, snow, rain, a wall of fire, a flamethrower, smoke, and many more just by adjusting some settings. However I would like to know what you think about it. Would you want to use such a particle system in your project? Is it a practical approach or just a beginners choice of how to handle particle systems? I see more pro's than conts:

pros:
- easy to use (using helper functions you need 8 function calls to set up a emitter with all parameters, and a force field
- allows a wide range of particle types
- user could easily write own types for movement, spawing, etc..
- straightforward to choose spawn/movement/.. type, no screwing around with obscure parameters to see what happens

cons:
- a lot of virtual calls on particle creation/resetting (though I don't know if thas a huge problem, removing virtual didn't increased performance much for 20000 particles on my pc)
- it has to be clear which type of component will be used (every component has a non-virtual SetProperties()-method, therefor you can't just create a SPAWN-instance, but have to create SPAWN_AABB and call SetProperties() if you want a AAAB to spawn particles. Again, I'm not really sure if this is a problem, using helper functions you don't even have to care about that part.

Any opinions? Maybe some issues I overlooked, or something I could improve? I already got everything coded out, so if someone is interested, I could post a demo application with some source code, or maybe a runtime-libary (but first I want to finish moving the whole thing to the gpu for performance-sake, only being able to render 100k particle on a C2D E8400 before the game starts going slow-mo isn't that great, I figured).

Share this post


Link to post
Share on other sites
Advertisement
This is a particle editor that I designed for my last commercial engine:
particuleeditor-1.png

I think you can get some ideas from this image.

Basically you have an Effect.
Then an Effect can have any number of Emitters.
Then Emitters are what throw particles into the air. They have properties describing the shape of the emitter and how frequently to throw particles.
The shape of an emitter can be, for example, a ring, a sphere, a box, a point, etc.

So that is the setup. Now we have particles that are coming into the air.
Here you can see many of the settings that you would want to apply to particles as they fly about.
How long they live, which image (rather, part of an image) they use, fade-in time, fade-out time, etc.

Pretty sure you can get ideas from this. This is a standard particle-system design.


L. Spiro

Share this post


Link to post
Share on other sites

This is a particle editor that I designed for my last commercial engine:

I think you can get some ideas from this image.

Basically you have an Effect.
Then an Effect can have any number of Emitters.
Then Emitters are what throw particles into the air. They have properties describing the shape of the emitter and how frequently to throw particles.
The shape of an emitter can be, for example, a ring, a sphere, a box, a point, etc.

So that is the setup. Now we have particles that are coming into the air.
Here you can see many of the settings that you would want to apply to particles as they fly about.
How long they live, which image (rather, part of an image) they use, fade-in time, fade-out time, etc.

Pretty sure you can get ideas from this. This is a standard particle-system design.
L. Spiro


Really nice editor.
Can we try it?
And ... the engine? :rolleyes:

Share this post


Link to post
Share on other sites
Similarly, we have implemented a particle system like mentioned above: effect, list of emitters and particles for each emitter. Effect is basically a render object and emitter holder. An emitter as the name implies, defines where and how are particles created. A particle is a point in space with direction velocity, color, texture info, etc...

Both emitter data and particle data have a bunch of evaluators (line/curve editor), which are driven with emitter/particle life, ie: size, color, alpha, velocity, gravity, etc... To get better re-usability, we've added "instance data", so that some specific options are not set (locked) on data, but there where data is used (ie: when emitter data is linked under effect data, an emitter instance data slot is created, under which the emitter data is linked).

Biggest problem we reached was when we tried to create fireworks effect - where a "particle" is also an emitter. We had to add the concept of child emitters. On a particle data we define a new emitter data link, and it's "active evaluator". This defines when the child emitter will be active in accordance to particle life. This way we can nest as much as wanted, but for sanity, memory and performance reasons the depth is limited to 3.

Each emitter can also hold various engine objects like lights, flares, sounds, etc... whose properties can be also evaluated (ie: light color, intensity and range).

The editor is written with inhouse UI (sadly smile.gif ), and the system is job friendly.


edit: current biggest wish by designers is ability to animate particle movement, so they can create fancy movement like spiral, tornado, etc.. we are probably just going to import animation keyframes from an external tool (ie: maya), and interpolate particle movement based on that. note, that this will be just the "base" particle position, something like:
newpos += animationdelta + (velocity * dt)
so that you can still modify the particle movement even if particle movement is animated

Share this post


Link to post
Share on other sites

Really nice editor.
Can we try it?
And ... the engine? :rolleyes:

Thank you.
But the engine is commercial and will cost you money.
I have been trying to get them to make it free for indies but they won't.





edit: current biggest wish by designers is ability to animate particle movement, so they can create fancy movement like spiral, tornado, etc.. we are probably just going to import animation keyframes from an external tool (ie: maya), and interpolate particle movement based on that. note, that this will be just the "base" particle position, something like:
newpos += animationdelta + (velocity * dt)
so that you can still modify the particle movement even if particle movement is animated

Just add paths that can be emitted for particles to follow, and have a setting that adjusts how much the particles can deviate from the path.
A path can be a bezier curve or a more efficient series of connected line segments.


L. Spiro

Share this post


Link to post
Share on other sites

[quote name='zfvesoljc' timestamp='1321372267' post='4884195']
edit: current biggest wish by designers is ability to animate particle movement, so they can create fancy movement like spiral, tornado, etc.. we are probably just going to import animation keyframes from an external tool (ie: maya), and interpolate particle movement based on that. note, that this will be just the "base" particle position, something like:
newpos += animationdelta + (velocity * dt)
so that you can still modify the particle movement even if particle movement is animated

Just add paths that can be emitted for particles to follow, and have a setting that adjusts how much the particles can deviate from the path.
A path can be a bezier curve or a more efficient series of connected line segments.
[/quote]

Line segments were something I was aiming at with keyframes. But I still have to use progressive update with position delta, since particles are dynamic - their behaviour can be affected by outside forces and even collisions. ie: a wind tornado like effect can be "pushed away" when a nearby explosion goes off and spawns a temporary force area (spherical), particles gain extra inertia, the "tornado" particle movement paths get disrupted, but as the inertia falls of, they start resuming their animated path again.

Share this post


Link to post
Share on other sites
Sorry if it was already mentioned but for those curious, what engine would that be? You say it's commercial but I don't see a link if anyone were curious as to the full feature set and cost.

Share this post


Link to post
Share on other sites
<hijack>
YogurtEmporer, I'm currently designing a sprite/map/particle editor for my game, and looking at that screenshot I think that editor is similar to how I'd like mine to be. Not exactly, of course, but similar. What language/tools did you use to make that editor? Is it a .NET app? Any insights/articles/etc you can share that would help someone like me know how to develop something like that?

Right now I'm using C# and it's going pretty well, and I've got databindings from my XML nodes to my controls to help with the updating of values. But I've no idea if I may be missing something that would help me to develop this.

[edit]
I've decided to restart it and make it a Qt C++ app for cross platform reasons, as I'm sick of Windows Forms and the Mono project has no support for WPF. Feedback is still appreciated though.
</hijack>

OP, I'm sorry for the complete, total hijack. One question I have for you though is how useful would the VOLUME component be? When you say reset, do you mean the particle gets destroyed? I think it would make sense for the particle to be destroyed if it leaves the volume and not to just be moved back inside the volume. But maybe that is what you meant by reset; I'm just not sure.

Share this post


Link to post
Share on other sites

Sorry if it was already mentioned but for those curious, what engine would that be? You say it's commercial but I don't see a link if anyone were curious as to the full feature set and cost.

I wanted to avoid saying this, but the reason I have been so ambiguous is due to a long story, but the short version is:
I started the engine on my own in another country years ago. Then this company in Japan saw it, hired me immediately, promised 50% of the profits, and finally gave me 0%.
They basically stole my engine.
So I have no intentions of helping them sell it, and I am now focused on my new engine, written from scratch (so they have no rights to it), and targeting next-generation platforms.
And it will be higher quality, include more features, and be free for indies.



<hijack>
YogurtEmporer, I'm currently designing a sprite/map/particle editor for my game, and looking at that screenshot I think that editor is similar to how I'd like mine to be. Not exactly, of course, but similar. What language/tools did you use to make that editor? Is it a .NET app? Any insights/articles/etc you can share that would help someone like me know how to develop something like that?

Right now I'm using C# and it's going pretty well, and I've got databindings from my XML nodes to my controls to help with the updating of values. But I've no idea if I may be missing something that would help me to develop this.

[edit]
I've decided to restart it and make it a Qt C++ app for cross platform reasons, as I'm sick of Windows Forms and the Mono project has no support for WPF. Feedback is still appreciated though.
</hijack>

OP, I'm sorry for the complete, total hijack. One question I have for you though is how useful would the VOLUME component be? When you say reset, do you mean the particle gets destroyed? I think it would make sense for the particle to be destroyed if it leaves the volume and not to just be moved back inside the volume. But maybe that is what you meant by reset; I'm just not sure.

Well, it just so happens that Qt was used, for the purpose of cross-platform compatibility.
I don't have articles but I don't think any are necessary. It was my first venture with Qt and all I used were the docs and the IRC help channel.
I use the name BadMrsFrosty in IRC.


L. Spiro

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!