Mandelbulber2: a Qt fractal raymarcher with a headless command line mode

One renderer for exploration, animation and unattended jobs

Mandelbulber2 is the official repository for Mandelbulber v2, a C++ application for generating three dimensional fractals. The scope is broader than a formula viewer: the feature list covers trigonometric, hyper-complex, Mandelbox and IFS fractals among many others, with a rendering engine built on 3D raymarching.

What makes the tool interesting for a technical audience is that the interactive and the batch paths share one engine. The feature list includes a simple 3D navigator, a rich GUI in a Qt 5 environment, keyframe animation for all parameters with different interpolations, a material management system, a rendering queue, and a command line interface for headless systems. So a parameter exploration that starts in the GUI can end in a queued or scripted job, and the command line is not a separate reduced tool.

The raymarching side is not a flat shader. The features list names hard shadows, ambient occlusion, depth of field, and translucency and refraction, and it mentions mathematical models and Monte Carlo algorithms for photo-realistic scenes. The Monte Carlo part matters for rendering quality, since stochastic sampling is how a raymarcher approximates soft lighting rather than hard coding it.

The repository reflects a mature application rather than a single library. The top level holds `mandelbulber2/`, `extlib/`, `contrib/`, a Dockerfile, a `.clang-format` file, a `policy.txt`, a `RESOURCES.md` and a `CONTRIBUTING.md`.

OpenCL, a render queue and distributed network rendering

Three capabilities sit under the heading of throughput, and they solve different problems.

Multi-GPU support via OpenCL is listed as high-performance computing with multiple graphics accelerator cards. The dependency on OpenCL is visible in the build configuration, where an MSVC Solution in the git package accommodates all dependencies with NUGET for autonomous compilation of an OpenCL accelerated binary. The repository also carries a Clang format configuration and a Coverity Scan integration.

A rendering queue is built in, which is what makes long animation jobs practical. Keyframe animation covers all parameters with different interpolations, so the timeline is not limited to camera moves. The GUI also handles texture mapping with color, luminosity, diffusion, normal and displacement maps, and the application can export 3D objects rather than only images.

Distributed Network Rendering is listed as a feature, which is the one to look at carefully before committing. It points at a setup where a render is spread across machines, and network rendering means the slowest link and the slowest node set the wall clock time.

The command line interface is the piece to reach for on a server with no display. A headless machine can take a parameter set from the command line and write frames to disk, which is how the rendering queue and the animation features become usable in a scheduled job.

The build wants Qt 5, LZO and GSL

Mandelbulber2 is a Qt application, and the system requirements are stated plainly: the QT5 framework is needed in conjunction with LZO for real-time data compression and GSL for scientific resources.

Development is natively set up for Linux with Qt Creator, on Debian or Ubuntu. The project file that carries the build system configuration is `mandelbulber2/qmake/mandelbulber.pro`, and the repository ships preparation scripts for Debian and for Ubuntu that install all dependencies, compile the program and create symbolic links in /usr/share/mandelbulber pointing at the working directory. The point of those scripts is that a contributor does not have to assemble the dependency list by hand.

For end users the route is simpler. The documentation points at the Releases page for the latest stable version, or cloning the repository for the development version, then unpacking the file and following the instructions in the deploy README, with further detail in the `mandelbulber2/deploy` folder. Arch Linux users have three AUR packages listed, for the current release, the current git snapshot, and the current git snapshot with OpenCL support, which is a useful signal about how the OpenCL build is packaged separately.

The image resolution line is also qualified. Unlimited image resolution is listed as a feature, but the entry specifies on 64-bit systems, so a 32-bit build carries a limit.

The container image is assembled from the AUR, not from source

The Dockerfile in the repository is worth reading because of what it does not do. It does not compile the project. The builder stage clones the AUR package for the OpenCL git snapshot and builds it with makepkg:

RUN git clone https://aur.archlinux.org/mandelbulber2-opencl-git.git src && \
    cd src && \
    MAKEFLAGS="-j$(nproc)" makepkg

The final stage installs the resulting package archive into an Arch based image, which means the container inherits Arch's packaging decisions and its OpenCL ICD setup rather than a hand written build of the C++ sources.

The base layer installs the runtime dependencies with pacman, and the list is a good summary of what the application needs on the machine: `gsl`, `libpng12`, `lzo`, `openmpi`, `qt5-base`, `qt5-multimedia`, `qt5-tools`, `ocl-icd`, `opencl-headers`, `opencl-clhpp` and `opencl-mesa`. Two of those are worth calling out. `ocl-icd` and `opencl-mesa` are the OpenCL loader and a software OpenCL implementation, so the image can run OpenCL code without a vendor driver, which also means it will not use a discrete GPU unless the runtime is configured to find one.

The final stage creates a non-root user named `mandelbulber` with uid 1001, gives that user a home directory, and prepares /usr/share/doc/mandelbulber2. The entrypoint and command lines are present but commented out, so the image starts as a container you exec into rather than one that renders on demand.

A camera you fly, and the parameters you can keyframe

The 3D navigator is a first-person camera in the fractal, and the keyboard shortcuts are documented in enough detail to be usable without the mouse.

In the render window, `Shift` plus `Up` or `Q` moves the camera forward and `Shift` plus `Down` or `Z` moves it back. `Shift` plus `Left` or `A` strafes left and `Shift` plus `Right` or `D` strafes right. `W` and `S` move the camera up and down, the plain arrow keys rotate the camera, and `Ctrl` combined with the left or right arrow rolls it.

Two conventions are worth noticing. The WASD cluster and the arrow cluster do different things, with WASD for vertical movement and arrows for rotation, and the roll gesture is deliberately on a modifier so it does not collide with the strafe keys. For anyone automating a camera path, that mapping is stable enough to script against, though the keyframe system is the more serious route for repeatable shots.

On a machine with no keyboard, the animation system does the work, because keyframes cover all parameters rather than only the camera, and different interpolations are available for the transitions. The rendering queue then handles running those jobs.

Where the project sits, and what it asks of you

The project is alive. The last push was on 2026-10-19, the repository is not archived, and the releases list shows a continuous build from 2026-10-11 alongside version 2.34 from 2025-10-05 and 2.33 from 2025-03-29. Continuous integration runs on several platforms, with badges for Linux on Travis CI, Windows on AppVeyor, macOS on Circle CI and an Azure Pipelines build, and Coverity Scan tracks the code quality of the project.

The licence is GNU GPL v3, and the LICENSE file sits at the top of the repository. GPL is the licensing decision with real consequences for a creative tool, because it attaches to the software rather than to the images the software produces, and the repository documentation does not address how output from the renderer is treated. That is a question for a legal answer, not one to infer from the licence text alone.

The software was developed for ARM, x86 and x64 CPUs on Linux, Windows and macOS, with the ARM entry marked experimental, so an ARM user is testing a path rather than using a supported one.

The alternative approach to producing these images is a smaller standalone fractal renderer or a general purpose renderer with a fractal formula plugged in. The difference in approach is scope: Mandelbulber2 ships the fractal types, the shading and material features, the animation timeline and the queue, so the workflow stays inside one application, whereas a general purpose renderer would give a more general engine at the cost of assembling that pipeline yourself. For an artist producing a sequence of animation frames, the queue and the keyframe system are the parts that would be hardest to replace.

Editorial conclusion

Mandelbulber2 fits a workflow that needs both hands-on exploration and batch production, because the same renderer backs the Qt 5 navigator, the keyframe animation system and the command line interface for headless systems, and the OpenCL path lets a machine with several graphics cards use them. Skip it if you only want a still image of a known formula, since the setup cost of a Qt 5 toolchain with LZO and GSL is real. Before you plan a long render, check that your CPU is covered, since the project describes ARM support as experimental while x86 and x64 are the supported targets on Linux, Windows and macOS, and confirm the licence fits your distribution, since the code is GPL v3 and a rendered image derived from it raises questions the project documentation does not answer.

Frequently asked questions

Official sources

1. buddhi1980/mandelbulber2 on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases