1D set-ups not working on 2D screen (vertical velocity creeps in)
Closed this issue · 11 comments
In the 2D screen, we should be able to set up a 1D situation, and ball collisions should not introduce motion in the other dimension if they are centered on each other with no y components of velocity. However after 2 collisions the balls start to have vertical velocity. Found at design meeting last week. Can you take a look at this Brandon? Fixing this physics is blocking for publishing the prototype. Thanks.
Related to phetsims/qa#524
@brandonLi8 I tested this in master before design meeting yesterday, and the 1D collisions were behaving correctly on the 2D screens. However, it's definitely buggy in the latest dev.
@brandonLi8 actually, I think I figured out why it was working for me yesterday. If you use the keypad to set the y-position and Vy to zero, 1D collisions behave normally. If you drag the ball or velocity vector with the mouse, the actual value probably just rounds to zero.
Is it possible to make sure the model values exactly match the view when dragging the balls or vectors?
Is it possible to make sure the model values exactly match the view when dragging the balls or vectors?
Technically this is possible, but I think it could be ugly. Essentially, balls would be snapping to super small grid lines (when grid is off) and to the normal grid lines (when grid is on). We would also have to snap the velocity to the super small grid-lines. From one of our design meetings, I remember that we didn't want to snap the velocity vector but I don't remember why.
I haven't been able to reproduce this locally. @arouinfar can you describe steps to reproduce or comment a video?
OK, I see what the issue is. I think the interaction could be improved with this sort of approach:
-
when grid is off and user is dragging the ball, it is moving freeform.
-
user drops the ball, and when that happens the sim detects and rounds the balls position to the second decimal (So if the ball is dropped at 0.0002, the position of the ball is moved ever so slightly to 0.00 and then set).
-
this rounding would only happen on mouse up (e.g. ball drop).
-
it would need to behave nicely with the other code that prevents overlap.
-
basically the goal and behavior of this would mean that if you drop the ball the initial setting value you see in the data table for position is accurate and doesn't have values you cannot see.
-
similar behavior can occur with dragging velocity vector. it is moving freely and then when you do mouse up it rounds to two decimal places.
I think that would work to avoid this situation of thinking you are doing 1D but not succeeding at it?
Good to know that this isn't an issue with the physics engine, rather an issue with setting up balls.
@kathy-phet I think snapping ball position/velocity to the nearest hundredth decimal on mouse release sounds good. The only part that I'm concerned about is this point:
it would need to behave nicely with the other code that prevents overlap.
I'm not quite sure how this would work. One way (the most feasible) would be to snap to the nearest 0.01 only when a ball is NOT dropped on top of other balls. If it is dropped on top of other balls, the same "bumping" code is used where the ball is moved next to the overlapping ball. @arouinfar @kathy-phet thoughts?
Hi Brandon,
Could the bumping code round after bump with a test that if normal rounding creates an overlap that it does rounding in the other direction?
So if 1.28903 rounds to 1.29 and that has overlap - that it rounds in the other direction to 1.28 - and if that has overlap, it does something else so that it doesn't end in an infinite loop?
@kathy-phet @arouinfar this should be done in the commits above. Please review in master.
Here is exactly how it works (if you are curious):
- Round each component of the ball velocity vector on drag release to the nearest 0.01.
- For the ball position, it is a bit more complicated.
- First, the sim rounds each component of the ball position vector on drag release to the nearest 0.01.
- Then, it checks for overlapping balls. If there are overlapping balls, it does the same bumping algorithm except it rounds the direction vector upwards. The direction vector is the vector that describes where to place a bumped ball from the center of the overlapping ball. It is rounded "upwards" by rounding the magnitude of the direction vector upwards to the nearest 0.01. The same old algorithm is still used to exit infinite loops.
Thanks - this seems like it will work. I'll check it out!
Works great on my quick test!! Awesome - so nice to set it with just the mouse and see the expected 1D behavior. Thank you!
@brandonLi8 this is looking really nice!