Should the skater be allowed to go underground?

[jessegreenberg]

Discovered as something that causes #430, but I find it a little strange that the skater is allowed to go below ground. We should handle the case in #430, but I am wondering if a broader issue is that the skater is allowed to go underground at all. @arouinfar @samreid, what do you think?

[arouinfar]

@jessegreenberg I also find it odd that the skater can go underground. Is there a reasonable way to prevent this? If the red point under the skateboard gets to h < 0, does the skater just "fall" off and sit on the ground next to the track? This method wouldn't prevent all underground cases, such as when the skater is only partially underground.

I think the bigger issue is what happens to the skater's energy when underground. In the screenshot above and in https://github.com/phetsims/energy-skate-park-basics/issues/432#issue-343765766, PE is greater than zero (since the red dot is above the ground). However, in https://github.com/phetsims/energy-skate-park-basics/issues/430#issue-343171015, the skater has negative PE, so the energy representations -- particularly the pie chart -- break down.

That said, I'm more concerned with preventing negative PE than a partially-underground skater.

[jessegreenberg]

If the red point under the skateboard gets to h < 0, does the skater just "fall" off and sit on the ground next to the track?

I tried this, but found a few other cases where h can be less than zero while dragging a control point, mostly while dragging a control point. The track bumps above ground at the end of the dragging interaction rather than during, which is why portions of the track can currently reach h < 0.

Can we ensure that the track rather than just the control points remain above zero while dragging?

[jessegreenberg]

That behaves strangely because it bumps up on every move.

[jessegreenberg]

This bug is only possible because the skater continues to move before the track is shifted above ground on release.

One option is that we could stop skater movement and reset energies while dragging the track. Sort of like how we "reset" the energy when the skater is grabbed. Is it important for skating to continue while dragging the track?

Another option (not too sure yet how this would impact performance) would be to prevent the track rather than control points from going below ground, so dragging a control point, track would be constrained to this:

Rather than this:

Perhaps that would feel broken? Or maybe there is another option. @arouinfar what do you think?

[samreid]

There is code that bumps the track to always be above y=0. We could change that to be y>=SKATER_HEIGHT, but then you could never make a parabola with y=0.

I don't think it's too confusing for the skater to pass in front of the ground--it is already somewhat unusual that the skater is hanging to the track like a roller-coaster, but hitting the ground would disrupt the motion and maybe distract from what the user is trying to see.

[jessegreenberg]

I agree @samreid. I think the larger concern that @arouinfar pointed out is that it is possible to have a temporary negative PE. There is code that bumps the track above y=0 when a control point is released, but it is not bumped up while the user is dragging. And while this is happening the skater continues to move.

[jessegreenberg]

Is the issue great enough that it needs to be resolved prior to the release of the upcoming LoL/phet-io version?

[arouinfar]

One option is that we could stop skater movement and reset energies while dragging the track. Sort of like how we "reset" the energy when the skater is grabbed. Is it important for skating to continue while dragging the track?

@jessegreenberg resetting the skater's energy seems a bit inconvenient, particularly if a user is trying to fine-tune the track (for example, to made the loop a bit shorter).

Another option (not too sure yet how this would impact performance) would be to prevent the track rather than control points from going below ground, so dragging a control point, track would be constrained to this:

That certainly sounds good, but I'd also be worried about performance.

Is the issue great enough that it needs to be resolved prior to the release of the upcoming LoL/phet-io version?

This seems like more of an edge case to me, so it wouldn't be critical for LoL, but not 100% sure about PhET-iO.

[ariel-phet]

@arouinfar @jessegreenberg @samreid here are my thoughts on this particular issue

1. I checked the java version of ESP, the skater can go underground in that one. So it would appear this behavior has been around for a LONG time, and I don't think it has caused any issues or concerns

2. To get the skater to have a negative PE take a very specific track arrangement, the skater skating on the "back side" of the track, the user moving the track while the skater is moving such that the skater can go under ground, and once the track is released, it pops back up to where the track is not below ground. (So I think a pretty specific edge case)

3. My experience with this sim is that tweaking the model/track algorithm can lead to lots of unintended consequences given the very sandbox nature of the sim. I think such tweaks should be carefully considered before investing the time.

Basically, I think this is a strong case of "it is not particularly broken, lets not fix it"

[arouinfar]

That seems reasonable to me @ariel-phet, given that creating a situation with negative PE is more of an edge case.

When height < 0, it looks like the the model assumes (sets?) PE = 0, and the total energy is unaffected. For ESPB, I think that's acceptable.

[jessegreenberg]

Thanks everyone, sounds good. Closing this issue.