Shaders

Shader workflow in Source 1 was a big mess, each shader having a lot of boilerplate that would need to be filled, you'd need to correctly manually bind each register bidirectionally between the render code and the shader code, even if you'd try to improve the description of the idea of what each register should be bound to, it was still a chore. 

Valve has improved this a lot in Source 2, adding a lot of near zero cost abstractions to make everyone's life easier but it still requires a lot of meddling around with external command line tools which makes parts of the workflow feel like a deja-vu, we've got much of that solved.

I wanted to do everything possible to make any kind of shader authoring as streamlined as possible, this includes any facilities on manipulating and reloading shaders, without ever touching anything besides Met and your favourite code editor.

I have reworked some of the code in the Source 2 engine to add support for loading and parsing shaders from our addon system, compiling them ingame, among other iterative improvements, and I made sure to add all those quality of life improvements to the editors.

All shader workflow is a closed loop now, from creation to distribution.

Save it in your editor and the changes you've previewed are instantly applied back in the game, if you are working on a new file that hasn't been compiled yet, it'll show on the shader list and compile itself when you load it at the first time.

attribute 'alt' not allowed

You can compile shaders using a wildcard to batch compile a bunch at once too.

attribute 'alt' not allowed

Oh yeah, Source 2 uses a new shader source format, on the core it's still HLSL code, only pre-processed into their syntax and exposing a lot of helpers.

It describes all functionality needed in the shader, encapsulating all shader programs into one tidy source, including parameters that you will set in the editor, and such readily appear there as a variable to be set per-material or dynamically in C# code.

A lot of how Valve has set up their shaders reminds me of how other game engines describe the idea of a base material to be expanded by their Material Editor, except describing such in code rather than in a node graph which is incredibly elegant.

For example I have toyed with it for building a test Vertex Shader for a blob mesh

You can expect the same readiness when constructing your shader expanding on PBR parameters for example, and this can be expanded infinitely, we're still evaluating how we can make it more accessible.

Even though it's not ours I think it's be nice to mention the Dynamic Material Expression stuff in material editor and how you don't need to make a shader to do simple stuff like flashing a colour or dynamically modifying a parameter.

This is certainly something we're going to expand more upon in the future.

I think one of the most immediate things people will use custom shaders for is for custom Post Processing Effects, and will be exposed as simple as possible to the player without losing it's power, instead of passing a complex list of parameters and commands, for most cases you only need to expose which material you want to render in a list of passes.

Post Processing effects can range from simple vignette effects to some crazy ideas you might find in something like Reshade, only better because you actually have control of everything.

There's still a lot in the pipeline we can expose to players, and it should be done the smartest way possible.

Our rendering pipeline is malleable enough for doing any expansions on the long term without reengineering much of it and keeping things compatible.