jacksonmj:

It's newtonian gravity that's based on FFTW.

 

Also, I suspect heat simulation isn't really optimised in all possible ways...

 So what's heat simulation based on then?

@Bekas (View Post)

 Are you copying the copy back to the original array? That would explain dissapearing particles, don't do it if you are.

And as for performance concerns, multithreading the logic in theory is simple. Seperate threads will improve performance and the easiest way will to have multiple arrays storing particle data, and each array is assigned a different processing thread. As long as the threads are load balanced and frame time restricted there wont be any discrepancies against how the 1 thread method would simulate.

^ Didn't come accross to clear, what I meant was have Draw, Logic, Logic. Each logic thread has an array which stores approximately 50% of the particle data. Making a copy for the draw method will be required for this.

I Really, Really hate to bring up an old thread, but i think the people here need to understand something, and while im no master programmer, these are my 2 cents. Lets say you add in 2 core capabilities, switching simulating particles over the cores. Each core would be checking where a particle could move before it did move, or "collisions" to be clear. And if the 2 threads tried to put a particle in the same spot, shit wouldnt work. Therefore, there would be tons of overhead Splitting up simulation calculations over the threads and making sure that particles that were calculated on separate threads couldnt move into the same "empty space" when their collisions were calculated. Not only would this be insanely difficult to do, even though there is an extremely buggy old version of tpt that uses 2 cores that basically has the problems ive specified, but it would end up taking so much time to double check everything was working properly that you would get no performance gain at all. 

Now a solution could be split up functions over threads. Possibly make a quad threaded version that runs the simulation, gravity, rendering and heat on different threads, and all have them "report" back to the simulation thread.

Sorry for posting on a dead thread

I dont think the renderer being a frame behind would be that much of an issue, seeing as how splitting things up would give a performance boost and most likely stay at 60fps most of the time keeping the "framelag" to 1/60th a second, which is not bad at all