# VRM4U turns a VRM file into a rigged Unreal Engine character > VRM4U imports VRM avatar files into Unreal Engine as rigged characters, generating bones, morph targets, spring bones and MToon materials at import time. It is the shortest path from a VRM file to a retargetable character without leaving the editor, but its documented engine range lags behind the versions its own patch history already covers. **ruyo/VRM4U** — Runtime VRM loader for UnrealEngine5 - Repository: https://github.com/ruyo/VRM4U - Stars: 1,999 · Forks: 242 - Language: C++ - License: NOASSERTION - Published: 2026-10-14 · Updated: 2026-10-14 · Language: en - Canonical page: https://hysenlabs.com/projects/ruyo-vrm4u ## Dragging a VRM file into the editor without a DCC step VRM4U is an Unreal Engine plugin with a narrow job: take a VRM file and hand back an engine-native character, with skeleton, blend shapes and toon shading already in place. The documented workflow is one gesture. Drop a VRM file into the editor and the importer writes bones, morph targets and BlendShapeGroups, spring bones with their collision bodies, and a humanoid rig that animation can be retargeted onto. That makes it relevant to teams shipping avatar-driven experiences, and to anyone who keeps avatars in the VRM format rather than an engine-native one. No separate digital content creation tool has to sit in the loop, and the result is a SkeletalMesh with an IKRig and a Retargeter rather than a bag of textures. The mobile story continues from the same import: BoneMap reduction is what lets a SkeletalMesh run on Android or iOS from the official editor, and both Forward and Deferred rendering are supported. Two operational facts belong next to that pitch. Development and support are handled individually by the maintainer, ruyo_h, and the project states outright that responses can be slow. Nothing here carries a support target, so a report about one bad file is worth sending with the VRM attached and the engine version named. ## What the importer generates before you press play The generated content is the substance of the plugin, and it is itemised rather than implied. Skeletal bones arrive as engine bones, morph targets and BlendShapeGroups become morph targets, and spring bones plus their collision volumes are recreated as physics objects in the scene. You choose how secondary motion is solved. The setting accepts either the plugin's own solver, `VRMSpringBone`, or a `PhysicsAsset`, so a team already set up for physics authoring can hand that work to the engine. VRM 1.0 models can also have a `PhysicsAsset` generated, an option that appeared on 2025/02/06, and the BindPose correction can be switched off while the root bone rotation is initialised instead. Retargeting happens at import rather than in a later setup pass. A humanoid rig is generated automatically, and separate passes extended that to the engine mannequins: IKRig and IKRetargeter generation for the UEFN Mannequin on 2024/06/17, a Retargeter for the UE4 mannequin on 2025/05/05, and automatic IKRig creation when the UE5.6 mannequin has none on 2025/06/14. Import options can skip Retargeter generation entirely, added on 2025/06/04, and a bulk material generation tool arrived on 2025/11/13. `MToon` is reproduced as a real material rather than a screen effect, so shadow colour, outline colour and width, and MatCap inputs are authored directly. Material name prefixes moved from M_ to MI_ on 2025/08/13, which renames assets underneath any content that referenced the old paths. ## Unpacking the plugin beside your .uproject file The install path runs through the project's download page rather than a package manager, and the layout is fixed. Unpack the plugin so that a Plugins folder ends up in the same directory as the project's .uproject file: ```bash + MyProject - MyProject.uproject - Plugins - VRM4U - VRM4U.uplugin ``` Read that tree from the inside out. The payload is a single plugin descriptor, `VRM4U.uplugin`, sitting in a folder named VRM4U under Plugins, and nothing is compiled on Windows for this step. For a guided first look, the project ships a sample map: ``` VRM4UContent/Maps/VRM4U_sample.umap ``` One detail deserves a check before anyone trusts that layout. The repository top level holds .github, Content, Resources, Shaders, Source, ThirdParty, README.md, README_en.md and VRM4U.uplugin. No VRM4UContent directory appears there, so a fresh clone gives you Content rather than the path the sample map line names, and that sample map is not part of what a clone hands you. If it does not appear in the Content Browser, the project tells you to check a set of settings shown in a screenshot rather than describing them in text. With the plugin in place, the first real action stays the shortest one in the documentation: drag and drop a VRM file. ## Where the prebuilt binaries stop and a build begins Platform coverage is uneven in a way the feature list never shows. Windows is the smooth path, with no special operation required, because assimp arrives with prebuilt libraries inside the plugin. macOS needs a project build, and it needs a custom assimp that you compile from source yourself. Mobile splits by use case rather than by version. An ordinary packaged build needs nothing extra, but runtime loading on Android or iOS depends on the custom assimp built from the maintainer's fork, which is the same source dependency the macOS path requires. The headline description, a runtime VRM loader, therefore hides a real build cost on exactly the platforms where runtime loading earns its keep. The fork is also a moving target. assimp moved to 6.0.2 on 2025/08/29, to 5.4.3 on 2025/01/03 and to v5.4.1 on 2024/05/30, each time through the maintainer's own branch rather than upstream. Anyone building from source compiles against a dependency the project owner carries. Old builds split off into a second repository. Plugins from 2023/11 or earlier have to come from `UnrealEngine_VRM4UPlugin`, and the project warns that those clones can return a 404 because Epic changed how its accounts authenticate against GitHub, linking to Epic's own explanation of the process. Upgrading from an old tree means moving to current binaries rather than rebuilding the old one. ## The documented engine range versus the engines it patches The stated environment is precise and dated: UE5.4 down to 5.0, and UE4.27 down to UE4.20, on Windows, on Mac with a project build, and on mobile. UE4.19 is listed as running too, with the caveat that no materials are generated, which leaves you a working rig and an untextured character. The patch history contradicts that ceiling. Support for UE5.5 landed on 2024/11/13, a UE5.6 binary on 2025/06/04, a UE5.7 preview binary on 2025/09/25, and official UE5.8 support on 2026/06/22 after a MorphTarget import failure in that engine was fixed. The environment list has not kept pace with the versions the project already ships binaries for, so treat it as a floor and confirm your engine against the build you download. A second mismatch sits next to it. A Linux build error was fixed on 2026/01/01, yet the supported environments name only Windows, Mac and mobile targets. No deprecation policy, per-version support window, or rollback path appears anywhere in the files, and Linux is documented nowhere, so compiling for it is an experiment rather than a supported route. ## Crash fixes that point at untrusted VRM input The fix history is the most telling documentation in the repository, and it clusters around files that break the importer. Crashes on load were fixed for VRM files that omit parameters on 2025/08/13 and for files that skip texture settings on 2025/08/14. A further pass on 2025/08/29 addressed import crashes and invalid writes on certain files, and 2025/09/21 fixed crashes that depended on the specific file. Validation arrived on 2025/10/25, was left active at runtime as well on 2025/11/13, and can now be skipped at import, an option added on 2026/05/14. Rendering failures show up in the same list. Outlines became invisible on 2025/01/03 and their thickness was being affected by resolution on 2025/02/06. UV coordinates landed above 1 after import on 2025/07/14. A morph sharing a name with a pose stopped the pose from being added at all on 2025/10/16, and models imported under UE5.7 would not open on the same date. Switching materials in UE5.5 crashed, and reimporting an asset while the editor still had it open crashed too. Importing with a Skeleton specified crashed on 2024/11/10, and a Vulkan SM6 crash was fixed on 2025/08/13. The practical reading for a pipeline owner is that imported characters deserve the same suspicion as any untrusted asset. VRM 1.0 detection and loading still have edge cases, including VRoidStudio files fixed on 2025/08/13 and a detection fault repaired the same day. No fuzzing or regression suite is described, so the only stated fitness signal for a given file is the project's own validation pass. ## Two ways to shade, two ways to move the bones Material handling is the design decision with the widest consequences. `MToon` is reproduced as an engine material, so a character composites into an existing PBR background without a post-process pass. Screen-space toon over the whole frame is not the shading path, though a PostToon sample exists and had its crash fixed on 2024/07/28, so a post-process route ships alongside it. Screen-space machinery is still registered for other work. A `SceneViewExtension` is in use, and its registration timing changed on 2026/02/14 to stop a crash when the plugin is brought into Lyra. Filters arrived on the same lines: a diffusion filter on 2024/05/16, a cross effect added to it on 2024/05/30, and a rim light filter on 2025/08/13. Screen capture was narrowed to the game screen only on 2026/02/14, and its aspect ratio was corrected on 2026/07/22. How the filters and the capture are implemented is nowhere documented. Secondary motion has a comparable fork, since the setting takes either `VRMSpringBone` or a `PhysicsAsset`, and the VRM 1.0 spring bone calculation was corrected on 2024/12/06. For teams driving avatars from live input, the VMC protocol receiver is the other half: it can be picked up in an AnimNode since 2024/05/06, listens on multiple ports since 2024/05/30, defaults its receive address to ANY since 2024/10/07, gained Perfect Sync on 2024/05/16, and had MetaHuman animation curves mapped to it on 2026/09/02. A fix on 2025/01/03 existed because some sending applications could not deliver the protocol at all, so coverage on that path is worth testing rather than assuming. Two defaults moved for stated reasons. On 2024/05/30 the default material became UE5-based for editor stability and primitive merging was turned off by default to protect appearance customisability, both switchable through import options. On 2026/05/14 material merging at import was switched off as well, which leaves batching decisions with your team. ## Running costs for a team adopting the plugin Several costs appear only after adoption. One person handles development and support, and the project says response times can be slow. The Linux fix from 2026/01/01 landed outside the documented platform list, so patches reach platforms nobody documented. Every engine upgrade becomes your maintenance event too: UE5.5 import crashes needed fixes on 2024/12/13, again on 2024/12/27, and again on 2025/01/03. Licensing needs a check against your own process: the repository is classified as a custom licence GitHub cannot classify, pointing to a LICENSE file at the top level and a separate `LICENSE_assimp`, while the README table lists MIT for VRM4U and RapidJSON and 3-clause BSD for assimp in both original and forked form. The last push was on 2026-09-23. Pin the plugin version you validate against, keep your own copy of the binaries, and decide whether the single-maintainer support model matches the title you are shipping. ## Conclusion VRM4U earns a slot in any Unreal project that treats VRM as the interchange format for avatars, because it collapses avatar import into one gesture and returns a rigged, retargetable character with MToon intact. Skip it if you need a documented Linux target, VRM files arriving from untrusted senders, or an engine version above the documented range. Verify first that a binary exists for your engine version, that you can build the forked assimp on macOS or for mobile runtime loading, and that validation accepts every file your creators actually ship. ## FAQ ### Which Unreal Engine versions does VRM4U support? The stated environment covers UE5.4 down to 5.0 and UE4.27 down to UE4.20, plus UE4.19 with the caveat that no materials are generated. The patch history records UE5.5, UE5.6, UE5.7 and UE5.8 work well beyond that listed range. ### Do I need to compile anything to use VRM4U on Windows? No. You unpack the plugin or clone the repository, because prebuilt assimp libraries are already included. macOS needs a project build and a custom assimp build, and mobile runtime loading needs that same assimp source built. ### How does VRM4U produce toon shading in an Unreal scene? The importer generates a material that reproduces MToon, covering shadow colour, outline colour and thickness, and MatCap. A character can be drawn into an existing PBR background because that material path does not rely on a post-process pass. ### Can I use the engine physics system instead of the plugin's spring bones? Yes, the setting accepts either VRMSpringBone or a PhysicsAsset as the spring bone solver. For VRM 1.0 models a PhysicsAsset can also be generated, an option added on 2025/02/06. ### Where should I report a crash that happens on one specific VRM file? Development and support are handled individually by the maintainer, who notes that responses can be slow. Attaching the VRM file, the engine version and whether validation flags the file makes such reports actionable. ### Does VRM4U load VRM files at runtime on Android and iOS? Runtime loading is supported, but it needs the custom assimp source built, unlike ordinary packaged mobile use which needs no extra step. The fork is obtained from the maintainer's own assimp repository. ## Sources - [Issues](https://github.com/ruyo/VRM4U/issues) - [README](https://github.com/ruyo/VRM4U/blob/master/README.md) - [Releases](https://github.com/ruyo/VRM4U/releases) - [ruyo/VRM4U on GitHub](https://github.com/ruyo/VRM4U) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ruyo-vrm4u