Experimental Progress Tracker

[JasonGrace2282]

Experimental Progress Tracking

Before merging into Main

• 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)
• Bugfixes to get tests functioning
• Instanced Rendering (Instanced Rendering #3816)
• Rewrite VMobject to be renderer agnostic
• Clean Up the Code

Nice to have

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

• Add support for "exotic" stuff (Scene subclasses, ImageMobject, Meshes, etc.)
• Support (of some kind) for sections in scenes
• Double pass rendering to decouple Scene and Manager

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.