Exporting Non-PBR Shaders from Blender to glTF

Exporting non-PBR shader node trees from Blender to the glTF format results in stripped node data, missing material attributes, or flat fallback colors because glTF strictly adheres to a standardized Physically Based Rendering (PBR) specification. Because the Blender glTF exporter only recognizes specific, predetermined node combinations—primarily built around the Principled BSDF node—any unsupported nodes, procedural textures, or custom math operations are silently ignored during export. To preserve the intended look of a non-PBR or procedural material in glTF, developers must bake their node trees into standard 2D image maps or manually rebuild the material to conform to glTF-supported PBR parameters.

Why glTF Rejects Non-PBR Nodes

The glTF (GL Transmission Format) standard is designed for fast, efficient runtime delivery in real-time engines and WebGL renderers. It defines a rigid material model based on metallic-roughness PBR workflows.

Blender’s shader system allows arbitrary node routing, procedural math, and render-engine-specific shaders (such as Cycles or EEVEE nodes like Diffuse BSDF, Glossy BSDF, or Shader to RGB). The Blender glTF exporter does not compile arbitrary node graphs into runtime shaders. Instead, it parses the node tree, looks for specific patterns connected to a Material Output node, and serializes only the recognized inputs into standard glTF 2.0 material properties.

What Happens to Common Non-PBR Elements

  • Procedural Textures and Math Nodes: Nodes such as Noise Texture, Voronoi Texture, Musgrave, ColorRamp, Math, and Vector Math are ignored. glTF cannot calculate procedural math at runtime. If a procedural texture feeds into an input like Base Color, that input will export either as a blank default color or fail to transfer entirely.
  • Legacy and Standalone Shaders: Connecting standalone shaders like Diffuse BSDF, Glass BSDF, or Toon Shaders directly to the Material Output results in an unsupported shader tree. The exporter typically defaults the material to a flat, featureless white or grey surface.
  • Shader to RGB Nodes: In EEVEE, the Shader to RGB node is frequently used to create non-photorealistic (NPR) or cel-shaded styles. Because this requires real-time scene lighting evaluations unique to Blender’s rendering pipeline, glTF cannot interpret it. The node and any post-processing connected to it are completely dropped.
  • Complex Mixing and Inversion Nodes: While standard image textures connected via straightforward UV maps will export, complex blending networks (like multiple Mix nodes combining different texture coordinates or blend modes) are dropped unless they fit exact exporter-recognized configurations (such as an Ambient Occlusion node combining with a glTF Settings node).

The Resulting glTF Output

When an asset with an unsupported node tree is exported, the resulting .gltf or .glb file will still contain geometry, UV maps, and the material slot. However, the material itself will be reduced to a bare-bones glTF material definition. Viewers and game engines loading the asset will display a plain, untextured mesh relying only on fallback values—typically a flat base color with default 1.0 roughness and 0.0 metallic values.

Solutions for Exporting Non-PBR Materials

To transfer the appearance of non-PBR node trees into glTF accurately, use one of the following workflows:

  1. Texture Baking: Bake the final procedural or non-PBR color, roughness, and normal information into standard 2D image textures (PNG or JPEG) within Blender.
  2. Restructure with Principled BSDF: Replace custom shader networks with a single Principled BSDF node, plugging the baked texture maps into the designated Base Color, Roughness, Metallic, Normal, and Emission inputs.
  3. Use glTF Material Extensions: If advanced effects like clearcoat, sheen, transmission, or unlit shading are needed, configure the shader using the specific node setups supported by official glTF extensions (such as using the Background or Emission node for an Unlit material).