But isn't.
... Constant rate of motion = linear interpolation (e.g. pos = startpos + scalar * (endpos - startpos))
Whereas a non-linear rate of motion - more specifically 'cubic hermite' interpolation aka 'smoothstep' would better suit:
Code:
float smoothstep(float edge0, float edge1, float x)
{
// Scale, bias and saturate x to 0..1 range
x = clamp((x - edge0)/(edge1 - edge0), 0.0, 1.0);
// Evaluate polynomial
return x*x*(3 - 2*x);
}
pos = startpos + smoothstep(0.0, 1.0, scalar) * (endpos - startpos)
Basically creates more of a swing in acceleration from the start and deceleration towards the final resting state, but as a deterministic function.
If you're animating this in the shader then check the docs as they probably already have a smoothstep intrinsic function supported for use here.
That's what I would have done if I just wanted to have some smooth swing-in
'n out, yet I'm on a different slope here. I'm not really doing screen
transitions, not yet, they are a by-product resulting from a testbed of mine
to please me and others over here. The transition is physically based to give
me a flexibility I need for another part of a project of mine (i.e. modulating
the velocity of a video beam). With respect to the transition example, am
integrating a force (here "gravity" for the sake of an example, to let the
columns fall under "gravity") two times to get position resulting in a
quadratic function. However, there is a linear term as well stemming from
integrating the acceleration to account for the initial velocity, unless
the initial velocity is zero. I've set the initial velocity quite high to push
the effect forward. If the initial velocity (in this case) is larger than the
force, then the linear term dominates for a specific amount of time until the
quadratic term takes over, which is the case in my example, yet a lil too late
to show the quadratic fall in full effect as you have recognize. Good
suggestions nevertheless. I appreciate! :+
