Shader keyword limit

We use the Terrain Tools, but not HDRP. Yet still in the HDRP_TerrainVisualiser there are more than 5 global keywords that are defined, severely limiting us.

 

I created a new HDRP project to test compatibility between the core assets that I will use to create my terrains with. So I imported Microsplat (for rendering the terrain), Nature renderer (for rendering the vegetation on GPU instancing), The vegetation engine (one asset to manage all my vegetation motion, shading etc.) and Nature manufacture forest asset. And I ALREADY hit the global keyword limit!

Honestly I don't know what to do..

 

Signing under this as well. The Vegetation Engine, Vegetation Studio, a package from Nature Manufacture and you're past the keyword limit.
After so many years of people begging to increase the limit, this is nothing but disrespecting asset store customers and developers, as they are the ones who get pushed around with keyword limit questions on a daily basis.

If at least HDRP or URP didn't eat up so many keywords on their own it'd be a bit more bearable but at this point not even Shader Control can help - some shaders just can't be modified into local without everything going haywire.

 

@LukasCh Is there any further progression on this?

Local keywords definitely helped but there are too many packages (and builtin Unity features) that add global keywords still.

 

Thank you very kindly!

 

The holy feedback we've been waiting for TwT

 

Thank you for listening to the community.

 

So, as an asset store developer, I'll offer some unique perspective.

Generally we can't easily switch to local keywords until all of our customers are on versions of Unity which support local keywords. It's not something you can easily #if UNITY_2019 around. Additionally, some graphical shader editors might not support these features, because they require lots of changes to support vs. just typing in text, so this stuff tends to lag behind.

As for MicroSplat, it uses its own system, and adds no local or global keywords to Unity. Basically I wrote my own because MicroSplat has around 750+ keywords, which is not really possible in either the local or global system.

 

Looking forward to seeing a resolution to this issue soon. Its been an absolute productivity KILLER.

 

@aleksandrk Thank you very much for this little ray of hope.

It would be great if we could have some assurance by Unity in this matter, since it threatens our game's release after years of development and it's mostly out of our control. Something like "If in X months we don't find a better solution, we'll allow user-defined max keyword limit, for those willing to lose some performance". Could maybe your team make a decision like this and share it with us? We'd at least *know* that we'd be able to build our project.

Edit: also, better tools for reporting exactly where the global keywords come from, would go a long way combined with an optional increase of the limit. Even Shader Control has limits.

 

This issue pretty much was the reason I started learning Unreal engine after my last cross platform project. Dealing with multiple render pipelines and platforms is terrible on unity so I had to build multiple projects, each for every platform I want to support to avoid this issue. Stuff like this is not only wasting time but also costly, so its very obvious to just switch the engine and that point.

Waited years for this to be solved, which never happened, so I switched to Unreal. No regrets so far.

 

Thank you for your efforts, we'll keep our fingers crossed. I certainly hope you can fix it and you sound confident about it, which is very reassuring.

I'd just like to state, so maybe you can forward it to someone above, that Unity may be underestimating this issue. For some of us this is no common bug or annoyance, but a dramatic threat. After a big investment in both time and money we suddenly feel everything hangs on the possible success of a fix that Unity has been unable to deal with for years. This affects many developers, not just us; for some it is merely a chore and a bother, but for others it's crippling and may even be final, and as a project grows I suspect many of the former will enter the later category. If we had "only" spent 5-6 months and under 50K in this project, we would be cutting our losses and switching engines now. And I love Unity, at least the good things in it.

 

My project has exceeded 256 global keywords using mostly assets from the asset store.

I have run Shader Control to switch from global to local keywords. But I'm still above the limit of 256.

What am I supposed to do in that case?
Is there some sort of clear way to identify which shader are used/unused by the project etc...
A todo list to follow in this case, anything really.

 

To expand on what i wrote here, this is what works-ish for us:

1. Ignore the problem. It might not be able to compile variations that were not even possible/visible. Of course not ideal, but try to find actual shaders that are broken in the build and fix those.
2. Recognise the different ways new keywords get added to the global limits, namely
   1. Keywords enabled on a material, visible in the debug view of the inspector. Its irrelevant if the shader actually has a variant for this, so create a tool to analyse shaders and their keywords, and strip out all keywords that exist in the material but not in the shader.
   2. Shaders with global keywords. Modify the shader to use a local keyword instead, when its not used by Shader.EnableKeyword globally.
3. Strip shaders and their variants using IPreprocessShaders. With this you can prevent variants being compiled that you dont want, even on shaders on which you cannot change the source (e.g. the terrain tools i was complaining about earlier). I think this step is only done when building though, so in the editor you might still have errors. Not 100% sure on that.
4. Once you tried all that, remove the Library/ShaderCache/EditorEncounteredVariants file, restart the editor. Hop around your desk 3.5 times on one leg to refresh the list even more, there doesnt really seem to be a reliable way to make Unity reconsider, or find out why a keyword is part of the list. Do random things until the shader compiler complains about the variants again, repeat above steps until it doesnt.

 

Or 4. Cry in the corner.

 

What is the current roadmap for the development on this considering it has been a very longstanding issue and concern ( since 2013) but especially concerning more recently (2016 and forward) especially with LWRP/URP and HDRP?

I don't mean to sound pessimistic but I've been a lurker on these forums for a very long time and again and again I keep seeing "We're looking at it" "Working on it" "Soon" "We'll let you know when we're ready for a release". I mean, you guys at Unity don't really have a good track record for product releases and updates, I mean, look how many years it took for some basic QOL terrain updates to occur.

Your comment "Don't worry, we'll figure it out" is from May 13th, 2020... it's been 6 months already. This thread was created in August of 2018, 2 years, 3 months ago. "We currently have option 3 implemented, but not publicly available. The option 2 still requires a bit investigation, because it would require fundamental changes of keyword system."

Why not, at our own choice, for the time being, make it selectablable in the settings to do Option 1, that way specific errors have a soft fix at the expense of performance. For me, with the size of my project, going from 256 to 512 would solve my issue since I have 379 keywords after stripping. Then continue to update us on Option 2. Unless there is a reason for not doing this such as it completely breaking Unity Builds or causing massive leaks or will break current production of Option 2 or is being implemented with Option 2 for selectable Keyword Sizes (or automatically expanding allocations), please be transparent with us.

I'd really like to know where progress stands with this side of Unity and so would many others, telling us "Soon" is not really telling us anything. I'd like a date, or an expectation of when to see it implemented in public beta releases (at the very least) or a full production release. Tell us 6 months, 9 months, 2 years, 5 years, at least let us know so we can build our projects around that timeline.

This shader issue and other issues with Unity in the past has almost made me, and I know others, jump ship and go over to Unreal Engine or engines of the like simply because of the slow progress and lack of transparency to updating basic systems.

 

Thank you for being transparent about it, though. It's good to know that some progress is being made and from the sound of it, it might the best alternative out of the three originally suggested. I just hope we won't go another year without any change whatsoever.

 

See, that's why I thought Unity as organization is underestimating this.

While you work on "option 4" others should have keywords increased to 1024 in Unity 2019 and 2020. If those increases end up being redundant because "option 4" works marvellously and is eventually backported, it'd still be worth it. I hope it's not the case but "option 4" may not work, or may not be backported, or may take a whole year to be backported to current versions, and during that time people still needs to release games. No cutting-edge feature those people could have been working on is anywhere as important as... shaders actually working and games being shipped. Trust me on this.

I don't want in any way to sound "ungrateful" to your personal efforts in this matter, which sound well founded and correctly planified, it's probably what any competent developer would try to do in your situation. You went to the core of the issue, a long-lasting solution, and you even have backup plans. Well done.

What I hope is whoever has the capacity to shift resources around at Unity, should at least take a deep look at this discussion and make a decision, because at least from many developers' perspective this is not just "another tech issue on the bugtracker".

With this, I'll just let you work and not moan anymore, and hopefully my next post in this thread will be to congratulate you and thank you for your success.

 

I very much appreciate the answer and the transparency. I've just grown impatient, with many others, as it felt as though we were not getting anymore than just "Soon" especially with so much time that has passed between responses (not only on this thread but others); to know a 4th option is being worked on as a possible final solution to this issue is very assuring, hopefully in the next few months, 4-16 months, we can see it implemented, the sooner the better though. Keyword issues has been a crux for those getting involved with HDRP/URP.

I can only hope that a patch is released for 2019.4LTS, however, at this point, it is more reasonable to expect to see this implemented into a stable 2020.4 LTS build and if possible. If this is the case, at the very least, I would hope 2019.4 LTS would be looked into, and 2020.4 if 'option 4' isn't implemented, in doing what you said, and just increasing the fixed keyword limits. Currently, the limit of 256 is not enough, however, based on what I've seen, a mild increase to 386 or even 512 would solve most people's issues as it seems most of us are stuck with 280-400 keywords when working with HDRP/URP.

 

I actually think waiting for a real fix is the right thing to do. The limit has been raised a few times, and always ends up in the same place, wanting it to be upped again.

While we're on the subject of keywords, what I think would be very useful is some kind of 'shader_feature_static". Right now our choices are multi-compile variants, which are set project wide and cannot be changed per material, or shader-features, which can be changed per material, but require compiling every variant when the shader imports, so that they are ready if these options are changed at runtime.

What I think would be extremely useful is a variant of shader feature which compiles ONLY the variants specified by a given material, and cannot be changed at runtime.

The reason I have ended up writing my own shader generation system is because I have hundreds of options to support. Some of my earlier shaders used shader_feature, and quickly ended up with 10 minute compiles, or crashing the shader compiler all together. So I switched to dynamically combining shader fragments together based on user options instead, rewriting the shader each time the user changes an option. While this has had some nice side benefits, like being able to ship MicroSplat as separate modules, I have written four of these frameworks now for different projects when I've realized that shader_feature was going to be too limiting and bloat the variant count.

By having a contract that says I cannot change these features outside of the editor, we avoid having to compile/build/strip any variants that are unused, because we only need to compile the exact variants specified for the material(s) that use it. When these options are changed in the editor a new set of variant will have to be compiled, but it's a small price to pay for having an infinite number of possible keywords (especially when shader compilation/importing/etc are finally async). Further, for keywords that use this model, no variant stripping is needed, and there is no possibility of including thousands of extra variants that will never be used.

And while it's cool that you can animate any shader_feature, it's not used by the majority of shaders, and if it is, special care has to be taken to prevent those variants from being accidentally stripped.

In a lot of engines, shader variants sprang from lighting systems needing separate shaders for different lighting combinations, or wanting to use the same shaders for skinned/non-skinned versions. Under these use cases, global shader keywords, multi-compile, and compiling all possible variants of features make a lot of sense. But for modern Uber shaders, which tend to expose a lot of user facing options, this quickly leads to an explosion of variants, and writing complex tools to strip the ones you don't need. But in the majority of cases, we know exactly which options we need because the material's are static in regards to compile time feature sets. We can compile exactly what we need and no more, not mess around with error prone stripping systems, etc, etc.. And it's not the engine variants that are pushing us over these limits, it's the user created variants for artist facing features.

 

This has not been my experience at all- I find that when I add a large number of variants via shader_feature keywords, compile times increase until the compiler crashes. For instance, if you check out the splat map shaders that ship with my free vertex painter, here:

https://github.com/slipster216/VertexPaint/tree/master/Examples/SplatMapping/Shaders

Compiling those shaders takes around 10 minutes if you install them all. Remove the shader_feature's from them, and they compile in seconds.

 

Copying the following files into Unity 2018.471:

SplatBlend_5Layer.shader
SplatBlend_4Layer.shader
SplatBlend_Shared.cginc

1 Minute until the compiling dialog comes up, 2:38 total time..

Comment out all shader_features:

About 1 second.

No materials referencing these in the project, just the shaders. Remove comments from #pragma shader_features, another 2:38 to reimport.

 

And just to double check, I commented out the shader features and defined the largest version of that shader myself:

Code (CSharp):

1. //#pragma shader_feature __ _PARALLAXMAP
2.       //#pragma shader_feature __ _NORMALMAP
3.       //#pragma shader_feature __ _METALLICGLOSSMAP
4.       //#pragma shader_feature __ _EMISSION
5.       // flow map keywords.
6.       //#pragma shader_feature __ _FLOW1 _FLOW2 _FLOW3 _FLOW4
7.       //#pragma shader_feature __ _FLOWDRIFT
8.       //#pragma shader_feature __ _FLOWREFRACTION
9.       //#pragma shader_feature __ _DISTBLEND
10.  
11.       #define _PARALLAXMAP 1
12.       #define _NORMALMAP 1
13.       #define _METALLICGLOSSMAP 1
14.       #define _EMISSION 1
15.       #define _FLOW4 1
16.       #define _FLOWDRIFT 1
17.       #define _FLOWREFRACTION 1
18.       #define _DISTBLEND 1

And this compiles in about a second too.

Now there might be something else going on here, but the exponential increase in compile times when adding shader_feature sure seems like the exponential possible variants being generated.

 

So is the surface shader code generating every variant or something then? Why does it exponentially grow with shader_feature keyword count?

 

Well from my point of view, that is effectively the same then- at least as far as the usability of shader_features is concerned (ie: everything I do will likely be too complex to use them). On the plus side, since y'all have stuck the knife into surface shaders, it's a problem that will eventually go away (Only being replaced by a far, far, bigger one of not having a shader abstraction to prevent constant breakage).

So in theory, then, a single shader could use 256 local keywords and still be fine. (MicroSplat is at about 700 now, so not likely I could change over, but still for most "sane" systems that's a lot of options).

 

I'm a hobbyist developer, but I've been using Unity for 8 years now. I know very little about shaders in general. I usually just download any assets I need from the asset store, and some of my projects have tens to hundreds of 3rd party assets. I had no idea this was even an issue, even though most of my projects constantly got spammed with this error/warning. So I finally looked it up.

That being said, is there a way to let the developer choose the keyword limit themselves -- so that they can choose their own price vs. performance of the keyword limit? Is that even possible?

It sounds like if Unity simply increases it to say 384 keywords (which would be better)....... my projects would still be over that limit the moment the limit is increased. Causing the need for another increase of course. I have no idea how many keywords I would need (or how 3rd party developers design their shaders). Is there a way to tell how many keywords the project has contained within it overall?

I have well over 256 keywords in a lot of my projects, and I constantly get spammed with the error/warning in most, if not all of them.

All of that being said, I would be willing to give up some performance personally, to have shaders work correctly, as long as the performance decrease didn't get too out of hand. But that's just me.

 

You have nop idea how happy I am seeing two experts in their field working to resolve this problem. Much respect.

 

I hope we will get a stable solution for that, i id workarounds to reduce my keywords but right now i cant reduce them anymore and hit into shader issue because the 256 limit is reached. Keep up the good work guys. Thumbs up

 

I'm very happy that this issue finally started to be fixed for a radical solution! Thank you!
Once the problem is solved, I will import all the assets I have bought and make a game!

 

I don't really want to write something like this.
I own more than 400 assets.
It's ridiculous to get this error if you let me buy a lot of assets and import them.
No detailed solutions are needed.
This error should never occur in the first place.

 

@Star-One
What you felt is correct. Everyone writing in this thread encountered the same problem and felt silly. What's more, the problem has been left unattended for several years.
Anyway, the fix has started now and should be resolved in a year at the latest.
You can now start making games with few assets at first. Once the issue is fixed, all assets will be importable.

 

I might do something wrong but using only Amplify, HDRP, and Nature Renderer I hit that limit.. 0 Custom shaders, except a lot of custom ShaderGraphs but I'm not sure they actually create keywords...

I voted for option 3 as it seems to be the most flexible but I feel like 1 should be the right way. Less limit in the editor and if in the build we use too many then it should fail but not while working, we usually only use a subset of shaders. Yes manually deleting shaders or using something like shader control is an option, but prone to error and not very flexible for most.

Thanks for looking into it at least.

Edit: I realize the first post is from 2018, I'll read the thread fully but is this still considered?

Edit2: Thanks @aleksandrk I was going to ask if nowadays the performance hit is still a big issue and if it's not our responsibility to maintain a reasonable number of shader keywords. Seems like it. I would have loved for it to land in 2020.2 but I guess we will see it soon if it's been the focus for months!

 

Please do this.

 

This problem kicking my project's ass at the moment. Ideally, I would write the shaders I use in my project and solve my own problem, but I don't know squat about shaders and I don't really have the time to figure it out. I have been trying to use Kronnect's Shader Control asset, but I can't add any new assets without having to go through the whole process. I hate to think I wasted a whole lot of money on assets I won't be able to use.

 

I'm finding this breaks shader graph in my HDRP product.

For example, in an empty project this effects asset works, but in a project with tons of assets it doesn't.

Does anyone have a real solution here

 

This is unbelievably frustrating to deal with. If there isn't some decent resolution to this soon, I'm dropping my unity subscription.

 

Found this thread. Please FIX it!!

 

Hi Alexksandrk,

Is there an update for this issue?

Thanks!