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

Give additional "tween delta" property to custom easing functions? #396

Closed
jessegrosjean opened this issue Jan 2, 2015 · 1 comment
Closed

Comments

@jessegrosjean
Copy link

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.

if (percentComplete === 1) {
    currentValue = tween.endValue;
/* Otherwise, calculate currentValue based on the current delta from startValue. */
} else {
   // OLD currentValue = tween.startValue + ((tween.endValue - tween.startValue) * easing(percentComplete));

    // NEW
    var tweenDistance = (tween.endValue - tween.startValue);
    currentValue = tween.startValue + (tweenDistance * easing(percentComplete, tweenDistance));

    /* If no value change is occurring, don't proceed with DOM updating. */
    if (!firstTick && (currentValue === tween.currentValue)) {
        continue;
    }
}

Here's my custom easing function (as described above), might help explain what I'm trying to do:

Velocity.Easings.birchEasing = function(p, tweenDistance) {
    tweenDistance = Math.abs(tweenDistance);

    var tension = 1.5,
        friction = 7;

    if (tweenDistance > MaxSpringDistance) {
        var over = Math.abs(tweenDistance / MaxSpringDistance);
        if (over > 1) {
            friction += over * 0.1;
            if (friction > 20) {
                friction = 20;
            }
        }
    }

    return 1 - (Math.cos(p * tension * Math.PI) * Math.exp(-p * friction));
}

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.

@julianshapiro
Copy link
Owner

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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants