pouët.net

from psonice

Hi, psonice here, about that scrolling :D

I'm hopefully going to get to the scrolling part later today, so it could be good to share some ideas / code.

What I'm writing is basically a photo library viewer, where it shows a grid of thumbnails (that can be scrolled), and tapping an image will zoom it in to fullscreen. The whole thing is done in openGL (on iOS), and I'm basically writing it from the ground up. Which is frustrating as hell, since iOS has a decent photo library viewer, and I've written my own using the system APIs already, but this needs to do some 'special' stuff :/ So far the thumbnail screen is running and the tap-selection/zoom part is working (just getting the interpolation right, which is tricky for zoom + move somehow!)

Next up will be scrolling, although it'll be complicated because I have to load / unload thumbnails in on the fly, otherwise it's going to be slow + crashy if I pre-load all the (possibly thousands) of thumbnails at once :(

At the moment I'm thinking straight linear deceleration should be enough. Something like this:

1. When the finger leaves the screen, get the distance between the last 2 sampled positions (more than 2 + smoothing might be better), divide by time between samples to get velocity.
2. Update velocity per frame using "v -= friction;" where friction is a constant.
3. Move display position per frame by v to scroll.

There's probably a massive flaw in my logic, there usually is :D What do you reckon?

Oh, these might be helpful, a bunch of 'missing features' for animation:

// clamps X in the range A..B
#define CLAMP(X,A,B) MAX(A, MIN(X, B))
// Interpolates between A and B, position set by X
#define MIX(A,B,X) A*(1.-X)+B*X
// Smooth in/out transition. X should be in 0..1 range.
#define SMOOTHSTEP(X) X*X*(3.-2.*X)
// Accelerate in transition. X should be in 0..1 range.
#define ACCELERATE(X) X*X
// Decelerating transition. X should be in 0..1 range.
#define DECELERATE(X) 1.-(1.-X)*(1.-X)

from Graga

Cool about the photo viewer, I hope it has a nice twist to it!

So, I'm writing my list in Unity3D because I want to make my app to be cross platform from its birth. Exactly what is does is a little more secret, but right now I have implemented nothing but lists anyway, so no harm in showing you ;-)

I went around and looked at the scrolling behavior of my Android phones. I sadly don't have an iPhone to test with, but I knew I liked the way that my phones scroll already, so I'll just stick with that.

From their lists, I have observed that there seems to be 3 "phases" in the scrolling:
Unemcumbered movement (for a split second)
Decelerating movement
Full stop when the velocity reaches a certain threshold.
At least it feels like that. If you look at your phone, maybe you can find somewhere that behaves similarly ("Weee!" - "Slowing down" - "Full stop!").

From my own own failed implementation attempts, this it what I have to say:
Physically based models are not the way to go. Deceleration is either wrong or takes way too long.
You really should let the list come to rest quite quickly (see the last phase of Android's behavior that I described ago).

The problem about linear deceleration is, that while it mimics friction, it has an exponential relationship between the initial velocity of the object and the total distance travelled.

I got tired of typing characters into my e-mail window at this point (I am afraid it becomes hard to understand) and went on to create a graph (see attachment).

I also attached a little test for you using the theory that I just talked about. It requires that you install the Unity3D webplayer, but it is a very unintrusive piece of software.

Here is my code-snippet:

Code: float touchDrag_releaseTime = // Time when the list was released //; listPosition = Vector3.MoveTowards(listPosition , target, Mathf.Abs(touchDrag_velocity) * Time.deltaTime * 0.9f); touchDrag_velocity *= Mathf.Pow(Mathf.Max(0.1f, 1f - (Time.time - touchDrag_releaseTime) * 4f), Time.deltaTime);

Let me know what you think / if that was useful.

from psonice
Cool, I'm going to take a good look through this in a minute (I've literally just got scrolling working, so momentum is next :)

Quick thought though: if you do a fast swipe, you want to travel further down the list. So momentum must be linked to initial velocity, and the deceleration time can't be constant.

Also, how are you planning to handle the end of the list? I know this is different between iPhone and some (not all) android phones. The 'easy way' is just to stop, but it's much more natural if there is a 'rubber band' effect, where it scrolls past the end and bounces back.

from psonice

Ah, ok. Your unity thing scrolls as expected (linear relationship between velocity + scroll distance, I should pay more attention :)

I'm going to put your code into grapher, see what it looks like, but it 'feels' good.

from psonice

Interesting - your scrolling seems to have a rapid initial falloff, then a gradual falloff (assuming I've got the maths right there).

I've just compared it with what apple do on the iPhone too. It seems apple have 2 different scrolling methods, for different situations (possibly 'short list' and 'long list'?):

1. Rapid (possibly linear) deceleration. This seems to happen in emails, where you don't normally scroll very fast.
2. Gradual deceleration (feels a lot like my 2nd graph, but might be a higher power). This happens on the main email list, which is long and generally scrolled through faster.

I'm going to try that 2nd method first, see how it goes.

After much fucking around with powers and curves, this works beautifully for me:

Code: scrollVelocity *= 1. - frameDuration * 4.; if( fabsf( scrollVelocity ) < 0.01) <end scrolling>

Set the scroll velocity to the distance moved per frame initially. I'm using signed velocity, it seems easier than tracking speed and direction separately. The 4 on the end is deceleration speed.

Once again, the old rule "if it's difficult, you're probably over thinking it" is true :D

Chris

from Graga

Velocity Curves
Great, thanks for the graphcs. I spent some time doing my own plotting after I saw yours.

I forgot to tell you that when my velocity reaches a certain threshold, it stops (like the 3 phases in android)

In my program, initial speeds range between 1,000 and 10,000. When a velocity falls under 500, I stop it dead in order to avoid slug-like movement.

If you look at my plots, the fall-off is actually close to linear... so I suppose you can use a linear fall-off, as long as you scale it to the initial velocity! Are you gonna try that? :)



Rubberbanding / End of lists
About the end of lists, I'm considering between rubber-banding and "heat" overlays like in this demo: http://www.youtube.com/watch?v=sZaW29Rh5u0

Averaging velocity over several frames
One thing that can be a little irritating about my scrolling is that you can some times get insane speeds if you just sample your velocity over one frame. So I might consider experimenting with something like:

Code:touch_velocity = 0.5 * (this frames raw velocity + last frames raw velocity)

I really like how your scrolling feels at low speeds, but at high speeds I feel that velocity falls too quickly.

Velocity Curves
Great, thanks for the graphcs. I spent some time doing my own plotting after I saw yours.

I forgot to tell you that when my velocity reaches a certain threshold, it stops (like the 3 phases in android)

In my program, initial speeds range between 1,000 and 10,000. When a velocity falls under 500, I stop it dead in order to avoid slug-like movement.

If you look at my plots (attached), the fall-off is actually close to linear... so I suppose you can use a linear fall-off, as long as you scale it to the initial velocity! Are you gonna try that? :)

Rubberbanding / End of lists
About the end of lists, I'm considering between rubber-banding and "heat" overlays like in this demo: http://www.youtube.com/watch?v=sZaW29Rh5u0

Averaging velocity over several frames
One thing that can be a little irritating about my scrolling is that you can some times get insane speeds if you just sample your velocity over one frame. So I might consider experimenting with something like:

touch_velocity = 0.5 * (this frames raw velocity + last frames raw velocity)

from psonice

Interesting - your scrolling seems to have a rapid initial falloff, then a gradual falloff (assuming I've got the maths right there).



I've just compared it with what apple do on the iPhone too. It seems apple have 2 different scrolling methods, for different situations (possibly 'short list' and 'long list'?):

1. Rapid (possibly linear) deceleration. This seems to happen in emails, where you don't normally scroll very fast.
2. Gradual deceleration (feels a lot like my 2nd graph, but might be a higher power). This happens on the main email list, which is long and generally scrolled through faster.

I'm going to try that 2nd method first, see how it goes.