   Particle System Help
  Hey guys.  I'm working on a basic particle system in 3D but instead of just spawning all the particles at the single point location of the particle emiter, I want to specify a region to generate them within.  Ultimately I want to be able to generate them inside a circle, ring, rectangle or a sphere.What's the best way to do this?  So far I thought up a method to generate them within a circle (I think, haven't tested yet) but it seems extremely inefficient.  It goes something like this, for each particle.float randomRadius = randomFloat(0.0f, CIRCLE_RADIUS);float randomRotation = randomFloat(0.0f, 2.0f * PI);particle.x = cos(randomRotation) * randomRadius;particle.y = sin(randomRotation) * randomRadius;particle.z = constant;What should I do?
Quote:... but it seems extremely inefficientHow have you determined this?How many particles to you expect to be emitting per-frame? I expect that the real performance gains for your particle system is going to be how you handle updating and drawing the thousands of active particles, rather than how you add a handful.If performance is your goal, have you considered implementing the particules purely on the graphics card?   ;  why should it be inefficent?   ;  The way I handled this before was, when adding a particle, to just repeatedly  generate positions for it in a rectangular region until the squared-distance between the particle and the center is less than or equal to the squared-radius of the sphere. Generally this requires only one or two attempts.   ;  I just assumed that 2 trig function calls per particle would be really slow in a case where something like 10 000 particles are spawned all at the same time.  Maybe I'm underestimating the power of a CPU though, I really don't know, that's why I'm asking.Quote:Original post by dmatterThe way I handled this before was, when adding a particle, to just repeatedly  generate positions for it in a rectangular region until the squared-distance between the particle and the center is less than or equal to the squared-radius of the sphere. Generally this requires only one or two attempts.That sounds really interesting.  I'm probably going to try it.   ;Quote:Original post by X Abstract XI just assumed that 2 trig function calls per particle would be really slow in a case where something like 10 000 particles are spawned all at the same time.  Maybe I'm underestimating the power of a CPU though, I really don't know, that's why I'm asking.Quote:Original post by dmatterThe way I handled this before was, when adding a particle, to just repeatedly  generate positions for it in a rectangular region until the squared-distance between the particle and the center is less than or equal to the squared-radius of the sphere. Generally this requires only one or two attempts.That sounds really interesting.  I'm probably going to try it.I don't think trig function would be that slow. I took a numerical analysis course 1-2 years before and they can be calculated as sum of series. I think it can perform it even faster by using a precalculated table and approach your input using it. although I have no idea how they are implemented. anyone knows how they are implemented?try both, but I don't think you will get any noticable performance boost. it might be even slower. it will miss the circle only 1-pi/4 ~= 20% of timebut I guess dmatter's method would give a more uniform result. if you choose a random angle and radius it will tend to be on the center   ;Quote:Original post by X Abstract XI just assumed that 2 trig function calls per particle would be really slow in a case where something like 10 000 particles are spawned all at the same time.  Maybe I'm underestimating the power of a CPU though, I really don't know, that's why I'm asking.I think 10,000 particles being spawned at the same time for one effect is your biggest concern. 10,000 is more like a number I'd expect to see when talking about all the particles from every effect currently active in the world.For individual effects, for instance smoke, you could easily get a realistic looking effect by spawning 20-50 per second (not frame). At 60fps thats less than 1 new particle every frame, which will trigger two trig functions. Not exactly going to break the bank.   ;  My particle system can handle up to about 100,000 with various tweaks, being drawn with OpenGL's Immediate Mode (it's on my list of things to fix).I did numerous things to allow such a high number, and the biggest gain was in fact pre-calculating the random numbers required. For example, I create a random position that is +/- a small percentage of the emitter's position. I also create a random velocity that is added to the initial velocity so not all particles fly off in exactly the same direction.This equates to 6 random number generations each time a particle is spawned (X,Y,Z for position and direction).Instead what I did is when the Particle emitter is first spawned, I generate a random number table that is actually smaller than the number of required random numbers, this add's even less regularity as it will reach the end of the random number table before it's spawned the last particle and start the new one.By doing this, I cut out the 6 random number generations for every particle each spawn event.Gave me significant increases, if you don't mind a second or two of init time whilst it's generated.   ;  Any observable speed ups you get from tweaking the generation method are only apparent because your test app is doing nothing else.Apart from the fact that you're making way, way too many per frame as others have said, when you put all this over an actual application, those sin/cos calls will dwarf away to nothing at all.But at least use sinf and cosf. Most of your current CPU power is going into converting floats to doubles and back again.   ;  This is just a suggestion - but if your worried about calling these trig functions all the time why dont you create a look up table during the program init stage for the random positions and iterate through the table emitting particles from these locations? The trade-off here will be that the locations wont be truely random but they will however emitt from a circle/ box etc.[EDIT] Appologies to AndyEsser, this is pretty much exactly what he said.   