pahgawk

14 ms·

1. 1.▲
   by pahgawk 1y ago

   You're right, it's not that expensive! The main limiting factor for me is that not all animations play monotonically forward in time. I'm also interested in using these in animation software where you have a timeline and can
2. 2.▲
   by pahgawk 1y ago

   true! I suppose you'd risk getting some oscillations in the anticipation depending on the scale of the force, but that could be desirable, or might not happen if the scale is small enough, and certainly makes the math a little easier
3. 3.▲
   by pahgawk 1y ago

   Author here -- kicking myself because this is way better lmao
4. 4.▲
   by pahgawk 1y ago

   Hi, author here! Two things come to mind: - Part of my use case is that I build animation software. In there, you've got a timeline, and you can seek anywhere on the timeline. So in that scenario, you're not always moving consiste
5. 5.▲
   by pahgawk 1y ago

   Thanks for sharing this library! Author of the post here, I'll definitely check out your implementation.
6. 6.▲
   by pahgawk 1y ago

   Author here! Nice, thanks for taking the time to create that demo! I also like the look of commenting out `vel.set(0, 0)` when the anticipation target is reached, as it has less "snap" between velocities. Although if you keep velo
7. 7.▲
   by pahgawk 1y ago

   This is good! Although I'd also say that initial velocity doesn't quite cover what I was talking about in the post -- even anticipation arguably can start from 0 velocity, accelerate backwards, decelerate, then accelerate in the
8. 8.▲
   by pahgawk 1y ago

   Hi, author here! When writing this, I was thinking more in the space of procedural character animation and motion graphics than UI animations. That's part of why I want a system with nice parameters, so that I do have the ability to fi