Archived

This topic is now archived and is closed to further replies.

Particle Systems

This topic is 5377 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

I am currently implementing a particle engine. I have the basic structures down and working, and was getting ready to start inheriting from them and expanding upon them, but I got to thinking... Particle Systems can be huge. I am running a couple of thousand particles for a basic effect; this number is likely to greatly fluctuate both up and down depending on the effect. Additionally, so many effects have fundamentally different behaviors. For instance, a fountain is stationary and spews out water particles, where as a rocket is moving and leaves a trail of water (vapor) particles. The fundamental difference being stationary vs moving particles and emitters. This is just one example of many. It made me think that perhaps I should not be inheriting from a set of generic base classes, but that I should be writing specific classes for specific effects, using very little code inheritance (and code reuse). The driving logic being that I intend to use a lot of particle effects at once, and am desiging for future uses of 100,000 particles from multiple different effects. Do you think that the speed gained would warrant designing such seperate classes? The Tyr project is here.

Share this post


Link to post
Share on other sites
For my particle system I use something similar to the "flyweight pattern" (I think that is how it is called in english) from the
"Design Patterns. Elements of Reusable Object- Oriented Software."-Book by Gamma/Helm/Johnson.

Basically, this pattern provides a solution to problems where large numbers of different but similar objects must be stored and accessed effectively. The trick is to only store the individual part which each object has and move the common parts to a small number of external objects.

In the case of a particle system, this means that you have only one single partucle object which stores only the current state and individual properties of the particle along with a reference to its "class" (not strictly in the C++ sense but rather classes of particles, like smoke or sparks). All "behaviours" and class properties are stored with the "classes", with only one instance per class!

When the particle system has to update and draw the particles, it goes through ist particle list one by one, using the "class" reference of the current particle to update and draw it.

Since all particles are stored in a single list, it is easy to limit the number of particles, even dynamically at runtime. E.g. you sometimes may not have time to render all the eye candy when displaying a very complex game situation with a somewhat constant frame rate). And you have only one place to look for collisions, frustum culling and such.

The "classes" can be as different as you like, modifying anything from position to color or mass of its particles. All they need is a common interface. However, I added some convenience functions like calculating the influence of gravity to the common base class of my particle classes, to keep me from writing the same code over and over again.

The indovidual properties of my particles include mass, position, velocity, age, lifespan, and the class reference. All other data can be calculated with this data (like the current heat of a smoke particle depends on its age).

Hope that made sense...

Tilmann

Share this post


Link to post
Share on other sites
Thanx, that did make sense.

I will pull out my Patterns book and reread the fly-weight pattern.

It seems to be a good system in general, but I am still unsure about a couple of issues (namely, stationary particles wasting time updating their velocity). However, I think that upon implementing your method an answer may become clearer. I also think that non-moving particle effects are going to be rare enough that I am not going to get that much of a speed increase for the headache of writing specific code for that situation.

Anyone else have any good ideas/methods?

The Tyr project is here.

Share this post


Link to post
Share on other sites
Write a particle editor.

It comes down to what you want to allow. In the scheme of things, particles can do pretty much anything that''s thought of, which would kill any inheritance that you have from generic classes. If you write a particle editor, it really gives you a chance to get the most expansion, with the most inheritance possible.

In the newest editor i''m working on, I''m creating a timetable for my system. This allows HUGE amounts of variation to be created in the linear movment of particles. And on top of that, I''m about to add quadradic equations to my movements as well.

If you write an editor, it gives you a great chance to optomize the hell out of things too. such as the NV_POINT_SPRITE extention etc.

~Main

==
Colt "MainRoach" McAnlis
Programmer
www.badheat.com/sinewave

Share this post


Link to post
Share on other sites
So with your particle editor how do you go about storing the created effects for later use in your game? Do you generate the code, store scripts, etc???

I was thinking about writing a small editor in the future but primarily just for tweaking effects and for the experience of writing an editor (which I have yet to do). But I hadn''t really thought about doing it on a scale of actually making the majority of effects through it and storing them for later use.

Share this post


Link to post
Share on other sites