Scenes should track cumulative time since starting

[eulertour]

Description of proposed feature

Scenes should store the total time since starting and make this value accessible via a public API.

How can the new feature be used?

There isn't currently a way to update mobjects based on the cumulative elapsed time since a given start point. Time based updaters only pass dt, the incremented time, which leaves the user to add that value to a running total manually in order to track cumulative time. This makes things like animating a continually growing angle unnecessarily complex.

It may be best to also add a new Clock class which inherits from ValueTracker and has APIs like Scene.get_clock(), Clock.start(), and Clock.stop().

[leotrs]

Agreed with the general point.

One nitpick: I would rather see a complete overhaul of ValueTracker before we inherit anything from it. Every single use of ValueTracker I've seen seems unnecessarily clunky...

[eulertour]

What sort of clunkiness are you trying to avoid?

[NeoPlato]

I support this venture. Seems helpful for the add_sound method in the scenes.

So there's the basic part: using it the first time is an error off the bat:

class AudioTest(Scene):
    def construct(self):
        group_dots = VGroup(*[Dot() for _ in range(3)])
        group_dots.arrange_submobjects(RIGHT)
        for dot in group_dots:
            self.add_sound("generic_sound.wav")
            self.play(FadeIn(dot))
            self.wait()


  File "C:\Users\User\ManimCommunity\manim\scene\scene.py", line 861, in add_sound
    time = self.time + time_offset
AttributeError: 'AudioTest' object has no attribute 'time'

So I take care of that by changing self.time to self.renderer.time here:

The animation actually plays well, with the sound in sync with the dots

AudioTest.mp4

Good tidings and fortune right? A man does a rerun:

AudioTest.mp4

After I toy with something in scene.py:

AudioTest.mp4

So the sound is not in sync. Hence caching affects the time count. How exactly? I spoke with my debugger:

1. Without caching. Note the number of frames on the left hand side

60 frames. All accounted for, right?

2. With caching

Considering add_sound directly uses that attribute to figure out where to place the sound, a separate class for this independent of caching effects is most welcome

Thanks to GitHub for adding video support a day after I typed an entire link for this comment

[eulertour]

@NeoPlato is right, this is already being done in Scene.renderer.time, so the solution shouldn't be any more complicated than adding a property to Scene to read the value from the renderer.

[eulertour]

Scene caching does change it, but if the scene is cached anyway maybe that isn't a problem?

[NeoPlato]

@NeoPlato is right, this is already being done in Scene.renderer.time, so the solution shouldn't be any more complicated than adding a property to Scene to read the value from the renderer.

Would that ensure the frames get updated correctly even with caching?

[eulertour]

The renderer time is updated in CairoRenderer.add_frame() and that's called from Scene.play_internal() which is skipped during caching, so unless this is handled somewhere else in the caching logic frames that depend on the cumulative time won't work properly if they follow a cached animation.

https://github.com/ManimCommunity/manim/blob/master/manim/renderer/cairo_renderer.py#L144
https://github.com/ManimCommunity/manim/blob/master/manim/scene/scene.py#L826

[NeoPlato]

that's called from Scene.play_internal() which is skipped during caching

Oh it skips the entire thing? That makes sense.

So you would have a separate construct that updates the frame from the Scene class independent of the caching

[Hari-07]

I'd like to take up this issue but since I havent worked on this project before a few pointers might help to start with this issue

[leotrs]

@Hari-07 thank you for volunteering! What kind of pointers are you looking for? If you start your work and come across a concrete doubt, don't hesitate to ask here or on our discord.

[huguesdevimeux]

Hi @Hari-07 , are you still willing to work on this? If you don't manifest, I think I'll do it.

As @eulertour said Taking the elapsed time from the renderer is a bad idea when a scene is skipped for some reason.

Instead, we could when an animation is skipped add its time to an internal clock of the Scene.

[Hari-07]

Yeah sure you can take it, I got engrossed in other side projects and forgot about this to be honest

…

On Tue, Jan 26, 2021 at 5:44 PM Hugues Devimeux ***@***.***> wrote: Hi @Hari-07 <https://github.com/Hari-07> , are you still willing to work on this? If you don't manifest, I think I'll do it. As @eulertour <https://github.com/eulertour> Taking the elapsed time from the renderer is a bad idea when a scene is skipped for some reason. Instead, we could when a scene is skipped add its time to an internal clock of the Scene. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#851 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFKWGRZLSOO7P3BSGAYQDZ3S32W35ANCNFSM4UTB4R3A> .