Unreal Engine 5.7 made Substrate the default material system for every new project, and if you've imported a metallic GLB since upgrading, you've probably watched it go flat and plasticky, or turn solid black the moment you open the material. Neither is a broken download. Substrate dropped the Metallic input that metallic-roughness PBR (the format glTF and every BitSoul GLB ship in) has used for a decade, and the fix depends on exactly how that model got into your project.
Two different bugs, two different causes. If your GLB looks matte and washed out — chrome reading like rubber, brushed steel reading like drywall — Interchange still built you a legacy DefaultLit material because the import happened through the generic Static Mesh path instead of the dedicated glTF importer. If the material is pitch black instead, you converted it to Substrate manually (or reimported into a project where Substrate got enabled after the fact) and something upstream — a material function, a parent instance — is still non-Substrate. Substrate materials render black outright when Substrate is disabled anywhere in that chain; there's no silent fallback.
Why glTF metal doesn't map onto Substrate cleanly
glTF's metallic-roughness workflow packs three values into one texture: occlusion in the red channel, roughness in green, metallic in blue. Every material node graph built around that format — including the one Interchange has generated for years — plugs the blue channel straight into a Metallic input on the Slab node. Substrate's Slab doesn't have one. It builds surfaces from Diffuse Albedo and F0 (reflectance at a straight-on viewing angle) instead, because that's what lets it stack real physical layers — metal under clear coat, cloth over skin — without the old shading-model switch statement underneath.
Epic didn't leave you to rebuild that math by hand. The Substrate Metalness-To-DiffuseAlbedo-F0 Helper node takes the same three inputs your glTF texture already has — Base Color, Specular, Metallic — and converts them into Diffuse Albedo and F0 for the Slab. It's a straight swap, not a redesign:
| glTF ORM channel | Old DefaultLit input | Substrate path |
|---|---|---|
| Red (occlusion) | Ambient Occlusion | Ambient Occlusion (unchanged) |
| Green (roughness) | Roughness | Roughness on the Slab (unchanged) |
| Blue (metallic) | Metallic | Base Color + Specular + Metallic → Metalness-To-DiffuseAlbedo-F0 Helper → Diffuse Albedo / F0 |
When Interchange imports a `.glb` or `.gltf` directly (File > Import Into Level, or dragging onto the Content Browser with the glTF plugin active) into a project with Substrate turned on, it wires this helper node in automatically — you'll see it sitting between your texture sample and the Slab if you open the generated material. That's the fast path, and it's why a fresh GLB import into a fresh 5.7 project usually just works.
Where it actually breaks
Old imports, new engine version. A GLB you imported under 5.4–5.6 got a standard DefaultLit material with a direct Metallic input, because Substrate wasn't the default then. Upgrading the project to 5.7 doesn't touch that material — Epic's upgrade path deliberately leaves existing projects on the non-Substrate pipeline unless you opt in, specifically so nobody's shipping title breaks overnight. If you then flip Substrate on in Project Settings > Rendering > Materials to get Nanite Foliage or the new PCG tools, every material imported before that point keeps its old graph and starts rendering flat, because the renderer is now evaluating Substrate materials but this one was never converted.
Manual conversion, no way back. Right-click the Material Root node and Convert to Substrate, and the engine recompiles that material's shaders onto the new pipeline — permanently. There's no "convert back" option. If you batch-convert an import folder and one material was actually feeding into a Blueprint that expects a Metallic parameter (dynamic material instances driving damage states, paint swaps, that kind of thing), that parameter now does nothing and the object just goes dull when the game tries to change it.
Black materials, not flat ones. This is the one that looks like corruption. It shows up when a Substrate-converted material references a material function or parent instance that itself hasn't been converted, or when Substrate is enabled in the editor's preview but disabled for the target platform in per-platform project settings. Check Project Settings > Rendering > Materials on both the editor and the platform tab — a mismatch there is the most common cause reported against the 5.7 preview builds, ahead of anything importer-related.
Fixing an already-imported GLB
For a single asset: open the material, select the final node feeding the Slab, and manually insert the Metalness-To-DiffuseAlbedo-F0 Helper between your texture sample and the Slab's Diffuse Albedo / F0 pins, matching the table above. For a whole import folder, it's faster to delete and reimport through the dedicated glTF plugin rather than hand-patch each one — Interchange will build the Substrate-native graph correctly the second time, and you skip the "which materials still have the old input" audit entirely.
If you're pulling reference geometry to test this — something with a genuine mixed-metal, mixed-finish surface is more useful than a single flat plane — the Chrome Boombox model has painted plastic next to brushed and polished metal on the same mesh, so a bad conversion shows up immediately as one surface reading right and the other going flat. A free account's two monthly downloads cover evaluation; commercial use is included with paid memberships — see pricing. You can also load the GLB straight into 3D Studio first to confirm the source materials and UVs are clean before you rule out the importer as the cause.
Gotchas worth knowing before you flip the switch
Enabling Substrate on an existing project doesn't just affect materials you touch — every DefaultLit material in the level still renders through the legacy path until you convert it, so a scene can end up half-Substrate, half-legacy indefinitely, and that's supported, not a bug. Landscape materials and some particle-system materials have narrower Substrate support than static mesh materials as of 5.7, so don't assume a folder-wide batch convert is safe without spot-checking those categories first. And because conversion is one-way, convert a duplicate of anything you might need to ship on a non-Substrate platform target later, rather than converting in place.
Substrate materials that read correctly in the editor viewport but go black only in a packaged build almost always trace back to the per-platform Rendering setting being out of sync with the editor setting — check that before assuming it's a shader compilation failure. If you're also chasing reimport issues on the same project, the UE5 glTF reimport fix covers the transform and hang cases that show up independently of Substrate. And if the GLB came out of Blender 5.0, check what Blender's glTF export still breaks first — a baked-wrong metallic map will fail identically under both material systems, and it's a five-minute check before you start rewiring node graphs.
---
*This post is part of the Ultimate Guide to Free 3D Game Assets — BitSoul's complete reference for formats, texturing, rigging, optimization, and engine integration.*