Rebuilding Manim From Scratch

[awesome-developer-20]

I am thinking a lot to rebuild manim since currently manim has lots of bugs, two seperate mobject trees (One for Cairo and One for OpenGL), etc.

So, what do you all think is the best language and framework to rebuild it and what do you all think about things I should keep in mind while rebuilding manim.

[awesome-developer-20]

My views are as follows

Language and Framework Suggesions:

1. Cairo with Python (Cairo doesn't support 3d rendering!!)
2. Moderngl with Python => though it's the best opengl api, apple has deprecated opengl :(
3. Three.js with TypeScript/Dart/JavaScript => This is best for web, but it is not in python :(
4. Babylon.js with TypeScript/Dart/JavaScript => Same as Three.js
5. LWJGL with Kotlin/JAVA => It's the best graphics api with all featues but JAVA is not dynamic typed :(

Things to keep in mind:

1. CONFIG should be carefully managed either by attrs/dataclasses or by mattribue approach if rebuilted in python, else find out some other way
2. All core features should be accesible by plugins
3. Renderer and Mobject logic should be properly seperated

[Darylgolden]

well... you can certainly try if you'd like, but it wouldn't be in the scope of this project.

[awesome-developer-20]

I just wanted your suggestions since you have worked on manim a lot. Anyway, thanks for supporting 😄

[AntonBallmaier]

My dream solution would be to port parts of the manim core library to C++ and Open-/WebGL and make that still accessible through python - not in this year thought 😆

[awesome-developer-20]

Great, Can you suggest good c++ webgl library?

[awesome-developer-20]

Check this out: pygfx
It's still under development but it's amazing 👍

[ChristopherWirtOfficial]

I've been thinking about this recently myself, not to gravedig, and i think my personal Py in the Skie is Rust for the core API, written to be highly portable and composable, and then a head API in your language of choice, mine being Typescript (with wasm of the rust core) and obviously Python.

I think this approach brings a ton to the table:

• It allows some amount of parallel development for the heads based on the decided core API spec (or just arbitrary best guesses eventually resulting in a spec lol)
• It encourages a diverse ecosystem that's still fundamentally unsplintered by keeping the vast majority of the API in core
• It allows working backwards from the existing Python community edition, slowly replacing API spec parts with Python shims of the API, then later rebuilding those shims in Rust piece by piece.

That last one is super important because it also means almost the entire test suite never stops being a true benchmark.