branch: priori

[brandonLi8]

From design meeting, #122, #4, #6 is a problem for the sim. The proposal is to move the collision detection to a priori. Doing this in a branch.

[brandonLi8]

In the commit above, I was able to predict ball to ball collisions before hand (priori) using a similar strategy to https://github.com/phetsims/collision-lab/blob/master/doc/images/ball-to-ball-time-of-impact-derivation.pdf except the time is forwards.

This was inspired by https://stackoverflow.com/questions/16902523/continuous-collision-detection-how-to-find-the-collision-according-to-these-2

Results are promising, but the collision response looks off. Investigating.

[brandonLi8]

Spoke with @jonathanolson about this.

• Overall, my plan for detecting collisions was good for both types of collisions.
• However, @jonathanolson recommended first detecting each collision that involves a ball (either with another ball or with the border) all at once and recording the time that collision will occur, and then responding to only the first collision that will occur and repeating the process. With this approach, the sim can handle extremely large time steps.
• We also discussed the possibility of multiple balls colliding at the exact same time. This should be handled using the same approach outlined above, where a Ball is only considered to collide with one other object. However, the response is handled successively since their colliding times are exactly the same.
• As far as storing which object a ball is colliding with and when the collision will occur, I'm going to use a data structure.

[brandonLi8]

I've tested the priori collision engine from the commits above and it works mostly well. Lots of clean up work still needs to be done and on some occasions balls can get stuck inside of the border when it is turned on after Balls have escaped. I also need to look into rewiring ball path collision detection (https://github.com/phetsims/collision-lab/issues/75) and look into how the CollisionEngine subtypes are affected.

I'm also planning to remove the documentation files from #88 and rewrite new ones for this model.

[brandonLi8]

Ball to ball collisions have been cleaned up and finished in the commits above. It works really really well. I tested for tunneling with extremely high velocity (in the order of ~20 m/s)/small radii balls and saw no tunneling from #122. I also tested with the query parameter?timeStepDuration=1 (time progressed when a step button is pressed) to simulate extremely slow frame rates and it all looked correct (both forwards and backwards).

However, I'm finding issues with ball-to-wall detection with ?timeStepDuration=1. For some reasons, the computation of how long before a ball-wall collision occurs fails when the ball hits near a corner with large time steps.

[brandonLi8]

In the commit above, I found the fix to the ball-wall detection issue.

[brandonLi8]

I've updated the CollisionEngine subtypes and I've merged this into master. Closing.