Shader Graph vs. Hand-Written GLSL/HLSL: When Visual Node Tools Start Costing You

one thing nobody mentioned: Shader Graph's keyword/variant system is genuinely painful compared to writing #pragma multi_compile by hand. the visual interface for managing variants is confusing and it's way too easy to silently balloon your variant count. had a project where Shader Graph was generating 64 variants of a shader because of keyword combinations I didn't realize were active. compile times got absolutely brutal before I figured out what was happening. hand-written HLSL would've been like 8 variants tops.

The hybrid approach you're hinting at, which I landed on after similar frustration, is using Shader Graph's Custom Function node as a pressure valve. You keep the visual graph for the stuff it's genuinely good at (branching material logic, quick iteration on surface properties, readable for non-programmers on the team) but drop into an HLSL function the moment you need derivative instructions, custom interpolants, or anything that needs to know about neighboring pixels.

The friction point is that Custom Function nodes in Shader Graph don't give you clean access to the full SV_Position or screen-space derivatives without some workaround gymnastics. Once you're fighting that, you know it's time to write the whole shader. My personal threshold: if I've added more than two Custom Function nodes to a single graph, I just port it.

One thing nobody mentions: hand-written shaders are much easier to version diff meaningfully. A Shader Graph .shadergraph file is essentially unreadable in a PR.

The Custom Function node is your escape hatch and more people should know about it. You can write raw HLSL inside a Shader Graph node, expose typed inputs/outputs, and keep the visual graph intact around it. I use this pattern constantly: Shader Graph for the high-level structure and blending logic, Custom Function nodes for anything that needs precise bit manipulation, custom derivatives, or intrinsics that the graph can't express.

Where I've found Shader Graph genuinely irreplaceable even at production quality: cross-material subgraph libraries. Once you've built a solid PBR detail layer subgraph or a triplanar projection module, sharing it across 40 materials with visual diffs is a real win that hand-written code doesn't match without serious tooling investment.

Where I'd push back slightly on the premise: the performance cost of Shader Graph usually isn't the graph itself, it's people not auditing the generated HLSL output. The generated code is inspectable. If you haven't looked at it, check it. Sometimes the compiler handles it fine; sometimes you'll find it's sampling a texture three times where you expected once.

Hit this exact wall trying to do a custom subsurface scattering approximation in Shader Graph. You can kind of fake it with some creative node abuse but the moment you need to access the depth buffer in a way Epic didn't anticipate, you're stuck. Ended up writing the whole thing in HLSL with a Custom node that's basically just a text box, which works but defeats the purpose of the graph at that point lol.

Shader Graph is great for materials artists who aren't programmers. For anything that needs real control over the rendering pipeline, it's a leaky abstraction. I don't think that's controversial, just needs to be said upfront so people don't paint themselves into a corner mid-project.