Bforartists: a Blender fork built around a rewritten interface

A fork with exactly one purpose

Bforartists is a fork of the 3D software Blender, and the README is unusually clear that the fork exists for one reason: to improve the graphical user interface and increase usability. Nothing else is claimed. The description in the repository says the same thing in one line.

The scope of the software itself is the whole 3D pipeline, and the README lists it as modeling, rigging, animation, simulation, rendering, and compositing. So this is a complete Blender replacement, not a plugin, a preset pack, or a lightweight modelling tool. If you switch to it, you are running a different build of the same application, with a different face.

Two statements in the README shape the whole project. The first is that Bforartists is fully compatible with Blender, that you can use both side by side to make a picture, and that the files are transferable, so switching costs you nothing. The second is the audience: the target audience for Bforartists is hobbyists and indie developers, while Blender tries to target professionals, and the README calls that a completely different audience and development target.

That framing is the honest summary of the fork. It is not a better Blender. It is a Blender for a different person, and the people who wrote it are explicit that the two can coexist on the same machine.

The change list is almost entirely about the interface

The README enumerates the differences from Blender, and the list is worth reading closely because it shows the scope of the effort and, just as usefully, its limits.

The headline change is an own keymap, described as reduced to just the necessary hotkeys, with a navigation that can be done purely by mouse. That single item explains most of the rest, because a reduced keymap means the tools that used to be shortcut only need a visible entry, which is the extended user interface change, formerly hotkey only tools having a menu entry now.

Around that sit the cleanups and rearrangements. Lots of unnecessary double, triple, or even more equal menu entries were removed. Some things are better accessible, and some are no longer in the way. There are improved defaults, colored icons, and as many icons as Blender has twice over, left aligned checkboxes and text where possible, better tooltips, and a more readable standard theme. The toolshelf has tabs again, and the layouts were improved.

The configurable UI elements are the more unusual idea, with the toolbar as the example and icon buttons as the mechanism, so a user can reshape a part of the interface that is normally fixed.

Two add-ons are singled out as examples of usability work, a reset 3D View addon and a Set Dimensions addon that scales in world coordinates in edit mode. The last item on the list is the smallest and maybe the most telling: not so much confirm dialogs, and the resurrection of the tabs in the tool shelf for quicker access to the tools.

None of this touches the renderer or the physics engine. That is the point of the fork, and also its limit.

The manual is treated as part of the product

The README argues that the code is only half of the show, and that the non-code things matter. The manual is the main item, and the criticism of it is specific: the Blender manual is unsearchable in big parts, has an odd structure, and still relies heavily on the Blender keymap, and the README calls that nearly unusable for users.

Bforartists rewrote it, with the tools in mind rather than the hotkeys, without opinions about which unwrapping method is better, without general CG tutorials, and with a structure that follows the editors and the menus. The manual lives in its own repository, Bforartists/Manual, and the README invites people who are willing to help with it to contribute there.

This is the part of the project that most affects a new user, and it is the part a fork can improve in a way an add-on cannot. Add-ons change what a menu contains; they do not change how the documentation is written or how it is structured. A manual organised around editors and menus matches an interface that is also organised around editors and menus.

The rest of the non-code work follows the same pattern. There is a detailed list of the changes in the release notes, hosted on the project wiki, a page of examples of the key differences, a YouTube video that shows the differences rather than describing them, and a playlist of quickstart videos. The README itself is deliberately short, with a comment at the top instructing contributors to keep it that way and to link to external resources instead of including content inline.

Nightly builds are not production builds

The first paragraph of the README is a warning, and it is worth reading before you download anything. The nightlies produced by GitHub Actions are not meant for productive work. They miss CUDA and OptiX, they will most likely not work, and their purpose is to show that the code compiles. The working versions are the devbuilds on the project download page.

That is a real constraint for anyone with a GPU rendering pipeline, because the hardware acceleration paths are simply not in those builds. The distinction between a nightly and a devbuild is the difference between a compile check and a usable application.

The continuous integration setup does cover the three desktop platforms, with separate workflows for Linux, macOS, and Windows, each with a badge in the README, so platform specific breakage is at least visible.

The releases follow a normal cadence for a project of this size. v5.2.0 was published on 2026-07-29, v5.1.2 on 2026-06-02, and v5.1.1 on 2026-04-23, and the repository is not archived with the last push on 2026-10-22. The version numbering, five point something, tracks the upstream Blender generation it is based on, which is the practical way to know which feature set you are getting.

Building it yourself is a Blender build with a different URL

The README is upfront that the setup for compiling is exactly the same as Blender, with the git clone URL changed, and it links to the Blender handbook pages for building on Linux, on Mac, and on Windows rather than duplicating them. The repository layout confirms the claim: it is the Blender source tree, with CMakeLists.txt, GNUmakefile, build_files, extern, intern, lib, source, scripts, tests, tools, and the usual clang format and clang tidy configuration.

Two things are specific to the fork. The first is the assets_bfa directory, which holds the fork's own assets, and the create_msix.py script at the root, which is for producing the Microsoft Store package. The second is that a Python configuration file, pyproject.toml, configures the autopep8 formatter with a maximum line length of 120 and an aggressive level of 2, with a list of disabled checks and a set of excluded paths, including the externally maintained glTF importer and a generated reference file.

# SPDX-License-Identifier: GPL-2.0-or-later

[tool.autopep8]
max_line_length = 120

The formatter configuration is not the interesting part for most people. The interesting part is the toolchain, because a fork has to track its upstream: every time Blender changes its build system or its library layout, the fork has to absorb that work before it can ship a release, and a build failure in the fork is usually a build failure inherited from upstream.

For anyone who wants to compile an older version of Bforartists, the README points at the Blender Subversion repository, where the precompiled libraries for all previous Blender versions are tagged, since a newer precompiled library set will not work with an older source tree.

The licence needs reading, and the fork carries a governance question

The licence is the one item in the project that requires more than a summary. GitHub classifies it as Other, a custom licence that cannot be classified automatically, and the repository has a COPYING file that is the place to start. The Python configuration in the repository carries an SPDX identifier of GPL-2.0-or-later, and a fork of a GPL codebase would normally be expected to keep that licence, but the fork's own terms, and any additional conditions attached to the assets and branding the fork adds, are the things to read in the file itself rather than infer from a badge.

That is the honest position: read COPYING, and treat the classification as a prompt to look rather than as an answer.

The governance question is separate from the licence question and is worth naming. A fork is a permanent commitment to merging upstream. Every upstream release is work that has to be taken, tested, and re-released, and the interface work has to be reapplied on top of it, which is why forks of this kind tend to lag by a release or two and why the version number tracks the upstream generation. The README treats this as a solved problem, and for a hobbyist audience it is one, because a slightly older Blender with a better interface is a good deal. For a studio that standardises on upstream, the same lag is a maintenance burden.

The alternative approach is worth stating plainly, since the README raises it. Upstream Blender with third-party add-ons can deliver parts of the same outcome, and add-ons have the advantage of being installable, disableable, and updatable independently. The fork's advantage is that its changes are the default, and that the manual, the keymap, and the interface were designed as one thing rather than assembled.

Editorial conclusion

Bforartists fits an artist or hobbyist who finds the upstream Blender interface hard to navigate, wants a mouse driven workflow without learning a new set of shortcuts, and wants those changes to be the default rather than an add-on. It does not fit a studio whose pipeline is standardised on upstream Blender, whose add-ons or scripts depend on the upstream keymap and default layout, or whose members want a single upstream codebase to track. Verify first that the build you download is a working devbuild rather than a nightly, because the nightlies are built without CUDA and OptiX and are meant only to show that the code compiles, and check that the add-ons you rely on are not keyed to the upstream shortcut set.

Frequently asked questions

Official sources

1. Bforartists/Bforartists on GitHub
2. Issues
3. Project website
4. README
5. Releases