F-Curve imprecisions for exponential interpolation #62958

New Issue

Alexander Court · 2019-03-26T11:11:21+01:00

Alexander Court commented

2019-03-26 11:11:21 +01:00

System Information
Operating system: Win10
Graphics card: GTX 1070

Blender Version
07f6be87a9
Worked: (optional)

Short description of error
Exponential interpolation introduces a "jump" for the y-value. Whilst the error is small for lower dimensions, its a problem if fcurve values span a wide range of values.

Exact steps for others to reproduce the error

Open attached .blend and have a look at fcurve.

key_interpol.blend

system-info.txt

**System Information** Operating system: Win10 Graphics card: GTX 1070 **Blender Version** 07f6be87a97e Worked: (optional) **Short description of error** Exponential interpolation introduces a "jump" for the y-value. Whilst the error is small for lower dimensions, its a problem if fcurve values span a wide range of values. ![fcurve.JPG](https://archive.blender.org/developer/F6885106/fcurve.JPG) **Exact steps for others to reproduce the error** 1. Open attached .blend and have a look at fcurve. [key_interpol.blend](https://archive.blender.org/developer/F6885109/key_interpol.blend) [system-info.txt](https://archive.blender.org/developer/F6885108/system-info.txt)

Alexander Court commented

2019-03-26 11:11:21 +01:00

Added subscriber: @spiegelball

Jacques Lucke commented

2019-03-26 11:56:23 +01:00

Added subscriber: @JacquesLucke

Jacques Lucke commented

2019-03-26 11:56:23 +01:00

I see the issue.

Can you describe more precisely when this is an issue in practice?

I see the issue. Can you describe more precisely when this is an issue in practice?

Jacques Lucke commented

2019-03-26 12:28:17 +01:00

Added subscriber: @brecht

Jacques Lucke commented

2019-03-26 12:28:17 +01:00

@brecht, this could be fixed with this simple hack.
It's obviously not a pretty solution, but it solves the issue in this file.
I computation time is probably dominated by the powf function call.
Not sure if there is a better way to get the required accuracy.

diff --git a/source/blender/blenlib/intern/easing.c b/source/blender/blenlib/intern/easing.c
index 07765276537..9cced397e74 100644
--- a/source/blender/blenlib/intern/easing.c
+++ b/source/blender/blenlib/intern/easing.c
@@ -251,7 +251,19 @@ float BLI_easing_elastic_ease_in_out(float time, float begin, float change, floa
 
 float BLI_easing_expo_ease_in(float time, float begin, float change, float duration)
 {
-	return (time == 0.0f) ? begin : change * powf(2, 10 * (time / duration - 1)) + begin;
+	if (time == 0.0) {
+		return begin;
+	}
+
+	/* Interpolate the beginning linearly to smooth out numeric inaccuracies. */
+	float linear_duration = duration * 0.01f;
+
+	float value = change * powf(2, 10 * (time / duration - 1)) + begin;
+	if (time > linear_duration) {
+		return value;
+	}
+
+	return BLI_easing_linear_ease(time, begin, value - begin, linear_duration);
 }
 
 float BLI_easing_expo_ease_out(float time, float begin, float change, float duration)

@brecht, this could be fixed with this simple hack. It's obviously not a pretty solution, but it solves the issue in this file. I computation time is probably dominated by the `powf` function call. Not sure if there is a better way to get the required accuracy. ``` diff --git a/source/blender/blenlib/intern/easing.c b/source/blender/blenlib/intern/easing.c index 07765276537..9cced397e74 100644 --- a/source/blender/blenlib/intern/easing.c +++ b/source/blender/blenlib/intern/easing.c @@ -251,7 +251,19 @@ float BLI_easing_elastic_ease_in_out(float time, float begin, float change, floa float BLI_easing_expo_ease_in(float time, float begin, float change, float duration) { - return (time == 0.0f) ? begin : change * powf(2, 10 * (time / duration - 1)) + begin; + if (time == 0.0) { + return begin; + } + + /* Interpolate the beginning linearly to smooth out numeric inaccuracies. */ + float linear_duration = duration * 0.01f; + + float value = change * powf(2, 10 * (time / duration - 1)) + begin; + if (time > linear_duration) { + return value; + } + + return BLI_easing_linear_ease(time, begin, value - begin, linear_duration); } float BLI_easing_expo_ease_out(float time, float begin, float change, float duration) ```

Brecht Van Lommel commented

2019-03-26 13:26:16 +01:00

For time 0 this formula gives 2^(-10) = 0.0009765625. So the function is just not defined to start from 0, it's not even numerical inaccuracy.

Using linear at the start seems good to me. There's more cases in this file with the issue though. Maybe you can define a replacement for powf(2, 10 * x) that is 0 at x == -1?

For time 0 this formula gives `2^(-10) = 0.0009765625`. So the function is just not defined to start from 0, it's not even numerical inaccuracy. Using linear at the start seems good to me. There's more cases in this file with the issue though. Maybe you can define a replacement for `powf(2, 10 * x)` that is 0 at `x == -1`?

Jacques Lucke commented

2019-03-26 13:33:52 +01:00

Yes, will check that. Will see if there is a better function that has almost the same curve...

Just for reference, here are all the easing functions I implemented for AN:
https://github.com/JacquesLucke/animation_nodes/blob/master/animation_nodes/algorithms/interpolations/implementations.pyx

I used a different abstraction. Instead of having (time, begin, change, duration) -> R functions, I used [0, 1] -> R functions.
Not sure if Blender makes use of this extra flexibility in the easing functions somewhere.

Yes, will check that. Will see if there is a better function that has almost the same curve... Just for reference, here are all the easing functions I implemented for AN: https://github.com/JacquesLucke/animation_nodes/blob/master/animation_nodes/algorithms/interpolations/implementations.pyx I used a different abstraction. Instead of having `(time, begin, change, duration) -> R` functions, I used `[0, 1] -> R` functions. Not sure if Blender makes use of this extra flexibility in the easing functions somewhere.

Jacques Lucke commented

2019-03-26 14:20:14 +01:00

How about this function:

lang=c
float BLI_easing_expo_ease_in(float time, float begin, float change, float duration)
{
	float t = time / duration;
	float mix_factor = powf(t, 6.2f);
	return BLI_easing_linear_ease(mix_factor, begin, change, 1);
}

Comparison old vs new:

The constant 6.2 was choosen to minimize the quadratic error compared to the old function.

lang=python
import numpy as np
import matplotlib.pyplot as plt

def old_func(x):
    return 2 ** (10 * (x - 1))

def get_new_func(exp):
    return lambda x: x ** exp

x = np.linspace(0.0, 1.0, num=51)

for exp in np.linspace(0.0, 10.0, num=1001):
    old_y = np.vectorize(old_func)(x)
    new_y = np.vectorize(get_new_func(exp))(x)
    error = sum((new_y - old_y) ** 2)
    print(f"{exp:.5f}, {error:.5f}")

Partial output:

6.14000, 0.00851
6.15000, 0.00847
6.16000, 0.00843
6.17000, 0.00841
6.18000, 0.00839
6.19000, 0.00838
6.20000, 0.00838
6.21000, 0.00838
6.22000, 0.00839
6.23000, 0.00841
6.24000, 0.00844
6.25000, 0.00848
6.26000, 0.00852
6.27000, 0.00857

How about this function: ``` lang=c float BLI_easing_expo_ease_in(float time, float begin, float change, float duration) { float t = time / duration; float mix_factor = powf(t, 6.2f); return BLI_easing_linear_ease(mix_factor, begin, change, 1); } ``` Comparison old vs new: ![exponential-easing.gif](https://archive.blender.org/developer/F6885939/exponential-easing.gif) The constant `6.2` was choosen to minimize the quadratic error compared to the old function. ``` lang=python import numpy as np import matplotlib.pyplot as plt def old_func(x): return 2 ** (10 * (x - 1)) def get_new_func(exp): return lambda x: x ** exp x = np.linspace(0.0, 1.0, num=51) for exp in np.linspace(0.0, 10.0, num=1001): old_y = np.vectorize(old_func)(x) new_y = np.vectorize(get_new_func(exp))(x) error = sum((new_y - old_y) ** 2) print(f"{exp:.5f}, {error:.5f}") ``` Partial output: ``` 6.14000, 0.00851 6.15000, 0.00847 6.16000, 0.00843 6.17000, 0.00841 6.18000, 0.00839 6.19000, 0.00838 6.20000, 0.00838 6.21000, 0.00838 6.22000, 0.00839 6.23000, 0.00841 6.24000, 0.00844 6.25000, 0.00848 6.26000, 0.00852 6.27000, 0.00857 ```

Jacques Lucke commented

2019-03-26 14:23:54 +01:00

Oh oops, just noticed that this function is not even exponential ^^
Next try.

Oh oops, just noticed that this function is not even exponential ^^ Next try.

Jacques Lucke commented

2019-03-26 14:38:19 +01:00

This works:

lang=c
float BLI_easing_expo_ease_in(float time, float begin, float change, float duration)
{
	if (time == 0.0) {
		return begin;
	}

	const float min_pow = 0.0009765625;
	return change * (powf(2, 10 * (time / duration - 1)) * (1 / (1 - min_pow)) - min_pow) + begin;
}

Turns out, this is actually the exact same thing I did in AN (link )...

This works: ``` lang=c float BLI_easing_expo_ease_in(float time, float begin, float change, float duration) { if (time == 0.0) { return begin; } const float min_pow = 0.0009765625; return change * (powf(2, 10 * (time / duration - 1)) * (1 / (1 - min_pow)) - min_pow) + begin; } ``` Turns out, this is actually the exact same thing I did in AN ([link ](https://github.com/JacquesLucke/animation_nodes/blob/master/animation_nodes/algorithms/interpolations/implementations.pyx#L115-L117))...

Alexander Court commented

2019-03-26 14:40:40 +01:00

In #62958#648339, @JacquesLucke wrote:
I see the issue.

Can you describe more precisely when this is an issue in practice?

In my scene there is a dolly shot from earths ground level into space, so the keyframes go from ~1m to ~10000km. Therefore any imprecisions (even if its just 0.1% of maximum value) lead to huge jump on the first frames of animation. I discovered something similar with bezier interpolation, made a new report for that: https://developer.blender.org/T62968.

> In #62958#648339, @JacquesLucke wrote: > I see the issue. > > Can you describe more precisely when this is an issue in practice? In my scene there is a dolly shot from earths ground level into space, so the keyframes go from ~1m to ~10000km. Therefore any imprecisions (even if its just 0.1% of maximum value) lead to huge jump on the first frames of animation. I discovered something similar with bezier interpolation, made a new report for that: https://developer.blender.org/T62968.

Brecht Van Lommel commented

2019-03-26 14:45:16 +01:00

@JacquesLucke, makes sense, can we do this for all the places that use powf(2, 10 * x)?

@JacquesLucke, makes sense, can we do this for all the places that use `powf(2, 10 * x)`?

Jacques Lucke commented

2019-03-26 14:48:15 +01:00

In #62958#648577, @brecht wrote:
@JacquesLucke, makes sense, can we do this for all the places that use powf(2, 10 * x)?

Yep, wait.

In #62958#648564, @spiegelball wrote:

In my scene there is a dolly shot from earths ground level into space, so the keyframes go from ~1m to ~10000km. Therefore any imprecisions (even if its just 0.1% of maximum value) lead to huge jump on the first frames of animation. I discovered something similar with bezier interpolation, made a new report for that: https://developer.blender.org/T62968.

I see, makes sense.

> In #62958#648577, @brecht wrote: > @JacquesLucke, makes sense, can we do this for all the places that use `powf(2, 10 * x)`? Yep, wait. > In #62958#648564, @spiegelball wrote: > > In my scene there is a dolly shot from earths ground level into space, so the keyframes go from ~1m to ~10000km. Therefore any imprecisions (even if its just 0.1% of maximum value) lead to huge jump on the first frames of animation. I discovered something similar with bezier interpolation, made a new report for that: https://developer.blender.org/T62968. I see, makes sense.

blender-admin commented

2019-03-26 15:43:51 +01:00

This issue was referenced by 9b39a71793

This issue was referenced by 9b39a7179372d0360021a9d2e88190f17f34b29e

Jacques Lucke commented

2019-03-26 15:45:09 +01:00

Changed status from 'Open' to: 'Resolved'

Jacques Lucke closed this issue

2019-03-26 15:45:09 +01:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

F-Curve imprecisions for exponential interpolation #62958