If you remember from the old thread I started with vectors I'm still working on it in my spare time and I've gotten the balls to bounce off of each other realistically but when they come to rest I would like them to settle out realistically. At the moment some balls that are slightly off center and on top of each other fall off and settle ok while others tend to "stick" like with the old problem I had so what you get is 4 or 5 balls all on top of each other but leaning in a way they should topple over, but I don't know how to make them more fluidic so that occurs. I saw a demo by Marcello IIRC that was a physics water type demo and that's pretty much how these particles should settle out, going to the state of least resistance or whatever.

Here is my current code:

Thanks for all the help I recieved on the old thread.

The first suggestion isn't going to work because you need to check the particle you are checking for collsions against, against all particles in the list, not just ones on or after it. Making it j = i causes particles earlier in the list fall through particles later in the list so it's an incorrect assumption. I think I'm leaving it as C syntax at the moment because it's just source and it has nothing to do with my problem, thanks for the suggestion though. The third suggestion is probably closest to something that may be what I need to do but I don't think it worked unless I did something wrong

Either way it still makes the particles now act like ice where they melt into one big conglomeration and not the way they are supposed to. Mabe it's just the shape of the particles or something that's causing them to act as such.. I could try changing the size and see what happens... I dunno.

I didn't check your code or anything, but I think the problem is that when you collide one particle with another you are doing point math...not sphere math. When a ball falls on another ball(ignoring the bounce of the 2nd ball) the ball will "roll" off because it's a ball.

Here, think this may have the math required to make the particles roll off each other: [url http://www.gamasutra.com/features/20000516/lander_pfv.htm]

EDIT: and if that doesn't help make particles roll off each other in your demo...at least you can try pool table physics!

EDIT: well if that didn't help...here's a theory that is probably wrong but may help a bit: When a particle/ball collides with another ball(not a flat wall) then have the reflection vector be perpendicular to the angle between the centers of the two balls/particles. That way the ball will be forced(roll) away from the other ball. Although in reality this is wrong...really what happens is the ball rolls off the other ball...causing it to continue to roll away. This algo wont make the ball continue to roll away. Maybe use the rolling algo stuff from the document I posted to hack in some roll...*shrugs*

If you haven't already done so, after determining that a collision occured, you should reset the ball locations so that they're no longer overlapping and just touching. This could solve problems where even after moving the balls after a collision, the balls still overlap, causing an unwanted collision with opposite vectors as a result.

Second, you need to implement a static physics model. In other words, forces on objects in addition to just momentum. If after a collision, if a static (2nd) ball cannot move in the "resulting" direction, then (a) the first moving ball new velocity vector must be recalculated such that it the second ball is like an immovable surface, [edit] well not quite, but this would be a good start [/edit] (b) you must transmit forces [edit] (look up momentum, forces, impulse) [/edit] from the 2nd ball to any other static ball it touches, and (c) apply gravitational force [edit] (not just "acceleration", since the ball could be held up by other balls) [/edit] to every static ball as well so they would eventually push balls out of the way if they're free to do so.

I discovered one more bug... it's possible (by clicking many times at exactly the same X coordinate) to cause two balls to have exactly the same positions. If that happens, then the vector_normal call in the collision handling will produce weird results, causing velocities to become Not a Number, and then then balls go to the lower left hand corner and start eating any other balls that touch them (you'll see what I mean). This can be fixed by adding a check in the collision code, if ((particles<i>.pos.x == particles[j].pos.x) && (particles<i>.pos.y == particles[j].pos.y)) continue;

Anyway, speed: you don't have any code timing the thing to the clock, so what happens is that with few balls the speed is limited by the rendering, and with many balls the speed is limitted by the physics. Here's some performance numbers off of my computer:

circumstance     rendering physics total
with 0 balls:    8 ms      0 ms    8 ms
with 235 balls:  9 ms      9 ms    18 ms

If you want it to go faster with 235 balls, you can do a few things:
1. Optimize your physics to go faster. Generally this would involve sorting or categorizing your balls somehow based upon their positions. There's lots of algorithms available, some are pretty easy, some are rediculously complex. Some libraries (including my own PMASK 4 & 5) include helpers for this.
2. Do your physics more times per rendering - if you did physics twice per frame, then with 235 balls you'd get about 37 fps on my computer (compared to the current ~55), but the balls moving 33% faster than they currently do, with the same precision of physics.
3. Increase the average velocity of your balls : ) (though the quality of collision calculations would suffer).