Design issues with the HDRP Post-Processing Stack

Hi All,

I have started this thread to formalize the core design issues at the heart of the HDRP postprocessing 'stack' if you want to call it that.

While I think the stack produces nice effects (finally) this has little to do with the design of it, and more to do with the nice compute shaders that whoever at Unity has written. As we know, as developers, there is no catch-all solution for any aspect of an engine, and every game will always require some custom effects, which has traditionally been where Asset Store authors have helped users save time (as David Helgasson once said).

The issue now is that Unity's HDRP PostPro stack has been designed in such an overly complex way, it makes it incredibly hard to know what is going on at any point in development or runtime. This leads to increased time to develop, higher risk of bugs, and at the end of the day, makes it no longer commercially viable for Asset Store developers to create and maintain effects that save regular devs thousands of hours.

I write this thread hoping to spark change in that.

Shader Bloat & Complexity
This is a template for the most barebones postprocessing shader, given as an example by Unity:

This alone includes:

• Common.hlsl: 1272 LoC
• Color.hlsl: 725 LoC
  • +Includes: ACES.hlsl: 1315 LoC
• ShaderVariables.hlsl: 388 LoC
  • +Includes Version.hlsl: 7 LoC
  • +Includes ShaderConfig.cs.hlsl: 36 LoC
  • +Includes TextureXR.hlsl: 129 LoC
  • +Includes ShaderVariablesGlobal.hlsl: 23 LoC
    • +Includes ShaderVariablesGlobal.cs.hlsl: 148 LoC
• FXAA.hlsl: 88 LoC
• RTUpscale.hlsl: 141 LoC
  • +Includes BuiltInData.hlsl: 108 LoC
    • +Includes Debug.hlsl: 279 LoC
    • +Includes: BuiltinData.cs.hlsl: 113 LoC
  • +Includes Filtering.hlsl: 146 LoC
  • +Includes PostProcessDefines.hlsl: 12 LoC

Compare this to what was traditionally required for a legacy post-processing shader:

• UnityCG.cginc: 1212 LoC

That totals to nearly 5000 LoC across 16 files with HDRP vs 1200 with legacy in one file. Given HDRP changes every other month, there is simply no way that any single developer (as is usually the case, even in small studios often only one person touches post-processing) can maintain a full understanding of how the most basic post-processing shader works.

---

Design Quirks

This is the interface for all PostProcessing components. It's a fairly useless layer of complexity, that serves only to complicate the actual implementation of finding out whether a post-process volume/effect is active or not.

There's also the 'active' boolean - you would probably think that if either the Post-Process volume monobehaviour was disabled, or the actual PostFX script that this is implemented in gets disabled within the volume, active would probably return "False", right?

Wrong. It always returns true in both of the above scenarios.

---

Lack of easily searchable documentation

Prior to Unity's decision to split its renderer into a mix of 3 beta/deprecated piplines, finding any documentation on Post-Processing was quite simple. Now, anything you google you have to translate, and ask the following questions:

• What version of Unity is this related to?
• What render pipeline is this related to?
• What version of that render pipeline is this related to?

And 9 times out of ten, the above isn't documented. Yes, there does exist a page or two where Unity, in an extremely high level overview, gives you an example on how to get a post-process shader 'working'. Try delving any deeper than "how do I blit these two textures" with HDRP and you are stuck up the creek without a paddle.

--

This is honestly the tip of the iceberg, but what I think are the most important issues to solve with HDRP. Documentation can be fixed by keeping the pipeline stable with no changes - so knowledge that accumulates across blog posts, forum threads, and public github repos actually stays relevant. The bloat and complexity... That's up to Unity.

 

Adding another gem from today - would someone from Unity be able to explain how hiding a very specific class 3,000 LoC deep within the monolithic PostProcessing .cs file "keeps the code readable"?



It's classes like this that should be accessible by default and provided by the engine. There is no post-processing developer I know that wouldn't use a pre-written render target pooling class like this, but instead we have to delve in, rip it out, and maintain our own variant?

 

Hi,

I'm working on my third project now with HDRP. I think you're right. It's extremly complicated to do custom effects with the new SRP. It's way too undocumented, bloated and complex, so that a studio needs a studied Master of Computer Graphics with a lot of time to find things out in order to achieve custom stuff. I know some stuff about shaders, but mostly I'm working with a node based system. But Unity's HDRP code is just black box that I'm afraid I will never be able to understand. I rely heavily on very talented asset store creator that go through the pain and making their assets compatible with both branches of URP and HDRP, doing the hardcoded stuff for every new SRP version. You already can see the messy situation on the Unity Asset Store. For certain advanced terrain and water system, you now forced to buy a second "license" in order to get URP or HDRP support.