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

2022-01-08 Meeting

Agenda

Steering Council and Project Governance

• New Governance scheme in effect, Steering Council has been elected: See Manim governance
• Money
  • OpenCollective account
    • Expenses:
      • Current maintenance costs: domain name
      • Future expenses: server, backhub, paid github plan for more CI?
      • Very far away goal: part-time/full-time paid devs
  • If anyone has any funding opportunities, please let us know!

Road to Manim 1.0

• See also: Roadmap - ManimCommunity/manim Wiki
  • Maintenance mode: Aiming for cleaning up internals, in particular: creating clean, abstract interfaces for central concepts:
    • Mobject, VMobject <- OpenGLMobject, OpenGLVMobject + trying to remove ConvertToOpenGL metaclass
    • Making Scene renderer agnostic
    • Abstract base class for Renderer, making CairoRenderer and OpenGLRenderer inherit from that new interface
    • Clear the road for a new rendering backend (kill backwards compatibility now wherever necessary)
    • What's in/out of scope to rewrite/refactor for "1.0"? Incremental code cleanup or complete redesign?
  • While in Maintenance mode: PRs with new features will be held back.
    • Will PRs from core devs be mergeable without review?
    • Is Manim still expected to work, or are we allowed to break stuff temporarily?
    • Are we still going to maintain the main branch? Will that be too much work?
    • What happens to currently open PRs?
  • Help is much appreciated!
  • Maki

Goals for Manim

• What do we want manim to be?
• How does Manim differ from other animation libraries (reanimate, p5js, processing, lottie, etc.)? what is our niche? why do users use Manim over other libraries? what functionality in Manim is not easily replicable in other animation libraries?
  • LaTeX rendering (except in Reanimate) is not easy in other libraries
  • Nice default animations? eg. Create, Transform, Write
• ignoring implementation details, how do we stay out of our own way in the future?
• no need to future proof, but what are we trying to accomplish?
• feature parity/superset of manimgl?
• strictly a community attempt to reproduce the 3b1b style?
• fully-featured programmatic svg editor? just for math/science?
• an svg animator? interpolator extroidinaire? just render shapely/sympy/etc data? - something else?
• something else?
• entirely separate 2d/3d geometry library to just be rendered?
• real-time interactive scenes?
• should we be using a model like reactive programming/MVC/etc?

Notes

slides

the point of Open Collective is to be completely transparent with funds

Gitlab is maybe cheaper for CI? rate limiting related?

Goals for Manim

TeX for mathematical videos easy to use, hard to master

community input:

• sane defaults
• code based 2d animation library in python
• highly customizable
• Programmatic animations. I tried to do these things in After Effects and it's such a pain.
• programmatic and mostly deterministic output
• Is there a possibility of Manim going the Blender way, wherein there's a realtime GUI alongwith coding tab.. so that someone could either use GUI to animate OR directly code as is being done now.
  • above is hard
  • possible with dearpygui?
  • https://www.aquabeam.me/manim/opengl_guide/
• I wish Manim was more animation focused. "always redraw" and updaters should be somehow the default behavior
• what are your feelings about the separation of manim the library and the source for a manim video? Should we make that break cleaner? eg having our own .manim source file that compiles to a video? Instead of having every user subclass Scene and implementing their own construct method?
• GUI could be helpful and handy especially you want to preview text locations and such
• https://github.com/ManimCommunity/manim/pull/1901

Relationship to 3b1b version

• unrealistic to match 3b1b
• community edition able to stand on its own
• not so much danger in making breaking changes not preventative for trying to bring in 3b1b features
• recommend 3b1b for interactivity and opengl
• default is to recommend ce due to usage and docs

interface wishlist

• svg parser lib
• svg export
• data vis (pandas)
• more reliant on optimized external libs
• napari https://github.com/napari/napari
• quaternions
• code vis
• sage
• geogebra/desmos replacement
• sympy
• lottie
• javascript

refactor

• bugfixes still merge in main?
• mostly feature freeze
• ditch cairo?
• shaders?
• multiple renderer solution is good for long-term

maki

• experimental rendering backend for c++
• uses opengl rn, but rendering apis can be easily implemented renderer vs renderer api
• time travel!
• only need to add one folder to renderer for new backends
• platform glfw; might want another for web
• atom chains; diffs of frames (applying and reversing objects in scenes)
• pretty neato!

else

• work allocation?
• more proposals and drafting needed

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