How to get balls colliding with other balls - elastic collision?

[carlo.b...@gmail.com]

Hi i'm new here and so im not sure if im posting this in the right section (forgive me if i am).

My problem is trying to get balls colliding with other balls at the proper angles. I have somewhat of an idea of the physics behind it, but I am not sure how to do this in appinventor2.

Any feedback is most appreciated.

[Scott Ferguson]

Ball EdgeReached and Ball Bounce work pretty well when a ball reaches the edge of a canvas to make it bounce in a realistic fashion.

Ball CollidedWith tells you if a ball has collided with another ball or ImageSprite, but how you handle a rebound is not defined.

I suppose if you had an ImageSprite bumper that could be turned to different Heading values, then you could (with the right formula) calculate a rebound angle for a ball when it collides with an ImageSprite.

But a flat side is easier to deal with than the round edge of a ball.

If you can find a formula to calculate the rebound angle for a ball that strikes another ball at a specific angle and know the angle at the surface where they meet you might be able to use the Ball Speed and Heading properties to send it in the correct rebound direction.

If you want to add more realism you could use the area of the balls to represent  a relative mass to make a smaller ball rebound faster.

Sorry, that I don't have the formulas at hand.

This would be much simpler if App Inventor had a physics engine.

---

Scott

[Rob Higbie]

The contact angle would be established by a line connecting the centers of the 2 balls.  I found a bunch of equations!

[Abraham Getzler]

Here's a link to a Doc covering ball on ball collision in AI2,
with sample code ...

https://docs.google.com/document/d/1vMOewOPYmN4gzbDiXJgLeCQ1W5MzuT7ogXQqV96R0P8/edit?usp=sharing

ABG

[Rob Higbie]

Well, at last I created a "physics engine" for this.  I called it "Fizz'N 2D Ball Collisions",  (Get it?  Fizz'N = Phys En.  Anyone want to collaborate on it?)  I posted the source code in the gallery.  I intend to beta release it in Google Play Store soon, too...

Fling the (white) cue ball toward one of three colored target balls to begin the action.  When a collision is detected between the cue ball and a target ball, the line of impact is determined by a line connecting the centers of the two colliding balls.  Then the incoming velocity vectors are broken down into components along and perpendicular to the line of impact.  Outgoing velocities along the line of impact are then calculated using conservation of momentum.  Outgoing velocities perpendicular to the line of impact are not affected by the impact.  Finally, outgoing velocity components are recombined into outgoing velocity vectors.  If desired, vectors may be displayed for each collision. (Collisions between target balls are not detected in this implementation.)

Next steps:

• I might incorporate Mr. Getzler's cannibalism-prevention code when implementing collisions between target balls
  
• Sometimes balls "stick" together.  I probably need to do some interpolation between intervals or something like that.
• Friction model is very simplistic and a seems a little unrealistic to me.  Maybe I need to think about F=ma.
• Elasticity (other than edge bounce which I already have)
• Add sprite capability
• Add rotations

I have some concerns about the lack of continuously smooth, fluid operation.  On my device, at least, there is a periodic hesitation.  Other Play Store games have much more on-screen activity and yet seem very fluid.  Is this an inherent limitation of App Inventor, or something related to inefficiencies in  my code?

[Abraham Getzler]

@Rob
You certainly have added Cadillac options.
Steering and responsiveness are somewhat lacking on the emulator.
I suspect the line drawing and redrawing is slowing it down.
Maybe setting some rotatable vector sprites in motion might help,
or pop up a second impact analysis screen?
Launching the cue ball is a drag, man.
When you get around to setting up shots, you will
discover directional anomalies.
True pause/resume requires saving speeds and headings.
You will eventually need lists of lists as your ball count increases.

Feel free to copy from my latest study for the pause/resume,
cannibalization, and directionality problems.
https://docs.google.com/document/d/1vMOewOPYmN4gzbDiXJgLeCQ1W5MzuT7ogXQqV96R0P8/edit?usp=sharing
ABG

[Rob Higbie]

Thanks for the tips and encouragement Abraham!  I incorporated your cannibalization and ball lists it is working as expected.  For the next update, I've decided to omit vector drawing entirely now that the physics is working.  (It was useful to me while debugging the core collision code, but it added a lot of unnecessary clutter in the blocks.)

[Abraham Getzler]

Adding drag blocks for the balls would be easy, and would allow
you to test your collision math in 8 directions by setting up shots.

ABG