glTFRuntime: loading glTF assets at runtime in Unreal Engine

Runtime import as the design decision

glTFRuntime is an Unreal Engine plugin for loading glTF files at runtime, and it supports UE 4.25 and UE5. That single phrase is the whole product.

Unreal's normal pipeline for 3D content is an editor import step: a mesh arrives as a source file, the editor converts it into Unreal assets, and those assets are cooked into the package. That pipeline is well suited to a game with a fixed cast of assets and a build pipeline that can absorb the conversion cost. It is badly suited to an application where the 3D content arrives after the build, from users, from a content pipeline, or from a marketplace.

glTFRuntime moves the conversion into the running application. The glTF file is read and turned into Unreal objects while the game is live.

The licence is MIT, which is unusually permissive for a commercial Unreal plugin, and the repository layout is what you would expect of an Unreal plugin: glTFRuntime.uplugin at the root, with Config/, Content/, Resources/ and Source/ directories beside it. The plugin descriptor is what the editor reads to know what the plugin is and which engine versions it supports.

The documentation is kept in a separate repository, glTFRuntime-docs, which the README links as the official docs, and there is a Discord channel linked at the top of the README for questions.

The plugin architecture and how formats extend

glTFRuntime can be extended with support for more file formats, and the README gives what it calls an incomplete list of available plugins:

* https://github.com/rdeioris/glTFRuntimeSTL (STL files support)
* https://github.com/rdeioris/glTFRuntimeOBJ (OBJ files support)
* https://github.com/rdeioris/glTFRuntimeFBX (FBX files support)
* https://github.com/rdeioris/glTFRuntimeVox (MagicaVoxel/Vox files support)
* https://github.com/rdeioris/glTFRuntimeWebP (WebP textures support)
* https://github.com/rdeioris/glTFRuntimePointCloud (PointCloud support for glTF, XYZ, PCD)
* https://github.com/rdeioris/glTFRuntimeKTX2 (KTX2 textures support)
* https://github.com/rdeioris/glTFRuntimeSTBImage (STB supported images, included HDR) 
* https://github.com/rdeioris/glTFRuntimeConvexCollisions (Support for convex collisions)
* https://github.com/rdeioris/glTFRuntimeDraco (Draco compression support)
* https://github.com/rdeioris/glTFRuntimeAudio (Audio file formats support, WAV, Ogg/Opus, Ogg/Vorbis, Mp3)
* https://github.com/rdeioris/glTFRuntimeGeometryCache (Geometry Cache support)
* https://github.com/rdeioris/glTFRuntimeAlembic (Alembic files support, includes grooming/hair and geometry cache)
* https://github.com/rdeioris/glTFRuntimeAvif (Avif textures support)

The list tells you the shape of the ecosystem. glTFRuntime itself handles glTF, and each other format lives in its own plugin repository under the same author. That is a clean separation: the core handles the glTF container, the loading pipeline and the Unreal object creation, while a format plugin handles one file format's parsing.

The range of these plugins is broader than the name suggests. Point clouds for glTF, XYZ and PCD are covered, which points at lidar and survey visualisation rather than game assets. Alembic support includes grooming and hair, and Geometry Cache is a separate plugin again, so the same author maintains two overlapping but distinct routes into cached animation data. Convex collisions as its own plugin implies that collision generation is optional rather than built in.

The format list also covers textures in several directions: WebP, KTX2, AVIF and STB with HDR included. KTX2 in particular is a GPU-oriented compressed texture format, which matters for streaming, and its presence as a separate plugin rather than a core feature suggests the core works with a more conventional texture path.

Compressed glTF and the separate Draco plugin

Draco support is called out separately in the README, above the plugin list, with a link to the glTFRuntimeDraco repository. That distinction is worth understanding rather than skimming past.

Draco is a mesh compression scheme that reduces the size of geometric data, and it is part of the glTF ecosystem's extension mechanism rather than the core format. That is why it can arrive as an optional piece rather than being baked in. The cost of that choice is a dependency: to read a Draco-compressed glTF you install the extra plugin.

The practical question for anyone adopting this is what their content pipeline produces. If your assets come from a standard glTF exporter, the core plugin is enough. If they come from a pipeline that applies Draco compression, typically because the files are large and you care about download size, you need the companion plugin, and you should confirm it is compatible with your engine version before committing to a content workflow.

The README also links a Features Showcase video on YouTube and the official documentation repository, which is where the actual API surface is described. The repository's own README is deliberately short, functioning as a signpost rather than a manual.

Animation retargeting and skeleton remapping

Two tutorials are listed, and they are about the hard part rather than the easy part.

The first is assigning existing animations to a glTF skeletal mesh, in a document called SkeletonRemapping.md. The second is runtime animation retargeting, in RetargetingRPMAndMixamo.md, whose filename names the two retargeting conventions involved: the rig used by the Reallusion character creator and Mixamo.

This tells you where the difficulty sits. Loading a static mesh at runtime is the straightforward part. Loading a skinned mesh with a skeleton, and then making animations authored for one rig play on a rig that came from a glTF file with a different bone layout, is where a runtime glTF importer earns its keep, and it is a genuinely hard problem that an editor-time import step usually hides because the conversion happens once, with a human able to fix the result.

The retargeting tutorials are also the ones to read before deciding, because they show the intended workflow rather than a promise. A runtime importer that cannot retarget cleanly is much less useful than the feature list suggests, since most glTF content in the wild is skinned and animated with Mixamo or Reallusion conventions rather than with a rig matched to your project.

The README also links instructions on packaging your project, hosted in the glTfruntime-docs repository under a section called notes when packaging a game, which is where the runtime dependency question, namely what has to ship with the packaged build, is addressed.

Funding, releases and where the source of truth sits

The README explains how the project is funded in a sentence. To support development you can buy glTFRuntime on the Unreal Marketplace, or become a Patreon. The repository also carries the Epic MegaGrants recipient logo in both light and dark variants, indicating the project received an Epic MegaGrant.

That funding detail matters for reading the licence and the repository split correctly. The plugin itself is MIT licensed in this repository, with a LICENSE file at the root. What the Marketplace listing sells is support and, in practice, the maintained version of the plugin for engine versions that the open repository may lag behind. The README's own wording about installing from the Marketplace and the separate documentation repository suggests a split between the public source and the supported distribution.

The releases are tagged by date rather than by semver, with tags 20260826 from 2026-08-26, 20260824 from 2026-08-24 and 20260113 from 2026-01-13. A date-based tag is a reasonable convention for a plugin that has to be rebuilt against each engine release, since it removes the question of which version maps to which engine build, and it lets you pin to the tag that matches your engine.

The last push to the repository was on 2026-10-15, the repository is not archived, and the maintainer is reachable through the linked Discord channel, so a project with a commercial product behind it and a public source tree is the arrangement here.

Where glTFRuntime is the wrong choice

Three limits are worth naming. The first is that runtime import is a cost paid at the worst possible moment if your assets are actually fixed. If the 3D content of your game is known when you build, converting it once in the editor produces cooked assets that are cheaper to load and cheaper to render, and Unreal's own glTF importer does that without a plugin. A runtime importer earns its cost only when the content genuinely arrives late, arrives per user, or changes without a rebuild.

The second is the plugin sprawl. Every format and every optional feature is a separate repository, so an application that needs glTF with Draco compression, KTX2 textures, Alembic caching and convex collisions is assembling four plugins, each on its own version cadence, each needing to be compatible with your engine build. The README gives a list of URLs and not a compatibility matrix, so the reader is left to work out the supported combinations from the documentation and the issue trackers.

The third is that the documentation lives elsewhere and the README here is thin. The runtime API, the loading options, the threading behaviour, the memory characteristics of a loaded mesh and the failure modes of a malformed file are all in the glTFRuntime-docs repository or the Discord channel, not in the source tree. That is a legitimate way to organise the documentation, but it means evaluating this plugin properly means reading a second repository and probably asking questions in chat, and the sort of decision that is easy for a single developer and harder inside a studio with a review process.

The comparison worth making is with Unreal's built-in glTF import. The difference in approach is where the conversion happens: in the editor as part of a build, or in the running application. Everything else, including how skeleton remapping is handled, is the same class of problem, and the built-in path gives you cooked, optimised assets for free at the cost of not being able to load anything new after the build.

Editorial conclusion

glTFRuntime suits an Unreal project that ships user-supplied 3D content, since it loads glTF at runtime without an import step in the editor, and its companion plugin format is a clean way to add formats the engine cannot read. It is the wrong tool if your assets are fixed at build time, because the built-in Unreal glTF importer covers that case without a runtime dependency, and it is the wrong tool if you cannot accept the plugin's own dependencies. Verify first which engine version and which formats you need, since the plugin claims UE 4.25 and UE5 support and Draco support comes from a separate plugin, and note that the newest tagged release listed is 20260826 with the last push on 2026-10-15.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. rdeioris/glTFRuntime on GitHub
4. README
5. Releases