Turn on Ray Tracing in an HDRP project, import a GLB through glTFast, and the console fills with `Shader error in 'Shader Graphs/glTF-pbrMetallicRoughness': 'PBRDeferredFragment': Opcode Sample not valid in shader model lib_6_3(closesthit)` — one line per texture, per material. Nothing is corrupted. glTFast's generated shader samples textures in a way the ray tracing pass can't execute, and there are two ways around it: patch the shader's sample nodes, or drop the generated material for HDRP/Lit.
Why HDRP's ray tracing pass rejects glTF materials
glTFast builds every imported material from one bundled asset, `Shader Graphs/glTF-pbrMetallicRoughness`. It works fine in the standard rasterized passes. The trouble starts with the extra pass HDRP compiles once Ray Tracing is on: a closest-hit shader running at the `lib_6_3` profile, the stage that answers "what did this ray hit and what color is it" for reflections, GI, and ray-traced shadows.
Closest-hit shaders don't run across a screen-space quad, so they have no pixel neighbors to compute derivatives from. The standard `Sample Texture 2D` node in Shader Graph compiles to a `.Sample()` call, and `.Sample()` needs those derivatives to pick a mip level automatically. Ask for one anyway inside a closest-hit shader and DXC — the DirectX shader compiler — rejects the instruction outright rather than guessing. It isn't a glTFast bug so much as glTFast's default graph never being built for this pass; HDRP's own shaders sidestep it by sampling with an explicit LOD instead.
A single glTFast material typically wires up four to five of these nodes — base color, normal, metallic-roughness, emissive, and occlusion if it isn't packed into the metallic-roughness map — so one imported prop can throw four or five near-identical errors, and a scene with a few dozen props buries anything else in the console.
This isn't just console noise. glTFast's own issue tracker lists the same failure as a hard build error once Development Build shader stripping tries to compile every DXR variant, not only the ones currently in view. If a build fails on shader compilation rather than the editor just logging warnings, confirm it's this specific issue by checking the log for `PBRDeferredFragment` and `lib_6_3` before chasing a different cause — HDRP ray tracing errors share enough wording that it's easy to end up patching the wrong shader.
Two fixes for the glTF shader crash
Patch the sample nodes. Editing the shader inside `Packages` won't stick — package updates overwrite it — so copy `glTF-pbrMetallicRoughness.shadergraph` out into your own `Assets` folder first, then point the affected materials at the copy. Open it in Shader Graph, find each `Sample Texture 2D` node feeding BaseColor, Normal, MetallicRoughness, and Emissive, and swap it for a `Sample Texture 2D LOD` node with a Float set to `0` wired into the new LOD input. That node compiles to `.SampleLevel()`, which closest-hit shaders accept. Reconnect UV and texture inputs exactly as before, save, and the DXR pass compiles clean.
Swap to HDRP/Lit. For a handful of props this is faster: select the material, change its Shader dropdown to `HDRP/Lit`, and drop in Base Color and Normal — both carry over with the same channel meaning. The metallic-roughness map doesn't: glTF packs occlusion, roughness, and metallic in a different channel order than HDRP's Mask Map expects, so a straight drag-and-drop reads the wrong data into the wrong slot. Why your ORM texture breaks in Unity but not Godot or UE5 has the exact remap.
Converting materials one at a time gets old fast past three or four imports. This finds every glTFast material in the current selection and reassigns it in one pass:
```csharp
// Editor script: batch-reassign HDRP/Lit to selected glTFast materials
foreach (var obj in Selection.objects) {
if (obj is Material mat && mat.shader.name.Contains("glTF-pbrMetallicRoughness"))
mat.shader = Shader.Find("HDRP/Lit");
}
```
Run it, then fix the Mask Map per material — the shader swap doesn't touch textures.
Which fix to pick
| | Patch the shader | Swap to HDRP/Lit |
|---|---|---|
| Setup time | ~15 min once, reused forever | Per-material, faster for a handful |
| Survives package updates | Yes, once moved to Assets | No dependency on the package shader at all |
| Texture work needed | None | Remap ORM to Mask Map order |
| Best for | Big imported libraries, ongoing pipeline | One-off props, quick tests |
Neither fix is needed if an object never has to appear correctly in a reflection or ray-traced shadow — background dressing, mostly. Pull it out of whatever Rendering Layer Mask the HDRP asset uses for ray tracing and the DXR pass never touches its shader, error included.
Testing either fix needs a genuinely reflective surface, not a matte crate — a chrome finish shows a broken Mask Map immediately, where a rough plastic prop won't. Chrome Boombox works well for this: its finish makes metallic and smoothness errors obvious in the viewport instead of a subtle gloss shift that's easy to miss. To build the Mask Map from source instead of unpacking it out of the GLB, grab the separate Base Color, Normal, and ORM maps from the model page directly — a free account's two monthly downloads cover evaluation; commercial use is included with paid memberships (pricing).
Two related fixes worth bookmarking alongside this one: Why Unity's glTF export discards your LOD levels if you're rebuilding the same models for export, and Emissive glTF materials look dim in Unity? Here's the real fix if the same imported material also looks wrong outside the ray tracing pass.
---
*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.*