Camera: Modify Camera Movement to work off of time, instead of frame rate, revisited #14809
Conversation
|
Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s). |
|
Snapshot stored with reference name: Test environment: To test a playground add it to the URL, for example: https://babylonsnapshots.z22.web.core.windows.net/refs/pull/14809/merge/index.html#WGZLGJ#4600 Links to test babylon tools with this snapshot: https://playground.babylonjs.com/?snapshot=refs/pull/14809/merge To test the snapshot in the playground with a playground ID add it after the snapshot query string: https://playground.babylonjs.com/?snapshot=refs/pull/14809/merge#BCU1XR#0 |
|
WebGL2 visualization test reporter: |
|
Visualization tests for WebGPU (Experimental) |
|
Visualization tests for webgl1 have failed. If some tests failed because the snapshots do not match, the report can be found at If tests were successful afterwards, this report might not be available anymore. |
|
Would be great to understand what impacted the particles changes as much ? |
I think that it's because I changed the constant frame time value from 16 to 1000 / 60 |
|
This pull request has been marked as stale because it has been inactive for more than 14 days. Please update to "unstale". |
|
This pull request has been marked as stale because it has been inactive for more than 14 days. Please update to "unstale". |
|
I just want to reiterate that this PR will introduce a new variable for each of the inertial types (eg. |
Posting as reference for @sebavan, @bghgary, @RaananW, and @Popov72 |
|
Visualization tests for WebGL 1 have failed. If some tests failed because the snapshots do not match, the report can be found at If tests were successful afterwards, this report might not be available anymore. |
This PR contains modified changes from these PRs:
The big difference is that there were new variables added to each of the camera's movement values (eg.
pendingCameraDirectionforcameraDirection) that will take a user's desired movement value, calculate what value is needed to move for the initial value to match the previous movement, and decay the inertial movement over time. It should be noted that the "pending" variables will only hold their values until consumed by the_checkInputsfunction is called by its corresponding camera. All of the inertial values will only be populated with the new values inside of the_checkInputsfunction.The expected behavior is that the 60 FPS behavior should be the same. Any initial values added to a "pending" variable will move with respect to the same time frame as 60 FPS (eg. A pending movement value at 60 FPS will take one frame and 120 FPS will take around two frames)