Some gravity particles

[User137]

Edit: you have an error within the last statement, (MAX_THREADS-2) should be (MAX_THREADS-1), otherwise the last thread will get more stars than it should (the same ones as in the prev. thread, not to mention it won't work with one thread

Just noticed that myself. I was testing with randseed:=1 just to see if i get same results with 1 thread or many. It crashed the moment i tried to set it on 1 thread Also 1 thread didn't result same kind of universe than 2 or more threads.

But that's fixed now. I added more debug info, like how many physics ticks are calculated, print out how many threads are used. Changed the visuals slightly, so that blue particles aren't add-blended, and there is the slow fade-to-black only when it is unpaused.

[imcold]

The visuals are really cool Final note for the threads - the load isn't distributed evenly between them, given the same amount of stars, the one with lower starting index does more cycle iterations. That's most likely why you see a speedup with more threads - the bigger the discrepancy, the more difference thread count does. Also, physicsthread.WaitFor on formClose; no need for thread counter at all.

[User137]

I realized today that while 3D is great, is not necessary to simulate the gravity particle effect, or should you call it "anti-gravity". This can be done in 2D, with big gain in performance, and better results to look at.

Now after testing it a little, it didn't seem to work somehow, or maybe i'm missing something. I also think that i'm able to rid of Sqrt() completely.

    for i:=FFirst to FLast do
      with star[i] do
        for j:=i+1 to count-1 do begin
          xx:=v.x-star[j].v.x;
          yy:=v.y-star[j].v.y;
          d:=xx*xx+yy*yy;
          if d>0 then begin
            d:=(G_FORCE*G_FORCE)/(d*d*d); // Compiler should optimize the constant multiplication to 1 value
            // If not, just remove multiplication and change G_FORCE value
            if star[j].positive<>positive then d:=-d;
            vec.x:=(star[j].v.x-v.x)*d;
            vec.y:=(star[j].v.y-v.y)*d;
            movement.x:=movement.x+vec.x;
            movement.y:=movement.y+vec.y;
            star[j].movement.x:=star[j].movement.x-vec.x;
            star[j].movement.y:=star[j].movement.y-vec.y;
          end;
        end;

The particles scatter endlessly, with no clear groupings done as was in 3D. I have tried with many different parameters. I wouldn't want to make boundaries to the "universe", where particles would bounce backwards, but i might have to. I also tried with every particle being same polarity, and they still did not group. It's not because of removal of sqrt(), that was almost last step in my tests, improvement to calculation time i'd say.

[SilverWarior]

Based on the code it seems you are only applying force to [j] particle and not to [i] particle at the same time.
Haven't you been calculating force between two particle once and then applying that force to both of your particles at once?

[User137]

Based on the code it seems you are only applying force to [j] particle and not to [i] particle at the same time.
Haven't you been calculating force between two particle once and then applying that force to both of your particles at once?

If i set NUM_TOTAL = 2; and 2 opposite particles, they start pushing eachother away in opposite direction, as should. Same code as before, i just commented Z-related lines. "with star[i] do" on second quoted line refers to "i" particle.

I didn't do the math before, i was thinking it might still be relatively same effect.

sqrt(4)*sqrt(4)*sqrt(4)
= 2*2*2 = 8

= sqrt(4*4*4)
= sqrt(64) = 8

X/Sqrt(Y)
= (X*X)/Y , if Y>=0

[imcold]

X/Sqrt(Y)
= (X*X)/Y , if Y>=0

Um, no. Trivially proven by X=1, Y=2.

[User137]

Oh crap... this is how it actually goes:
X / Sqrt(Y)
= (X*Sqrt(Y)) / Y
which puts us back to square 1... on why doesn't it work, or works like that even when using sqrt? I have tried decreasing, but also increasing the G_FORCE to compensate lack of particle density in depth direction. But at the same time there is a more uniform force pulling every direction, from the overall system.

[imcold]

The modified "d" calculation doesn't produce the same values as the previous equation if you take out the sqrt, so the effect has to be different.

dist = sqrt(v)
d = G_FORCE / (dist*dist*dist) = G_FORCE  / (sqrt(v) * sqrt(v) * sqrt(v))

power:

d^2 = G_FORCE*G_FORCE / (v * v * v)
d = sqrt(d^2)