Conversation
|
Haven't tested yet but the code looks good! I was the person who implemented the work for non-linear easing at first, but abandoned it after I failed to figure out why my example file (which included position keyframes) was failing. I'm really happy to see someone else do the rubber duck test and spot the issue I failed to see! I'll give it a go later. Bless |
|
Will this need to be ported into Interpoli as well? |
|
Yes, @atoktoto Could you also PR the same change into the https://github.com/linebender/interpoli/ repository, please? |
|
Local testing looks great. Super happy to land this; going to push a bug fix version for this as well. |
linebender/interpoli#31 made a tracking issue for that |
Fix for #31 based on linebender/velato#42. One difference is that I had to enable `mint_types` feature for `keyframe` crate dependency that pulls in `mint`. As far as I can tell the project is still `#![no_std]`.
It seems to me that most of the work to get non-linear easing is already done.
In order to check what is left to be done I removed the linear-only enforcement, created a simple example with 3 key frames and compared the results with lottielab.com editor:

I have found that:
The way I understand it is that while we are moving into position described by next key frame, we still should be using
oandiparameters from the previous one.After changing the
Time::frames_and_weightto use the easing from current key frame, positions seem to match pretty well:What do you think? Is there anything else missing to enable non-linear easing?
Thanks for creating an amazing library!