System Rain

Prozix

New Member
Reaction score
7
Then the system must perform an additional 400*32 (12800) complex calculations per second to perform something that probably detracts from the point of the system. Not a bad thought, but rain forms streams more than clumps... :p

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
 

Jesus4Lyf

Good Idea™
Reaction score
397
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.
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.
 

Lyerae

I keep popping up on this site from time to time.
Reaction score
105
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.

My brain hurts now, honestly. :nuts: :banghead:
 

quraji

zap
Reaction score
144
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.
 

Ghan

Administrator - Servers are fun
Staff member
Reaction score
889
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. :)
 

Joker(Div)

Always Here..
Reaction score
86
Change tile to snowy, Model to frost breath, size to 3, and volia! IT'S SNOWING!
lk0ex.jpg
 

Prozix

New Member
Reaction score
7
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.

Sorry, I wasn't clear, again...

attachment.php


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?)
 

Attachments

  • CollisionSquareIndexing.GIF
    CollisionSquareIndexing.GIF
    2.6 KB · Views: 449

Jesus4Lyf

Good Idea™
Reaction score
397
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...
 

Prozix

New Member
Reaction score
7
You'd have to list them at creation?
Well I was just wondering if what I said was possible :p
 

quraji

zap
Reaction score
144
>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.
 

Prozix

New Member
Reaction score
7
>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) ?
 

quraji

zap
Reaction score
144
>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).
 

Prozix

New Member
Reaction score
7
>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 :)
 

quraji

zap
Reaction score
144
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
 
General chit-chat
Help Users
  • No one is chatting at the moment.

      The Helper Discord

      Staff online

      Members online

      Affiliates

      Hive Workshop NUON Dome World Editor Tutorials

      Network Sponsors

      Apex Steel Pipe - Buys and sells Steel Pipe.
      Top