System Rain

Discussion in 'Systems and Snippets' started by Jesus4Lyf, Jun 30, 2009.

  1. Prozix

    Prozix New Member

    Ratings:
    +7 / 0 / -0
    What if you divide the rain area in several smaller areas :p. Ultimately updating more and more rain drops in puddles will take more calculations per second.... ultimately.

    Hahah I set the lifespan ticks to 200 and changed the timer speed to 0.01. The world was being shot by blue bullets xD
     
  2. Jesus4Lyf

    Jesus4Lyf Good Idea™

    Ratings:
    +394 / 0 / -0
    Excuse me, 400*32 was wrong, it should be 80,000*32 (2,560,000). The distribution of the drops is irrelevant. It's O(n^2) for manual collision detection of locusted units.
     
  3. Lyerae

    Lyerae I keep popping up on this site from time to time.

    Ratings:
    +105 / 0 / -0
    My brain hurts now, honestly. :nuts: :banghead:
     
  4. quraji

    quraji zap

    Ratings:
    +143 / 0 / -0
    I think it would be 80,200 operations to check collisions between 400 units. O(n^2) is excessive (which for 400 drops would be 160,000 not 80,000 right?)..

    Also, wouldn't it be less since you would only be considering the raindrops that are not falling? And would it shrink further as any "puddles" got larger (if you would consider the puddle to be one large drop)?

    Just wondering.
     
  5. Ghan

    Ghan Administrator - Servers are fun Staff Member

    Ratings:
    +773 / 0 / -0
    I put LIFESPAN_TICKS at 2000 and the fps leveled out around 10-15, with it going below 10 when I would head over to the bottom right corner where lots of the drops liked to congregate. :)
     
  6. Joker(Div)

    Joker(Div) Always Here..

    Ratings:
    +86 / 0 / -0
    Change tile to snowy, Model to frost breath, size to 3, and volia! IT'S SNOWING!
    [​IMG]
     
    • Like Like x 2
  7. Prozix

    Prozix New Member

    Ratings:
    +7 / 0 / -0
    Sorry, I wasn't clear, again...

    [​IMG]

    The green dot is in the area C3, so collision checking needs to occur only with units in the area C3. The blue dot is in the areas (A,B)(4,5) so this one needs to check collisions with units in 4 areas.

    I'm wondering if the indexing of the units in areas every now and then can result in a performance optimization.

    Lets say we have 4 areas with in all of those 10 units. Normally this would take 40+39+38...+1 = (40²-40)/2 = 780 calculations
    With the units indexed this would approximately take 4*(10+9+8...+1) = 180 calculations.
    If you double calculate the differences (n²) then it becomes 1600 vs 400.

    The problem would be the algorithm to accomplish this...

    (and btw isn't it 400²/2-200 = 79800?)
     

    Attached Files:

  8. Jesus4Lyf

    Jesus4Lyf Good Idea™

    Ratings:
    +394 / 0 / -0
    As far as I know, it is not possible to enumerate locusted units an an area whatsoever. Hence, as far as I know, I would have to compare all raindrops to all other raindrops. :)

    There's probably optimisations which could be done, but it just isn't going to happen. It wasn't the objective for this system...
     
  9. Prozix

    Prozix New Member

    Ratings:
    +7 / 0 / -0
    You'd have to list them at creation?
    Well I was just wondering if what I said was possible :p
     
  10. Jesus4Lyf

    Jesus4Lyf Good Idea™

    Ratings:
    +394 / 0 / -0
    Every raindrop is indexed. You could manually set a raindrop's region to a region struct and maintain a linked list on the struct of each raindrop in the region, yes. There's all kinds of stuff you could do. :)
     
  11. quraji

    quraji zap

    Ratings:
    +143 / 0 / -0
    >The green dot is in the area C3, so collision checking needs to occur only with units in the area C3. The blue dot is in the areas (A,B)(4,5) so this one needs to check collisions with units in 4 areas.

    What if a raindrop was in the center-right of one cell, and another in the center-left of an adjacent cell to the first cell's right? Wouldn't they merge?

    >(and btw isn't it 400²/2-200 = 79800?)

    Edit: That's correct, I made an error.
     
  12. Prozix

    Prozix New Member

    Ratings:
    +7 / 0 / -0
    >What if a raindrop was in the center-right of one cell, and another in the center-left of an adjacent cell to the first cell's right? Wouldn't they merge?

    they can be in multiple areas like it said:

    >>The blue dot is in the areas (A,B)(4,5) so this one needs to check collisions with units in 4 areas.

    Wouldn't full collision checking be 400*(400-1) ?
     
  13. quraji

    quraji zap

    Ratings:
    +143 / 0 / -0
    >they can be in multiple areas like it said:

    I guess my scenario isn't really a problem. Only in a perfect world :p

    >Wouldn't full collision checking be 400*(400-1) ?

    Full as in checking every drop against every other drop only once, n*(n-1) would be excessive (it would check drops A vs. B, then later B vs. A which isn't necessary).
     
  14. Prozix

    Prozix New Member

    Ratings:
    +7 / 0 / -0
    >I guess my scenario isn't really a problem. Only in a perfect world:p
    Well I think that if they collide, the radius's (radiusi? radia? radiusculae?) have to overlap, when they overlap one another at least one of them has got to cover multiple area's because the indexing should be done like this: (UnitX-UnitR < RectMaxX and UnitX+UnitR > RectMinX) and (something similar for Y)

    >Well if you check each drop against eachother the equotation becomes 0.5(n-1)n
    Imagine 4 points, the first one connecting with 3 others, the next one only has to connect with 2, the third one with 1 and the last one with 0 because it was already connected by all points. That makes 3+2+1 = 6
    5 points make 4+3+2+1 connections -> (4+1)+(3+2) = 2*5
    6 points: (5+1)+(4+2)+3 -> 2*6+3 = 2.5*6
    n points: ((n-1)+1)+((n-2)+2) ... = eugh I suck at explaining it but I figured that the formula becomes (n²-n)/2 :)
     
  15. quraji

    quraji zap

    Ratings:
    +143 / 0 / -0
    Yes, that's the formula I was describing when I said: (n-1)+(n-2)+(n-3)...+(n-n), but I an error when I actually calculated it :p

    >Well I think that if they collide, the radius's (radiusi? radia? radiusculae?) have to overlap, when they overlap one another at least one of them has got to cover multiple area's because the indexing should be done like this: (UnitX-UnitR < RectMaxX and UnitX+UnitR > RectMinX) and (something similar for Y)

    Also true, I was thinking as if the drops would have 0 radii and would merge when they were within a certain distance, instead of merging when their radii intersected. That would be where the problem of being "close enough to merge" but being in separate grid cells would arise. Didn't really spend time thinking it through I guess :p
     
  16. Weep

    Weep Godspeed to the sound of the pounding

    Ratings:
    +400 / 0 / -0
  17. Prozix

    Prozix New Member

    Ratings:
    +7 / 0 / -0
    Right.... there goes the efficiency :p
     
  18. kingkingyyk3

    kingkingyyk3 Visitor (Welcome to the Jungle, Baby!)

    Ratings:
    +216 / 0 / -0
  19. Weep

    Weep Godspeed to the sound of the pounding

    Ratings:
    +400 / 0 / -0
    That has nothing to do with what I posted, which didn't use any area enumerations on locusted units.
     
  20. azareus

    azareus And you know it.

    Ratings:
    +63 / 0 / -0
    My computer began lagging 1 min in at 3000. Über comp lol.
     

Share This Page