Add some basic tests for easing functions#16675
Closed
scottmcm wants to merge 1 commit intobevyengine:mainfrom
Closed
Add some basic tests for easing functions#16675scottmcm wants to merge 1 commit intobevyengine:mainfrom
scottmcm wants to merge 1 commit intobevyengine:mainfrom
Conversation
Contributor
Author
|
The tests fail: see the mentioned issue for discussion. |
IQuick143
added
C-Testing
BenjaminBrienen
added
the
S-Blocked
Contributor
|
Marking this as blocked on fixing #16676 with another PR, at which point this can be rebased and the tests should then pass. |
Contributor
Author
|
Pulled these tests into #16910, so closing this PR. |
github-merge-queue bot
pushed a commit
that referenced
this pull request
Dec 24, 2024
…6910) And add a bunch of tests to show that all the monotonic easing functions have roughly the expected shape. # Objective The `EaseFunction::Exponential*` variants aren't actually smooth as currently implemented, because they jump by about 1‰ at the start/end/both. - Fixes #16676 - Subsumes #16675 ## Solution This PR slightly tweaks the shifting and scaling of all three variants to ensure they hit (0, 0) and (1, 1) exactly while gradually transitioning between them. Graph demonstration of the new easing function definitions: <https://www.desmos.com/calculator/qoc5raus2z>  (Yes, they look completely identical to the previous ones at that scale. [Here's a zoomed-in comparison](https://www.desmos.com/calculator/ken6nk89of) between the old and the new if you prefer.) The approach taken was to keep the core 2¹⁰ᵗ shape, but to [ask WolframAlpha](https://www.wolframalpha.com/input?i=solve+over+the+reals%3A+pow%282%2C+10-A%29+-+pow%282%2C+-A%29%3D+1) what scaling factor to use such that f(1)-f(0)=1, then shift the curve down so that goes from zero to one instead of ¹/₁₀₂₃ to ¹⁰²⁴/₁₀₂₃. ## Testing I've included in this PR a bunch of general tests for all monotonic easing functions to ensure they hit (0, 0) to (1, 1), that the InOut functions hit (½, ½), and that they have the expected convexity. You can also see by inspection that the difference is small. The change for `exponential_in` is from `exp2(10 * t - 10)` to `exp2(10 * t - 9.99859…) - 0.0009775171…`. The problem for `exponential_in(0)` is also simple to see without a calculator: 2⁻¹⁰ is obviously not zero, but with the new definition `exp2(-LOG2_1023) - FRAC_1_1023` => `1/(exp2(LOG2_1023)) - FRAC_1_1023` => `FRAC_1_1023 - FRAC_1_1023` => `0`. --- ## Migration Guide This release of bevy slightly tweaked the definitions of `EaseFunction::ExponentialIn`, `EaseFunction::ExponentialOut`, and `EaseFunction::ExponentialInOut`. The previous definitions had small discontinuities, while the new ones are slightly rescaled to be continuous. For the output values that changed, that change was less than 0.001, so visually you might not even notice the difference. However, if you depended on them for determinism, you'll need to define your own curves with the previous definitions. --------- Co-authored-by: IQuick 143 <IQuick143cz@gmail.com>
pcwalton
pushed a commit
to pcwalton/bevy
that referenced
this pull request
Dec 25, 2024
…vyengine#16910) And add a bunch of tests to show that all the monotonic easing functions have roughly the expected shape. # Objective The `EaseFunction::Exponential*` variants aren't actually smooth as currently implemented, because they jump by about 1‰ at the start/end/both. - Fixes bevyengine#16676 - Subsumes bevyengine#16675 ## Solution This PR slightly tweaks the shifting and scaling of all three variants to ensure they hit (0, 0) and (1, 1) exactly while gradually transitioning between them. Graph demonstration of the new easing function definitions: <https://www.desmos.com/calculator/qoc5raus2z>  (Yes, they look completely identical to the previous ones at that scale. [Here's a zoomed-in comparison](https://www.desmos.com/calculator/ken6nk89of) between the old and the new if you prefer.) The approach taken was to keep the core 2¹⁰ᵗ shape, but to [ask WolframAlpha](https://www.wolframalpha.com/input?i=solve+over+the+reals%3A+pow%282%2C+10-A%29+-+pow%282%2C+-A%29%3D+1) what scaling factor to use such that f(1)-f(0)=1, then shift the curve down so that goes from zero to one instead of ¹/₁₀₂₃ to ¹⁰²⁴/₁₀₂₃. ## Testing I've included in this PR a bunch of general tests for all monotonic easing functions to ensure they hit (0, 0) to (1, 1), that the InOut functions hit (½, ½), and that they have the expected convexity. You can also see by inspection that the difference is small. The change for `exponential_in` is from `exp2(10 * t - 10)` to `exp2(10 * t - 9.99859…) - 0.0009775171…`. The problem for `exponential_in(0)` is also simple to see without a calculator: 2⁻¹⁰ is obviously not zero, but with the new definition `exp2(-LOG2_1023) - FRAC_1_1023` => `1/(exp2(LOG2_1023)) - FRAC_1_1023` => `FRAC_1_1023 - FRAC_1_1023` => `0`. --- ## Migration Guide This release of bevy slightly tweaked the definitions of `EaseFunction::ExponentialIn`, `EaseFunction::ExponentialOut`, and `EaseFunction::ExponentialInOut`. The previous definitions had small discontinuities, while the new ones are slightly rescaled to be continuous. For the output values that changed, that change was less than 0.001, so visually you might not even notice the difference. However, if you depended on them for determinism, you'll need to define your own curves with the previous definitions. --------- Co-authored-by: IQuick 143 <IQuick143cz@gmail.com>
ecoskey
pushed a commit
to ecoskey/bevy
that referenced
this pull request
Jan 6, 2025
…vyengine#16910) And add a bunch of tests to show that all the monotonic easing functions have roughly the expected shape. # Objective The `EaseFunction::Exponential*` variants aren't actually smooth as currently implemented, because they jump by about 1‰ at the start/end/both. - Fixes bevyengine#16676 - Subsumes bevyengine#16675 ## Solution This PR slightly tweaks the shifting and scaling of all three variants to ensure they hit (0, 0) and (1, 1) exactly while gradually transitioning between them. Graph demonstration of the new easing function definitions: <https://www.desmos.com/calculator/qoc5raus2z>  (Yes, they look completely identical to the previous ones at that scale. [Here's a zoomed-in comparison](https://www.desmos.com/calculator/ken6nk89of) between the old and the new if you prefer.) The approach taken was to keep the core 2¹⁰ᵗ shape, but to [ask WolframAlpha](https://www.wolframalpha.com/input?i=solve+over+the+reals%3A+pow%282%2C+10-A%29+-+pow%282%2C+-A%29%3D+1) what scaling factor to use such that f(1)-f(0)=1, then shift the curve down so that goes from zero to one instead of ¹/₁₀₂₃ to ¹⁰²⁴/₁₀₂₃. ## Testing I've included in this PR a bunch of general tests for all monotonic easing functions to ensure they hit (0, 0) to (1, 1), that the InOut functions hit (½, ½), and that they have the expected convexity. You can also see by inspection that the difference is small. The change for `exponential_in` is from `exp2(10 * t - 10)` to `exp2(10 * t - 9.99859…) - 0.0009775171…`. The problem for `exponential_in(0)` is also simple to see without a calculator: 2⁻¹⁰ is obviously not zero, but with the new definition `exp2(-LOG2_1023) - FRAC_1_1023` => `1/(exp2(LOG2_1023)) - FRAC_1_1023` => `FRAC_1_1023 - FRAC_1_1023` => `0`. --- ## Migration Guide This release of bevy slightly tweaked the definitions of `EaseFunction::ExponentialIn`, `EaseFunction::ExponentialOut`, and `EaseFunction::ExponentialInOut`. The previous definitions had small discontinuities, while the new ones are slightly rescaled to be continuous. For the output values that changed, that change was less than 0.001, so visually you might not even notice the difference. However, if you depended on them for determinism, you'll need to define your own curves with the previous definitions. --------- Co-authored-by: IQuick 143 <IQuick143cz@gmail.com>
mrchantey
pushed a commit
to mrchantey/bevy
that referenced
this pull request
Feb 4, 2025
…vyengine#16910) And add a bunch of tests to show that all the monotonic easing functions have roughly the expected shape. # Objective The `EaseFunction::Exponential*` variants aren't actually smooth as currently implemented, because they jump by about 1‰ at the start/end/both. - Fixes bevyengine#16676 - Subsumes bevyengine#16675 ## Solution This PR slightly tweaks the shifting and scaling of all three variants to ensure they hit (0, 0) and (1, 1) exactly while gradually transitioning between them. Graph demonstration of the new easing function definitions: <https://www.desmos.com/calculator/qoc5raus2z>  (Yes, they look completely identical to the previous ones at that scale. [Here's a zoomed-in comparison](https://www.desmos.com/calculator/ken6nk89of) between the old and the new if you prefer.) The approach taken was to keep the core 2¹⁰ᵗ shape, but to [ask WolframAlpha](https://www.wolframalpha.com/input?i=solve+over+the+reals%3A+pow%282%2C+10-A%29+-+pow%282%2C+-A%29%3D+1) what scaling factor to use such that f(1)-f(0)=1, then shift the curve down so that goes from zero to one instead of ¹/₁₀₂₃ to ¹⁰²⁴/₁₀₂₃. ## Testing I've included in this PR a bunch of general tests for all monotonic easing functions to ensure they hit (0, 0) to (1, 1), that the InOut functions hit (½, ½), and that they have the expected convexity. You can also see by inspection that the difference is small. The change for `exponential_in` is from `exp2(10 * t - 10)` to `exp2(10 * t - 9.99859…) - 0.0009775171…`. The problem for `exponential_in(0)` is also simple to see without a calculator: 2⁻¹⁰ is obviously not zero, but with the new definition `exp2(-LOG2_1023) - FRAC_1_1023` => `1/(exp2(LOG2_1023)) - FRAC_1_1023` => `FRAC_1_1023 - FRAC_1_1023` => `0`. --- ## Migration Guide This release of bevy slightly tweaked the definitions of `EaseFunction::ExponentialIn`, `EaseFunction::ExponentialOut`, and `EaseFunction::ExponentialInOut`. The previous definitions had small discontinuities, while the new ones are slightly rescaled to be continuous. For the output values that changed, that change was less than 0.001, so visually you might not even notice the difference. However, if you depended on them for determinism, you'll need to define your own curves with the previous definitions. --------- Co-authored-by: IQuick 143 <IQuick143cz@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Objective
Context for #16676
The release notes nerd-sniped me again. I was looking at the
EaseFunction::Exponential*definition and wondering why that specific definition was chosen. And looking into it I noticed that it seemed wrong and there weren't any tests, so here are those tests -- which are failing as proof.Solution
I don't know what the best answer is here, but I think having tests is at least a good start for a discussion.
Testing
These are tests 🙂