Skip to main content
gamedev.net
🔒 Locked

Particle System

Started by Unresolved External 2 replies 1.5k views
Original Post
Unresolved External
Unresolved External
[color=#333333]Hello! I'm making a simple particle system for my asteroid-belt. It consists of only GL_POINTS with a randomized location, color, and alpha value.

I have a class called Particle which consists of the mentioned variables. Then I have a class called ParticleSystem which includes a vector of Particle.

If I have very small values for the number of particles it works fine. But I want to have a lot more for a better look. When I have about 7000 particles it begins to lag. But for it to look good I want to have at least 30000.

So, my question is, how can this be optimized? I bet a complicated particle system consists of more than 7000 particles, or?
haegarr
haegarr
You haven't written anything about what you mean causes the lag, how Particle is implemented, how the rendering is done, and how the drawing is done... Correcting that would be the first step of optimization
rip-off
rip-off
There are many different levels of particle optimisation. The first step is to determine if your particle subsystem problem is the CPU or GPU.

If CPU bound the problem is usually trying to bring all the data in from memory, you can structure the data in a cache-friendly manner. If the problem is getting them drawn, ensure you are batching the calls properly. For extreme cases you can actually implement the entire particle system on the GPU. You store the particle data in a "texture" and you use custom shader to "render" the update phase, and to draw the current state.

For example, last year I started off using a naive implementation, immediate mode textured quads in Java. I was having performance problems with large particle systems (obviously!), the problem was the CPU processing time. I moved to a "structure-of-arrays" approach, and did some rudimentary culling. I believe this brought me up to between 10 and 20 thousand particles on screen, and far more off screen.

As with all optimisation, measure before and after to ensure that you are changing the right thing and that the changes are having a positive effect. Have a performance goal in mind, it is easy to get carried away and optimisation tends to have diminishing returns. Set your goal and when you hit it, start work on something else.

A related idea is to have a "throttle" in your particle system, so that if the frame rate starts to drop you start spawning less particles (but you could render them larger, perhaps). This can have visual implications, but at least your game stays playable on older machines.
Helicobster
Helicobster

[color="#333333"]So, my question is, how can this be optimized? I bet a complicated particle system consists of more than 7000 particles, or?


You haven't really described what you're doing with those particles: how you're updating them, or how you're rendering them.

Are your particles interacting with each other? That's somewhat difficult to do efficiently, but it can be done. N-body gravitational simulations and smoothed particle hydronamics use all sorts of clever tricks to avoid checking for interactions between every possible particle pair, and most can easily run in realtime with a few thousand particles - but that would be a major coding project in itself.

You say you have randomised particle locations, though. How often do you randomise their locations? You're not randomising them with the same seed on every frame, are you? That could be very slow. You should only randomise them when they're born, storing the position & velocity (and optionally force or acceleration), and thereafter just use the stored velocity to update the stored position, modifying the velocity with forces like gravity as necessary. You can use glDrawArrays to render them directly from the position array. Unless those forces are hard to compute (eg: complex gravity fields or collisions), that'd be very quick with 30,000 particles or more.

On a single-core notebook CPU, a decent particle system should be able to run in realtime with a hundred thousand particles. On a well-spec'd gaming PC you should be able to get a few million simple particles going at decent speed - especially if you use the GPU for both simulation and rendering.

If you let us know what you're actually doing with your particles, I'm sure we'll be able to help you get them running faster. Meanwhile, try using a profiler to see which lines of code are taking the longest to execute.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.