Forking the discussion that started in #297 to here.

The problem

In the documentation, there will eventually be a (hopefully) substantial number of examples, both code and output videos/gifs. Git is pretty bad at tracking binary files, and if we keep these in the main repository, it will bloat up and become very clunky. Further, not every user/developer that clones the repository will need to (or want to) interact with the example gifs/movies.

The solution

@kolibril13 suggested that we create a new repository under the ManimCommunity organization. This repo would contain the gif/video files to be included in the documentation, but not the documentation itself. The documentation itself will remain under the main repository. Further, @naveen521kk brought up the fact that using GitHub for hosting is fine, but we should use other solutions for delivery and suggested jsdelivr. The benefits are that it will be much faster, and will be up whenever github is down.

What we need from you

Adding a new repository to the ManimCommunity organization is a fairly big change to the face of the organization, and I would not want to do that without making sure the core team approves. Up to now we have four people in favor (@Aathish04, @naveen521kk, @kolibril13, and myself). We need to hear from at least few more among @kilacoda @yoshiask @eulertour @PgBiel @XorUnison @kilacoda @huguesdevimeux @safinsingh @faielgila. Please feel free to thumbs up or down and/or raise any issues that you want to discuss.

PS: sorry for the multiple mentions in the other issue and this one. I just can't bring myself to make executive decisions on my own without running it by the whole team!

We have discussed about the variable CONFIGpreviously on discord. What should we do about it ?

I personally think we should modify at least a little bit of its architecture. it alters the readability a lot. One problem with that would be that in changing CONFIG we would have to review the entire architecture of the code.

What do you think?

Motivation

Over the past couple of weeks being part of the Manim Discord, I've seen a couple of issues with the SVG renderer. I myself have also had a lot of problems with it, most recently trying to import a map of the US as an SVG file. I think the SVG engine needs more robust functionality, and it looks like this is acknowledged but not an active priority (https://github.com/ManimCommunity/manim/projects/8).

I think SVG support is important to allow videos to go beyond the algebra and geometry constructs that 3b1b has made his bread and butter.

Overview / Explanation for Changes

In short, a rewrite of the SVG engine was needed, along with a fairly comprehensive test suite. Both of these will be addressed.

Oneline Summary of Changes

- Reworked the SVG rendering engine (:pr:`915`)

Testing Status

New tests have been provided and work effectively.

Further Comments

Full list of changes

SVG changes

• Rewrite of the SVG "path" interpretation code.
• Added multiple SVG unit tests in small hand-created SVG files
• Added multiple SVG system tests based upon SVG images that were provided by members of the Discord.
• SVGMobjects now include the fill and stroke properties of the images they were created from.

Non-SVG changes

• Added .idea to gitignore because I use PyCharm

Acknowledgements

• [x] I have read the Contributing Guidelines

Reviewer Checklist

• [x] Newly added functions/classes are either private or have a docstring
• [x] Newly added functions/classes have tests added and (optional) examples in the docs
• [x] Newly added documentation builds, looks correctly formatted, and adds no additional build warnings
• [ ] The oneline summary has been included in the wiki

There are a number of problems with our integration with Pango that are detrimental to library's code hygiene. Only one community member understands the code, how to build it, and how to deploy it. It's caused difficulty for installation and development from the time it was first added to as recently as #1075, but more than either than those it just isn't necessary for manim's use.

We developed the plugin system but continually find reasons not to use it, even in instances like this that it was designed for. I'm fine with keeping it in the pypi package, but leaving ManimPango in the main code doesn't make much sense to me.

As an aside, there are a number of additions that we should probably consider moving into plugins as well, such as jupyter integration and (more of) the webgl renderer now that #1075 is merged.

List of Changes

• Change 1

Add a streaming scene that uses its own file writer to override the normal functioning of the original to create a streaming protocol. Then, the original Scene class can use CairoRenderer as a default, until a helper class by the name Stream uses the advantage of renderer initialization for scenes to add a special renderer, that uses a special file writer. Most of the work I've been doing is make this accessible for other scenes. And I can say for sure, totally worth it.

class Stream:
    """This class is really intended for inheritance of the style:

    >>> class Streamer(Stream, Scene): # doctest: +SKIP
    ...     pass
    ...
    >>>

    This order is paramount. This :class:`Stream` class does the switch to
    the specialized renderer, which uses the :class:`StreamFileWriter` to
    handle specialized streaming services. That explains the calls to super,
    which dig through the MRO of a class instead of using just a single
    implementation contained in Scene. Okay, the references in super probably
    point to things in the :class:`Scene` class only, but it's already happened so...

    PS: You can probably already tell using this class on its own will bring you
    errors.

    """

• Change 2

Use rtp instead of tcp as the streaming protocol. Mainly for no other reason than it's what I understood and coded in that direction. If you think that means I didn't crack Twitch streaming then you are absolutely right. I tried tcp and udp already so feel free to tell me how to open a udp stream without blatant packet errors.

• Change 3

There are two versions of the livestreaming I made. Both do the same thing. The one under the function livestream is the main version and opens up an interactive session. The other one, stream, just returns the streamer. Easy to use for casual on the fly testing like:

>>> from manim import stream, stuff, other, stuff
>>> manim = stream()
>>> manim.play(...)

Nevertheless, both are available in the main library, depending on whether you need 500 objects in your global variables or not.

• Change 4

Any extras were probably made in order to have this working.

Explanation for Changes

I figure that any livestreaming option that was there in the past kind of broke, but the backbone of its capability was continuously carried around like a fossil. So I tried to implement it and it worked.

Testing Status

There's varying amounts of good and bad news here. Let me explain.

• Good

Since this Manim can directly influence camera configurations from the command line, this gives you high quality streaming:

python -m manim --livestream

This gives you medium:

python -m manim -qm --livestream

This gives you IMAX:

python -m manim -qk --livestream

• Good

Ability to use other base scenes for streaming. Really the crux of my implementation detail.

https://user-images.githubusercontent.com/67624028/113116179-dde9fd00-9215-11eb-8d9c-31a412f10628.mp4

• Superb depending on utility

Ability to render pre-made scenes with baked setup and/or construct methods.

https://user-images.githubusercontent.com/67624028/113116280-f78b4480-9215-11eb-8cfa-173b99bf8426.mp4

You can also use the play_scene function to specify a start and end animation, analogous to the -n keyword from the command line. For example: play_scene(scene, start=0, end=4)

• Bad

If I did my job well the ffplay window should be triggered automatically. But if it doesn't for some reason a command along the lines of this may help:

ffplay -x 640 -y 360 -protocol_whitelist "file,rtp,udp" -i "path\to\manim\media\streams\streams.sdp" -reorder_queue_size 0

• Bad

ffplay might glitch and show you a lot of red for some reason. Reopening it should fix one of those problems. For example the avai;able open_client(); get_streamer().wait() sequence should open ffplay again and trigger the opening of the window. Also there's something about the last frame of the animation not showing, but it's just one frame. You can close the window and run open_client() to restart the window, if this is the beginning of further glitching.

• Good

If it works though, expect something like this:

https://user-images.githubusercontent.com/67624028/113116436-1b4e8a80-9216-11eb-8a3f-712f0a8a47ed.mp4

Further Comments

• From StreamCairoRenderer

"""I wish there was another way to have a renderer that uses the
    file writer created for the purpose. However, I can't do that without
    the original code being aware of the extra implementation, which is probably
    undesirable style.
    """

• When using get_streamer, it is technically possible to use multiple classes to inherit more methods. The argument syntax clearly supports it yet its main use is to generates the tuple of the passed scene automatically. Multiple inheritance would be delicate and would only work if the classes after the first merely add more methods than override base ones. For example MovingCameraScene, LinearTransformationScene is a tempting concoction but unstable. For one, naming them in reverse is already an error, courtesy of the assertion in MovingCameraScene. Also, the latter adds attributes used in its methods from __init__, which wouldn't be called thanks to strict initialization minus super() proxies. Then again, multiple inheritance of scenes was always a delicate matter in Manim.

Acknowledgement

• [x] I have read the Contributing Guidelines*

*half true ***70 of the commits don't count, I was learning

Ok y'all, this is a doozy. I've been working on this and there's a few things that we need to decide as an organization. I'm going to try to make my points clearly and I'll bold the points at which I need y'all's input.

Rationale

The current repo is very badly disorganized and needs a good cleanup. One of the sources of this is the fact that there are different ways of manipulating what manim does as a whole:

1. constants.py sets some global variables (most of which are actually constant, but some of which are not).
2. config.py parses the CLI arguments, uses it to set camera_config among other things. It also initializes directories.
3. HOWEVER, there is also a dirs.py file that allowed you to set default output directories. config.py reads that in as well as the CLI arguments.

As a result, I think it's quite the hurdle for a user to figure out where to get or set the value of a particular variable that determines how manim works. If I want to change a directory, should I use dirs.py, or a CLI argument? Which has precedence over the other? If I want to change the resolution, should I do it in constants.py, by CLI argument, or in the CONFIG of my Scene objects?

The main purpose of this PR is to provide a single default source of global truth for configuring how manim works. (And, in the event that there is more than one possibility to set the value of a particular variable, the precedence between those possibilities should be very clear and documented.)

The proposal

The main way to do this is as follows. This PR makes it so that there is one single place to write/determine/set how manim works, and one single place to read/check/get those configurations once they are in place.

• Write: The user can now use an optional manim.cfg file to tweak the default behavior. Note this is a file that the user can have on their machine without touching the manim codebase at all. We will also ship a default config file so the user doesn't need to have such a file, but can have one if they want it.
• Read: once all configuration variables, directories, and CLI arguments have been parsed/processed, there is one single place where all of the configuration lives in for the rest of the execution: the global config dictionary that can now be imported by doing from .config import config (if within the library codebase) or by from manim import config (if importing the library as end user).

The constants.py file still exists, but as much as possible, it should not contain configuration variables, only constants. (more on this later).

How it works

I want to explain the main workflow of how this works. For this, note that there are two different ways of using manim: importing it as a library (to have access to Scene, Mobjects and so on), and as a command line script (to actually render a video).

If being imported as a library, this is what's going to happen. The user will type from manim import * at the top of their file. This executes the contents of __init__.py, which in turn imports/executes config.py before anything else. config.py defines and exports the config dictionary by parsing the manim.cfg file. This config will now contain all configuration needed for the end user (and indeed for internal purposes as well). Finally, config.py will also setup some directories (more on this later). (Note that this is a very odd way of using manim, like for example if you open a python interpreter and type import manim. Importantly, this will also be the case during testing. In most cases, manim will be used in the other way, in the next paragraph.)

If being used from the command line, for example as python -m manim ... or as manim ... or as manimcm ..., the file that gets executed first is __main__.py. This file also imports/executes config.py as the first order of business. In this case, config.py will recognize it's being used from the command line and, after parsing manim.cfg first, it will also parse the CLI arguments. The CLI arguments will override the default settings defined in manim.cfg. At the end, the global config dictionary will contain all configuration that correctly corresponds to the defaults in the .cfg file as well as the CLI arguments.

The result

When manim is being used as a library, there is no visible change other than the fact that some imports of the type from manim.constants import SOME_VAR and then using SOME_VAR will become import manim.config as config and then using config['SOME_VAR'], because some variables (that weren't constants) have been moved from constants.py into the config dictionary. More on this later (see discussion points).

When manim is being used from the command line to actually generate scenes, the changes are as follows. All the command line arguments are still in place. BUT, now the user may set the defaults by using their own manim.cfg file. For example, the -p (or --preview) flag is turned off by default so if the user wants the movie to play after it's rendered, currently they need to always specify -p. After this PR, the user can create a new manim.cfg file with the line PREVIEW = TRUE. If they do so, running manim without the -p flag will still show the video once it's rendered. This has the advantage that if a user needs a particularly long CLI command with lots of flags to render their scenes, they can just dump all of those flags into the manim.cfg file and just run manim myfile.py. The manim.cfg file currently allows to set default values for each command line argument.

The discussion points

I'm just going to dump a bunch of issues here in no particular order. I'll do my best to be brief and to point exactly what needs to be answered/discussed/decided in bold.

1. The main problem here is that we are still conflating constants along with configuration variables, in the following way. The PIXEL_WIDTH (previously called DEFAULT_PIXEL_WIDTH) variable can be set in command line via the -l, -m, -e, -r flags. So it is not a constant, and it should live inside config, not in constants.py. This PR makes it so. Now, there are other values, for example FRAME_WIDTH, that directly depend on the value of PIXEL_WIDTH, thus they are also not constant. HOWEVER, the configparser library that parses .cfg files does not support arithmetic operations. So right now there is no easy way to only set PIXEL_WIDTH once and have FRAME_WIDTH and related variables update their values as well. Right now, in this PR this is being done in the constants.py file: it is loading the config dictionary, which contains PIXEL_WIDTH and defines the other variables accordingly. I very much don't think this should be merged as is, but I wanted to ask what is the best way to solve this, knowing that this cannot happen in the .cfg file? My suggestion is that this happens inside config.py, with a special function that defines those variables such as FRAME_WIDTH once PIXEL_WIDTH is set. However, this means that the user can set only the latter and the former will always be tied to it in the same hard-coded way. EDIT: I think a good example to fix this issue is to consider the question, where do we define TOP? Currently, it is defined in constants.py, with the line TOP = FRAME_Y_RADIUS * UP. Now, I think UP is a true constant and it should stay in constants.py. But FRAME_Y_RADIUS depends on FRAME_HEIGHT, which is not constant and is set by CLI argument in config.py. If we adhere to the strict view that only true constants must remain in constants.py, then TOP must go elsewhere.

2. Due to the above (some configuration variables are being loaded into constants.py), I converted all configs and constants to ALL_CAPS. Accordingly, the CONFIG dictionary of Scenes and Mobjects were also turned to ALL_CAPS. I think this is ugly as hell and hope this changes in the future. Fixing the issue of constants vs config variables should make this go away.

3. For the problem of importing config.py before anything else, see #26. I think we are in the clear here.

4. The current version does not work with python -m manim ... (see definition of prog in config.py). This is because it is actually very difficult to determine if the library is being imported or run from the command line (at least from the config.py file). I need suggestions for how to fix this.

5. This is a pretty big change so if there is anything that you can think of, please bring it up here.

6. Currently, all of the keys in SceneFileWriter.CONFIG are keys of the global config dict. Does SceneFileWriter really need a copy of each? Pinging @PgBiel here who is working on attrs.

7. Yes, this has been tested and renders scenes well. I have by no means ran an exhaustive test suite of all constants/configs/CLI flags yet.

List of changes

I'll list some of the minor changes made that are not big-picture issues. Please comment on these too if you have anything to say.

1. start_at_animation_number is now FROM_ANIMATION_NUMBER. Similarly, end_at_animation_number is now UPTO_ANIMATION_NUMBER. These are shorter and have the same meaning. (I don't like the ALL_CAPS, but that's a different issue touched upon above.)
2. dirs.py has been eliminated. Instead of dirs.video_dir, now you have to do config['VIDEO_DIR']. This will require changing from dirs import video_dir to from config import config and using config['VIDEO_DIR']. If we don't want to have to load the whole global config just for the one directory name, we can package the directories in a separate dict, also defined in config.py and load it as from config import dirs.
3. input_file_path has changed to INPUT_FILE, and file_name has changed to OUTPUT_FILE. The original names were just confusing.
4. The default configuration file is now packaged with the rest of the code, as seen in in setup.py.
5. DEFAULT_PIXEL_WIDTH, DEFAULT_PIXEL_HEIGHT, and DEFAULT_FRAME_RATE have been changed to PIXEL_WIDTH, PIXEL_HEIGHT, and FRAME_RATE. The reason is that once the config is read and the CLI arguments parsed, they are no longer a 'default' value, but possibly a value set by the user, so the names were misleading. The new names are also shorter.
6. PRODUCTION_QUALITY_CAMERA_CONFIG is now just the default config['CAMERA_CONFIG']. Also, note that config['CAMERA_CONFIG'] is changed by the *-quality flags (low-quality, medium-quality, high-quality) and by the --resolution flag.
7. The scene_names CLI argument is now --scene_names for easier parsing.
8. Changed open_video_upon_completion to PREVIEW so it has the same name as its corresponding CLI flag. It is also way shorter.
9. Removed the ignore_waits option which was never used and was set to the value of args.preview.
10. Most CLI flags have been changed to have no default value. For example, -p was by default False, but will now default to None. This is done that we can easily determine whether the user actually specified this flag by comparing it to None. If the flag is None, we read the default value from the manim.cfg file instead. Importantly, this is a subtle change in the code (see comments inside _parse_cli() in config.py if you are interested.
11. The way everything is setup right now, passing only the -s flag will also write a movie (since WRITE_TO_MOVIE is True by default in manim.cfg). See #41.

List of standing or future issues

While working on this, I realized there is a number of other things that I would also like to change, but I'm not sure if they should be part of this PR or a separate one.

1. I think there are a bunch of variables/constants that have DEFAULT_ in the name but that should not have it.
2. The output directories are being created during initialization (when config.py is read). I think the directories should be created at the last possible minute. If I run manim and it crashes before writing the scene, the directories will be created but empty.

PS

Mostly for my sanity: this interacts with #65, #81, #77, #151 so I'll get back to those when this is merged.

In this PR

• Add configuration for Poetry.
• Changed links in the Readme file to use Github Url instead of a relative path. ( Required for Publishing Package )

What is Poetry?

Poetry is a dependency manager as well as help us publish packages to Pypi. Refer to their website for more info https://python-poetry.org/.

But even here, pycairo creates a problem. Well, we should need to think about it. (Now it is fixed)

See https://github.com/python-poetry/poetry#installation for installation on your PC. Also, don't forget to read the documentation.

Also, according to https://www.python.org/dev/peps/pep-0518/ adding a pyproject.toml is necessary.

You could read https://github.com/python-poetry/poetry#what-about-pipenv.

One thing which should be done.

• [x] Wait for new Pycairo release

Motivation

Closes #452

This is a refactor which moves Manim away from argparse and towards click in order to allow future developers to easily add future subcommands, options, and arguments.

Changelog / Overview

This change breaks the CLI API to organize the structure of Manim Community's commands, options, and arguments.

To be more in line with POSIX compliant CLI conventions, options for commands are given BEFORE their arguments. In Argparse: manim basic.py -p -ql With Click: manim -p -ql basic.py

Although this is primarily a refactor and most of the common options are still there, some options have been added/removed. Use the manim command's -h, --help option, or simply run the command without providing options/arguments to view the help page with the full list of subcommands/options/arguments.

• Added a --fps/--frame_rate option which allows for custom fps that don't have to be integer (i.e. 29.97, 23.98, etc.). Users no longer have to specify the FPS from within a config file. Additionally, the --webgl_renderer_fps option has been removed. Use --fps or --frame_rate instead.
• Added a --renderer option which you can use to select your choice of renderer (e.g. --renderer=opengl). There are currently THREE renderers to choose from!
• Removed the --background_color option. Reassigned the --background_color option's shorthand -c to --config_file.
• Removed the --leave_progress_bars option. Use --progress_bars=leave instead.
• Removed the deprecated render quality flags, in particular: -l, -m, -h, -k.
• Removed the --sound option. It lost support long ago with the removal of SoX.

By default, the manim group calls the manim render subcommand through some decorator magic (i.e. manim -pql basic.py is a shorthand for manim render -pql basic.py). All of the subcommands and their options are contained within the manim/cli directory which is where the focus of the code should go. Most testcases that involve using the CLI had to be refactored as well to accomodate the new method of providing options before arguments ( arguments being the file/scene(s) ).

Testing Status

All test cases are currently pass on all OSs in our CI!

Further Comments

There will be some refactoring in future commits to this PR, particularly documentation of the functions. This is a successful first draft though.

The intent is to eventually redo the ManimConfig object as well using a similar decorator style approach to easily add config options with customized validation logic.

The new CLI structure is as follows:

manim [Defaults to: render*]
    |- options
|---render
    |- options
    |-file, scenes
|---cfg
    |---export
        |- options
    |---show
    |---write
        |-options
|---plugins
    |-options

If you're curious to see the new help messages without adding my remote:

Usage: manim [OPTIONS] COMMAND [ARGS]...

  Animation engine for explanatory math videos

Options:
  --version   Show the version and exit.
  -h, --help  Show this message and exit.

Commands:
  render*  Render SCENE(S) from the input FILE.
  cfg      Manages Manim configuration files.
  plugins  Manages Manim plugins.

  Made with <3 by Manim Community developers.

Usage: manim render [OPTIONS] [FILE] [SCENES]... COMMAND [ARGS]...

  Render SCENE(S) from the input FILE.

  FILE is the file path of the script.

  SCENES is an optional list of scenes in the file.

Options:
  Global options:
    -c, --config_file FILENAME    Specify the configuration file to use for
                                  render settings.

    --custom_folders              Use the folders defined in the
                                  [custom_folders] section of the config file
                                  to define the output folder structure.

    --disable_caching             Disable the use of the cache (still
                                  generates cache files).

    --flush_cache                 Remove cached partial movie files.
    --tex_template FILENAME       Specify a custom TeX template file.
    -v, --verbose [DEBUG|INFO|WARNING|ERROR|CRITICAL]
                                  Verbosity of CLI output. Changes ffmpeg log
                                  level unless 5+.

  Output options:
    -o, --output TEXT             Specify the filename(s) of the rendered
                                  scene(s).

    --media_dir PATH              Path to store rendered videos and latex.
    --log_dir PATH                Path to store render logs.
    --log_to_file                 Log terminal output to file  [default: True]
  Render Options:
    -n, --from_animation_number TEXT
                                  Start rendering from n_0 until n_1. If n_1
                                  is left unspecified, renders all scenes
                                  after n_0.

    -a, --write_all TEXT          Render all scenes in the input file.
    -f, --format [png|gif|mp4]
    -s, --save_last_frame
    -q, --quality [l|m|h|p|k]     Render quality at the follow resolution
                                  framerates, respectively: 854x480 30FPS,
                                  1280x720 30FPS, 1920x1080 60FPS, 2560x1440
                                  60FPS, 3840x2160 60FPS

    -r, --resolution TEXT         Resolution in (W,H) for when 16:9 aspect
                                  ratio isn't possible.

    --fps FLOAT                   Render at this frame rate.  [default: 30]
    --webgl_renderer PATH         Render scenes using the WebGL frontend.
                                  Requires a path to the WebGL frontend.

    -t, --transparent             Render scenes with alpha channel.
    -c, --background_color TEXT   Render scenes with background color.
                                  [default: #000000]

  Ease of access options:
    --progress_bar [display|leave|none]
                                  Display progress bars and/or keep them
                                  displayed.  [default: display]

    -p, --preview                 Preview the rendered file(s) in default
                                  player.

    -f, --show_in_file_browser    Show the output file in the file browser.
    --sound                       Play a success/failure sound.
  -h, --help                      Show this message and exit.

  Made with <3 by Manim Community developers.

Usage: manim cfg [OPTIONS] COMMAND [ARGS]...

  Manages Manim configuration files.

Options:
  -h, --help  Show this message and exit.

Commands:
  export
  show
  write

  Made with <3 by Manim Community developers.

Usage: manim cfg export [OPTIONS]

Options:
  -d, --dir TEXT
  -h, --help      Show this message and exit.

Usage: manim cfg show [OPTIONS]

Options:
  -h, --help  Show this message and exit

Usage: manim cfg write [OPTIONS]

Options:
  -l, --level [user|cwd]  Specify if this config is for user or the working
                          directory.

  -o, --open
  -h, --help              Show this message and exit.

Usage: manim plugins [OPTIONS]

  Manages Manim plugins.

Options:
  -l, --list  List available plugins
  -h, --help  Show this message and exit.

  Made with <3 by Manim Community developers

Acknowledgements

• [x] I have read the Contributing Guidelines

Reviewer Checklist

• [ ] Newly added functions/classes are either private or have a docstring
• [ ] Newly added functions/classes have tests added and (optional) examples in the docs
• [ ] Newly added documentation builds, looks correctly formatted, and adds no additional build warnings
• [ ] The oneline summary has been included in the wiki

Motivation

Manim doesn't render animations completely. For a video rendering library, this should be priority 1 right now. See #183 for @huguesdevimeux's excellent report. In short, the animation

class MyScene(Scene):
    def construct(self):
        self.play(ShowCreation(Square()))

generates a video whose last frame is this:

You can see that the square has not been rendered fully, there is still a bit of the animation left to play (see open top left corner).

After discussion in #183, the way to solve this seems to be to simply add the last frame manually at the end of the video. With the mess that is scene file writer, scene, renderer, caching, etc, it was not obvious to me how to do this correctly. Luckily, thanks to all the good work put it by the dev team recently, I was finally able to figure it out, I think.

Explanation for Changes

The way things currently work:

1. Each call to play opens a new FFMPEG pipe.
2. Each frame is fed into the pipe.
3. When animation ends, the pipe is closed.

The way I'm proposing we do things:

1. Each call to play closes a previous FFMPEG pipe, if one exists.
2. Open a new pipe.
3. Feed each frame into the new pipe.
4. Leave the pipe open.

After all frames are fed, one of two things can happen: (a) play is called with a new animation (in which case it would close the currently open pipe in step 1.), or (b) the video ends. If the video ends, Renderer.finish() is called, which now takes care of writing the last frame (this is the bug fix! :tada:) and closing the open pipe, so no pipes are ever left unattended. This is basically what you see in the diff in renderer/cairo_renderer.py.

There is only one sticking point: the first call to play will try to close an (unexisting) pipe, so I added a quick check for that in scene/scene_file_writer.py

Testing Status

The tests currently do not pass, because this fix will change some tests. However before further work I wanted to hear what everyone thinks. Mainly, this bug will make it so that a manim script with a single 1s animation will render a video that is longer than 1s. I believe this should be fixable by tweaking the last call to ffmpeg somehow, but I'm not sure how.

Further comments

I believe #618 should be addressed only after merging this (or else fixing #183)

This is a pretty big change and it will break user space so thoughts appreciated @ManimCommunity/core

This was discussed in yesterday's meeting that the Manim Core should be small and easily understandable, and shouldn't contain complicated code. As in it should only contain Renderer, Scene, Camera, File Writer and basic Mobject structures.

My thoughts on this:

• Create a new project, call it manim-core and move all the Renderers, Camera, Scene and anything we consider important. Let it have the same module name, manim and I have seen that this works. This repository will have a dependency on the other and published as a separate PyPI package.
• manim-core would only have as much as it is useless without other parts of the library, with no other extra dependencies like ManimPango, NetworkX.
• Make this project, manim a collection of curated plugins by the community, while this doesn't affect the core library.
• Making parts of library optional to install, for example, one could be able to just get geometric Mobjects + Core renderer.

Motivation

The three methods seem to create some confusion for beginners, its not really a breaking change, just making things more intuitive.

Overview / Explanation for Changes

Before:

set_fill(), set_stroke() - Changes fill/stroke color, doesn't affect opacity if not mentioned set_color() - just calls the above two methods together

Problem:

The default fill color has 0 opacity, as a result doing this:

Circle().set_stroke(BLUE) - a BLUE outlined circle
Circle().set_fill(BLUE) - a default colored outlined circle
Circle().set_color(BLUE) - a BLUE outlined circle

Isn't that confusing because the default fill is transparent?

After:

set_fill(), set_stroke() - Called on transparent object and opacity not mentioned? then set opacity to 1 set_color() - works exactly the same. just added optional opacity parameter if you want to adjust fill.stroke opacities together

Circle().set_stroke(BLUE) - a BLUE outlined circle # same as above
Circle().set_fill(BLUE) - a default colored outlined + blue filled circle # opacity altered here with this change
Circle().set_color(BLUE) - a BLUE outlined circle # same as above
Circle().set_color(BLUE, opacity=1) - a BLUE outlined circle + filled circle # new feature/parameter

And this looks much more intuitive and better. Also set_color_only() function is added which doesn't affect these opacities, (to make FadeToColor animation work as intended) Added docs to some functions

Oneline Summary of Changes

- set_fill() and set_stroke() improved, set_color() optional opacity parameter added (:pr:`956`)

Acknowledgements

• [x] I have read the Contributing Guidelines

Reviewer Checklist

• [ ] Newly added functions/classes are either private or have a docstring
• [ ] Newly added functions/classes have tests added and (optional) examples in the docs
• [ ] Newly added documentation builds, looks correctly formatted, and adds no additional build warnings
• [ ] The oneline summary has been included in the wiki

Fixes #3104

Overview: What does this pull request change?

No change in behavior or features. Only changes explanation displayed when --help flag is used

Links to added or changed documentation pages

Configuration Page

Reviewer Checklist

• [ ] The PR title is descriptive enough for the changelog, and the PR is labeled correctly
• [ ] If applicable: newly added non-private functions and classes have a docstring including a short summary and a PARAMETERS section
• [ ] If applicable: newly added functions and classes are tested

Porting all the new features from 3b1b/manim drastical rewrite of the render system.

Currently no explanation because it is highly experimental. Further discussion about this can be found on the discord server.

Overview: What does this pull request change?

Adds assignments from self.depth_test to SHADER_WRAPPER.depth_test in the update_SHADER_WRAPPER methods of OpenGLVMobject. Without this assignment, the depth_test parameter would not be given to the shaders and thus effectively ignored (as it is only assigned to self.depth_test, but not used further).

Motivation and Explanation: Why and how do your changes improve the library?

Links to added or changed documentation pages

Further Information and Comments

Reviewer Checklist

• [ ] The PR title is descriptive enough for the changelog, and the PR is labeled correctly
• [ ] If applicable: newly added non-private functions and classes have a docstring including a short summary and a PARAMETERS section
• [ ] If applicable: newly added functions and classes are tested

Overview: What does this pull request change?

Motivation and Explanation: Why and how do your changes improve the library?

Links to added or changed documentation pages

Further Information and Comments

Was added in #2915, after the conversion of all param types to type-hints in #2988, so this is currently the only param type in docstrings.

Reviewer Checklist

• [ ] The PR title is descriptive enough for the changelog, and the PR is labeled correctly
• [ ] If applicable: newly added non-private functions and classes have a docstring including a short summary and a PARAMETERS section
• [ ] If applicable: newly added functions and classes are tested

The current documentation of the --resolution flag says the format is (W,H) which is confusing because the passed value needs to be of the form "W,H"so the documentation should be updatet accordingly such that it reflects the usage -r "W,H" best with an example of -r "1920,1080"

class Test(ThreeDScene):
    colors = [RED, GREEN, YELLOW, WHITE, BLUE, ORANGE]

    def create_cube(self):
        cube = Cube(1)
        for i, face in enumerate(cube):
            face.set_fill(self.colors[i])
            face.set_stroke(BLACK, 2)
            face.round_corners(0.2)
        return cube

    def construct(self):
        self.move_camera(phi=75 * DEGREES, theta=-45 * DEGREES)
        cubes = []
        for x in range(3):
            for y in range(3):
                for z in range(3):
                    cube = self.create_cube()
                    cube.shift((x - 1) * RIGHT + (y - 1) * UP + (z - 1) * OUT)
                    cubes.append(cube)

        self.play(
            AnimationGroup(
                *(GrowFromPoint(cube, cube.get_center()) for cube in cubes),
                lag_ratio=0.5,
                run_time=2
            )
        )
        self.wait(