Page 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 35

Thread: Some gravity particles

  1. #21
    Wow, this became quite a practise for threads You are right again. But also with this change i could test how 32 threads would effect, and as expected, it seemed just as fast as 4 or 8 threads. And minor difference in the creation, to support odd particle counts aswell
    Code:
            for i:=0 to MAX_THREADS-2 do
              pt[i]:=TPhysicsThread.Create(FParent,
                i*tcount, (i+1)*tcount-1);
            pt[MAX_THREADS-1]:=TPhysicsThread.Create(FParent,
              (MAX_THREADS-2)*tcount, count-2);
    New version is also uploaded, and there is extra test in rendering loop commented out. I tried what it looks like when full screen clear would be replaced with slow fading to black. Particles can leave kind of trails when they move. I'm not sure if it looks better than original though, so that's why it's commented.

  2. #22
    Also (a bit akin what Dan suggested) you can play with the condition affecting when to apply the force to particle:
    Code:
    if (d > 0) and (d < DISTANCE_TO_IGNORE)
    With distance set to 15 or so gives a nice speedup in later stages, when the particles spread out.
    Smaller distances (try 5) will give you more speedup in early stages but have a more noticeable effect on particle behavior (less tight clusters).
    Larger distances (100) cause slowdown in early stages
    Dynamically tuning the "ignore distance" would probably lead to best results (2xfaster execution shouldn't be a problem).

    As per more calculation threads than cores: if threads with similar workload start competing for resources, you'll get slowdowns from overheads associated with threads, scheduling, context switching, cache trashing and so on.


    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
    Last edited by imcold; 14-06-2013 at 08:25 PM. Reason: code review

  3. #23
    Quote Originally Posted by imcold View Post
    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.
    Attached Images Attached Images

  4. #24
    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.

  5. #25
    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.
    Code:
        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.

  6. #26
    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?

  7. #27
    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.
    Code:
    dist = sqrt(v)
    d = G_FORCE / (dist*dist*dist) = G_FORCE  / (sqrt(v) * sqrt(v) * sqrt(v))
    power:
    Code:
    d^2 = G_FORCE*G_FORCE / (v * v * v)
    d = sqrt(d^2)

  8. #28
    Quote Originally Posted by SilverWarior View Post
    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

  9. #29
    Quote Originally Posted by User137 View Post
    X/Sqrt(Y)
    = (X*X)/Y , if Y>=0
    Um, no. Trivially proven by X=1, Y=2.

  10. #30
    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.

Page 3 of 4 FirstFirst 1234 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Comodo SSL