Why glTF 2.0 Deprecated GLSL Shaders for PBR

glTF 2.0 deprecated arbitrary GLSL shader code to solve severe cross-platform compatibility issues and achieve visual consistency across different rendering engines. While glTF 1.0 embedded raw WebGL/OpenGL Shading Language (GLSL) code to define surface appearances, glTF 2.0 replaced this approach with a standardized Physically Based Rendering (PBR) material model. This article explores how abandoning platform-specific shader code in favor of parameter-based PBR transformed glTF into the universal "JPEG of 3D."

In glTF 1.0, materials were defined using custom GLSL shaders. While this gave creators flexibility, it tied the format directly to the OpenGL and WebGL ecosystems. Modern graphics hardware and software run on a diverse set of modern APIs, including Microsoft DirectX (HLSL), Apple Metal (MSL), and Vulkan (SPIR-V). When an application using DirectX or Metal attempted to load a glTF 1.0 asset, it had to parse, translate, or transpile the embedded GLSL into its own native shading language. This translation process was error-prone, computationally expensive, and frequently produced compilation failures or rendering bugs on target platforms.

Embedding programmatic shaders also destroyed visual consistency. Because artists could write arbitrary mathematical formulas to render light and surfaces, different rendering engines interpreted and handled the code with slight variations. The same 3D model could look radically different—or fail to display entirely—when moved between distinct 3D viewers, game engines, or online marketplaces. This unpredictability contradicted glTF’s primary design goal: to serve as a reliable, interoperable runtime asset delivery format.

To solve these issues, the Khronos Group introduced a standardized Metallic-Roughness PBR workflow as the core material definition in glTF 2.0. Instead of supplying executable code that dictates how a pixel is drawn, a glTF 2.0 asset supplies standardized data parameters representing real-world physical properties. These parameters include base color, metallic factor, roughness factor, normal maps, occlusion maps, and emissive properties.

By providing standardized physical values rather than executable code, glTF 2.0 decoupled the asset data from the underlying rendering implementation. Target engines—such as Unity, Unreal Engine, Three.js, or custom Vulkan renderers—are free to write their own native, highly optimized shaders tailored to their specific platform, hardware, and rendering pipeline. Because the inputs adhere to universally accepted physics-based lighting equations, the asset renders with predictable visual fidelity regardless of the operating system, graphics API, or runtime environment.

Ultimately, deprecating GLSL shaders in favor of standard PBR materials eliminated platform lock-in, removed the need for runtime shader transpilation, and guaranteed reliable visual uniformity across the entire 3D industry.