View Full Version : Particle Engine Fields

05 May 2007, 07:47 PM

I wrote a 3D particle engine (real original right?) based on various sources found on the internet, and now I am trying to figure out how to add fields to effect the flow. I built it off of differnt sorces becuse I really didn't know how program in OpenGL some of the other things needed, now that I have something working I would like to build the rest from scratch. If someone knows of any resources with equations/formulas for different fields, would be of great help. I have an idea of how to implement a couple of things like wind and gravity. But it seems almost too simple. Things like sinks, turbulence and attracters I am less confident on. I'm pretty good with the physics and math of it (since I have a degree in physics and engineering) so it doesn’t matter how complicated it needs to be. The numerical analysis won't be a big challenge.

I'd like to show my progress in developing this software on here so that maybe I can get more ideas from this comunity on how to improve it (I have a bunch of ideas already that I would like to implement in it). I will post a couple of pics of the program when I get home from work.

Thanks for the help,


Ian Jones
05 May 2007, 08:36 PM
The biggest problem you'll probably have is implementing a computer simulation model of physics in comparison to the engineering and physics mathematically accurate model. With computer physics for simulation / entertainment accuracy is not important, believability is. There are things you can do in real world physics which are just too computationally intensive for real-time application. I'd suggest you try and find resources which describe these differences, I know they are out there. This should be a good way for you to learn about it as it will build upon your existing physics and engineering knowledge. I remember reading about these differences in a book called 'game programming with python' of course the language may not be useful to you but there chapters in this book are really quite impressive regardless of the programming language used. I'd suggest you find it if possible and have a read.

05 May 2007, 11:11 PM
Thanks for help Ian. I am aware of the diference since I perform structural and fluids/thermal analysis for a living. Some of my analysis have taken 30 days to solve, and thats only for a simulation that runs for a fraction of a second . I have read a bunch of papers on natural phenomena in CG also. But thatnks for reinforcing that point. Sometimes as an engineer I get caught up in making everything behave physically correct.

Here is an image of the particle engine with three different emitters.

I'm still looking for information on fields if anyone knows about them.

Thanks for the help

05 May 2007, 11:35 PM
It's not overly difficult, it's just a matter of adding if (particle is within x of deflector/attractor) then (affect velocity by y*x or y*(1-x) or whatever). This is assuming that you have a way of handling velocities that is.

The main point of implementing it, mind, is to calculate all distances as squares so if x^2+y^2+z^2 < r^2 then that's all you need to know and you can base all your equations on that with falloff calculated as appropriate.

If, of course, you want to then calculate particles bouncing off each other then you need to consider each as a small field and say that if any particle is within range then the two velocities need to be considered against each other and the result implemented and if you want something a little more than that you'll probably want to calculate all the forces acting upon each particle at any given time (although as this can be defined atomically it's best to copy the results into a new array so you don't get the new velocities mixed in while you're still calculating).

To speed all this up, have a look at KD-Trees ( as they're a very effective way of partitioning objects in 3D space as continuously rearranging the tree as objects move through space isn't quite as intensive as having to calculate distances for everything in the scene for every single frame :D

05 May 2007, 01:26 AM
Thanks for the help odubtaig. I'm glad its that easy.


05 May 2007, 06:20 AM
I decided to change it over from an OpenGL window to MFC before I add any more capabilities. I'm still haveing some animation problems though.

05 May 2007, 02:57 PM
What problems are you having? I can have a guess from the attachment that your radial distributions a little off, and this very problem has been discussed in another thread here, but I'm not sure.

05 May 2007, 04:40 PM
Hey odubtaig

Thanks for the reply, you've got good eyes I am having a problem with the distribution. It originally was square but then I remebered seeing the post you were talking about and I changed it to what was last posted. But it still has a few gliches. I tried to adjust the following but still gives me an uneven distribtion.

float angle = ((float)rand() / (float)RAND_MAX)* 3.14159f * 2.0f;
float vX = sin(angle) * emRadi;
float vZ = cos(angle) * emRadi;

The problem was that it was not emiting particles unless I rotated or translatd the scene. but I fixed that last night with this command

InvalidateRect(NULL, FALSE);

Now, I don't think that the particles are properly deleting out of memory. I'm still in the learning phase of OpenGL and windows programing. I'm more of a numerical analysis guy, put in an equation get out your answer. So if you have a better way of doing things let me know.

EDIT: It is deleting properly from memory its the timeGetTime command that I use to updat the emiter. it seems to add more and more particles as time increases.

Thanks for the help

05 May 2007, 06:42 PM
One thing I would do straight away is an optimisation. While premature optimisation may be the mother of all headaches, any optimisation that doesn't make it difficult to rewrite your code is just fine.

I would pre-define all of the equation that is always going to give the same result at the start of the code. in C this would be:

GLfloat pi_mult = (1.0f/(float)RAND_MAX)*3.14159f*2.0f;

In C++ you would use:

const GLfloat pi_mult = (1.0f/(float)RAND_MAX)*3.14159f*2.0f;

This means you only do that multiplication and division once (and division is much more costly in CPU time than multiplication) and can just have:

angle = (float)rand() * pi_mult;

Other than that, I'm not specifically seeing any problems with the code I can see, I thought it might be an execution order issue but you've quite clearly got the division bracketed off.

One thing I would be curious to know is how the value for emRadi is calculated as it's entirely possible that your angular distribution is fine but that your radial distribution is bunching up around certain values, especially if you're using a sine or cosine function to determine it.

Also, are you initialising the random seed with srand? It's important that you do if you want anything like random numbers rather than the same numbers every time.

At some point I'm really going to have to write a proper tutorial as I'm seeing particles questions cropping up more than I used to. Next thing you know peeps'll be asking about vertex shading and all sorts :eek:

05 May 2007, 11:49 PM

Thanks again for the help. I wasn't using srand. I will add it after i figure out why the emission rate is increasing with time. It was working before I moved it over to windows. Very strange.

I use gltranslate to randomly place a particle in the emitter using that function.

Thanks again

CGTalk Moderation
05 May 2007, 11:49 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.