Experimental Progress Tracker

[JasonGrace2282]

Experimental Progress Tracking

Tracker issue for rewriting the core of Manim

Before merging into Main

Essentially, what needs to be done in #3112

• Restructure the render loop to use Manager (Rewrite Animation Loop #3785)
• Merge main into experimental (Merge with main #3815)
• Functioning FileWriter (Bring in main's FileWriter into experimental #3821)
• Catch up to main
  • Sections (Implement sections for scenes #3883)
  • Skipping to animation number
  • Fix all Animations
  • Scene subclasses
  • ThreeDScene
  • Animation of Camera
  • Clean up the code
  • Basic bug fixes to get most tests functioning
• Instanced Rendering (Instanced Rendering #3816)
• Rewrite VMobject to be renderer agnostic
• ImageMobject
• PMobject (is this even used?)
• Get all tests working

Nice to have

The following would be nice to have, but could also be implemented in follow-up PRs to reduce the diff.

• Double pass rendering to decouple Scene and Manager
• Audio support

Follow-Ups

• Caching
• Plugin Hooks

Timeline Goals

• v0.20.0: Experimental should have most tests passing
• v0.21.0: Experimental should be released, and the follow-ups should be in the process of being implemented.

But... Why?

Motivation

The current Manim codebase is very entangled.

To give you a sense of what I mean, let's look at an example. The renderer has access to a file writer. The Scene has access to the renderer, and as such indirectly to the file writer as well. But the renderer also has a reference to the scene. To make matters worse, at some points in time animations also have references to the scene (sometimes), and much more. This is an attempt to clean that up by introducing a `Manager` class whose sole job is to orchestrate communication between the `Scene`, `FileWriter`, and a `Renderer`.

Additionally, the current implementation of renderers (OpenGL mainly, but Cairo as well) in Manim is unmaintainable. The OpenGLMobject contains shaders inside itself! This means in the future if we ever want to allow more types of renderers (e.g. Metal for MacBooks), we'd have to create a third base Mobject, and a new Camera, which is just stupid. Instead, *Mobjects should be renderer independent, and all the renderer specific stuff should be inside a class implementing the RendererProtocol.

New Structure

Here you can see every class has its own responsibilities. The Camera is responsible for the FOV, the Scene for orchestrating animations, Mobjects have no dependency with the renderer, and the Renderer only cares about a SceneState, not the actual Scene.