But I was wondering if it is possible to calculate the rate of change (speed graph). I tried like this which did not work. If the calculation works out perfectly, I will have a constant rate of change of linearEase only for each t.
Sorry @mootari it took me a while. My end goal is to visualize ease and to be able to see both value and speed. In After Effects, you can see both value and speed graph for any given AE ease and I am trying to find a way to see if it is possible to achieve the same for a given d3 ease. Since Ease makes or breaks an animation, I want to be able to see how the speed changes over time when I am assigning ease (now, that I can also assign CSS easings, thanks to @Fil ).
I have done something like this and here is a relevant notebook.
To obtain the speed data, I have rounded the derivative calculation and I am not 100% sure if that was the correct approach. But, without rounding, the derivative values were extremely weird. I used linear as a test case for derivative and the speed should be equally same for all t. Without rounding, I could not achieve it. If you can please let me know if rounding was the correct approach for derivative calculation, I should be good (I like to think that value calculations are okay and they probably match to this)
In my opinion, the speed graph provides more insight into easing than the value graph. Therefore, I prioritize ensuring the accuracy of the speed graph. Let’s take the QuadOut easing function as an example. While the value graph depicts the change in position, the speed graph effectively illustrates the sharp deceleration of the animation property change over time, which aligns with the intended easing effect. Unless the author is familiar with the specific animation easing equation and constructs a chart accordingly beforehand, it is difficult to determine the intended easing effect before assigning the ease.
Regarding the implementation, I am not familiar with Plot, and since Observable is not my production environment, I prefer to utilize d3.js and a different production environment for my solution.
I’m not sure what you mean by that. You’re measuring during a live transition, with all the noise that is introduced by the browser. The shorter the transition, the fewer samples you have and the noisier the resulting data gets.
This is not exclusive to Observable; rather, it’s quite generally the case that selectors of greater specificity will be more performant and less error prone. The need for this grows with the complexity of the environment.
More generally, Observable encourages good programming practices that will serve you well in other environments. You should not dismiss these practices because references on D3 written several years ago don’t use these techniques.
@mcmcclur May thanks; after referring to your notebook, I can see that my work produces an identical speed grpah to yours. So coming back to my original question on this “Should I round the values of the derivatives of the live interpolation data” - The answer is probably yes, cause by doing this it generated an identical speedGraph to yours.
I will move on now to CSS Easing. I have longed for a speedGraph for so many years for easing (and I could not think of bringing one to life till I started with d3. d3 is super awesome, to say the least) and I like to think I am directionally correct with my approach to chart live interpolation data both for position and speed.
@mootari just so I understand, so you are asking me to perform this task with data that is not based on interpolation (as I have originally done. By “interpolation”, I meant data generated out of live transition). So, create static data first based on the easing function and chart based on that.
I feel we may be using different definitions of “interpolation”.
Your example samples values during a live transition. These samples aren’t evenly spaced because the transition steps don’t occur at perfectly even intervals. Unless your easings are somehow guided by factors that you don’t know beforehand, there is no benefit in doing it this way.
Instead you’d pick the sample size (e.g. 1000 as in my example), and then calculate the eased values, and from those calculate the rate of change for every sample.
Visualizing that rate of change gives you your speed graph, at a precision of your own choosing.