Why I created MotionGfx?

Prelude

For those unaware, MotionGfx is a backend-agnostic motion graphics creation framework. It uses a command-based workflow to generate animations (similar to Manim and Motion Canvas). We’re working hard on an editor and LLM integration.

The old guard: After Effects

For many years the industry has been stuck with After Effects. It’s amazing, even effective when it comes to motion graphics. However, throughout my usage of the software, I’ve run into 3 recurring bottlenecks:

1. Performance. After Effects is extremely inefficient. I still remember importing an SVG or converting my text into Bézier curves and trying to trace all the paths within it like 3b1b style and the software just keeps playing back at such slow speed, even less than 1 frame per second sometimes. This was a few years back, so I’m not sure if they’ve since improved on that. I’m sure I had great hardware (GTX 1080 Ti at that time).
2. Repetitive labor. Animating something complex was such a pain. You will have to manually create and adjust keyframes. Not to mention the scripting experience was horrible, and it was the only way to achieve procedural-related animations.
3. Lack of real-time integration. This may not affect anyone, but I do care about it as I used to be a game developer. And knowing what you could do with After Effects, and then knowing it’s not easy to bring it into real-time applications is a bummer.

Lottie and Rive

Then came Lottie. Lottie never intended to replace After Effects. In fact, they knew it so well that they even made a feature that allows users to export Lottie into After Effects. Lottie also introduced state machines recently, making it even more seamless to plug into real-time applications. Lottie is this middle-ground thing where it’s small, efficient, real-time, but yet, not as powerful as After Effects. A major drawback is that they only focus on pure vector graphics, when in fact, they should be able to extend into 3D meshes too! (3D meshes are vector graphics too!)

Rive, on the other hand, is arguably the closest to what an AE successor would look like. It has low-level support (custom shaders / pipelines), 3D support, state machines for real-time applications, etc. The major downside, however, is its closed source policy. When a technology is behind pay walls, it tends to reduce confidence in developers, especially open source enthusiasts like me! We desperately need a version of Rive with some changes to how it handles keyframe animation (we’ll talk about this later) that is open, and free. One where anyone can just depend on the file format and swap any renderer they want and with whatever custom workflow / pipeline they decide.

Both, however, did not address the keyframe problem that Motion Canvas and Manim resolve beautifully.

Note: I’m intentionally leaving Blender out of this because it’s another beast, I don’t think we can match what Blender has in terms of 3D animation, but with time, we could?

Keyframes vs commands

Keyframes

The keyframe problem goes like this. Say you created an animation sequence and you’re proud of your result. You take it to your boss and show it to him. Your boss says that one section of your animation is lacking and asks you to add details. So you go back to edit your animation, but now you’re greeted with a wall of keyframes.

With keyframes, inserting these new details requires dragging chunks of keyframes out of the way to make room for new ones! Not to mention, these new details may have knock-on effects to the original keyframes. So you’ll have to manually tweak those to keep the whole animation fluid and sensible.

Commands

Commands treat animation in a different way. Instead of specifying each and every state in precise timing, you describe the motion as a sequence of actions.

This way, editing the animation can be as simple as adding a new action anywhere in between! Of course, this is a simplified visualization of it. In practice, commands can be very complex too — you can create a flow of actions, chain them, or have them played simultaneously. But the point is, the timing was never baked in, it’s always a consequence of the actions that came before it!

This is how you create animations in Manim, Motion Canvas, or MotionGfx under the hood! Animations are created as a sequence of actions / commands and layered on top of one another.

30 seconds from this timestamp by the original Motion Canvas author sums it up well.

The AI era

Then came the AI era, with YC backed companies like Hera and Midrender/Revideo. I know there’s also Palmier, but that’s more like Premiere Pro than After Effects.

Midrender/Revideo in particular is pretty interesting to me. I have personally used Motion Canvas for a presentation before on “shaders” (repo). It’s beautiful, seriously. The workflow is very intuitive, and it’s close to the web. And that might be one of its downfalls. I’m not against using web as a renderer, but you have a bunch of limitations when it comes to web technology, especially when it comes to what the GPU can do. I know WebGPU has done a great job to reduce that. But then again, the browser is not the first place where you get to use the most advanced features. What’s even more pressing here is that TypeScript is simply not fast. There was a section in my slide where I was showcasing the many pixels you have on screen, but I was limited to how many squares I can animate due to performance issues. This also brings me to my next main topic: keyframes might not be the problem that Manim and Motion Canvas want to solve.

But before that, quick word about how these companies use AI.

Midrender

Midrender still relies strongly on generating animation via code (Motion Canvas’s way of doing things). It works but to a point. I’ve recently released a few videos using AI to create animations using MotionGfx. While it’s usable and very powerful, the audience for this kind of workflow is very niche. The everyday animators and designers simply do not code! Furthermore, it can sometimes get tricky to keep track of what the AI is generating, especially without something (like a timeline) to visualize your animations.

Hera

Hera generates animations entirely using AI, with some room to make limited changes, like the color of an object. Changing much more requires regenerating the entire animation. To me, it’s just not an editor. You need to have full control over your timeline structure to be able to make custom modifications. No serious animators would want a prompt-only editor. In my eyes, it’s set to fail. Not that it won’t make money, but that it can’t scale.

How will MotionGfx use AI?

My plan with MotionGfx hasn’t been consolidated yet. But it’s heading somewhere that lets you edit animations via the editor itself, while also being able to create complex motion templates or low-level shaders from scratch using code.

What’s wrong with just using commands?

The problem is twofold: first and foremost, this animation paradigm is still saturated with using code as the main workflow. The other is how command-based animations are being sampled.

The first problem, I think, in my humble opinion, is just a mere design problem. We just need someone to come up with an editor with amazing user experience!

The second problem is what causes Manim and Motion Canvas to be sluggish as an editor. Every time you scrub the timeline backwards (let’s say from 10s to 5s), the engine has to recalculate all the state from the first frame until “now”. This is the result of using “command” based animation as opposed to “keyframe” based. MotionGfx mitigates this by embracing both worlds. I know that command-based animations are nice in that you can easily articulate your animations and have an easy time editing them. But I also understand that it’s only keyframes that allow you to scrub your animations in both directions with equal performance.

MotionGfx achieved this unification in a very simple way. Treat the animation creation method as commands, then, bake them into keyframes once before performing the animation!

Closing thought

I have a very optimistic view of what MotionGfx can become in the future: a unified motion engine with low-level support, real-time integration, 2D and 3D native, video and audio support, and most importantly, fully open sourced and dual licensed under MIT and Apache 2.0!

I’ll admit, creating a motion editor while trying to compete with this industry-leading software is extremely challenging. But that’s not a reason for us not to try! After all, we’re born to create, and create we will!