[BUG-General] Updaters do not behave well with t values

[huguesdevimeux]

Consider this scene :

RUN_TIME = 1


class Test(Scene):
    def construct(self):
        path = VMobject()
        dot = Dot()
        path.set_points_as_corners([dot.get_center(), dot.get_center()])
        def update_path(path):
            previus_path = path.copy()
            previus_path.add_points_as_corners([dot.get_center()])
            path.become(previus_path)
        path.add_updater(update_path)
        self.add(path, dot)
        self.play(Rotating(dot, radians=PI, about_point=RIGHT, run_time=RUN_TIME))
        self.play(dot.shift, UP)

Running normally (Rotating with RUN_TIME = 1, t values = 0,1/15,2/15 etc) :

When changing RUN_TIME to 0.1. there is therefore way less t values, and :

As you can see, it's not smooth at all.

When there is only one t = 1, (eg when rendering the last frame with -s ):

as you can see, the updaters are updated only if there is a t value. Although this can be seen as the normal processus, it causes trouble, for example here, when scene-cacher skips an animation (the t value is directly set to the end). One gets this :

This happens as the first animation (Rotating) is cached so it uses a partial movie file instead of playing the animation. When the second animation is played the t value is directly set to 1, and manim is tricked into drawing a straight path, when there should be several points correponding to all the t values.

This is seemingly quite impossible to fix, as it would mean refactoring the whole t values thing, which .. is simple.

Related to #339

[leotrs]

Excellent report.

As you say, this kinda sorta makes sense given that the way we are drawing paths (by just manually setting the corner points of a VMobject). If we had a dedicated Path class, then this could probably be made to work by setting the path beforehand (for example by a parametric curve) and rendering the whole path up to a certain point of the parameter.

What should change here is how we draw paths, not how we render scenes.

[leotrs]

In fact, I just discovered that TracedPath exists. It also looks like it would suffer from this bug currently, but any logic for fixing this issue should go in that class.

We should discourage the manual use of updaters to trace paths.

[huguesdevimeux]

You're right, I knew there was something to draw Path, but I didn't remember.

We should discourage the manual use of updaters to trace paths.

But is there an alternative ?

[leotrs]

Yes, the alternative is TracedPath. Not a perfect alternative, but the code it produces is much cleaner.

[huguesdevimeux]

But ... TracedPath works with updaters doesn't it ?

[leotrs]

Yes. Sorry I should be more clear. I mean we should discourage the end-user from manually using updaters to, in essence, replicate what can already be done with TracedPath.

TracedPath, on the other hand, should still use updaters. It just doesn't need to expose them to the user.

For the purposes of this issue: we should include the new logic within TracedPath, and enforce that users use that instead of touching updaters at all. But the way TracedPath/updaters work should still be refactored.