System Rain

[Prozix]

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...

What if you divide the rain area in several smaller areas . 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]

What if you divide the rain area in several smaller areas . 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]

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]

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]

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

Change tile to snowy, Model to frost breath, size to 3, and volia! IT'S SNOWING!

 

[Prozix]

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...

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

 

[Jesus4Lyf]

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]

You'd have to list them at creation?
Well I was just wondering if what I said was possible

 

[Jesus4Lyf]

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.

 

[quraji]

>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]

>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]

>they can be in multiple areas like it said:

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

>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]

>I guess my scenario isn't really a problem. Only in a perfect world
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]

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

>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

 

[Weep]

As far as I know, it is not possible to enumerate locusted units an an area whatsoever.

Pseudocode:

call ForGroup(raindrops, UnitRemoveAbility(GetEnumUnit(), 'Aloc'))
call Enum(bleah)
call ForGroup(raindrops, UnitAddAbility(GetEnumUnit(), 'Aloc'))

 

[Prozix]

Right.... there goes the efficiency

 

[kingkingyyk3]

Pseudocode:

call ForGroup(raindrops, UnitRemoveAbility(GetEnumUnit(), 'Aloc'))
call Enum(bleah)
call ForGroup(raindrops, UnitAddAbility(GetEnumUnit(), 'Aloc'))

The group native is unable to get the locusted units by using Inxxxx stuffs.

 

[Weep]

The group native is unable to get the locusted units by using Inxxxx stuffs.

That has nothing to do with what I posted, which didn't use any area enumerations on locusted units.

 

[azareus]

My computer began lagging 1 min in at 3000. Über comp lol.