LightingModel class final

A lighting model: one pre-built fragment shader and what the engine may bind to it.

A value class rather than an enum, so this list is not closed. Shaders are compiled ahead of time, so a material graph cannot be assembled at run time — but an application that builds its own bundle can add an entry to it and describe it here, and the renderer will cache a pipeline for it like any other. What it cannot do is add a shader to a bundle it does not build; that is the remaining limit, and it belongs to the bundle rather than to this type.

Two properties used to be derived by comparing against particular constants, which is the sort of thing that works exactly until somebody adds a seventh model. They are declared now.

Shaders are compiled ahead of time into the bundle, so a material graph cannot be assembled at runtime. Switching models therefore means switching shader — and switching shader means a different RenderPipeline, which is why the renderer caches pipelines by shaderName.

The uses… flags are declared rather than detected. Shader reflection cannot answer the question: it reports a uniform block as present because the GLSL declared it, even when the compiled shader binds no buffer for it, and binding that phantom block segfaults inside Metal with no Dart stack trace. The same applies to samplers — the compiler drops one whose result never reaches the output, which is why Lambert does not sample the metal-rough map even though the header declares it.

The truth is printed by tool/build_shaders.sh after every build, as a table of what each entry point actually kept. When this metadata and that table disagree, the table is right.

And since 0.8.0 the table is what binds — gfx-92n. Every backend hands the engine's own stages that table as ShaderHandle.kept, the renderer asks it first, and an encoder refuses anything it names as dropped. The binding flags below are the answer only for a stage the device cannot answer for — one from an application's own bundle, or a material language stage — and on the built-in models they are the fallback a device without the table would use. usesMaterialParameters and usesMetallic are not about binding at all: they tell an editor which controls do something.