Manim 2.0?

[hugglesfox]

There seems to be quite a lot of maintainability issues with the current Manim and areas which don't make full use of features of the python language but fixing them would basically require a rewrite of the codebase. Here are a few of the potential areas for improvement I have found:

• There's lot of getter and setter functions in which should be properties

• Using a python based latex compiler such as PyLaTeX would help decrease non-python dependencies. It would be nice if we could eliminate all non-python deps to simplify the install process although I'm not sure if that's practical.

• Using the new pipfile standard to manage python dependencies.

• imports.py should be __init__.py and __init__.py should be __main__.py

• 609 split it modules. A lot of Manim is only required for specific use cases which is inevitable for it's use but that code should be split into modules based on functionality which the user can chose whether to be imported or not. E.g. if #764 is merged, then it should have it's own module called physics. This would also allow for large files to be split up (not to pick on #764 but it's good as it shows how much effort currently needs to be done to implement new objects) e.g psychics.py could be split into particle.py and pendulum.py inside the physics module.

• Configuration management could be done much the same way as flask, through a single object called Config which parses say a yaml file then all the other modules can import the config and use it like a dictionary e.g config['CAMERA_QUALITY'] to get values instead of having functions such as get_camera_configuration().

The end goal of all of this is to abstract and automate as much of the internal stuff away from the module writers as well as users to make the code clean and readable.

Although these changes would break a lot of existing code using the library thus something that needs to be decided by the community whether it's worth it.

If you have any other suggestions for changes that would be suitable for a 2.0. Please comment on this issue. It would be nice to start compiling a list.

[eulertour]

You raise some good points. I also noticed that manim has a lot of maintainability as well as convenience problems and started working on a full rewrite of manim in an entirely different language, javascript, at v2.eulertour.com: github link It's still in the works, but when it's finished this version will allow for real-time previews, a user interface for visually tweaking animations and mobjects, interactivity, portability, and of course all of the features that are in this version of manim.

There's a lot of work to be done before this is ready, so if you're interested in helping please get in touch with me on the manim discord.

[PhilippImhof]

I absolutely agree with the issue at hand. When adding the new function for customizing the LaTeX template, i struggled a lot with the structure. Also, pull requests are pending for a long time and do not seem to be merged regularly. This is frustrating, especially for small improvements.

@eulertour Your work is impressive. I will have a look at it and see whether I am able to contribute, albeit rather small things.

[hugglesfox]

@eulertour Whilst eulerv2 is very cool but I don't know javascript. I also don't think that just forking and rewriting, whilst a valid option, is particularly a good idea as I feel like were taking the project away from Grant. I don't particularly agree with Grant's view of not wanting to document or properly support it especially as Manim (imo) is probably the best math visualization tool currently open sourced but I can see why he takes this view and respect it.

[PhilippImhof]

@haydenhughes Good point. I would not want to take anything away from Grant, even less so because I am grateful he shared his work (the videos and the tool to create similar ones) with us. As I understand it, eulerv2 is, first of all, a frontend. Having better usability and documentation could actually make more people use the tool and thus, as I see it, be able to honor Grant's work.

You say you see why he does not want to document it. I could see one possible reason: he does not have the time to do it himself. But then again, wouldn't he be happy to see that many people are willing to contribute smaller or larger things to make his work even better. As I never saw any statement from him on this subject, do you know more about his reasons?

[hugglesfox]

@PhilippImhof I don't know the reason. @3b1b?

[eulertour]

@haydenhughes It seems like you're conflating two different things. On one hand, Grant has repeatedly said that he has no desire to document or maintain manim beyond what is necessary to make his videos, and I also think that's a reasonable view to take. But keeping the project associated with Grant is a different topic entirely, and I don't see the reasoning behind it.

As I said before, Grant has made it very clear that he doesn't want to put the effort into making manim a community tool. At the same time, he's said that he wants more people to use it, but acknowledges that setting up and using manim is too difficult for him to recommend it to most people. He has also personally advocated the development of this project after I presented it to him.

The goal of developing manim is to make it as easy as possible to educate people. I don't think it makes sense to forgo that goal in order to maintain some sort of continuous association with the original project.

[625248808]

Emm... Just a question, how to download the manim? When I checked the botton named Clone and Download, it didn't give me any way to download. What happend? How to do it?Hope to get a quickly answer.

[hugglesfox]

@625248808 There should be a button named download zip in the clone and download submenu which just gives you this link: https://github.com/3b1b/manim/archive/master.zip

[yoshiask]

These suggestions are things we've discussed in detail before on the manim Discord server. I agree that manim would likely require a rewrite to implement most of the proposed changes. I personally think that Python is far from the best choice for a library like this. I prefer C# because it's an easy language and supports nearly every platform in existence. It's also easy to install both the library/program itself and any developer tools it requires.

That being said, manim doesn't need to have one specific language. Manim can simply be a standard for how scenes are made and how the rendered video looks. For example, both my .NET library and @eulertour's JS library mimic manim without using its original Python code at all. That way, manim can be used wherever a mathematical visualization would be beneficial, not just for the creation of videos.

[PgBiel]

The good in using Python is its wide range of math- and science-related libraries, such as numpy. That will definitely be a huge point to consider when porting manim to any other language, noting that there are math libraries in most, if not all, languages, but most don't even come close to the Python languages' power. This requires being pondered at, considering there are many complex manim projects out there (by other people than 3b1b, but also his own projects) that simply depend on this.

[leotrs]

I prefer C# because it's an easy language and supports nearly every platform in existence. It's also easy to install both the library/program itself and any developer tools it requires.

@yoshiask, Python also fits this description. Besides, similar to what @PgBiel said, most people I know who would be interested in producing videos with manim are far more likely to know python than to know C#.

I think the general topic of manim 2.0 is different than porting to other languages (@eulertour), or taking anything away from Grant. The whole point of open source is that anyone is able to take the code and make the best of it. I respect Grant's decision to not want to maintain a community tool -- it's usually hard, painful, and thankless job. However, that does not mean that the community itself couldn't do it.

I'm all for either a) convincing Grant to give his blessing on a community maintainer of this repo, or b) forking and making a separate community repo (still in python). I think both of these options respect everybody's wishes, including @3b1b's and @eulertour's, and also answer the clear call from the community to push manim into a production-level community tool.

[yoshiask]

I prefer C# because it's an easy language and supports nearly every platform in existence. It's also easy to install both the library/program itself and any developer tools it requires. Python also fits this description. Besides, similar to what PgBiel said, most people I know who would be interested in producing videos with manim are far more likely to know python than to know C#.

Installing Python and all of Manim's dependencies is not an easy task. At any given time, there are at least 3 open issues from people asking for installation help. C# libraries don't have this issue as much, since Visual Studio manages .NET and NuGet handles external packages. As for who this is for, it doesn't have to be used directly from user code. I personally already started my own port of Manim to C#, but it's intended to be used by my own app that provides a visual editor. The library is meant to represent Manim, not necessarily replace it entirely. You're probably right that more people interested in Manim know Python, but a .NET implementation isn't entirely useless.

I'm all for either a) convincing Grant to give his blessing on a community maintainer of this repo, or b) forking and making a separate community repo (still in python). I think both of these options respect everybody's wishes, including 3b1b's and eulertour's, and also answer the clear call from the community to push manim into a production-level community tool.

I completely agree with this. As much as I've invested in .NET Manim, I agree that it isn't a complete solution. Both options you listed are viable on their own, and I'd fully back whichever one we go with. Personally, I think either @eulertour or @PgBiel should take the role of community leader, since they already are mods for the Manim Discord.

[yoshiask]

The good in using Python is its wide range of math- and science-related libraries, such as numpy. That will definitely be a huge point to consider when porting manim to any other language, noting that there are math libraries in most, if not all, languages, but most don't even come close to the Python languages' power.

Yes, this is a big problem. There are .NET implementations of numpy (see NumSharp), but they're not easy to use. And that's not to mention that simple actions in Python (such as array slicing) is difficult to implement properly in C#. However, I still think that a .NET port would be beneficial for external applications. I agree that a .NET version isn't very helpful for direct usage.

[leotrs]

I think the installation problem has a lot to do with having a stale code base. Well-maintained python code is easy to install. But let's not get in the weeds here. I agree with everything else you said (and I never meant to say that a C# version would be/is useless).

I completely agree with this. As much as I've invested in .NET Manim, I agree that it isn't a complete solution. Both options you listed are viable on their own, and I'd fully back whichever one we go with. Personally, I think either @eulertour or @PgBiel should take the role of community leader, since they already are mods for the Manim Discord.

Fully agree here too.

[yoshiask]

@leotrs Glad we agree!

Now that I realize it, this isn't the right place for me to discuss any kind of manim port, so I'll shut up about that for now. If you're interested, feel free to open an issue on my repo https://GitHub.com/yoshiask/ManimInteractive.

[yoshiask]

For anyone who may be watching here and not on the Manim Discord, a small team has been assembled to create a community version of Manim. https://github.com/ManimCommunity/manim