Blender add-on compatibility

Superluminal lets artists select enabled Blender add-ons, package the selected non-default modules, and transfer them with a render submission. The packer does not silently bundle every enabled module. Each selected module gets its own ZIP archive with the module folder preserved.

Not every Blender add-on is compatible with cloud rendering. A package can transfer successfully yet fail because of licensing, machine activation, compiled libraries, operating-system assumptions, external services, interactive UI, missing data, or an incompatible Blender API. Test the exact add-on and Blender version before a long render.

How add-on packaging works

Compression level is an implementation detail, not a speed promise. Likewise, a completed add-on upload is not an execution result.

Why explicit selection is safer

Blender installations often contain development tools, UI helpers, exporters, local pipeline integrations, and licensed products that are irrelevant to a render. Packaging all enabled modules would increase transfer size and could move code the artist did not intend to run elsewhere. Explicit selection creates a review point: the artist can include only the modules the scene requires.

The eligible list also excludes configured default modules and the submission add-on itself. The package name is based on the selected module, and the folder hierarchy is retained inside its archive. The transfer worker treats selected add-ons separately from the main scene archive or project files.

None of those steps decides whether the add-on's license permits farm execution. Check the license before uploading it.

What to record for an important add-on

A useful compatibility note includes:

• the add-on's exact name, version, package hash, and source;
• whether the test copy is licensed for the tested execution model;
• the exact Blender patch and runtime image;
• installation and activation steps;
• required system libraries, services, environment variables, and network access;
• the rights-safe scene fixture and deterministic action;
• dependency-scan and packaging findings;
• local and farm output artifacts;
• exact hashes or declared numerical/perceptual tolerances;
• relevant logs with private values removed;
• pass, partial, fail, or requires-pinning status;
• known limitations and negative cases; and
• test date, reviewer, expiry trigger, and correction history.

A narrow result is still useful. “Add-on A version 2.4 passed this scene on Blender 5.1.1” is more actionable than “all add-ons supported.”

Status definitions

Packageable means the selection and ZIP path can include the module. It says nothing about licensing or successful execution.

Tested pass means the exact licensed package installed and activated in a clean environment, executed the fixture, completed a farm render, and met its output checks.

Partial means the declared core fixture passed but a named feature, platform, engine, or licensing path did not.

Requires pinning means the result depends on a particular Blender or add-on version.

Unsupported means the test scene failed or cannot be executed under the tested terms.

No named third-party add-on has a public pass on this page yet. Test your exact combination before production.

Interaction with Blender versions and dependencies

Add-on compatibility is three-dimensional. The package version must be tested against an exact Blender build from the Blender version inventory. Its files and generated assets must then survive the dependency scan and packaging path. Finally, the original farm output must be compared with a local reference.

An add-on that generates Geometry Nodes data needs different checks from one that registers a custom render engine. A material library may depend on textures and linked .blend files. A simulation tool may create caches that need directory-aware handling. One vague compatibility badge cannot cover all of those cases.

From a Market download to a farm render

A complete Market-to-render test starts with an authorized download, installs the exact package in clean Blender, selects it for the job, scans dependencies, activates it on the farm, renders a scene, and compares the output. Customer files and ordinary seller packages are not used without permission.

Artist checklist

Before including an add-on in a job:

1. verify that its license permits the intended farm use;
2. record the exact add-on and Blender versions;
3. confirm any machine activation or seat requirement;
4. identify external executables, compiled libraries, services, and network calls;
5. test representative output locally;
6. select only the required modules;
7. inspect dependency warnings; and
8. retain original local output for comparison.

This process is less exciting than a universal-support slogan, but it answers the question artists actually have: which exact combination was tested, what happened, and what could still fail?