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

Fix "withDecay clamps position to the wrong boundary" #4591

Merged
merged 5 commits into from
Jun 27, 2023

Conversation

Latropos
Copy link
Contributor

@Latropos Latropos commented Jun 20, 2023

Summary

Closes #4508

Bug description

BEFOREAFTER
Animation looks good if and only if the animated square has no positive velocity (velocity towards center of screen). In other case it moves much too fast and clamp to the opposite position with no bouncesIf square has some positive velocity it moves visibly faster. Square always bounces when approaching clamp limit (with rubber band effect on).
Screen.Recording.2023-06-20.at.11.27.36.mov
Screen.Recording.2023-06-26.at.16.48.00.mov

Description of code change

I've removed a condition updating the derivative only when square is within predefined boundaries - since we want to keep its springified movement even if it is overshooting. Especially that we used to end animation almost immediately after exceeding limits.

Since after this change the derivative is always modified we should no longer compare it to zero, but use some epsilon instead.

Test plan

I've tested it on this example: https://github.com/MatiPl01/reanimated-issues, linked in the issue.

@Latropos Latropos requested a review from piaskowyk June 20, 2023 10:05
@Latropos Latropos marked this pull request as ready for review June 20, 2023 10:23
piaskowyk
piaskowyk previously approved these changes Jun 20, 2023
@@ -38,6 +38,7 @@ export interface InnerDecayAnimation
current: number;
}

const EPSILON = 0.01;
Copy link
Member

@tomekzaw tomekzaw Jun 21, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't it too much? What about 1e-3?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Latropos I know that you discussed this with Tomek offline, but let's write the conclusion in a comment to keep the informations in one place, please 🙏

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure! We want to have similar precision for decay and withSpring. Also we have tested, that it works well with const EPSILON = 0.01; and that we animate static spring for long time if epsilon is smaller.

Copy link
Member

@piaskowyk piaskowyk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As we discussed it last time, let's merge it, and add more "real life physic" behaviour in another PR.

@Latropos Latropos added this pull request to the merge queue Jun 27, 2023
Merged via the queue into main with commit bbc755b Jun 27, 2023
@Latropos Latropos deleted the acynk/decay-bug-fix branch June 27, 2023 10:23
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

Successfully merging this pull request may close these issues.

withDecay clamps position to the wrong boundary
3 participants