Discussion Gave this render pipeline a solid go, here's some fast feedback.

I've seen good, bad and ugly from Unity, Max, Maya, Unreal, to Houdini. Give me graphical bells and whistles and I'm a kid in a candy. I migrated my Unity project to HDRP last night, it was not a pleasant experience. I would go so far as to say a big warning should be added to this package and users should be warned not to migrate existing projects.

Everything is a scattered mess: I began to wonder if internally the tools are being tracked for core things like where scene lighting is adjusted, where post processing is generated. Is it on the camera? Or is it on volumes? Or is it in one of the several HDRP property assets I just created? Or maybe it's in the player settings that's where important things go right? NOPE! It was under build options. It's a total mess. 5 hours of fiddling with things at a rapid pace, and I do not once remember finding the settings for the lighting in the scene.

This notion of creating new assets, and having them be something you can throw anywhere, then drop in on various volumes is incredibly counter intuitive. You guys need to lock in your pipeline, there is absolutely no reason the user should be having to add and remove key features across such a haphazard system.

Same goes for shaders and materials. Every single material I was having to tell to be transparent or opaque MULTIPLE TIMES all over, and dealing with massive headaches with graphical glitches from the get go. Again, it feels far too open ended, we need some level of structure, having to tell individual materials whether they are opaque or transparent, as well as setting these up within the shader feels like madness, a if this pipeline doesn't know what it wants to do, and wants to give the user as many possible chances for user error as possible.

Over the years various settings are now all over the place, and these settings have MASSIVE ramifications for how a scene will perform and look. You can't make progress on a system that has no form, and doesn't know what it wants to be. As it stands everything is far too open for customization.

Lighting: Mostly a scattered mess, but also felt incredibly buggy. I did not have a complex lighting setup in my scene. 1 directional light and a few point lights. I could not for the life of me after 4 hours of working with this system figure out how to get these lights to update or work at all. Only the core directional light. Beyond this, at no point did I feel I was able to have any level of control over fog, shadows, point lights, scene lights, etc. I want to stress that I am no stranger to working with complex systems in various graphical environments. After 5 hours of attempting to utilize this system, I am more confused by how to use the HDRP than when I started. I never had an "ah hah" moment, nothing ever became more clear after fiddling with things, nothing came together, and I still have no idea how to do anything in HDRP because of how scattered and unrealized base setups are when you transition to these tool.

Emmision: A massive swath of my systems just straight broke in shaders. There are a lot of little tricks and smoke and mirrors i've pulled using fresnels and emissions and any game that isn't going for hyper real and has some fancy effects becomes totally impossible to generate in this pipeline. As it stands even if the above issues are sorted, and this pipeline becomes usable and easy to light, and generate shaders and materials for, I would still likely pass on this, because the new "bells and whistles" of this pipeline are far to restrictive in shaders, in that it stiff arms you out of using the powerful and easy to use emmsive properties of the prior shader systems. Maybe there's a setting burried in shader graph to use legacy emmisive settings, I didn't find it.

No direction:
I'll just come out and say it. Open Unreal and look at how they have set up their graphical settings. 1 place, it doesn what you need it to do. There is no reason to make setting up fog, post process color grading, shadows, scene lighting, etc. some kind of customizable thing. It needs to reside in one area within the engine. Now that my project is back to the URP, I can easily open the lighting panel and see some core settings here:


You guys need to pick one place to plop all these settings, and get rid of the madness of generating alternative setting objects and plugging them in. Switching to HDRP should be a toggle in the core graphics panel in the engine, and it should auto generate key panels for fog, scene lighting, and post processing. AND MOST IMPORTANTLY they need to work!

Trying to keep this constructive, but my experience with HDRP was not impressive, it was a bit of a nightmare. It's a scattered mess, core functionality feels missing, there seems to be no plan moving forward, and everything is coming together with no coherent vision for how graphics in this pipeline should reside.

It's not JUST that things weren't working, it was clear from my experience last night that they never will work, because it doesn't seem you guys have a vision for what a high definition pipeline is, you have no checklist of key features to guide you step by step to realizing this thing. It feels like you guys are just adding one lofty thing at a time and if prior, core features break or aren't realized, you just move on and year after year this pipeline has fallen apart.

I couldn't believe it when the Brackey's video (better days with Unity then) I was watching on how to set this system up showed that it was uploaded some 5 years ago... 5 years later and this system is completely discombobulated with no idea what it wants to be or how to be.

I get this is Unity, the "identity" of Unity is that you can piece things together however you see fit. I think I can see the allure for you guys to create this open ended system so internal team members could work on specific features independently so they could all come together at some time in the future. But when are any of these independent features going to work? I have so many questions about how things became the way they are now, why nothing is working, why there is no processes for setting anything up. It's a symphony is disfunction and it feels like with so much failure happening across the board, no one is being held accountable to get anything actually working.

You guys need to figure out the basic feature list: Anti Aliasing, linear/ gamma, scene lighting, fog, post processing, etc. Put these all in one prominent place in the engine, and get them working out of the box. Don't require the user to go through a laundry list of features and add them wherever they want on these bizarre scene volumes.

There is absolutely no need for things like weights on volumes, and multiple setting assets. Just make it easy to adjust these values in code, you can then make plugins that modify these key values that are tangible and reside in one place.

I hope this post is clear, the current trajectory of this pipeline is madness. I know this post is aggressive, and to the point, it has not been a good week for me working in Unity, so apologies you are bearing the brunt of days worth of frustrations.

I'll end with some good: There's a lot of promise here, the motion blur, the lighting when you disable scene lighting looked really nice with the light orangish look (never figured out how to emulate that with my own lighting).

This is doable, but you guys gotta start with a major first step towards sanity. You need to decide you're going to end the madness, ditch all the weird project objects regarding setups, and just lock these core visual properties in one singular place in the editor and decide on a core feature list that you're going to get performant and usable out of the box that "JUST WORKS". Start with scene lighting, move on to other core things like ambient occlusion and fog. Stop making these things you need to find in some corner of a script or setting, and feature them prominently in one place, the user can enable or disable them, but they cannot remove them.

This isn't rocket science, other engines have implemented these things perfectly already, you have all the tools, just arrange them as they did, and get to work fixing usability and conflicts once things are locked in place.

 

Some of the things you mention are a little baffling to me, like which post-processing and scene lighting settings you found in the "build options"? And the thing about the materials being adjust "multiple times" - I just can't relate, or probably have misunderstood what you mean. You also mention lights not working (apart from the main directional light) - not working in what way?

So it seems like you are experiencing a state of temporary confusion when first jumping into HDRP. I remember that feeling when I first started experimenting with HDRP several years ago. Last night, when I jumped into Diablo IV for the first time, I was basically confused and disoriented for a few hours, just struggling to figure out how everything is supposed to work... does that mean the Diablo IV designers did a bad job? No. I just needed to spend a bit of time and it all fell into place.

I would also specifically like to challenge your perception that things are scattered and overly confusing. For example, in classic Unity, you would have to jump between the Lighting tab (which had extremely limited options) and a separate Post Process volume, for example. Now I simply go to my Volume and adjust the overrides as required. It feels far more organized than it used to back in the day.

The customizability and programmability of HDRP is an order of magnitude better than the built-in pipeline, and I think the HDRP team did a great job of somehow organising all this power and customizability into the volume framework.

There is also the element of "migrating" your project to HDRP. I don't know the approach you took, but there is a very strong possibility that some things are set up incorrectly post migration.

The advice I will give you is:
1. Start with your HDRP settings asset, learn what all those options mean, and enable and disable the features appropriate for your project.
2. Always remember to enable or disable the matching settings in your default frame settings or in the frame settings override of your camera. The frame settings determine exactly the features you want on/off for your camera rendering, vs. let's say reflection probe rendering, and so on.
3. Add overrides to your Volume(s) and don't forget crucial steps like adjusting your exposure to match your general light levels. You just have to learn what all the volume overrides are for - but at least it is all in once place, which is nice.

 

It was a bit of a made up scenario to illustrate the volume of places settingns can be found using build options as one example, so not a tangible example of where to find lighting settings, I never actually found them.

In the surface options rollout there were options to set a material to opaque/ transparent outside of the shader graph editor, maybe there's a way to hide these settings, but I didn't find it in my short try with these setups:


After migrating to HDRP and using the wizard it said my project was good to go, but various things weren't working like point lights in my scene, no matter what I tried.

If I could start from scratch in a new project, I'm sure I could figure these bells and whistles and enjoy a quality looking project and day after day nudge my graphical look in the right direction.

I appreciate the insights from you guys, but using templates sounds like ANOTHER system that could break or cause a user error.

Maybe my project just has a weird edge case bug, I dunno. The issues with settings being overly scattered and not well incorporated into the engine remains.

What I don't understand is why this system is built this way. Why are additional settings objects generated within the project, why aren't these auto generated and internal, easy to find and adjust? Why aren't they featured prominently in one place like the lighting panel? Why don't they "just work" out of the box?

Perhaps I missed a setting somewhere that gives inherent scene lighting that needed to go in the render settings object or something, I'm thinking it's maybe an override somewhere. I don't know, the entire system is wishy washy, scattered, and prone to user error. I could watch an hour long video, maybe that would solve some issues as I slowly piece together these setups. But after my experience last night trying to transition a fairly large project over I just see too many other problems for my project's needs even if I get these things sorted with inherent shader issues that would require revamping of a great deal of shaders.

 

Yes this makes sense. But can't you have it both ways? Have an internal value list of core properties like fog, color grading, depth of field, etc, have it all easily edited and in one place like unreal does it... Then have various tools that would set these values based on player position/ triggers, etc? I'm not understanding how having these settings scattered across project objects and having the user have to find and enable each and every element of the pipeline makes it better.

You guys put the cart before the horse a bit with the way this system functions for us users. I'm sure internally you all have intimate knowledge with each element and have designed these systems to exist as individual properties, but for the vast majority of us users, we are used to first tuning these core settings in one easily found place, and if we ever need to create transitionary setups for lighting or whatever, we explore those later.

I think I understand what you're saying about in-scene transitions, how only adjusting what you want changed per trigger is useful... but tying the core functionality of the HDRP to this "a la carte" style of pick what you want out of nothing feels weird for core systems you would want 99% of the time like scene lighting. A few very core graphical settings should be automatically generated and locked in at one easy to find place. Scene lighting, shadows, fog, etc. This is how it works for URP and most Realtime graphic toolsets.

The entire workflow seems to be centered around the concept of scene triggers that transition settings rather than a quality set of graphical systems with a sane home in the Unity UI that works out of the box which is bizarre. There should be one internal list that's auto generated, that isn't prone to user error or poor setups that simply houses your core lighting settings, shadows, anti aliasing, etc. and then you could have these dynamic lists that override those values in real time depending on scene triggers, unique scene values, whatever.

The dynamic shader settings confuse me because I've never created a shader and thought, this could be either transparent or opaque, because the considerations for both are so different. Just seemed odd to my personal workflow. It would be nice if we could hide these settings to avoid user error. Currently if I make a shader that's designed to be transparent, I need to go into every material generated by this system and set it to be transparent.
Just my 2 cents after wrestling with this for some time.

 

I'm confused - I think it is trying to be the opposite of scattered - imagine a Volume that you set up, and this volume is your base global volume. We indeed have such a thing in our game, and in this volume we set the sky, tone mapping, bloom, shadow settings, ssao, ssr, fog settings, volumetric cloud settings, exposure, indirect lighting settings and color adjustments - ALL IN ONE PLACE

Then, we have 4 additional global Volumes - one for Day, one for Night, one for Dusk and one for Dawn - in here, we just add a bare minimum of overrides in the volumes - for example changing the sky settings (different gradients).

Now, we can simply blend the volumes via script and easily create environments for different time of day - it works amazingly well and in a simple way where all our settings live in a set of Volumes.

Well, let's take the standard HDRP/Lit shader. Imagine if HDRP team had to maintain a copy-and-paste version of the shader for Opaque vs. Tranparent, or Alpha clipping On/Off, or Material Type. The ability to have one shader, and then produce 10 different useful materials from it, means the DRY principle is easy to maintain. Add to that, Material Variants, and the DRY principle is even easier to maintain because you can keep all your material settings, and just tweak the bare minimum that you need in a variant.

Because you have to have your core settings in one place somewhere, and a global volume is as good a place as any. If the core settings were in some other format in some other place, then it would be more confusing to add overrides to volumes because you would need to learn the "core settings" and the "volume settings". The way it is set up, you just need to learn the volume settings.

Anyway, I'm definitely not trying to argue or overly defend Unity, lord knows I'm dealing with some serious problems myself, as you can see in my various posts on this forum - but the one thing that I think they got super right, is the volume framework.

 

I think I'm beginning to understand how this all works, but I disagree with this statement. It's counter intuitive for users who didn't feel out the render pipeline or watch tutorial videos. There's no reason there can't be a panel within Unity when HDRP is enabled, like in most every existing Realtime graphics engine where you go to set your core settings for lighting, shadows and various other core graphics settings in the engine. This panel serves as a sort of "home base" where the user learns "Oh, these are the things this engine can do, these are the bells and whistles I can adjust" having all these settings scatteres across so many different places, and forcing the user to have to enable core systems is a HUGE pitfall for users new to the system, especially those attempting to transition an existing project.

A nice middle ground might be some option to auto generate these core settings, but maybe that's what the template does, I dunno. I didn't see a template option anywhere when working with this system.

Sure I could watch tutorial videos and sort this stuff out over hours and hours... or the absolute core graphics system of this engine could just work "out of the box", that would be nice.

My dream as someone migrating to HDRP would have been to have the first and global render asset be generated automatically and not exist in the project hierarchy, but listed internally. It would have the core setups for lighting, shadows and post processing stuck to it, and below that collapsible panel would be various settings in one rollout migrated from other panels like "linear/ gamma" color space. Everything existing in one spot under scene lighting or some facsimile. The primary scene dictionary light could be easily adjusted here for example. The sky settings, the fog, one central hub panel.

Maybe I'm just grumpy things didn't work for me, maybe if i'd started years back with this current system and built it from the ground up in the HDRP I would think this is nitpicking. I dunno, this is my kneejerk reaction, but maybe it's more "jerk" than knee!

Again these are just my 2 cents, invested a good bit of time trying to adopt this pipeline and it just didn't work for me, there's the feedback from my personal perspective having experience in many other graphical packages.

Quick aside: Same issue on a much smaller scale with the global post process volume setups for cameras in URP. Same cart before the horse situation. How many users have tried to get some nice post process effects on their cameras only to be hit in the face with this global volume stuff? Same problem here. You guys saw value in having transitionary systems, but frontloaded them and the system breaks and wont work at all until you start creating settings objects and start dealing with volume weights and stuff. These should be settings the user decides if they want to wrangle with and not the default settings. The user should simply be able to add post process effects to a camera without added headache of scene objects and volumes, weights, triggers etc.

 

I like the design of SRP Volume system. We can control where the effect should be applied and adjust settings at the same time. It's also extendable so that we can control our own effects using Volume. It'd be impossible if applying post-processing to cameras.

I think the HDRP (and the coming URP) sample scene(s) is a good starting point for new users to get familiar with the features of a pipeline.

I agree that the settings in HDRP is quite messy because there're several ways to enable/disable a feature. I understand that some of them are designed for shader variant stripping and different game quality, but it'd be nice to add more warnings (SSGI already did this) when users mistakenly disabled a feature which causes something won't work.

 

I might be entirely mistaken, but I remember a thread from a few years ago where the default volume did not apply as expected, and I think it had to do with switching the volume layer on the camera - so if you use a specific layer for your visual volumes, then the default volume profile stopped applying, which then required you to set up your own global volume in the scene anyway. I didn't test this recently at all, so I might be dropping bad info, but this is something to double check if you decide to rely on the default values.