Blender version compatibility

Superluminal currently lists stable Blender runtimes from 4.0.2 through 5.1.1. The add-on can automatically match the running Blender major and minor version or let the artist choose manually.

A Blender 5.2 candidate was also configured, but its archive returned HTTP 404 when checked on 29 July 2026. We therefore do not present Blender 5.2 as available. Always test the exact Blender patch, engine, add-ons, and scene features before moving a production range.

Exact build inventory

The 5.2 row is intentionally labeled unavailable. A candidate is not a stable release, and the checked archive did not resolve. It must not be recommended for production merely because a selector and inventory row exist.

How version selection works

The add-on has one version-selection authority. In automatic mode it reads Blender's running major and minor version, maps that value to a supported selector, and sends the normalized selector with the submission. In manual mode the artist can choose a different minor. The interface also warns that the scene needs to remain compatible with the chosen version.

Automatic selection reduces accidental mismatches, but it cannot establish compatibility by itself. A scene created in one patch can depend on behavior changed by another patch. Add-ons can have narrower version ranges. Geometry Nodes, file formats, render passes, Python APIs, OCIO configuration, and compositor behavior can also change independently. The safest interpretation is therefore: matching the local major and minor is the default, while an exact patch-level test determines the published result.

Render engines have their own requirements. See render engine compatibility for Cycles, EEVEE, Workbench, settings, and output formats.

What to test before production

A useful version test records:

• the exact Blender patch and build identity;
• the worker-image or runtime-bundle identity;
• the render engine and device;
• the fixture version and checksum;
• dependency, add-on, Geometry Nodes, compositor, pass, color, and output cases;
• the expected and actual output checks;
• failures, exclusions, retries, and known limitations;
• the date, reviewer, and next retest trigger; and
• a reusable test scene where possible.

The suite must include negative cases. A compatibility index that records only successful jobs cannot tell an artist what fails, why it fails, or whether a later release fixed the problem.

Classroom on Blender 5.1

The CC0 Classroom scene completed dependency scanning, packaging, and upload using the Blender 5.1 selector. The Classroom submission snapshot contains the machine-readable details. The full end-to-end Blender 5.1 render comparison is still being prepared.

The planned Blender 5.1 benchmark starts with Classroom by Christophe Seux. Blender publishes its benchmark content as CC0, which makes the scene suitable for a reusable public test.

Choosing a version today

Start with automatic matching unless your project has a documented reason to pin a different minor. Before submitting:

1. save a copy of the scene;
2. confirm that every required add-on supports the target patch;
3. open the scene locally in that target patch when possible;
4. check linked libraries, caches, scripts, and simulation data;
5. render representative frames and inspect original outputs; and
6. preserve the exact local version in the production notes.

If an archive is unavailable, do not select it for production. For every other entry, a short scene-specific test remains the safest way to catch patch, add-on, Geometry Nodes, compositor, and output differences.

Keeping the list current

The list should be rechecked when Blender publishes a stable or LTS update, a runtime archive changes, the worker image changes, or an engine integration changes. Until then, use the exact runtime table above and test the features your scene needs.