Duration for Kinetic Scrolling (Momentum) Based On Velocity?

i'm trying to implement kinetic scrolling of a list object, but i'm having a problem determining the amount of friction (duration) to apply based on the velocity.

my applyFriction() method evenly reduces the velocity of the scrolling object based on a duration property. however, using the same duration (IE: 1 second) for every motion doesn't appear natural.

for motions with a small amount of velocity (IE: 5 - 10 pixels) a 1 second duration appears fine, but applying friction over a 1 second duration for motions with lots of velocity (IE: 100+ pixels) the scrolling object will appear to slow and stop much faster.

essentially, i'm trying to determine the appropriate duration for each motion so that both small and large amounts of velocity will share a matching friction, so the moving object will appear to always have a constant "weight".

is there a general algorithm for determining the duration of kinetic movement based on different ve开发者_StackOverflow中文版locities?

note: i'm programming in ActionScript 3.0 and employing the Tween class to reduce the velocity of a moving object over a duration.

A better model for friction is that the frictional force is proportional to velocity. You'll need a constant to determine the relationship between force and acceleration (mass, more or less). Writing the relationships as a difference equation,

F[n] = -gamma * v[n-1]
a[n] = F[n]/m
v[n] = v[n-1] + dt * a[n]
     = v[n-1] + dt * F[n] / m
     = v[n-1] - dt * gamma * v[n-1] / m
     = v[n-1] * (1 - dt*gamma/m)

So, if you want your deceleration to look smooth and natural, instead of linearly decreasing your velocity you want to pick some constant slightly less than 1 and repeatedly multiply the velocity by this constant. Of course, this only asymptotically approaches zero, so you probably want to have a threshold below which you just set velocity to zero.

So, for example:

v_epsilon = <some minimum velocity>;
k_frict = 0.9; // play around with this a bit

while (v > v_epsilon) {
    v = v * k_frict;
    usleep(1000);
}

v = 0;

I think you'll find this looks much more natural.

If you want to approximate this with a linear speed reduction, then you'll want to make the amount of time you spend slowing down proportional to the natural log of the initial velocity. This won't look quite right, but it'll look somewhat better than what you've got now.

(Why natural log? Because frictional force proportional to velocity sets up a first-order differential equation, which gives an exp(-t/tau) kind of response, where tau is a characteristic of the system. The time to decay from an arbitrary velocity to a given limit is proportional to ln(v_init) in a system like this.)

i had looked into this problem before: why does Android momentum scrolling not feel as nice as the iPhone?

Fortunately, a guy already got out a video camera, recorded an iPhone scrolling, and figured out what it does: ^archive

flick list with its momentum scrolling and deceleration

---

When I started to work [on this], I did not pay attention carefully to the way the scrolling works on iPhone. I was just assuming that the deceleration is based on Newton’s law of motion, i.e. a moving body receiving a friction which is forced to stop after a while. After a while, I realized that this is actually not how iPhone (and later iOS devices such as iPad) does it. Using a camera and capturing few dozens scrolling movement of various iOS applications, it came to me that all the scrolling will stop after the same amount of time, regardless the size of the list or the speed of the flick. How fast you flick (which determines the initial velocity of the scrolling) only determines where the list would stop and not when.

This lead him to the greatly simplified math:

amplitude = initialVelocity * scaleFactor;
step = 0;

ticker = setInterval(function() {
    var delta = amplitude / timeConstant;
    position += delta;
    amplitude -= delta;
    step += 1;
    if (step > 6 * timeConstant) {
        clearInterval(ticker);
    }
}, updateInterval);

In fact, this is how the deceleration is implemented in Apple’s own PastryKit library (and now part of iAd). It reduces the scrolling speed by a factor of 0.95 for each animation tick (16.7 msec, targeting 60 fps). This corresponds to a time constant of 325 msec. If you are a math geek, then obviously you realize that the exponential nature of the scroll velocity will yield the exponential decay in the position. With a little bit of scriblling, eventually you find out that

325 = -16.7ms / ln(0.95)

Giving the motion:

Your question was about the duration to use. i like how the iPhone feels (as opposed to Android). i think you should use 1,950 ms:

- (1000 ms / 60) / ln(0.95) * 6 = 1950 ms