- Python 98.2%
- GLSL 1.6%
- Dockerfile 0.1%
8a5267a9ee* sub_alphas is derived directly from to_update so they're guaranteed to be of the same length. * self.shapes is initialised as a direct copy of the mobject, guaranteed to be of same length. * linspace in this case guarantees both arrays are of equal size (self.n_segments). * Any transformation already requires that each datapoint in the first tuple has a corresponding datapoint in the second (ie same length) * Replaced arange with linspace, eliminates risk of floating point errors and forces rgbas and offset to be the same size for strict=True * all_arc_configs is either defined specifically by length of point_pairs or strictly forced to be the same length (n). In any case they'll always be the same length so strict=True works. * There should always be an equal amount of start and end anchors; radius_list is defined directly from the length of vertex_group; both outer_vertices and inner_vertices posess n vertices. * boundary_times always contains has an even length so both 'slices' in the zup function are the same length. * colors_in_gradient is defined to be the same length as p_list_complete; labels and parts are seemingly user inputs with no guarantee of equal length; val_range is defined to be same lenght as self.bar_names; however there's no authentication that self.values has a fixed length after it's been defined ie user can append to the list creating a mismatch between len(self.values) and len(self.bars) * In most cases here, the tuples are either defined to be of same length or manipulated to be by the align_data function. In the match_points function there is currently no validation to ensure both mobjects are the same length. * Reverting _add_x_axis_labels() zip() function back to strict=False due to failing test cases * Reverted strict zip usage * color_gradient is defined to be same length as p_list_complete & within _add_x_axis_labels we define val_range to be the same length as self.bar_names * align_data and lock_matching_data have no validation to ensure tuples in the zip() function are of the same length. Every other time zip() is used here it is generally immediately manipulating or explicitly defining the tuples to be of same length * All tuples in zip() functions here are either clearly the same size or manipulated to be the same size using the make_even function. * The tuples in the zip() function will clearly be of equal length, the second tuple is simply a cyclic shift of the first. * In the ingest_submobjects function arrays is a one to one mapping of attrs so they are guaranteed to have equal lengths. * Every usage of zip() consists of tuples that are either manipulated to be equal size or defined to be equal size. * the zip() function in bezier_remap will always consist of equal length tuples as current_number_of_curves is read directly from the shape of bezier_tuples and is used to dictate the size of split_factors. * The zip() function color_gradient() will always consist of equal length tuples as floors is defined directly from alphas (which also defines alphas_mod1) * The tuples in the zip() function in adjacent_n_tuples will always be the same length so strict=True. * The find_intersection() contains a zip() function that has been set to strict=True. While it is technically possible to pass tuples to this function that are *not* the same length, this would result in generally unexpected behaviour anyway. * Changed zip() function to have strict=True in __init__() as custom_labels is dependent on tick_range so guaranteed to have the same length. * Several instances of zip() set to strict=True. In add_coordinates we have axis manipulated to be the same length as tick_range. In get_riemann_rectangles() we have colors dependent on of x_range_Array forcing them to be the same length. Finally in plot_line_graph() it is clearly intended that all inputs used in the zip() function are of the same length (except possibly z which may not exist and will be made equal length to x); while it is not guaranteed they will be the same length this would cause unintended behaviour. * zip() function bool changed to strict=True in all these test cases. Most test cases either a) hardcode two things to be the same length, b) verify things are the same length before the function or c) explicitly exist to check whether two things are the same length. |
||
|---|---|---|
| .github | ||
| docker | ||
| docs | ||
| example_scenes | ||
| logo | ||
| manim | ||
| scripts | ||
| tests | ||
| .codecov.yml | ||
| .codespell_ignorewords | ||
| .codespellrc | ||
| .dockerignore | ||
| .flake8 | ||
| .git-blame-ignore-revs | ||
| .gitattributes | ||
| .gitignore | ||
| .pre-commit-config.yaml | ||
| .pylintrc | ||
| .readthedocs.yml | ||
| CITATION.cff | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| crowdin.yml | ||
| lgtm.yml | ||
| LICENSE | ||
| LICENSE.community | ||
| mypy.ini | ||
| pyproject.toml | ||
| README.md | ||
| uv.lock | ||
An animation engine for explanatory math videos
Manim is an animation engine for explanatory math videos. It's used to create precise animations programmatically, as demonstrated in the videos of 3Blue1Brown.
Note
The community edition of Manim (ManimCE) is a version maintained and developed by the community. It was forked from 3b1b/manim, a tool originally created and open-sourced by Grant Sanderson, also creator of the 3Blue1Brown educational math videos. While Grant Sanderson continues to maintain his own repository, we recommend this version for its continued development, improved features, enhanced documentation, and more active community-driven maintenance. If you would like to study how Grant makes his videos, head over to his repository (3b1b/manim).
Table of Contents:
Installation
Caution
These instructions are for the community version only. Trying to use these instructions to install 3b1b/manim or instructions there to install this version will cause problems. Read this and decide which version you wish to install, then only follow the instructions for your desired version.
Manim requires a few dependencies that must be installed prior to using it. If you want to try it out first before installing it locally, you can do so in our online Jupyter environment.
For local installation, please visit the Documentation and follow the appropriate instructions for your operating system.
Usage
Manim is an extremely versatile package. The following is an example Scene you can construct:
from manim import *
class SquareToCircle(Scene):
def construct(self):
circle = Circle()
square = Square()
square.flip(RIGHT)
square.rotate(-3 * TAU / 8)
circle.set_fill(PINK, opacity=0.5)
self.play(Create(square))
self.play(Transform(square, circle))
self.play(FadeOut(square))
In order to view the output of this scene, save the code in a file called example.py. Then, run the following in a terminal window:
manim -p -ql example.py SquareToCircle
You should see your native video player program pop up and play a simple scene in which a square is transformed into a circle. You may find some more simple examples within this GitHub repository. You can also visit the official gallery for more advanced examples.
Manim also ships with a %%manim IPython magic which allows to use it conveniently in JupyterLab (as well as classic Jupyter) notebooks. See the
corresponding documentation for some guidance and
try it out online.
Command line arguments
The general usage of Manim is as follows:
The -p flag in the command above is for previewing, meaning the video file will automatically open when it is done rendering. The -ql flag is for a faster rendering at a lower quality.
Some other useful flags include:
-sto skip to the end and just show the final frame.-n <number>to skip ahead to then'th animation of a scene.-fshow the file in the file browser.
For a thorough list of command line arguments, visit the documentation.
Documentation
Documentation is in progress at ReadTheDocs.
Docker
The community also maintains a docker image (manimcommunity/manim), which can be found on DockerHub.
Instructions on how to install and use it can be found in our documentation.
Help with Manim
If you need help installing or using Manim, feel free to reach out to our Discord Server or Reddit Community. If you would like to submit a bug report or feature request, please open an issue.
Contributing
Contributions to Manim are always welcome. In particular, there is a dire need for tests and documentation. For contribution guidelines, please see the documentation.
However, please note that Manim is currently undergoing a major refactor. In general, contributions implementing new features will not be accepted in this period. The contribution guide may become outdated quickly; we highly recommend joining our Discord server to discuss any potential contributions and keep up to date with the latest developments.
Most developers on the project use uv for management. You'll want to have uv installed and available in your environment.
Learn more about uv at its documentation and find out how to install manim with uv at the manim dev-installation guide in the manim documentation.
How to Cite Manim
We acknowledge the importance of good software to support research, and we note that research becomes more valuable when it is communicated effectively. To demonstrate the value of Manim, we ask that you cite Manim in your work. Currently, the best way to cite Manim is to go to our repository page (if you aren't already) and click the "cite this repository" button on the right sidebar. This will generate a citation in your preferred format, and will also integrate well with citation managers.
Code of Conduct
Our full code of conduct, and how we enforce it, can be read on our website.
License
The software is double-licensed under the MIT license, with copyright by 3blue1brown LLC (see LICENSE), and copyright by Manim Community Developers (see LICENSE.community).