Official Khronos glTF/GLB Plugin for Autodesk 3ds Max

Just a few years ago, glTF was often seen as a format "for web developers." That is no longer the case. Today, glTF and GLB models can be opened directly in a browser, used in augmented and mixed reality, imported into game engines, and published in online stores and interactive product configurators.

The format powers Google Model Viewer, which makes it possible to embed 3D models and AR previews in a regular web page. It is used across the Microsoft Mixed Reality ecosystem and by Shopify tools for displaying products in 3D. Experiences familiar from the websites and digital projects of IKEA, Nike, and Wayfair-viewing an item from every angle, changing its finish, or placing a piece of furniture in a room through AR-show exactly why businesses need a lightweight and portable 3D format.

Much of the modern web 3D stack also relies on glTF. It is supported by Three.js, Babylon.js, and PlayCanvas, allowing the same asset to appear on a product page, in a browser-based viewer, in a WebXR project, or in an interactive presentation. The binary version of the format, GLB, is particularly convenient for delivering finished models because geometry, materials, textures, and animation can all be packaged into a single file.

For 3D artists, the takeaway is simple: glTF stopped being a niche format a long time ago. If you create content for the web, AR, games, configurators, or digital catalogs, you will almost certainly encounter it sooner or later.

For Autodesk 3ds Max users, however, working with the format has not always been straightforward. Export was available, but a complete and predictable workflow-from import and editing to delivering an updated file-was still missing.

That is about to change. The Khronos Group has sponsored the release of a free, open-source glTF 2.0 importer and exporter for Autodesk 3ds Max. What makes this important is not only the new feature set, but also the organization behind the project.

The Khronos Group is not simply another third-party converter developer. It is the open industry consortium under which the glTF standard itself is developed.

Khronos helps define how PBR materials, animation, cameras, lights, and format extensions are represented. Its involvement therefore gives the project several major advantages:

It is worth describing Khronos' role accurately: the organization sponsored and released the project, which was developed in collaboration with experienced independent specialists and the wider community. This is not simply a new official label attached to Autodesk's old exporter. It consists of separate import and export plugins designed to provide a full glTF 2.0 workflow.

Khronos has already stated that it intends to continue supporting the project, including further development of KHR_interactivity and support for the upcoming glTF 2.1 specification. In other words, this is not a one-off attempt to fill a gap. It is a foundation for a long-term production workflow.

The new plugin has a useful history behind it. Its foundation came from years of work by independent programmer Hayashi Satoshi, who previously developed commercial glTF plugins for 3ds Max. Khronos brought him into the project alongside Josef Wienerroither, a developer with extensive experience creating and validating 3ds Max plugins.

Eric Chadwick, a senior 3D technical artist at DGG, also contributed testing, documentation, feedback, and practical knowledge of artist workflows.

This path makes more sense than starting from a blank page. The project began with a tool shaped by real production experience, then developed into an open solution with source code, documentation, and long-term community support.

The plugin is free and distributed under the Apache 2.0 license. Its source code is available on GitHub, while ready-to-use builds are provided for 3ds Max 2020-2027. That broad version range is particularly useful for studios with mixed software environments: not everyone has to upgrade to the newest version of Max just to access the new workflow.

The built-in capabilities of 3ds Max could produce a glTF or GLB file, but in a serious production pipeline, simply having an Export button was not enough.

The main problem was fragmentation. Import and export did not form a single, reliable path, so artists often had to assemble the workflow themselves:

This was especially frustrating when working with materials. Corona and V-Ray provide artists with rich and flexible shader systems, but glTF is built around a different goal: a portable PBR material that can be interpreted consistently across many applications.

Metalness, Roughness, and Ambient Occlusion maps also need to be packed into the correct texture channels. When that conversion goes wrong, even a small model can end up with unexpectedly heavy textures. In real production work, packed PNG maps could grow to tens of megabytes, making the final GLB far too large for the web. Artists would then have to use external optimization tools, inspect the materials again, and manually search for a workable balance between quality and file size.

Add unreliable transfer of complex scenes, the lack of a convenient full-featured importer, and the need to maintain custom MaxScript workflows, and it becomes easy to understand why many artists used Blender or standalone converters as an intermediate step.

The new project Khronos is trying to eliminate precisely this fragmentation.

Loading...

The key phrase in the plugin's description is round-trip pipeline:

This represents an important change in approach. Instead of being a final container that cannot safely be touched, glTF becomes a working format inside 3ds Max.

The plugin aims to move a scene into Max and back out while preserving as much of its structure as possible, including geometry, materials, cameras, lights, animation, instances, and supported extensions. You can, for example, receive a GLB from a client, adjust its model or animation, and deliver an updated file without having to convert it through FBX and another application.

Of course, "round-trip" does not guarantee mathematically identical results for every possible scene. 3ds Max and glTF represent some data differently, and certain Max features have no direct equivalent in the standard. Even so, a unified import-edit-export path substantially reduces the amount of manual work.

You can download the Khronos GLTF/GLB plugin from this link. 

Loading...

The importer reads .gltf and .glb files and brings into the scene the elements an artist would expect to continue working with:

Its handling of modern PBR properties is particularly interesting. The plugin understands not only base color, metalness, and roughness, but also a range of extensions for more advanced surfaces, including clearcoat, anisotropy, transmission, and volume. This makes it possible to transfer coated, anisotropic, and transparent materials more accurately instead of reducing everything to the simplest possible shader.

UV transforms and compressed texture formats are supported as well. Because 3ds Max does not open WebP directly, the importer can convert a WebP texture to PNG for editing while preserving the path to the original file in custom attributes. On export, the plugin can use the original compressed file again, avoiding unnecessary re-encoding and further quality loss.

For users of 3ds Max 2024 and later, the project also provides Khronos PBR Neutral Tone Mapping. It helps bring the viewport presentation of PBR materials closer to the neutral appearance expected in glTF viewers. This does not replace final testing on the target platform, but it reduces the chance of unpleasant surprises after export.

Loading...

The exporter can create all the main glTF 2.0 variants:

GLB is usually the most convenient option for publishing on the web because it is easy to transfer, store, and integrate. A separated glTF package can be more useful during debugging, when you may want to replace a texture quickly or inspect the file structure.

The plugin exports geometry, splines, shapes, cameras, and lights. It can preserve hierarchy and supports both regular instances and the EXT_mesh_gpu_instancing extension. GPU instancing is especially valuable in scenes containing many repeated objects, such as chairs, lamps, or decorative elements. It does come with specific rules, however, and may not preserve parts of the hierarchy or animation data. The option should therefore be enabled deliberately rather than by default.

Animation covers translation, rotation and scale, Morph animation and a number of additional parameters via KHR_animation_pointer. For procedural controllers that do not have regular keys, Bake Animation is provided. The cost of convenience is predictable: frame-by-frame bake increases the amount of data, so for the web it is better to use it only where it is really needed.

The exporter also supports Skin and Morph deformation, transfers custom scene, object, and material properties through extras, can create multiple scenes inside one file, and supports material variants. Material variants are useful when a single product model needs several finishes-for example, multiple fabric colors or different housing options.

One of the most practical features is control over how the Metalness, Roughness and Ambient Occlusion cards are assembled.

In glTF, these values are commonly packed into separate channels of a single texture. This saves space and reduces the number of requests needed to load a model, but the maps must be prepared correctly. The new exporter offers several workflows:

For an artist, this is much clearer than assembling channels manually in Photoshop or a separate utility. It also provides direct control over size: a small object displayed in a browser does not always need 4K textures.

The exporter can also work with WebP and KTX2 through custom attributes. These formats can significantly reduce texture size, but compression, image quality, and compatibility should always be tested on the target platform. The more aggressive the settings, the more carefully you should inspect gradients, normal maps, transparency, and fine details.

For many 3ds Max users, this may be the most important part of the release. The exporter lists support for Scanline, PBR, Physical, glTF, Arnold, V-Ray, Corona, and USD materials.

This means that artists no longer have to rebuild every ordinary Corona or V-Ray material manually as a standard PBR material before delivering a GLB. The plugin attempts to translate the material's main properties into a model that glTF can understand.

It is important, however, to keep expectations realistic. Corona and V-Ray were created for high-quality offline and GPU rendering, while glTF is designed for fast, portable real-time presentation. There is no complete one-to-one match between them.

Materials with clear PBR logic are converted best:

Complex procedural networks, Blend materials, unusual Falloff setups, layered coatings, displacement, and renderer-specific effects may still require baking or manual adjustment. Corona and V-Ray support is not a magic button, but it can remove a significant amount of repetitive work.

The practical approach remains the same: export the model, open the GLB in the viewer or engine where it will actually be used, and compare the result with the source scene.

The plugin can apply Draco compression and add the KHR_draco_mesh_compression extension to the exported file.

Draco compresses mesh data, including vertex positions, normals, UVs, and other attributes. The size difference can be substantial on dense models, which makes the technology valuable for the web and mobile devices.

Draco does not reduce texture size, however. If images account for most of the GLB, enabling a single checkbox will not solve the problem. The target viewer must also support Draco decoding, and opening the model will require additional processing.

The right question is therefore not "Should Draco always be enabled?" but "What is the current bottleneck?"

Optimizing a GLB always means balancing file size, startup speed, and visual quality.

The plugin can be called from MaxScript using the standard importFile and exportFile commands. If several glTF handlers are installed, the documentation provides IDs that explicitly select the Khronos plugins:

Plugin settings are stored in INI files inside the plugcfg directory, so they can be prepared before batch processing. This is useful for studio pipelines, automated delivery of multiple assets, and repeatable export of several versions of the same model.

There is one important organizational detail. If an existing script expects a different glTF exporter, you should verify which handler is called after installing the new plugin. Specifying the plugin ID explicitly removes that ambiguity.

The complete example and current IDs can be found in the official documentation under Execute from Script.

The new plugin solves many problems, but does not eliminate the technical boundaries of glTF and the differences between applications.

At the time of publication, the documentation lists several limitations:

These limitations are not a reason to avoid the tool. They are better treated as a checklist before starting a project. When the requirements of the target platform are known in advance, most issues can be resolved while preparing the asset.

I have been working extensively with GLB lately, and the most tiring part has never been the export itself. It was everything surrounding it. Producing a file was easy. Producing a file that was lightweight, visually correct, and ready to publish was much harder.

Materials and textures made this particularly obvious. Separate Metalness and Roughness maps could turn into an unnecessarily heavy packed texture, forcing me to move to external tools, optimize the result, and check everything again.

That is why, for me, the main advantage of the new solution is not an individual Draco checkbox or even Corona support. The most important improvement is that importing, editing, packing maps, exporting, and delivering an updated file now form one understandable workflow inside 3ds Max.

The plugin does not remove the need to understand the fundamentals of real-time graphics. Artists still need to watch polygon counts, texture resolution, PBR values, transforms, and compatibility with the target viewer. What it does remove is much of the mechanical work that used to stand between a good model and a finished GLB.

If you regularly prepare models for websites, AR, WebXR, game engines, or online configurators, the new Khronos plugin is absolutely worth adding to your workflow and testing on your typical scenes.

It will be particularly useful for:

It is best to begin with one representative asset rather than a large project. Compare the visual result, file size, and preparation time with your previous workflow. Test the model in its real target environment: Model Viewer, Three.js, Babylon.js, PlayCanvas, a game engine, or your own application. This will quickly reveal which settings are right for your pipeline.

glTF has already become one of the main 3D content formats. It connects DCC applications, browsers, game engines, AR and e-commerce - areas that 3D artists increasingly need to move between.

In that context, the official open-source project sponsored by Khronos looks like far more than another exporter. It fills a long-standing gap in the Autodesk 3ds Max ecosystem by providing full import, more controllable export, and the ability to edit glTF assets through a round-trip workflow.

No converter is perfect. Complex Corona and V-Ray materials will still need to be checked, procedural maps may sometimes need baking, and models intended for the web still require deliberate optimization. But a large part of this work is now contained within one tool-one that understands modern glTF, is open to the community, and is being developed with the involvement of the organization responsible for the standard itself.

For artists, the result can be summarized very simply: **exporting GLB from 3ds Max is finally becoming a normal part of the production workflow instead of a one-off conversion with unpredictable results.

FAQ