On Blender 5.2 LTS, VRM Addon for Blender only enables from 4.4.0 up, and on 5.3 alpha even the latest 4.7.1 refuses to enable. The cause is blender_version_max in the extension manifest, which is an exclusive bound: it names the first Blender version the extension does not support, not the last one it does. For 4.3.0 and newer, every combination the manifest gate blocks still enables through the legacy add-on zip, which has no version gate at all. The 3.9.0 line is the exception: it fails on both paths, because Blender 5.0 removed an API it imports.
This is for anyone who upgraded to Blender 5.x and found the VRM add-on missing from the panel or refusing to switch on. On 2026-09-22, on macOS Apple Silicon, I installed four add-on versions into four Blender versions two different ways and ran all 32 cells headless. The Blender builds were 5.0.1, 5.1.2, 5.2.2 LTS and 5.3.0 alpha; the add-on versions were 3.9.0, 4.3.0, 4.4.0 and 4.7.1.
The problem
Drop the 4.3.0 extension zip into Blender 5.2.2 LTS. The install reports success, and then the add-on never turns on. The console has the reason:
ERROR vrm: This Blender version (5.2.2) must be less than the maximum version (5.2.0)
Package was expected to be installed but not found: vrm
On 5.3.0 alpha the latest 4.7.1 hits the same wall, with only the version in parentheses changing to (5.3.0). Inside the app it is quieter than that: the Extensions panel shows no error, because the VRM entry is not listed at all.
Since Blender 4.2, add-ons ship as extensions, and an extension zip carries a blender_manifest.toml at its root declaring blender_version_min and blender_version_max. When those values do not match the running Blender, the files unpack fine and activation is refused.
VRM Addon for Blender publishes two zips per release:
- Extension:
VRM_Addon_for_Blender-Extension-4_7_1.zip - Legacy add-on:
VRM_Addon_for_Blender-4_7_1.zip
The two behave differently on 5.x, and that difference is the point of this post.
What the measurements show
blender_version_max is not the last supported version. It is the first unsupported one. The manifest example in the Blender manual says so outright (checked 2026-09-22):
# Optional: Blender version that the extension does not support, earlier versions are supported.
blender_version_max = "5.1.0"
The wording of the runtime error, must be less than, means the same thing.
So 4.3.0 declaring blender_version_max = "5.2.0" is a statement that it supports up to 5.1.x. From 5.2.0 onward it is blocked whatever the patch number. The latest 4.7.1 declares 5.3.0, which covers 5.2 LTS and stops short of 5.3 alpha.
I downloaded the manifest from all 71 release tags to find the boundaries. blender_version_min is 4.2.0 on every tag. Only blender_version_max ever moved, and it moved four times:
blender_version_max |
Add-on range | First tag | Blender it enables on |
|---|---|---|---|
| 5.0.0 | v3.9.0 – v3.15.0 | 2025-07-19 | 4.2 – 4.5 |
| 5.1.0 | v3.16.0 – v3.21.1 | 2025-11-08 | 4.2 – 5.0 |
| 5.2.0 | v3.22.0 – v4.3.3 | 2026-03-16 | 4.2 – 5.1 |
| 5.3.0 | v4.4.0 – v4.7.1 | 2026-07-11 | 4.2 – 5.2 LTS |
Sampling only the x.y.0 tags gets the boundaries wrong. Looking at v4.0.0 alone hid the entire 5.1.0 group of 22 tags. The "5.2 LTS needs 4.4.0 or newer" conclusion comes out of this table.
Then I checked what actually enables, across 32 cells. Each cell got a fresh BLENDER_USER_RESOURCES directory so it could not inherit state from a previous cell or from my own Blender config. O means the add-on enabled and the roundtrip passed, where the roundtrip is importing a VRM file, exporting it, and importing the export again, for both a VRM 0.x and a VRM 1.0 sample.
Extension install:
| Add-on \ Blender | 5.0.1 | 5.1.2 | 5.2.2 LTS | 5.3.0 alpha |
|---|---|---|---|---|
| 3.9.0 | X | X | X | X |
| 4.3.0 | O | O | X | X |
| 4.4.0 | O | O | O | X |
| 4.7.1 | O | O | O | X |
Legacy add-on install:
| Add-on \ Blender | 5.0.1 | 5.1.2 | 5.2.2 LTS | 5.3.0 alpha |
|---|---|---|---|---|
| 3.9.0 | X | X | X | X |
| 4.3.0 | O | O | O | O |
| 4.4.0 | O | O | O | O |
| 4.7.1 | O | O | O | O |
The legacy path has no version gate. 4.3.0 enabled on 5.2.2 and on 5.3.0 alpha and passed the roundtrip in both. That means the direct cause of the extension being refused on the spot is the manifest gate. It does not mean those combinations are free of other API incompatibilities — this run only went as far as activation plus a two-file roundtrip.
Of the four versions I tested, only the 3.9.0 line fails to activate at all. Install it the legacy way and it still raises during module load:
ImportError: cannot import name 'ShaderNodeTexPointDensity' from 'bpy.types' (unknown location)
This add-on is not compatible with Blender version 5.0 or later. Your current version is 5.2.2.
Blender 5.0 removed bpy.types.ShaderNodeTexPointDensity, 3.9.0 imports that type at module load, and the add-on carries its own guard that prints the second line. There is no install path that makes this combination work.
The silence in the Extensions panel has its own explanation. The panel queries the extensions.blender.org API filtered by Blender version, and the filtering happens server side. Ask with blender_version=5.2.2 and you get vrm 4.7.1 back; ask with 5.3.0 and there is no vrm entry in the response at all (checked 2026-09-22). The panel is not hiding an error, it is being handed an empty result.
The roundtrip passed in all 20 cells that enabled. Two samples were used: minimal.vrm for VRM 0.x, which is CC0, and VirtualCast's Seed-san.vrm for VRM 1.0, licensed under the VRM Public License 1.0. Exporting Seed-san grows it from 10,917,800 bytes to somewhere between 16,549,208 and 16,551,476 bytes — the exact figure varies slightly per combination, and all of them land near 152% of the original. I did not investigate why it grows. Whether it is related to the texture duplication issue #1114 is a separate question I have not answered.
What to do
- Check your Blender version first. On 5.2 LTS you need add-on 4.4.0 or newer. On 5.0 and 5.1 the latest 4.7.1 enables fine. If you are pinned to an older add-on, read the right-hand column of the boundary table above.
- If VRM is missing from the Extensions panel, grab the extension zip from the GitHub releases directly —
VRM_Addon_for_Blender-Extension-<version>.zip— and use Install from Disk. The panel only ever offers the single latest version. - If the extension is refused with
must be less than the maximum version, the legacy zip is a way through. InstallVRM_Addon_for_Blender-<version>.zipfrom the same release as an add-on rather than an extension. It is also the only way to run 4.7.1 on 5.3 alpha. Be aware that this puts you outside the range the maintainer declares support for; if something breaks, moving the add-on to a version inside the supported range is the first thing to try. - The top-level folder name inside the legacy zip changes between versions. 3.9.0 unpacks to
VRM_Addon_for_Blender-3_9_0, and the 4.x releases unpack toVRM_Addon_for_Blender-release. If you are enabling it from a script, discover the module withaddon_utils.modules()rather than hardcoding the name. - Give up on the 3.9.0 line under 5.x.
ShaderNodeTexPointDensityis gone and no install path gets around it. - If you took the legacy route, export a VRM and import it back. That roundtrip is as far as this measurement went.
Reading VRM files from a Flutter app rather than Blender is written up separately in Parsing VRM in Flutter without a package. The VRM 0.x thumbnail samples in that post were built with the 5.2.2 LTS and 4.7.1 combination from this one.
Images: both are the measurement logs (evidence/matrix-install.log) redrawn as a table and a console view.
Takeaways
Read blender_version_max as the first version that is excluded, and pick the add-on from the boundary table rather than from the panel. The legacy zip bypasses the gate, but bypassing a declared support range is a workaround, not a fix.
Unverified
- Whether combinations enabled via the legacy bypass are fully functional: only the roundtrip was checked. Spring bones and the expression editing panels were not.
- Windows and Linux behaviour: this ran on a single macOS Apple Silicon machine. The manifest gate is platform independent, but I could not confirm that 3.9.0 raises the same message elsewhere.
- When the add-on will support Blender 5.3 after its stable release: these numbers are from 5.3.0 alpha. If
blender_version_maxmoves to5.4.0, the 5.3 column changes.
Changelog
| Version | Description |
|---|---|
| 1.0 | 2026-09-22 first version (Blender 5.0.1 – 5.3.0 alpha x add-on 3.9.0 – 4.7.1, 32 cells across extension and legacy installs) |
| 1.2 | 2026-09-22 added the cross-link to the Flutter VRM parsing post |
Top comments (0)