-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Give additional "tween delta" property to custom easing functions? #396
Comments
I'll be integrating this in tonight's release. Stay tuned for commit log. |
Rycochet
pushed a commit
that referenced
this issue
Aug 3, 2020
Closes #293. You can now pass a `tween` property for creating arbitrary tween callbacks via the `progress` function. Refer to VelocityJS.org/#progress for more information. Created e/p/o shorthands for elements/properties/options syntactic sugar arguments syntax. Refer to VelocityJS.org/#arguments to learn more. Closes #368. The stop command now has increased targeting for `queue: false` animations, and is more robust. Refer to VelocityJS.org/#stop for more. Closes #396. Easing functions are now passed `opts` and `tweenDelta` so that custom easing functions can have greater access to animation parameters. Refer to VelocityJS.org/#easing for more. Closes #343. Differently-colored border colors don’t throw off `border-color` animation anymore. Closes #321. Implements “finish” feature for prematurely stopping current animations, but having them reach their end values and trigger their corresponding callbacks. Refer to VelocityJS.org/#finish for more. Closes #352. Prevents Firefox from throwing an error when animating an SVG element that isn’t being visually rendered. Closes #317. Array compacting now happens within ticks to ensure loops don’t cause arrays to bloat. Thanks so much, @marvelousNinja! Closes #324. HTML tables and tbody’s now have their proper display values set by Velocity. Thanks so much to @dtreiter and @okrad! Closes #371. Looping `backgroundPositionX/Y` to 100% causes a proper incrementing loop instead of alternation.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I use spring easing in for my animations. But the distances that I'm animating things very greatly. For example I'm using animations to "expand" and "collapse" branches in an outline. This issues is that there's no single easing function that works for all values in a nice way. In particular if the branch is really big then the "bounce" effect becomes much to large. On the other hand if I boost the friction up, then the bounce effect isn't noticeable when expand/collapsing smaller branches.
Because of this I'd like some way to dynamically calculate the easing function based on the tween values. For example if I'm animating a value from 0 to 100 then I'll leave in the default spring function. But if I'm animation a value from 0 to 1000 I would like to boost the friction value a bit so that the bounce effect doesn't reach cartoon proportions.
Right now I'm doing what I want by modifying Velocity.js as shown below (see OLD vrs NEW)
Does that make sense? Or is there a better way to solve this problem.
Here's my custom easing function (as described above), might help explain what I'm trying to do:
Here's a rough demo:
http://codepen.io/anon/pen/bNBayR
Note that when the first (red) paragraph is collapsed the physics are OK... meaning they are not to much of a distraction. On the other handle when the second (green) paragraph collapses the bounce is just to much.
Both animations use the same easing function, it's just that the distance (height) being animated is different. And while the spring physics are consistent between the two, the results are not really desirable. I don't want my user to a bounce as big as in the second green case even if it is consistent spring physics, it's just to distracting.
So my idea for a fix is to pass in an additional tweenDistance into the easing function. And have the function adjust it's internal physics parameters based on that. In my example when the tween distance is larger then more friction is added (I don't know much about spring physics... maybe that "friction" label is wrong, but it seemed to do what I wanted :)).
In this example nothing is getting fixed because Velocity hasn't been modified (as described in my first post) to pass in that tween value, so that logic is being skipped. But if it was, then the second case should have a less distracting animation I think.
Hope that helps.
The text was updated successfully, but these errors were encountered: