Manim addons and customizability

@yoshiask had developed an initial structure for what seemed to be support for using addons (i.e., extra functionalities from 3rd-party libs) in manim (see his pull request at the 3b1b repo and his .pptx export extension). This idea has a lot of potential and can be generalized for many functionalities needed by manim.

First, we should implement an API like the one suggested by @yoshiask, which would allow the usage of custom options, classes and functions that interact with manim’s inner structures. An example of project that could benefit from this is chanim.

Second, we should generalize this API for multiple functionalities, and allow for more customizability in manim, generally speaking. For example:

• We should allow the user to pick how the video should be rendered, i.e. which rendering method should be used (this is a matter to be discussed by itself!) - @eulertour’s manim web port could benefit from this. For instance, the user could pick between rendering in the browser (using @eulertour’s tool) or with cairo, which would leverage the latter from being a required dependency (see #14).

  • This will require, of course, developing an interface that abstracts rendering away. E.g.: To render a shape, we just call render_shape(...data...), a function that tells the renderer to do this, which can then interpret this message as it wishes.

  • Note that anyone would be able to create any renderer compatible with manim that they wish.

• We can also, similarly, allow the user to choose how to render LaTeX (see #23, #24). They can delegate it to an online website, should someone create an extension for this, or simply use the available installation (the default behavior). We would do this, also similarly, by abstracting away the rendering processes with an appropriate interface.

Note that the use of dataclasses (see #7) and proper organization/typings would immensely aid us here.

Comments? Suggestions?

[eulertour]

Most of that makes sense, although a render_frame() function will probably make more sense than a render_shape() one since it allows the renderer for more freedom over how to process each frame. I also think we should add a realtime renderer to the base repo, since the one with cairo is really slow.

Other than that it seems like we’ll basically have to allow users to overwrite any function they want, which seems like it could be tricky to get right…

[yoshiask]

@eulertour and I were discussing the extensibility and modularity of rendering. I think that we could make the actual rendering parts as add-ons, since we want people to be able to add new rendering backends on their own.