BabylonJS Exporters: frozen Maya and Max plugins with a working baseline

The README leads with a warning, not a feature list

Most project pages open with what the software does. This one opens with a warning triangle and a single sentence that changes how you should read everything after it: the Babylon.js Exporters are no longer in active development. The page says the tools will continue to work for existing versions of Maya and Max, specifically the 2022 releases, and that the team cannot guarantee they will continue to work for future versions of those applications.

That framing is unusually direct. It also means the project has already answered the question most reviewers would spend the article on, so the useful question is different: what exactly still works, what is left in the repository, and what should you use instead if your DCC version moves forward.

The rest of the page is a set of links. There is a pointer to the latest installer, documentation for the 3ds Max exporter, documentation for exporting from 3ds Max to glTF, documentation for the Maya exporter, documentation for exporting from Maya to glTF, and a link to the Babylon.js forum for questions. A link to a separate page about alternative export options follows the warning, which is the project's own redirect for anyone whose needs fall outside the frozen plugin pair.

Two documented exporters sit inside a much wider set of DCC folders

The repository root holds directories for more applications than the documentation covers: 3ds Max, Maya, Blender, Cheetah3d, Cinema 4d and Unity, alongside shared and tooling directories named SharedProjects, Tools and BabylonJS_Installer, plus a ConvertLineEndings.ps1 script and a license.md file at the root.

Only 3ds Max and Maya have documentation links on the page. The other application directories are present in the tree, but the README says nothing about their support status, their build steps or their current compatibility, and a directory name is not a promise of a working exporter. If your pipeline runs Blender or Cinema 4d, the honest reading is that the project gives you no information about those paths, and you would need to inspect the directory yourself or ask on the forum.

The language metadata is worth noting for the same reason. GitHub lists Wolfram Language as the primary language for the repository, which sits oddly beside a set of DCC plug-ins and does not tell you which folder drives the export path. The shared folders hint that common code is factored out, but the repository layout alone does not reveal how the plug-ins are assembled for each application.

There is no build-from-source path in the documentation

If you are evaluating this as a library or a component you can compile yourself, the page offers no instructions for it. There is no clone, build or package manager command anywhere in the documentation, and no description of a toolchain for Maya or 3ds Max plug-in development. The only acquisition route given is the installer, and the page points to the GitHub releases page for it, describing it as the latest installer for the exporters.

That distinction matters for a technical decision. A plug-in that ships as a packaged installer for two commercial DCC applications is a deployment artifact with a compatibility envelope, not a dependency you can pin and rebuild at will. The continuous integration badges on the page point at an Azure DevOps build and a deployment pipeline on the master branch, and the release list is filled with automatically generated names such as CD Release 20260423.4 and CD Release 20260423.3 from the same day, which suggests the releases are produced by that delivery pipeline rather than curated by hand.

The practical consequence is that the release list is long and mechanical. Version numbers track the delivery date, so there are many tags without many meaningful milestones, and choosing which installer to trust is not a matter of picking the newest entry blindly.

The glTF export route the project points to instead

The warning block links to a page about alternative export options at doc.babylonjs.com, under the preparing art for Babylon section, and the README pairs it with two dedicated pieces of documentation, one for exporting from 3ds Max to glTF and one for exporting from Maya to glTF. The project description itself says the exporters handle the Babylon.js and glTF file formats, so glTF is not a separate concern from the plug-ins; it is one of the outputs they support.

The real alternative, then, is a different pipeline rather than a different library. A team that needs to stay on current Maya and Max versions can use the documented glTF export routes, or a dedicated glTF export add-on, and bring the result into Babylon.js as glTF instead of relying on the frozen Babylon.js-specific exporter. The trade-off is control over the output: the frozen plug-in was built to emit Babylon.js scene output directly, while a generic glTF path produces a standard interchange file that a loader then interprets. Which one you want depends on whether your pipeline depends on Babylon-specific output or on a format that survives a DCC upgrade.

There is also a community option the project does not advertise but implies. The alternative export page exists because people do export from these applications without this plug-in, and the forum link in the README is where that traffic goes.

Two supported DCC versions, and no promise about the next one

The maintenance picture is clearer here than for most projects, because the project says it out loud. The README states the tools are no longer in active development, that they will continue to work for existing versions of Maya and Max with 2022 named as the baseline, and that the team cannot guarantee future compatibility. It also says the maintainers would welcome help keeping the tools working for newer versions, with the Babylon.js forum named as the contact point.

The last push to the repository was on 2026-04-23, and the three most recent releases are dated 2026-04-23 and 2026-03-19. So the source tree did receive commits in 2026 even after the notice went up, which is consistent with a project in maintenance mode rather than one that has been abandoned outright. The distinction is worth holding onto: what is frozen is the compatibility promise, not necessarily the code.

For an adoption decision, the practical test is narrow and answerable. If your artists are on Maya or 3ds Max 2022, this tooling continues to do its job. If anyone is on a newer release, you are outside the stated coverage, and the fallback in the same notice is the separate glTF export documentation plus a possible contribution to keep the plug-ins working.

A custom licence you have to read yourself

The repository is not under a licence that GitHub can classify as a standard open source identifier, so the file to read is license.md in the root. The project description and the repository listing confirm the presence of that file, and the machine-readable licence field on the repository reports the category as other, a custom licence.

Practically, this means two things. First, you cannot answer a compliance question from a badge, and any procurement or legal review has to be based on the text of license.md rather than on a recognized SPDX identifier. Second, the usual assumptions that come with MIT or Apache style terms, such as a patent grant or a defined notice obligation, cannot be inferred from the repository listing alone.

This is not legal advice and no conclusion about your own obligations can be drawn here. It is a flag for the review process: unlike most plug-ins in the DCC ecosystem, this one does not arrive with a licence name you can paste into a policy document. Read license.md before shipping anything that depends on it, and note that community contributions in the wider Babylon.js ecosystem may carry their own terms.

Where this fits against a glTF-first pipeline

The honest comparison is between a frozen, format-specific plug-in pair and a format-generic export path. The BabylonJS Exporters give you a direct route from the two applications the project supports, and they were built with Babylon.js output in mind, which is the point of the separate glTF documentation pages for each application. In exchange, you accept a ceiling at the 2022 versions of those applications and a project that has asked for outside help to move past that ceiling.

A glTF-first pipeline inverts the trade. It survives application upgrades, keeps the export step generic, and lets the runtime decide how to interpret the scene, but it gives up the exporter's Babylon-specific authoring and the direct pipeline the plug-ins were built for. Which side of that line you land on is decided by your DCC versions, not by quality.

The practical evaluation order is therefore short. Check the versions of Maya and 3ds Max your studio actually runs. If they are 2022, take the installer from the releases page and read license.md. If they are newer, follow the alternative export documentation the project itself points to, and evaluate the frozen plug-in only for historical scenes you still need to re-export.

Editorial conclusion

Adopt the BabylonJS Exporters if your pipeline is locked to Maya or 3ds Max 2022 and you need a Babylon.js or glTF export path from those exact versions, and treat the installer on the releases page as a frozen artifact rather than a dependency you can upgrade on demand. Do not adopt it for a pipeline that has to survive a Maya or Max upgrade, because the README makes no guarantee for future versions and offers the separate glTF export documentation as the alternative. Before you commit, read license.md in the repository root, since the terms are a custom licence that GitHub cannot classify, and run one export from your own scene on the exact DCC version you run in production, because the only stated coverage is the 2022 baseline.

Frequently asked questions

Official sources

1. BabylonJS/Exporters on GitHub
2. Issues
3. README
4. Releases