pouët.net

Oh; it's an embarassingly simple effect. (It's not really up to 2010's standards ;)

About 10k particles emitted from spheres and controlled by repulsive and rotational forces (think about like flight404 magnetospheres) with added some volume constraints (a particle cannot go inside the volume of any sphere)

The forces/masses of the particles are altered during the course of the effect. Each particle has a different color and the alpha is varied during the course of its life.

I'm very naive so I just emit a quad list via gl's glDrawElements inside an interleaved array. I might add some form of quad deformation in the direction of the speed vector to fake a sort of motion blur

I'd like to have it run on a netbook style device basically.

So that's the reason why it's cpu based and not shader based.

anyway I'm going to try some of the suggestions here, see how they fare.

I actually did try to apply framerate adaption to a particle effect, last year. I got it to work fairly well. Although, as Nytrik etc projected, it didnt look good enough so I ditched it. Figured out that effects using that needs to be designed from start to finish with that in mind. Even so the bounds of the effect needs to be strictly regulated. Which makes the whole thing less interesting.

Although. Cant be that hard to find low spec computers to try things on can it? Family, friends, job? I often bring an exe with me when I visit someone that has a computer with interesting specs and do a testrun. Although I need a better tweaking system: http://www.pouet.net/topic.php?which=7126 To make it worth my while and general good.

actually one of my embarassing spots where the cpu piked was due to a "tweakable constant" that I put by mistake in an inner loop ;) in the test builds it would keep looking up the values in a hashtable :]

Constant frame rate with raytracing style stuff, or raymarching, or anything per pixel based, using a dynamic resolution works very well, the render resolution for the next frame depends on the rendering time used in the last one. John Carmack has also tweeted about this http://twitter.com/ID_AA_Carmack/status/22937909362.

My intuition tells me it'd be a safer bet to create a limited set of "good configurations", say like four or five, by tweaking each effect while testing it on the actual target hardware. Then do benchmarks on criteria relevant to the effect code (CPU in your case, add test criteria as needed: GPU fillrate, shaders etc.) and note the minimum score required for each configuration to work. Then at load-time, run the benchmarks and select the best configuration based on the results.

That would greatly simplify the whole thing, and spare you any nasty surprises. And even if it doesn't sound very elegant, I strongly suspect it would be much easier in the end: finding all the magic constants you'd need to automatically balance particle count, particle size/intensity, timestep, CPU core usage and so on, that can't be easy (possible, even?).

And you'd only find that you still need a lot of different setups to test it out. You might as well have used those setups to create a set of configurations you know are acceptable.

Btw, one issue if you go for pure adaptive effects: put a top limit on stuff. Otherwise if a system is fast enough, particle counts or whatever will get insane, likely resulting in a crash. And when the demo gets captured, that's kind of like an ultra fast machine where this will happen :)

I so want it to be insane.

If it gets insane enough, the particles will be so dense they'll form a singularity. At that point the particle count overflows and reverts to 1. Clearly, 1 particle effects are the future.

wow!

So it's 10k alphaed particle billboards drawn by GL with 'fake' motion blur. interesting.