Feature Request Editor-specific shader workflow

Hi, please add one for Unity Editor as well so that the shader for editor side can be different to the deployed shader. This allows for major optimisations, cleaner sources and so debug visuals, solving very similar problems this feature does, and increases value of this feature.

 

Proxy shaders!

Yes, PLEASE!!!

 

Hmmm if we can have editor only passes and subshaders as well, it would extend the usefulness. I would like to hear what @bgolus thinks too, as they'd seemed interested in this as well.

 

The old thought was just to have a keyword, though more recently I've realized ideally it would be one that could be disabled while in the editor for testing. I've mentioned elsewhere that I've work around this before with

#if UNITY_EDITOR

c# scripts that set a global keyword, but the side effect of this is obviously those variants can end up in the build. This isn't really the end of the world, but depending on the shader could mean several megs of "useless" data, so I usually try to comment out the

#pragam multi_compile

lines for it once we get close to final release. Or I've abused platform defines when working on projects that won't be shipping on PC to detect when "in the editor".

Thinking about it more right now, I actually wonder if something like a built in

#pragma multi_compile_editor

that the build and shader variant collection would ignore couldn't be useful, and/or maybe something akin to the project settings' Scripting Define Symbols, but for shaders to let use set our own global platform keywords.

 

This is a usable option for the BIRP. It's slightly less convenient for some use cases (ie: wanting to show data validation feedback ala the Material Validation Scene view modes), but workable. My issue with this option is it doesn't really work for the SRPs since they have intentionally limited multi-pass shader support. If I was going to separate out stuff to a separate pass, I'd just make it a separate shader & material and attach it to an editor only object / script to make sure it doesn't get caught by the build's resource tracking. In the past were I've done this kind of thing I usually generate the material in code and use a

#if UNITY_EDITOR

covered

Shader.Find()

, and manually pull it from any Shader Variant Collection once we start using one. That last step is the only thing it potentially helps with, which might in itself be enough to make it worthwhile to add for some personal sanity depending on the current project / team workflow and how / how often the variant collection is being updated.

Doesn't this edge case already kind of exist if you have the same keyword in a multi_compile and shader_feature? Shaders already throw warnings on duplicate keywords. To me this is the same issue, though maybe it should be an error instead of a warning.

Though I should note when I originally wrote

multi_compile_editor

I was thinking of it explicitly like a

multi_compile_instancing

or other built in multi_compile where the keywords aren't user assignable, but more literally a

#pragma multi_compile _ UNITY_EDITOR

equivalent. For editor only shaders I'll make heavy use of dynamic branching rather than keyword variants as I'm not concerned that the current GPU can't do that efficiently. And in the few cases I've wanted to be able to control per-renderer settings for debug visualization I tend to lean heavily on using MaterialPropertyBlocks instead of instanced materials, so I explicitly can't make use of per-material keywords. Though I've also not moved to using SRPs for any of our projects where property blocks are decidedly less useful due to not having SRP Batcher support... which is another topic for a different thread.

That was kind of the idea behind having the fixed keyword version of

#pragma multi_compile_editor

. Let it get dirty in the editor and make a lot more variants. But just make sure things like the build pipeline and shader variant collection system explicitly avoid adding the

UNITY_EDITOR

keyword variants. The alternative with people adding their own "editor only" keywords via

shader_feature

or

multi_compile

already comes with the pain of increased import times ... because more variants inherently make that more expensive.

Since that's already what happens to c# when you use Scripting Define Symbols, this seems like a worthwhile trade. Though presumably something like the user assignable

#pragma multi_compile_editor MY_EDITOR_KEYWORD

could be used to limit reimporting to just those shaders, I get that it'd have to be tracked and make everything slightly slower. But it's more an "interesting concept" than one I'm especially stuck on.


To me (without direct insight into the internal code) having a single

UNITY_EDITOR

keyword that is excluded from builds and has to be explicitly added to a pass via a

#pragma multi_compile_editor

feels like the most straightforward and least painful way to implement this. It also allows an easy path for allowing it to be toggled in the scene view effects toggles / game view gizmos / editor wide setting.

 

I would say that's probably how most people would expect it to work, as that's how it works in c#. Though I'm also heavily in favor of shader stuff that can be easily toggled off in the editor for easier testing and iteration. Granted comment out a few lines isn't too hard. I'd also want the "compile and show code" to either have the option to toggle or never have

UNITY_EDITOR

enabled.