Mixar is a Blender fork with an AI agent bolted onto the side, and the fork is the hard part

A fork, not a plugin, and that decision drives everything

Mixar is an AI-powered 3D content creation tool built as a custom fork of Blender 5.2. It adds an AI chat agent that can drive Blender, a layered texture-painting system, AI-assisted 3D generation, and a set of Mixar-native editor spaces, while keeping everything you already use from Blender.

Calling it a fork is the honest description and it is the single most consequential fact about the project. This is not a Blender add-on. It is Blender's source tree with an overlay applied and a few extra C++ targets linked, and the README says so directly: building it means building Blender, applying the Mixar overlay, and linking a few extra C++ targets.

That choice buys things a plugin cannot. Layers and node-driven material graphs sit inside the same UI as Blender's own workspace. Sculpting, animation, simulation, rendering and scripting are unchanged and available alongside the additions. And the editor can be extended in ways that go beyond what an add-on API exposes.

It also costs things a plugin does not. Every Blender user has to rebuild their own application rather than installing a file. The upstream Blender version is pinned, so a Blender release does not arrive automatically. And the AI side is split across the network boundary, which is the subject of the next section.

The repository is the source for the Mixar desktop app, the Blender-side client. The project status line in the README reads v2.0.0, first public source release, built on Blender 5.2, while the release list shows versions 4.3.4, 4.3.2 and 4.2.3 from October 2026. Those two version tracks do not line up, so treat the release tags as the shipping version and the status paragraph as a note about when the source was opened.

The AI half is a hosted service, and the boundary matters

The README is direct about which parts need the network. Mixar's AI features, which it lists as the chat agent, image-to-3D and hosted generation, call Mixar's hosted backend.

The hosted AI backend remains a separate, closed-source service, and the app talks to it over the network.

So the open source repository gives you the client and the whole 3D application, while the models and the orchestration behind the agent are not in it. That is a reasonable commercial arrangement for this kind of product, and it also means the open source release is not a fully independent product for those features.

The account requirements follow from that. You need a Mixar account at mixar.app, the desktop app authenticates via browser SSO and talks to the backend over HTTPS and WebSocket. With bring-your-own-key you can route the chat agent through your own provider account, OpenAI or Anthropic among others, without consuming Mixar credits.

That distinction is worth holding onto: bring-your-own-key covers the chat agent and your own provider credentials, while image-to-3D and the hosted generation tools still go to Mixar's backend.

The non-AI parts of the app, which the README lists as the Blender features, the layered paint module and file IO, work without a Mixar account at all. So the layered painting system is usable standalone, which matters if your interest in the project is the texture workflow rather than the agent.

What the added features actually are

The feature list is worth reading as a list of separate products rather than one product, because the individual items are substantial.

The chat agent is called Mixie, an in-app chat agent that can plan and execute multi-step tasks against your scene: model from prompts, paint textures, set up shading, fix UVs, suggest fixes.

Layer-based texture painting is a Photoshop-style system with stacked layers and node-driven material graphs, masks, modifiers, baking, UDIM support, procedural materials, decals and asset export.

AI 3D generation covers text-to-3D and image-to-3D mesh generation through integrated providers, Hunyuan models and others, with retopology and auto-UV-unwrap.

Moodboards and scene generation let you drop in reference images, generate scenes from boards, do 360 degree lookdev, and go from image to 3D.

Asset search uses neural embedding search across your asset library, which is the kind of feature that becomes valuable the moment a library stops being small.

And there are Mixar-native editor spaces: dedicated Layers, Properties, Assets and Chat editors integrated into the Blender workspace, rather than as separate windows.

One detail on the generation side is worth flagging for anyone with a NVIDIA card. The text-to-3D path goes through integrated providers rather than a local model, so the compute and the licensing for that step sit with the provider, and the retopology and auto-UV-unwrap steps are what the README emphasises as happening locally in the app.

Building it: Blender's build, then the overlay

The build instructions start by telling you to do Blender's build first and to confirm a clean Blender build works before adding Mixar. That is sound advice for any fork project and it is where most of the time goes.

You need everything required to build Blender 5.2 itself, following Blender's official build instructions, plus Python 3.11 or newer and rsync on the build host. The native Windows build through scripts/windows/build.bat requires Visual Studio 2022 17.14.14 or newer with the C++ workload.

The Ubuntu dependency list is long and specific.

sudo apt-get install -y build-essential cmake gcc-14 g++-14 git git-lfs \
  ninja-build python3-dev python3-venv rsync pkg-config \
  libcurl4-openssl-dev libdbus-1-dev libegl-dev libgl-dev libice-dev libsm-dev \
  libwayland-dev libx11-dev libxcursor-dev libxext-dev libxi-dev \
  libxinerama-dev libxkbcommon-dev libxrandr-dev libxxf86vm-dev \
  patchelf wayland-protocols xz-utils xvfb zstd

Then the submodules, and the LFS assets, have to be initialised in a way that does not move Blender to a different commit.

git submodule update --init upstream
git -C upstream -c submodule.lib/linux_x64.update=checkout submodule update --init lib/linux_x64
git -C upstream/lib/linux_x64 lfs pull

The checkout should sit on a native Linux filesystem, and the build wants `CC=gcc-14` and `CXX=g++-14`.

The quickstart sequence is clone with the upstream Blender submodule, run `make init`, copy `.env.example` to `.env` and edit it, then `make build`.

# 1. Clone with the upstream Blender submodule
git clone --recursive https://github.com/Mixar-AI/mixar-texture-painting.git
cd mixar-texture-painting

# 2. Initialise submodules and LFS-tracked assets (if your clone skipped recursive)
make init

# 3. Configure runtime environment (copy template, fill in any backend URLs you want to target)
cp .env.example .env
$EDITOR .env

# 4. Full build: overlay + CMake + compile + bundle
make build

Binaries land under build/<MIXAR_ENV>/bin/, with MIXAR_ENV=Prod the default, pointing at https://api.mixar.app, and MIXAR_ENV=Dev giving you a development backend.

The build switches that change what you get

The environment file is the control surface for the build, and its comments are unusually informative about the consequences of each setting.

`MIXAR_ENV` selects Prod, Dev or UAT, and with it `MIXAR_BACKEND_URL` and `MIXAR_FRONTEND_URL`, so the backend the app talks to is decided at build time rather than at runtime. `MIXAR_LOG_LEVEL` sets the log level.

The interesting one is `MIXAR_CUDA`. With it on, nvcc compiles the whole Cycles kernel once per architecture in CYCLES_CUDA_BINARIES_ARCH, which is ten passes and dominates a clean build. The file says it changes nothing for incremental Mixar-only rebuilds, and that the resulting app renders Cycles on CPU only, and warns never to ship a release built this way. `MIXAR_CUDA=0 make build` selects a local CPU-only Cycles build when CUDA and OptiX are unavailable, and the comment notes this does not disable viewport GPU drawing.

Two more CUDA switches exist. `MIXAR_CUDA_BINARIES=1` keeps CUDA and OptiX device support but skips the precompiled kernels, so Cycles compiles them at runtime on the first GPU render. And `MIXAR_CUDA_BUILD_SERIAL=0` builds cubins one after another to cap peak memory, which the file says release CI uses on the memory-constrained Ubuntu runner.

The DEV_BYPASS values deserve care. They are the dev-only browserless login for the isolated GUI QA harness, they are baked into Dev bundles, and configuration generation aborts if any DEV_BYPASS value is set while MIXAR_ENV is not exactly Dev. That is a sensible safety property: you cannot accidentally ship test credentials in a production bundle.

The Makefile also carries i18n_update and i18n_check targets that re-extract UI strings into mixar.pot, merge them into every language catalog, derive sr_RS@latin and en_GB, then validate placeholders and report per-language coverage.

Licence, governance and what the repository tells you about itself

Mixar is released under GPL-3.0-or-later, with the SPDX identifier in the README header and the LICENSE file at the root.

For a fork of Blender that is the expected licence, since Blender itself is GPL. The practical consequence for anyone thinking about shipping a Mixar-based application is the same one that applies to Blender: the combined work is under the GPL, so distributing a build means offering the corresponding source.

The repository has the paperwork of a large, professionally run project rather than a solo hobby, and it is worth noting what that paperwork implies. There is a LICENSES/ directory and a REUSE.toml, which is the machine-readable licence metadata standard, so third party code in the tree is tracked rather than assumed. There is a NOTICE.md and a SOURCE_CORRESPONDENCE.md, which is how a fork documents where each piece of upstream code came from, which is exactly the file you would want when auditing a fork. TRADEMARKS.md and MAINTAINERS.md and AUTHORS sit alongside SECURITY.md, SUPPORT.md, CONTRIBUTING.md and a CODE_OF_CONDUCT.md.

There is also a .pre-commit-config.yaml, a pytest.ini and a conftest.py with a tests/ directory, a cmake/ directory, and a CLAUDE.md.

On release cadence, the listed releases are Mixar 4.3.4 from 2026-10-18, 4.3.2 from the same day and 4.2.3 from 2026-10-11, with the last push on 2026-10-20. Two releases on one day with a gap in the numbering suggests a branch-based release process rather than a strictly linear one.

The homepage is mixar.app, and the default branch is main.

Where Mixar is the wrong choice

Four cases argue against it.

The first is needing the AI features without a service dependency. The chat agent, image-to-3D and hosted generation all call a closed backend. Bring-your-own-key covers the chat agent and your own provider credentials, and that is all it covers. If a hard requirement is that the model inference runs on infrastructure you control, this repository does not deliver it.

The second is not wanting to build an application. This is a fork with a pinned upstream Blender, a pinned upstream library submodule, LFS-tracked assets, an overlay step and extra CMake targets. For most people the practical answer is to install the released Mixar application, not to produce one. Building from source is for people who need to patch it or work on it.

The third is a Blender release cycle that matters to you. Because upstream is pinned, a new Blender release does not arrive on its own, and the more the Mixar overlay touches, the harder it is for the project to take an update cleanly. The overlay step is where that friction lives, and it is a cost you carry rather than a one-off.

The alternative is to stay on stock Blender. The difference in approach is that a Blender add-on would give you the layered painting, the agent and the generation tools without a fork, at the price of working within the add-on API and a separate UI rather than native editor spaces. For a workflow where the agent drives the scene and the layers feed the node graph directly, that price is the whole value proposition, which is why the fork route exists. If your needs are a scripting workflow and a texture set, stock Blender with an add-on or two is a far smaller commitment for most of the same outcome.

Editorial conclusion

Mixar fits a Blender user who wants layered texture painting, an in-app agent and text or image to 3D without leaving a familiar workspace, and who is prepared to build Blender 5.2 from source with a large overlay applied on top. It does not fit a team that needs the AI features without a service dependency, because the chat agent and generation tools call Mixar's hosted backend, and it does not fit a build without a compiler toolchain and a pinned submodule checkout. Read `.env.example` first, since `MIXAR_ENV` decides which backend the build points at and `MIXAR_CUDA=0` decides whether you get GPU rendering at all.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Mixar-AI/mixar-app on GitHub
3. Project website
4. README
5. Releases