Skip to content

What is MC Animaker?

MC Animaker is a powerful ecosystem of tools designed for map makers, content creators, and animators who want to push the boundaries of what is possible in Minecraft Java Edition.

It bridges the gap between Blender's advanced animation capabilities and the Minecraft datapack system. The addon can be used to create and animate models from simple ones to extremely advanced ones. It dramatically streamlines the creation process, making complex animations that would previously be insanely difficult (or downright impossible to code by hand) easy and intuitive to produce.


How It Works

MCA Toolkit runs inside Minecraft and prepares everything needed for MCA Link to work. It also loads exported scenes and controls them in-game (play, move, rotate, etc).

MCA Link runs inside Blender and gives you the tools to create objects and manage properties like block states and custom NBT. You can animate them using Blender's native tools, and export them in a format that MCA Toolkit can understand.

In short:

  • Create your scene in Blender
  • Export it with MCA Link
  • Load and play it in Minecraft with MCA Toolkit

Even though MCA Toolkit is required to play the animations, the models and animations themselves are fully vanilla.

This means that anyone who joins your world can see the models and animations (even without the mod installed).


Why the change?

If you used older versions of MC Animaker, you might wonder why we shifted to a "Mod + Addon" ecosystem. The main reason is that the old workflow, which relied entirely on direct datapack exports, had several technical bottlenecks that made the user experience unnecessarily complicated.

Here are the main issues we faced with the old approach:

  1. Setting up the project required manually setting up the addon with your resource pack and datapack folders. Even though you could save these to the preferences, it was a tedious and unnecessarily confusing process for anyone working across multiple worlds, since you needed to manually edit the paths and, of course, guarantee that the scene would not be exported to a different world by mistake.

  2. Most textures do not include block or item models by default. That means we needed the addon to come with a built-in database, which forced us to manually update the database when working with different versions. This meant downloading a specific resource pack with the necessary models, changing paths, enabling Dev Tools, and updating the database manually. All of this just to make sure the addon would correctly import the blocks.

  3. Testing tiny animation adjustments required typing /reload in the game every single time you wanted to test the animation in-game. Of course, we could use command blocks, macros, or scripts, but it was a very unnecessary and time-consuming process, since /reload reloads ALL enabled datapacks and not just 1 scene.

  4. Datapacks get huge very fast. A scene with less than one minute of animation and a few hundred entities could easily surpass 100MB. Of course, we could compact the scenes into .zip files to save space, but again, a very tedious and manual process.

  5. Sharing a specific exported scene meant you had to manually dig into the datapack folders, delete all other exported scenes, and re-zip the file before sending it to someone else. Alternatively, you could open Blender, load your project, rename the datapack, go to the folder, and compact the datapack into a zip. Both processes were very manual and very time-consuming for no reason.

  6. And, the dealbreaker: RAM consumption. Minecraft loads the entire datapack into memory. Having multiple projects (with 2000+ keyframes each) in the same datapack caused massive memory consumption. In our tests, loading a datapack with several large, independent scenes caused an over 700% increase in RAM usage, reaching over 8 GIGABYTES — yes, gigabytes of RAM just to keep the datapack loaded, not even playing any of the animations. And we are talking about real memory consumption, not temporary spikes, being used for absolutely nothing.


Conclusion

To solve some of these struggles, the old MC Animaker was adapted into this new ecosystem. The MCA Toolkit mod was created alongside a brand new custom file format (.mcaproj), providing a much better workflow:

  • Automatic reload. No more need to manually /reload or recreate the scene every time you export it.

  • The exported project files (.mcaproj) can be 25x smaller than the old system. Even if we zip a scene on the old system, the .mcaproj file is still nearly 30% smaller for longer scenes.

  • Sharing an exported scene is now as simple as copying a single project file (.mcaproj) and sending it to a friend. And even with longer scenes, it rarely surpasses 10 MB.

  • You can have dozens of scenes with thousands of keyframes, and only the currently loaded scene will actually consume resources. This means that drastically fewer resources are needed to actually play the animations in-game, since the mod reads a single file instead of thousands of individual JSONs.

So... no more vanilla animations then?

Actually, the vanilla spirit is very much alive. While the current ecosystem requires the MCA Toolkit mod to load and play the animations, the core goal remains the same: bringing high-end animation to the vanilla experience.

It is important to understand that even though the mod is currently needed to manage the scenes, the animations themselves are still technically compatible with vanilla Minecraft. This means that if you host a world or play with friends, they will be able to see all your models and animations perfectly fine, even if they do not have the mod installed.

While we don't have a direct datapack exporter available right now, building one is absolutely on our roadmap. In the future, we aim to release a new (and hopefully much more optimized) vanilla datapack exporter. This will eventually allow you to turn your finished .mcaproj scenes back into pure vanilla datapacks.

This shift was a drastic change, but it was necessary to make the tool accessible. By moving away from massive, memory-heavy JSON files during the creation process, we’ve made it possible for creators to manage scenes across multiple worlds seamlessly. More importantly, it ensures that users without massive amounts of RAM can actually enjoy these animations without the game becoming unplayable.

In the end, it is about making sure that no matter how complex the animation is, it remains efficient, manageable, and accessible for everyone.