I considered making a Node-based material system, but figured out most shaders would be the same more or less anyway - at least for the visuals I try to achieve.

When going for "Realistic Graphics", eventually using PBR (Physically Based Rendering), and maybe doing a Deferred Rendering pipeline, the amount of "Special Cases" isn't that high, because all materials take the same sort of input, apply the same sort of tricks, and go through the same sort of lighting (hence, physically based) stages.

At least, that goes for the majority of solid geometry, like your walls, terrains, furniture, and so on. Semi translucent matter like tissue or plants may need some boosters.

What I did, is making "Uber Shaders", basically 1 or few big all-scenario shaders, with a lot of #IFDEF's inside them. Then the artist would toggle (read #define) options, like NormalMapping on/off, or "Use layer2 diffuse texture". Most important are a small bunch of standard sliders, like the Smoothness/Roughness of a material, the Fresnel, or whether its a Metal or Non-Metal surface. Works out pretty well for most stuff, and the artist has almost nothing to do, other than drawing kick-ass textures of course.

Depending on the enabled options, the actual shader gets subtracted from the Uber-Shader. And before doing so, I check if it wasn't made already by some other material using the same options. The actual amount of unique shaders stay pretty low, making it suitable for sorting.

The more special cases are typically alpha-blended materials, like glass, jelly-cake, or particles. Sure a Node System would be nice for those, especially from an Artist point of view. Then again, they make up a small fraction in my case, and simply toggling techniques on / off still works here, and is a hell lot faster than building your shader with nodes from ground up. But of course, the artist is bound to whatever options the programmer delivers, which can be limited.

I think the Node System comes from times where PBR and such weren't standard yet, so special hacks had to be made to simulate different materials, such as metal or wet pavement. GPU's are strong enough these days to treat them as one (with some overhead yet), running the same code over them.

My experience is similar to Digitalfragment's: even if you have a fairly standardized set of inputs into your lighting calculations, there can potentially be *many* ways to generate those inputs. In our engine, most of these permutations revolve around our concept of "layer blending", which is essentially the process of combining parameters from multiple sub-materials into a final result. This happens based on maps, vertex color channels, projected decals, normal orientation, etc. Good technical artists can do fairly clever things in this area if you give them a node graph: for instance, they might blend in snow based on the Y component of the vertex normal so that it only shows up on the top of meshes.

Some engines (like id's engine) side-step this issue by having unique virtual textures for all level geometry. This lets them pre-compute all of the blending into the unique textures, which makes their shaders simpler since their inputs are more uniform.