Roadmap

Internals redesign

Problem: currently Manim's modules are very convoluted and the rendering logic is not really easy to understand.

Solution: Let's try to come up with a general interface for things. We'll start with basic concepts, and then move on from there. Once we have settled for a design that makes sense, we can start pushing the current implementation more in that direction. (Or rewrite parts from scratch, which might be easier in some cases.)

class Scene:
	"""
    A scene is Manim's basic canvas.
    """
    # Attributes 
	camera  # <- might be owned by the renderer
    mobjects
    renderer  # <- might be owned by the camera
    
    # Methods

class Mobject:
	"""
    Mobjects are "Manim objects", that is, objects that
    can be added to Scenes (+ animated!)
    """
    # Attributes
    # Methods

class Camera(Mobject):
	"""
    A camera is a special mobject which is used to capture
    the perspective of someone viewing a scene. The camera
    talks to a renderer (or maybe the renderer talks to the
    camera of a scene?).
    
    The Camera works independently
    of the actual renderer implementation being used.
    """
    # Attributes
    # Methods

class Renderer:
	"""
    Renderers are responsible for turning the information
    relayed to them by a camera into data that can be
    used for producing an image or an animation (or maybe
    even more advanced types like SVGs?).
    
    This has to be an abstract class,
    which can't be instantiated.
    It only serves as an interface for
    the actual implementation using a specific rendering API—
    like Vulkan or OpenGL. That way the rest of Manim doesn't "care"
    which rendering implementation is being used
    under the hood.
    """
    # Attributes
    # Methods

Timeline

Jan 2022 - ?

Contribution guidelines

• Main branch to be frozen, only bugfix support (or no support at all?)
• Most PRs to the refactor branch unrelated to the refactor may be ignored

Ideas / Discussion

• Can we create an abstraction for mobjects that can be understood by any renderer?

• Where possible use the same logic / objects for all renderers and where not possible move that logic to the renderers

• Define clear responsibilities for mobjects and renderers. E.g. what is the minimum mobjects should do and leave the rest to the renderers?

• Refactoring the config included in manim 1.0?

• Try to reduce the number of flags as it increases complexity. Some discussion on it here - https://github.com/ManimCommunity/manim/issues/2069

• In opengl a lot of objects are created each frame. E.g. Mesh and ShaderWrapper objects are created for each mobject each frame. We should avoid this to improve performance

Rendering specifics

VMobject data

• VMobjects: should they consist of quadratic or cubic bezier curves?

• Quadratic bezier curve advantages: Simpler to render, closed-form solution for signed distance field

• Quadratic bezier curve disadvantages: Less smooth ($C^1$ continuity for smoothed composite quadratic beziers) than cubic, SVGs may contain cubic beziers which will have to be approximated to quadratic beziers if we want to render them

• Rendering approaches: render quadratic bezier signed distance field directly, or approximate with polylines?

• Is the fill of a VMobject well defined in 3D where not all the points are coplanar? What do we do then? What does Grant's shaders already do?

• Test rendering approaches: polyline vs signed distance field

Tasks

• Create an abstract renderer (in progress)

• Make scene agnostic to the renderer (in progress)

• Create a mobject class that can be used by both renderers

• Remove opengl_compatibility (likely will depend on a number of other tasks)

Tools

Visualization

From Discord:

Hello! Anticipating the discussion for the roadmap, I was hoping there would be an easy way to get a big-picture view of the codebase so I used py2puml and plantuml to make a class diagram for everything in manim/mobject.

py2puml is pretty strict so I've had to clean up or omit parts of the manim codebase (only in five files), but I'm hoping to clean up that branch soon so I can share the process. Eventually all of manim could be done I suppose, but I can get to that later.

I plan to make a copy of the manim_mobject.txt and edit that by hand for some drafting and design wishlist stuff that's easy to visualise and share (can't tell yet if that's going to be easier than just using the above workflow on a draft branch).

Attached should be manim_mobject.txt which is in PlantUML syntax and can just be run with plantuml -tsvg manim_mobject.txt to output an svg (the default png output cuts off for me but ymmv). I'll also try to send the svg but it's quite wide!

As of 2022-01-03, manim/mobject on branch main is good to go. Still working on getting py2puml to work on the whole codebase :)

tl;dr

Use py2puml and PlantUML to make a class diagram for manim.

In manim's git root directory on your terminal:

$ py2puml manim/mobject manim.mobject > manim_mobject.puml
$ plantuml -tsvg manim_mobject.puml