Feedback Wanted: High Definition Render Pipeline

There's a threshold slider coming soon, which does exactly what you described. If you are using the latest 2020.1 alpha you can get it from Github. Otherwise, the next package released should have it.

 

Yeah, was going to say that the old style bloom breaks energy conservation as bright areas magically get brighter with no additional energy getting in to the system.

Having said that, it's a whole lot easier to tune for prettier pictures than the new one. With this the scattering is basically how much jelly/tears/water is on the camera lens, and relies entirely on the brightness of the pixel to carry further. More correct, since the bright areas are bleeding light to the dark areas, but at the same time, the dark areas are bleeding light to each other.

Only tip I've worked out is to make sure the bright areas are still very bright before they get sent to bloom. that way you can set the scatter value low, but still get bright light to blur a bit.

 

are you using realistic lux and exposure?

 

7.1.7 is available.

I assume 7.2.0 is final version.

 

I think HDRP needs some more public APIs (and docs) related to dynamically creating materials.

The typical code doesn't really work with HDRP:

Code (CSharp):

1. Material mat = new Material(Shader.Find("HDRP/Lit"));
2. mat.SetInt(HDMaterialProperties.kMaterialID, (int)Lit.MaterialFeatureFlags.LitSpecularColor);
3. mat.SetFloat(kSurfaceType, (float)SurfaceType.Transparent);
4. mat.SetFloat(kBlendMode, (float)BlendMode.Additive);
5. mat.SetFloat(kEnableBlendModePreserveSpecularLighting, 0);
6. mat.SetTexture("_BaseColorMap", baseTexture);
7. AssetDatabase.CreateAsset(mat, "Assets/Materials/Test.mat");

While the values do get set and you "see" them in the editor, the material does not actually reflect the settings that are set. i.e. The editor says "Surface Type: Transparent" but the material isn't actually transparent until you manually change settings in the GUI for each material.

I understand this is because there are other internal configurations that get set when you change things in the GUI. However if so we also need an API to set the various settings from editor scripts. From what I can tell all the classes related to this like LitGUI are left as default private classes meaning none of the functions used to re-initialize these internal settings or set things can be called from editor scripts outside the package.

 

Big problem: HDRP detail textures are blending the roughness channel in such a way that it nukes the main texture's smoothness rather than enhancing it. More of an alpha than a multiply. This is probably a bad move, and I'm afraid it may be too late to change but... Yikes! I wondered why my standard pipeline version looked better.



Here you see a rock (no baked global lighting etc, just a plain directional).

Note how the detail channel nukes ALL roughness data from the original texture if the slider is at 100%

Note how nice the desert patina looks if the detail texture is set to 0%

The smoothness channel (G) of the detail texture is centered on 50% since I assumed it'd multiply.

It seems the roughness, if set to 100%, almost entirely overwrites the original roughness.

Note that the final result isn't the 50% roughness of the detail texture, though. More like 0-10%...


So I don't see how you can use the detail texture's roughness at all. It doesn't enhance, it de-hances. Can you think of a situation where you'd want to blank-out roughness? As an artist, I sure cant. If it were to be multiply it'd add noise to the main texture, which would be the desired result rather than what I'm seeing. Whats your take on this?

 

Probably your maps are inverted or your channels are different? I mention it because HDRP doesn't use roughness at all, and that's a nuanced point that's well worth observing... it instead uses smoothness which is 1-rough (invert it).

 

Hi Hippocoder. Maps are not inverted and the channels are set up perfectly. Call it what you want-- Potato potato.

I took the time to post examples of the "roughness/smoothness" maps that I used and you'll see that I'm using them correctly in my image. I'm trying to help Unity make HDRP better, and I honestly cant see what they were thinking. I'm starting to wonder if the "smoothness" channel in the HDRP detail shader is just subtractive? If so, say so somewhere. I took the time to make the post because I'm days from publishing a very large asset with an HDRP option and I want to be sure I'm using it right. You're getting real feedback from a real photogrammetry artist trying to use this much hyped pipeline, so there ya go.

I forgot to add one note though: You have to uncheck the mysterious sRGB flag on the detail texture import settings (in HDRP only) for some reason. If you fiddle with the flag you'll see what I mean-- The detail map becomes far too powerful if you leave sRGB on. Because this little trivia point is well hidden, I doubt many people have ever gotten the detail texture to work at all. I suggest adding some kind of pop-up warning if its set wrong like you do (sometimes) for normal maps.

 

It's not a dig. It's necessary to talk about because many Unity shaders support spec, roughness or smoothness. Obviously they have entirely different results. So covering these, followed by which channels are the first step in debugging. If it's still not giving you the right results, file a bug and Unity should be able to tell you what went wrong.

 

Is it possible to create Spherical fog volume as additional to box volume?

I have bigger box fog volume and a smaller box volume. Edges of box volume can be seen . They are distracting. But Spherical fog volume would fit nicely. Fog would exponentialy fall off from centre toward the sphere so that box volume can't be seen.

 

If you are not scrolling the fog you can use a 3D texture to define the shape of the fog inside the volume.

 

How to make 3D texture ?

 

You can find a tool in HDRP for it. Read the docs

 

Well we got our bloom threshhold value! I just tried it in HDRP 7.1.7 The threshhold goes from 0-100 but anything above .99 has zero effect, which is kinda not what I'd expect but that being said...

Its still just as confounding as it was before no matter what slider I put in what position, and thats regardless whether I use 100,000 lux or 10 lux. Could you guys link me to a video of you setting it up to actually look good and do something other than fuz-blur-out the whole screen? I want to see glare coming from a sunset backlighting something. I want to see big fat glints from shiny parts on a machine. I cant get anything from bloom even after the threshhold was added. Have the guys that make all your show-off cut-scenes like Heretic and Book of the Dead show us how its done. They're really smart and have access to engine coders so it'd be a nice blog post or something.

At the very least have a working bloom for the final 2019 version of Unity. And just so the coding team knows, 99% of artists would prefer awesome glints and glare than worrying about photon energy conservation. HDRP shaders are really brilliant and I have to say I'm always surprised how well thought out some of them are, and how 'usability' is built in as if the coders were also artists. Lets just say for this one issue, its time to go back to the drawing board

 

The streaky one from The Heretic should be keijiro s one.
https://github.com/keijiro/Kino

You can take it and do additional rotations towards star crosses but it doesn t solve this unexpected behaviour from the bloom overall.

Here my question and an answer from unity about the bloom and dof behaviour from PPV3.
I also wished these got a little more love.

https://forum.unity.com/threads/pho...nto-digital-assets.521946/page-2#post-5230607

See also post before and after.
They choosed an non additive bloom behaviour.

 

"The bloom in HDRP is not additive, it is somewhat like blending with a blurred version version of the image in HDR. Bright values will naturally produce more noticeable glow but dark tones will be modified as well. The way it softens the image is very useful for unifying the tones and it's also great for getting a lot of subtle gradients in the values so that you can increase the contrast afterwards while still keeping details everywhere (not clipping)."

Ok but thats not really bloom as we know it. Call it something like 'image softening' and I'd understand that. I'm usually fighting to increase detail rather than removing it.

 

Think the same. It could be moved to an soft clip override.
https://noamkroll.com/why-soft-clip...inematic-look-how-to-easily-apply-it-in-post/


In BuiltIn RP PPV2 i use these changes
Quick fix for MUCH BETTER BLOOM
https://github.com/Unity-Technologies/PostProcessing/issues/787

Sampling.hlsl
(Changes are in lines 17, 60 and 82 )

but the PPV3 implementation has some other theory behind.
Would be nice to get some tips and advice from the PPV3 programmer.

 

Hi all,

So I recently just upgraded to 2019.3 from 2019.2, and was a bit disappointed to find that a bunch of former public classes previously under the .experimental namespace) have become internal. I'm specifically talking about UI classes. Now I've looked up the change on the github and it might be from a while back, but since it's just made it to the public release, I'm just now seeing it.

We have a bunch of custom shaders in our project, and created them using the

MaterialUIBlock

system so that we could keep aesthetic properties similar to the rest of HDRP's materials. All of our UI classes inherit from the

MaterialUIBlock

, and in order to keep parity with the rest of Unity, we use the

SurfaceOptionUIBlock

so that our shaders can get a lot of the goodness that was exposed to us.

All of those classes and any of the previous MaterialUIBlocks have all gone internal, because of a change on the github done sometime in June of last year (https://github.com/Unity-Technologies/ScriptableRenderPipeline/pull/4013).

What I think is funny is how the code still has a giant comment in it explaining how they wrote it this way so that users like me could subclass this to create aesthetically similar UI. (See

MaterialUIBlockList.cs

)

Code (CSharp):

1.     // A Material can be authored from the shader graph or by hand. When written by hand we need to provide an inspector.
2.     // Such a Material will share some properties between it various variant (shader graph variant or hand authored variant).
3.     // To create a such GUI, we provide Material UI Blocks, a modular API to create custom Material UI that allow
4.     // you to reuse HDRP pre-defined blocks and access support header toggles automatically.
5.     // Examples of such material UIs can be found in the classes UnlitGUI, LitGUI or LayeredLitGUI.
6.  

At this point, I could literally go ahead and copy a bunch of the HDRP code into my own project (

MaterialUIBlockList, MaterialUIBlock, MaterialEditorExtensions

), and use reflection in my UI in order to invoke the

SurfaceOptionUIBlock

, but that seems absolutely horrible. What's the point of creating a really beautiful modular UI system meant for users to subclass, and then marking it all as internal, thus removing the entire point of its existence?

 

EDIT: After some consideration, it seems we need the ability to make our own custom master nodes.

We desperately need a way to do custom lighting setups in HDRP (such as with Custom Master Nodes). The old Forward pipeline gave us the ability to get the position, color and attenuation for all the lights. This is great for toon shaders and other lighting implementations to thrive. Is this possible in HDRP without modifying the pipeline?

This all seems to be fairly easily possible in LWRP/URP.

The crucial part is that this should be possible out of the box, i.e. we should not need to alter the pipeline or add C# scripts to our lights. Look at games driven by user content like VRChat, they would not work in HDRP without some serious modifications, because user content would not be able to change the pipeline. Currently they use the Forward renderer, which means any shader that supports Forward rendering will work.

I'm also not a fan of nodes being mandatory (I used to manually code shaders and still prefer it that way), but that's a story for another time.

Finally, for toon shaders it is very useful to be able to render a second pass for the outlines (with the vertices extended outwards from their normal a little). This does not seem to be possible in HDRP either.

As for geometry shaders, are those still possible? I think that without manual coding support for stuff like extra passes and geometry/tessellation, HDRP is simply not viable for many non-standard use cases.

 

There is a custom pass api for that.

 

Which brings me back to the first problem, which is user content and the fact that this requires C# scripting. It's not always great to have the pipeline, scripts and shaders so tightly coupled together, especially when the old pipelines and the 2018.3 custom master node "hacks" have shown that it might not be always necessary.

 

One way a lot of these headaches could be alleviated is by allowing us to make our own "Master Nodes". In 2019.1 this API was made internal, however. Are there any plans to reverse this decision? If it is already possible, is there any documentation on where or how to do so?

This has already been requested a few times before, and I heavily stand behind this request.

There are many projects which would ideally want HDRP but still want to keep their own stylized or toon shading, in which case a custom master node would be the ideal solution. Sadly this no longer seems to be possible, which means I cannot switch to HDRP yet.

 

Please IES lights support in SRP.

 

Well I already do this just fine via the emission port. Is there something preventing you?

 

That's like saying "why don't you rewrite the entire lighting algorithms in shader graph and then pass it to the emission port?"...

 

What does LatestGreen mean for SRP and when is available ?

 

That is an extremely hacky workaround for a problem that does not need to exist.

Getting the actual light data reliably inside a shadergraph shader is not a well-documented or even supported process. Even doing it "correctly" in a custom function node seems to cause mysterious compile errors. Abusing the emission port or the unlit node is by no means pleasant, at that rate I would rather write the entire shader by hand without touching Shadergraph at all.

Then there's also the energy conservation going on in the HDRP Lit shader, meaning that even using the emission port with everything else black gives imperfect results.

Let's be real here, it seems that master nodes are the new "shaders", and not supporting custom master nodes basically means that HDRP does not support custom shaders. A nodegraph is more like making a variation or remapping inputs on an existing shader, not necessarily a new shader in itself.

Shadergraph is ideal for adding variations to existing shaders, like resolving all the different ways in which programs handle metallics and specular. Being able to fine-tune the input parameters or make small variations on an existing shader in a node system is great. I think custom master nodes are the way to go here, allowing us to not only leverage the full power of Shadergraph, but also allowing us to have better control over custom shading.

 

This is the problem here. HDRP is physically based so all the shaders, lighting, and post processing are made to be in unified lighting/material system. With that said there's no way to have custom shading for HDRP that's not physically accurate unless you want to rewrite the rendering pipeline.

So if the renderer is physically based and it already comes with physically based shaders, the only thing you would want to do is extend them to add missing functionality if necessary.

For custom shading, URP would be a better fit to do something like this.
In general most if not all of us would like the ability to be able to make custom master nodes for Shader Graph. This would make things easier for those who want to customize URP or create their own render pipeline. It's beneficial to HDRP as well but would be limited to HDRPs physically based confines as all the systems are deeply integrated with each other (Unified lighting/material system)

 

There are more benefits to be had in HDRP than just being physically accurate. There are many use cases where you want HDRP, but still want stylized/toon shading, or shading that may not be completely "physically accurate". Especially now that games driven on user-content are becoming more popular, you will most likely start to see mixes between physically accurate characters and toony characters in the same scene.

It seems like both Shadergraph and HDRP are going completely the wrong way. We need more power and more customizability, not less.

In addition, there are also many cases where you want physically accurate shading, but also want geometry shading or tessellation. It seems like Shadergraph currently does not allow for this. It feels like two steps back.

 

Lighting physical accuracy does not mean realism.

Disney movies are physically accurate and stylized.



Games like Luigi Mansion 3 are totally replicable in HDRP:



Additionnaly, there are ways to customize both HDRP and URP, thanks to them being fully open sourced. Just look at this toon shading plugin from togycchi on GitHub

 

People need to seriously look at emission port. both those screens are 100% achievable without modification in shadergraph today on URP and HDRP.

 

That's what Pixar, Dreamworks, and all those other animation companies already do this with Physically Accurate Path Tracers. You can't get more physically accurate than that. The stylized look is because of how things were, modeled, textured, lit, and Post-processing. Not because the shading was changed to something that wasn't physically accurate.

With that said you can see those movies still kind of all look similar because at the end of the day you have to stay in the PBR confines. Into the Spider-Verse is still using PBR but they added spent some time developing their look and post pipeline (2D Drawing layered on top) for the film to get the desired look. For anything really custom you would need to use an NPR renderer.

 

It's not just about lighting, it's also about a lot of other things. Geometry shading, more complex vertex shading, extra passes, stencils are all pretty much not possible within the current system.

Hell, the very existence of the separate "Hair" node in HDRP proves that you cannot necessarily capture every look using just the provided master nodes. Otherwise, they wouldn't have bothered to make the Hair master node, they would have just used the Lit node, right?

Is hair somehow physically inaccurate? Of course not, but Unity still felt that it had to be a separate shader anyway. Its existence and its separation of the Lit node proves that even if your goal is physical accuracy, there might be many more needs that HDRP currently does not cover.

That's also a bit of an issue, we are required to modify the entire rendering pipeline and build our pipeline around our shaders and vice-versa. This makes it a lot harder to share shaders or buy/sell them on the asset store, for instance. In the current Forward pipeline, you can simply buy a shader and expect it to work pretty consistently. Now I'm locked into one particular pipeline adjustment.

Those screenshots you posted are also very specific examples that are just a bit too convenient (since one of Standard's lighting models is literally based on the "Disney Diffuse"). What about something like, say, Xenoblade Chronicles 2, or the Dragonball Z games? Cel shading that still reacts dynamically to the lighting? The classic sharper "toon ramping" method is currently not possible without modifying the pipeline, seeing as HDRP and shadergraph do not give you any lighting info by default.

That Github example you linked doesn't support multiple directional lights or point/spot lights, nor does it support full shadows. Probably because it is just a vector property set globally. Add some point/spot lights into the mix, and now I'm suddenly also required to re-implement almost all the light culling, batching and rendering code myself, just for a simple ramped toon shader. That's one step forward and two steps back. A lot of grievances with the pipeline could be fixed by just making a single class not internal.

Sure you could say "Use URP", but that's not really an answer.

That's kind of the point I was making. HDRP does not truly allow for custom shaders out of the box, you have to do the things you want to do with just the provided Lit and Hair shaders and after-effects.

Like I said earlier, Unity felt that Hair was a special enough case to warrant its own master node. I'm sure there are more physically accurate use cases possible than "hair" and "not hair".

 

This is already possible with the Custom Passes feature. Recently support for custom stencil buffers was added to it. There's another feature coming called Compositor which further allows additional post-processing of a frame.
https://github.com/Unity-Technologi...-definition/Documentation~/Compositor-Main.md

It was never stated to use just one node as an Uber shader. All that's been mentioned is that all the default nodes and shaders are physically based.

Yea, but it doesn't mean those break PBR they are just specialized to do a certain task that the general Lit shader won't do best. In HDRP there are Master nodes for a lot of shader/material types that give a specialized lighting response to mimic their real life counterpart

- Water (Soon)

So you either want to extend in the confines of PBR as these shaders do or to do custom shading/rendering as you are asking for which isn't PBR so you'd need to do a lot more work to get that going with a renderer like HDRP.

Currently, since shader graph doesn't support custom Master nodes as you know, even writing another type of PBR shader for HDRP is somewhat of a mission. Even if shader graph supported custom master nodes, creating stylized custom shading for HDRP without modifying the pipeline would still limit you to PBR only. As you saw with the GitHub sample above where not all the features will work properly when you try to do something stylized like toon shading.

For URP this is quite easy as there's a lot less to go through and it functions more like the Built-in renderer even modifying it is simpler. A lot less complex and you still have the ability to add what you want to the renderer (Deferred URP render coming soon as well).

What made you want to use HDRP over URP?

 

@HugoZink, If you can't summarize your ideas don't expect people to do that for you in order to help. Also:

• Read about HDRP custom passes
• Check how people wrote shaders before the existence of Shader Graph in Unity (which is fairly new)
• Notice that HDRP, URP and built-in pipelines are all being actively supported, so there really isn't anything that you cannot do at the moment, including Dragon Ball and Xenoblade-like visuals, all without touching the source of a render pipeline

 

This is the main purpose of SRP isn't? not HDRP or URP, but SRP

 

Is v9 getting backport in 2019.3 and 2019.4LTS ?
https://github.com/Unity-Technologies/ScriptableRenderPipeline/releases/tag/v9.0.0-preview.0

 

Can we get raytracing support for Nvidias 20xx Super GPU lineup? (Includes the 2060 Super, 2070 Super and 2080 Super)
Have been wanting to check out raytracing in Unity, but it complains that my 2070 Super doesn't support Raytracing.

 

Doesn't seem like something that would happen as I've been using raytracing on my 1080 in Unity.

 

2019.3.6f1 HDRP 7.2.1 - all did work great

Same project just updated to HDRP 7.3.1
- sky does not work and getting console errors even after restarting editor, and reimporting HDRP multiple times !

 

They have a set list of what graphics cards works with raytracing and which don't and 20xx Super cards are not on that list. The Super variants are beefed up versions of the 2060, 2070 and 2080 and yet they aren't marked as capable of raytracing

 

All 20 series cards support Raytracing

 

Issue found, we get this error due to removing the Default Volume Profile... now it's fine !

 

Hi,
I just lost about 20 fps by upgrading 7.1.8 to 7.2.0 (also tested with the newer versions: not better) (Unity 2019.3.6f)



I'm currently just rendering one big mesh with Graphics.DrawProceduralIndirect() (and a simple sphere).

Would be great if the next version will have the same performance as 7.1.8 has! Maybe some settings are different, but I actually just replaced the HDRP packages and didn't touch anything else.

The custom mesh has a custom Lit shader, however they both work and have not much difference to a normal Lit shader, only a custom vertex function was added, like in the "NoiseBall4 github" project.

Cheers,
Chris

Btw. I get the same performance loss, when I test the different HDRP 7.x versions with the NoiseBall4 project, so I think it does not depend on my project settings.
https://github.com/keijiro/NoiseBall4

(I currently didn't test it with Unity 2020 HDRP 8.x versions because of some bugs with Unity 2020 affecting my project.)

 

Yes, that's why i want them to whitelist the 20 series Super variants so i can actually utilise raytracing
Update: It now works. Not sure if it was upgrading from 7.1.8 to 7.3.1 or it hadn't changed it to use DirectX 12, but it works

 

Feature request from my side: Light functions would be a neat addition to the light component. Having shadergraph in HDRP makes things a lot easier - and with a light function master node, it would be even more useful!

 

You can use CustomRenderTexture for that.

 

In what way would be used, as input to the graph for example ?

 

As input in the graph you can treat it as a standard texture input

 

Which Unity version does use SRP 10?
https://github.com/Unity-Technologi...render-pipelines.high-definition/CHANGELOG.md