Rotating Cluster collision with wall doesn't consider overlapping time

[brandonLi8]

Currently, when a cluster of balls that is rotating around the center of mass hits the border of the pool table, both balls have 0 velocity. This works as intended.

However, this doesn't take into account the time one of the rotating balls has been overlapping with the border.

This is taken into account for normal ball-border collisions. See https://github.com/phetsims/collision-lab/blob/master/doc/images/ball-to-border-time-of-impact-derivation.pdf

This is a problem for low frame-rate devices. I changed the step size to a much larger number locally to simulate a slow frame-rate device:

As you can see, the rotating ball overlaps with the border, when in reality the Ball hit the border in between frames.

---

At a first glance, the calculations described in the document above to find the overlapping time will probably be much much harder to do for rotating balls.

EDIT: In addition, with a high velocity center of mass, in one frame, both balls could technically be overlapping with the border, which would make this calculation even harder. In addition, since the velocities of the Balls are always changing, we cannot exploit a dot product projection as we did for normal ball-wall collisions.

[brandonLi8]

I've thought about this more. Firstly, calculating the time the ball(s) have been overlapping with the border when rotating is probably not feasible.

Secondly, I thought about maybe approximating the overlapping time based off the center of mass's velocity and the joint-bounds of the Balls at the frame it is overlapping with the border, or something along those lines. The thing is, all methods of approximating this calculation will not work for this case; an over-approximation of the overlapping time will make it look like the balls stop before it hits the wall. In reality, the amount a ball is overlapping with the border is minimal. It's unlikely the sim will actually be running at that slow of a frame rate. Even stepping the simulation with the step button (without an artificially large step size) steps doesn't induce obvious overlaps.

The only approximation that would 'work' would be to translate the balls at their current angle (relative to the center of mass) upwards so that both balls are in bounds. The computations for this wouldn't be involved (reasonable) and would be feasible.

OR we could leave the current behavior.

[brandonLi8]

@ariel-phet and I spoke about this over zoom.

Our conclusion was to try the translation strategy I outlined above as a first attempt:

The only approximation that would 'work' would be to translate the balls at their current angle (relative to the center of mass) upwards so that both balls are in bounds. The computations for this wouldn't be involved (reasonable) and would be feasible.

After I implement it, we will re-evaluate. Doing this now.

[brandonLi8]

I implemented the translation of overlapping rotating balls in the commits above.

Results look promising. No visible hiccups and it doesn't look strange.

Here's what it looks like running the sim "normally":


---

I also added a query parameter to change the step-size when pressing the step button with ?timeStepDuration= (default 0.3 seconds).

I tried the same test outlined above with timeStepDuration=1 and got:

details:


which looks pretty reasonable in my opinion for that large of a step size.

This is what it looks like with `timeStepDuration=0.3`:


which also looks reasonable.

---

I also published a recent dev version with this feature implemented: https://phet-dev.colorado.edu/html/collision-lab/1.0.0-dev.27/phet/collision-lab_en_phet.html

[brandonLi8]

At this point, this looks reasonable in my opinion and works as intended.

Assigning @ariel-phet to comment on if he thinks this approximation is a good tradeoff. @ariel-phet please close if it is, otherwise this assign back to me.

[ariel-phet]

@brandonLi8 yes I think that looks good for our learning goals! Closing