t values issue that causes the animations to not be finished entirely.

[huguesdevimeux]

y values are generated with those lines : (progress_through_animations, l883, scene.py).

        for t in self.get_animation_time_progression(animations):
            dt = t - last_t
            last_t = t
            for animation in animations:
                animation.update_mobjects(dt)
                alpha = t / animation.run_time
                animation.interpolate(alpha)
            self.update_mobjects(dt)
            self.update_frame(moving_mobjects, static_image)
            self.add_frames(self.get_frame())

get_animation_time_progression returns a ProgressBarDisplay object, from the library tdqm that we use to display the progress bar.

When doing -s, skip_animations is enabled to t value is set to 1.0 (no intermediary values as we just need the last frame).

When running normally, eg with 15 fps, there are logically 15 t values, that are :

0.0
0.06666666666666667
0.13333333333333333
0.2
0.26666666666666666
0.3333333333333333
0.4
0.4666666666666667
0.5333333333333333
0.6
0.6666666666666666
0.7333333333333333
0.8
0.8666666666666667
0.9333333333333333

As you may see, 1 is never reached. In other terms, the animations is stopped at 93%). Not that 1.0 change depending on the rn_time : if the run_time was let's say 3, last t value would be 2.93.

We can see this issue with a single pixel that should be here :

To give an idea of a fix, I will use the words of @leotrs :

I've never used tqdm myself so my question is: is it orthodox/expected/good practice to determine the course of a program by querying the progress bar itself? I'm not sure how this works at all.

It'd be much more reasonable I think for manim to determine its own course of action and then tell the progress bar to reflect that, instead of the other way around

[leotrs]

So there are two problems here. Correct me if I'm wrong.

1. progress_through_animations gives a range of t values that never reaches 1.0. I don't think this has anything to do with the config system right? In any case, can we modify progress_through_animations? It should be as easy to ask it to partition the interval in one more chunk (as right now it ends 1/15 short of 1.0).

2. I still don't understand why the t values come from the progress bar. It should be the other way around: manim decides what t values it wants the progress bar to show.

If fixing 2 is too costly, then we can just fix 1 and open a new issue for 2. I understand this interacts with the tests, so we should try to fix this asap.

[huguesdevimeux]

See these lines : l678 scene.py

if file_writer_config['skip_animations'] and not override_skip_animations:
    times = [run_time]
else:
    step = 1 / self.camera.frame_rate
    times = np.arange(0, run_time, step)
time_progression = ProgressDisplay(
    times, total=n_iterations,
    leave=file_writer_config['leave_progress_bars'],
    ascii=False if platform.system() != 'Windows' else True
)

When -s is called, skip_animations is True as well and the progressbar is set up with only one step that has the length of the run_time. That's why there is only one single t value equal to 1 (in the case where run_time = 1).

On second thought the problem does not come from the progress bar but from np.arrange that yield 15 values from 0 to 0.93333 (although we should change that).
I would suggest just changing times = np.arange(0, run_time, step) by

number_frames = int(self.camera.frame_rate *  run_time) #arbitrray rounded down, maybe should be round this up ?
times = np.linspace(0, run_time, number_frame) 

With that we would have a correct repartition of all the t values.

And I completely agree with 2.

And btw it does not interact with the tests. We can merge #185 before or after that, it does not matter :)

[leotrs]

Let's see, arange does the following

In [7]: np.arange(0, 1.0, 1/15)
Out[7]: 
array([0.        , 0.06666667, 0.13333333, 0.2       , 0.26666667,
       0.33333333, 0.4       , 0.46666667, 0.53333333, 0.6       ,
       0.66666667, 0.73333333, 0.8       , 0.86666667, 0.93333333])

While linspace returns

In [8]: np.linspace(0, 1.0, 15)
Out[8]: 
array([0.        , 0.07142857, 0.14285714, 0.21428571, 0.28571429,
       0.35714286, 0.42857143, 0.5       , 0.57142857, 0.64285714,
       0.71428571, 0.78571429, 0.85714286, 0.92857143, 1.        ])

One uses 1/15 and the other uses 15. So I'm not sure why the need to round anything. But in any case, yes it seems like using linspace is going to do the trick. PR?

[huguesdevimeux]

I think since we are changing this logic we could think of a more general refactoring, and do what you suggested in you second point.

I already have 2 PR to take care of, so I won't be able to PR this right now. Feel free yo do it if you have time ;D

[leotrs]

What is "free time"?

[huguesdevimeux]

What is "free time"?

An interesting concept that only high school students under lockdown seem to benefit from lol

[huguesdevimeux]

One uses 1/15 and the other uses 15. So I'm not sure why the need to round anything. But in any case, yes it seems like using linspace is going to do the trick.

We need to round this as np.linspace only takes integrers as third parameter.
Example : run_time = 2.5 seconds, at 15fps. How many frames will be generated ? 37 or 38 ?

I missed that when I read your answer

[leotrs]

Oh I see now. I'd say we should round up!

[eulertour]

Keep in mind that if we do this then the last frame of animation n and the first frame of animation n+1 will always be the same, which would cause an unavoidable pause between animations which would be especially noticeable at low frame rates. It wouldn't be possible to create the effect where animation 1 runs from 0s to 1s and animation 2 runs from 1s to 2s. This isn't technically possible now, since playing an animation for 1s at a given frame rate generates <frame_rate> frames, which is only (frame_rate-1)/frame_rate seconds of video.

If you did want to do this, you'd probably want to increase the number of samples to 1 more than the frame rate so that each animation played for 1s rather than (frame_rate-1)/(frame_rate) seconds as it does now. Consecutive calls to play() would then generate video lengths of 1s, (2 + 1/frame_rate)s, (3 + 2/frame_rate)s, etc.

However, I think the proper solution is just to add a terminating frame at the end of the last animation, so that consecutive calls to play() would generate video with frame counts of 16, 31, 46, etc., which corresponds to video lengths of 1s, 2s, 3s, etc. at 15fps.

[kilacoda-old]

Using np.linspace instead of np.arange seems to be break the run_time parameter of animations btw. For example:

class TestScene(Scene):
    def construct(self):
        self.play(FadeIn(Text("Hello"),run_time=4))
        self.wait(2)

with this get_time_progression method:

def get_time_progression(self, run_time, n_iterations=None, override_skip_animations=False):
    if self.skip_animations and not override_skip_animations:
        times = [run_time]
    else:
       
        rate = self.camera.frame_rate
            
        times = np.linspace(0, run_time, rate)
            
    time_progression = ProgressDisplay(
        times, total=n_iterations,
        leave=self.leave_progress_bars,
        # ascii=False if platform.system() != 'Windows' else True,
    )

    return time_progression

outputs this:

(only 3 seconds, 1 for the animation and the other 2 from the wait)

and with the original method:

def get_time_progression(self, run_time, n_iterations=None, override_skip_animations=False):
    if self.skip_animations and not override_skip_animations:
        times = [run_time]
    else:
        step = 1 / self.camera.frame_rate  # frames per second -> time per frame
        times = np.arange(0, run_time, step)
            
    time_progression = ProgressDisplay(
        times, total=n_iterations,
        leave=self.leave_progress_bars,
        # ascii=False if platform.system() != 'Windows' else True,
    )

    return time_progression

outputs this:

(6 seconds, 4 from the animation and 2 from the wait, i.e. as it should be.)

[huguesdevimeux]

@eulertour I didn’t think about that. This is a very good point.

However, I think the proper solution is just to add a terminating frame at the end of the last animation, so that consecutive calls to play() would generate video with frame counts of 16, 31, 46, etc., which corresponds to video lengths of 1s, 2s, 3s, etc. at 15fps.

So seeing your note this is IMO the best solution.

@kilacoda Did you implement number_frame variable as I did in on of my previous answer ?

[kilacoda-old]

Welp. My stupidity strikes me again. Adding the number_frames variable worked. Looks like I overlooked it😅