Slow motion is a bit jerky

[arouinfar]

@kathy-phet said:

One question I noticed when playing with it that I was wondering about... the slow motion appears to be somewhat jerky because it basically jumps between positions like the step button does ... or at least that is what it looks like it does. Is there a way the animation could be smoother in slow motion, maybe adding some in between timesteps so that it is smooth motion?

I agree that slow motion could look smoother, but I think the dots also create an illusion that the animation is a little jerkier than it actually is. Regardless, I think it would be good for @andrea-phet to look into @kathy-phet's suggestion.

[andrealin]

I have looked into this and find it hard to come up with a solution that wouldn't either change a lot of the model or worsen performance. How important is this?

[arouinfar]

Thanks @andrea-phet. I think that's really a question for @kathy-phet or @ariel-phet, so I'm reassigning the issue to them.

[kathy-phet]

I think its worth a conversation with JO to see if he sees an option.

[kathy-phet]

I think it would only need to have this smoother action during a "slow mode" setting, not say adding a smaller timestep at all times.

[arouinfar]

Sounds good @kathy-phet! Reassigning to @andrea-phet and @jonathanolson.

[jonathanolson]

There are a few options to handle this.

Interpolation

I recommended (very briefly) interpolation between model steps in https://github.com/phetsims/projectile-motion/issues/49 (like wave-on-a-string and potentially other simulations that have a larger fixed-DT timestep, smooth animation between those is desired).

The proper way to do this is to compute the two large-timestep states that we are "between", determine how far from the "start" to the "end" we are in every timestep, and blend those two states together to determine where the projectile should be.

Allowing the trajectory to adjust in-between states would be complicated and probably not visibly noticeable, so computing the trajectory steps as they are now sounds good (with the added interpolation added on).

Variable-timestep model

Looking into whether we can include air friction into a fully integration-based approach may allow for enough precision to get by with variable timesteps (e.g. Pendulum Lab, where the model includes friction in the Runge Kutta integration which gives the necessary precision).

This would allow the projectile's motion to be very smooth, but a bit of extra effort would be required to evenly space the visible points on the path.

Also important to note is that Pendulum Lab's integration needs 10 steps per frame to get the desired ~11 digits of precision, so this could increase computational cost (whereas interpolation would have the highest potential performance). NOTE: This is probably why we can't just "switch to a smaller timestep for slow motion", because it wouldn't land in the same place, and readouts may show the difference in trajectories.

[jonathanolson]

My first thoughts would be to look into the variable-timestep model (as the current way of handling friction leads to accumulation of error due to the timesteps).

Any objections?

[arouinfar]

@jonathanolson spoke with @kathy-phet and it sounds like it's worth some investigation (possibly in a branch in case things get messy). Do you have time to work with @andrea-phet and @jbphet on this?

[kathy-phet]

@ariel-phet - We could also consider improvements in slow motion for a version 1.1 and release with the current model for this school year fall use.

[ariel-phet]

@andrea-phet I think improvements for slow motion are fine to leave for a later version (step is far more beneficial in this sim than slow motion in my opinion)

[kathy-phet]

OK -- Deferred it is!

[matthew-blackman]

Looking at this again since the lack of smoothness in slow motion is noticeable. I was able to significantly improve the smoothness of slow motion by decreasing the TIME_PER_DATA_POINT constant (see video below). This seems like a start but needs to be discussed and optimized. Will discuss with @zepumph.

TIME_PER_DATA_POINT = 25ms

https://user-images.githubusercontent.com/108756567/206749297-1dafc85e-1ba1-4b4d-91d0-cc2bcdfbe1c1.mp4

TIME_PER_DATA_POINT = 10ms

https://user-images.githubusercontent.com/108756567/206749324-6bd8f125-f7cb-4c15-95e3-46e037799d4d.mp4

[matthew-blackman]

@zepumph and I met with @jonathanolson to discuss this, based on this post - https://github.com/phetsims/projectile-motion/issues/124#issuecomment-321070508

We discussed the following:

• Being able to dynamically change air resistance makes it unviable to precisely calculate the path of the trajectory via integration.
• Using a dynamic timestep creates issues with the frame that the user switches between slo-mo and realtime. This could be accounted for, but would require a refactor. There is also an issue with reproducibility of trajectories with air resistance. Since we are integrating to find the trajectory with air resistance, a variable timestep will cause inconsistency in the projectile's path when timestep is changed.
• Interpolation could work, but would require a refactor as well as handling of the edge-cases for apex and landing positions. Additionally, predicting the future model state could conflict with user input (air resisance/gravity sliders).

With this in mind, we recommend changing the TIME_PER_DATA_POINT to a lower value, and dealing with potential consequences that come with creating additional data points as they arise.

Closing this issue as slow motion is much smoother with these changes and we haven't encountered any performance issues.

[matthew-blackman]

TIME_PER_DATA_POINT is currently set to 12 ms. Slow motion is much smoother with these changes and we haven't encountered any performance issues. @arouinfar can you review slow motion?