Manim scene caching does not play well with the -n flag
See original GitHub issueHere’s a scene
from manim import Scene, Integer, ShowCreation, Transform
class TestScene(Scene):
def construct(self):
number = Integer(0)
self.add(number)
for i in range(10):
self.play(Transform(number, Integer(i)))
Problem 1
This scene cannot be rendered with manim -pl test.py -n5,10
. That is, if the first time you render it, you try to render only a specific number of animations, it cannot be done. It can be rendered normally without specifying the -n flag: manim -pl test.py
.
Problem 2
After successfully rendering with manim -pl test.py
, I tried again manim -pl test.py -n5,10
, but the whole scene is being rendered. The -n flag is ignored.
Comments
Judging by the output, I think this has to do with scene caching (cc @huguesdevimeux). I recommend that while we are working out the kinks of the scene cachinc system, we add a flag --disable_caching
, so that it can still be used even while the caching system is not fully debugged.
UPDATE: even when using --disable_caching
, you get the same behavior.
Issue Analytics
- State:
- Created 3 years ago
- Comments:10 (10 by maintainers)
You’re right, and I don’t think it is an issue as it is set to false by default at each scene rendering (this flag is not meant to be used by the user in any way).
I’m not that busy, I’m just working on other things (tests) and this is my priority right now. But I will be able to take care of this in a few days, no doubt.
I think we should be smarter than what was implemented before. My idea would be to do some tricks with
scene.num_plays
in @handle_caching play and @handle_caching_wait: ifscene.num_plays
is between i and j, then we skip everything to the next iteration, if not, we can continue normally and it should work fine. This is just a draft if you don’t see really how to fix I will be able to work on it in a few days.If it’s never touched by the user, and it’s only touched by each Scene instance, then it should be a member of Scene, not in the config. But we can leave that for another issue.