Navigation Menu

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wasd-controls flies for tens of meters during framedrops with a single key press. #4241

Closed
ngokevin opened this issue Jul 31, 2019 · 5 comments

Comments

@ngokevin
Copy link
Member

Description:

When wasd-controls became independent of frame rate, the behavior during frame drops worsened to flying at high-speeds across the world.

@dmarcos
Copy link
Member

dmarcos commented Jul 31, 2019

Any steps to reproduce? I had tested the frame independence by throttling the render loop.

@ntamas
Copy link
Contributor

ntamas commented Feb 25, 2020

I think the problem is in the incorrect handling of the scaledEasing multiplier in this commit.

The code refers to this post on Stack Overflow. In the SO post, the scaledEasing value is calculated the same way as here, but then it is simply applied as a multiplier to the current velocity to implement exponential decay. This seems to be the mathematically correct way for me to treat deceleration due to friction. However, the code in A-Frame effectively multiplies the current velocity with 1 - scaledEasing -- which means that if delta is sufficiently large (as it is after significant frame drops), we do not decrease the velocity at all (contrary to the expectation that it should decrease a lot due to friction).

I have fixed the code according to the SO post in my copy of wasd-controls because I also wanted to use the C/E keys for changing the altitude (just like the walkthrough navigation in 3DSMax), and it seems to work better.

@ntamas
Copy link
Contributor

ntamas commented Feb 25, 2020

Furthermore, the current code has another problem that manifests itself when the browser schedules a new frame in quick succession to another frame (probably because it tries to compensate for a frame drop). In Firefox, on a Macbook with an integrated Intel Iris Pro, it often happens on my machine that two new frames are rendered in less than 3 msec after a longer frame drop (~100 msec), which brings scaledEasing very close to 1. The net effect is that the velocity suddenly drops to near-zero, which is definitely not what we want.

@dmarcos
Copy link
Member

dmarcos commented Feb 25, 2020

Please share your fix. Thanks

@ntamas
Copy link
Contributor

ntamas commented Feb 25, 2020

PR sent. I did not include my additional changes that implement movement along the Y axis with E/C as that is currently outside the scope of wasd-controls. I can prepare and submit that as a separate PR if it is a good idea to extend wasd-controls with additional functionality.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants