Feedback Wanted: High Definition Render Pipeline

This is a forum for feedback on the HDRP.
What it demonstrates is that in the same scenes that come with it with all the effects turned off so things are all the same, LWRP and Standard get average 300 fps on that scene while HDRP gets 40. So what is using all that extra power if whats visible is all the same?

 

think of it like this.

Imagine you are comparing a ferrari and a hyundai i10.
the first is a sports car and the second is a entry level hatchback.

Now, to compare them, you test drive it, but limit the speed to 30 miles an hour.

then you are saying. "Not much difference, in fact, I think i10 performs better."

if you really want to compare, then put on HDRP's core features on the standard as well (alternative 3rd party assets), and then scale the scene content to a reasonable size, then compare.

I am not saying HDRP is better, I am just saying your way of comparing the two provides no meaningful results other than the fact that HDRP requires higher hardware specs.

Hope this helps

 

I'm pretty sure I've seen other people (I won't say names in case I understood wrong) explain that HDRP is doing a lot more upfront so it scales better, which would be where that extra power is getting used even though you aren't seeing the benefits of it in that scene. Which is why I was mentioning that using the initial scene which clearly isn't pushing Standard very much is probably not the best way to test this, if you're actually trying to find which one will be more perforant for a high visual fidelity game.

I'm assuming I could write a simple engine that would blit 1 image across the screen and make it perform better than HDRP ... but that doesn't mean HDRP isn't better for bigger, modern games ... it just means it probably isn't the right pick for something that simple, and it should be pretty obvious that hdrp is going to have a lot more overhead than some code drawing 1 image. Obviously an exaggerated comparison, but I'm assuming thats roughly what you're seeing with the 300 vs 40 fps ... theres just more going on upfront, since they expect you'll eventually need to do more than that initial scene.

With that said, I'm not basing this off of actual tech knowledge or tests, so feel free to scale upwards and find out where that threshold is.

 

If I may add some personal experience,

• specularity/smoothness in general is at another level compared to standard. There is no comparitive third party asset as far as I know quality-wise.
  
• Standard lit compared to HDRP lit in general -feature wise- is also far apart.
• SRP Batcher is superior to standard's dynamic/static batching all day.
• Built in volumetrics and decals just add to it, although, atm I think standard's third party assets have better quality and feature.
• VFX, which is only available on HDRP, is GPU accelerated particles which is better than particle system in pretty much every way.
  
• PBR sky (very early) is already miles better than standard's procudural/cubemap sky.
• Camera based rendering which helps fight floating point errors, (further away from origin, things start to jiggle) up to 10km (no jiggle). Try to put your camera 10km away from originin standard and see what happens.
• DXR.
• Hybrid Renderer, still early, but when finished, will probably be the obvious choice for open world games.

Also, lastly, HDRP improves day after day, and standard is and will be the same until the end of times. Next year this time around, there won't be a debate about HDRP. It is really just a matter of time.

 

I would also imagine once HDRP gets stable enough that 3rd party assets can safely be created for it ... we're going to see a tremendous jump in terms of what we can do with it.

I can't wait for it to really open up ... imagine Standard with no asset store ... that's what I'm hoping it will become for HDRP.

 

Shader graph has always had a bug with texture _ST vector4s.
Like if I wanted a scale and offset for a texture called _Albedo
I have a vector4 called _Albedo_ST with the default of (1,1,0,0)
However changing these material values in the editor don't stay, they soon get overriden.

 

Does this happen with alternative names? Just wanted to check if those names are reserved.

 

Please update Hdrp v6.9.2.
PBR master preview is not present in editor viewport. Only in play mode.

 

If you have a bug on released version, best way to get it solved is to make an official issue report using the bug reporting tool.

 

It's only with those names, but at one point earlier on when I made my main shader-graph shaders, it worked fine, and upgrading to shadergraph was made easier by reusing the old names. It also does work temporarily, until I undo or something refreshes then it reverts. The only way I can change the values permanently is by going into debug inspector mode and find the tex env and modify it there, then it sticks.

I guess the proper solution would be to add the option to have a scale/offset drawer to the property in the blackboard (and probably requiring the _ST vector4 in the blackboard for use in the graph). But I'd be happy if I can just edit the vector4s as they are now.

 

It was already reported. I believe it's happening in v5 also.

 

Hi all,

I need to display a 360 video in HDRP. Before, one would use the Panoramic shader, create a skybox material, use a render texture, etc... However, Skybox material no longer work in HDRP. What are my options?
I've thought of:
1. The old-school inverted normals on a sphere strategy.
2. Converting my equirectangular video into cubemap, and using an HDRI Sky module in a Volume.

Any other solutions?

 

Will HDRP get support for ParticleSystem lights?

 

Please support for GPU instancing like drawmeshinstancedindirect! It's mind-boggling that it's no longer possible..

 

There's a lot of this sort of thing going on. Seems to be related to some very specific decisions made early on in the interest of maximizing performance. Not sure if that applies to this case, but it did to some others. The issue is you have a general-use engine, who's most competitive (visually) rendering is tuned to a relatively narrow set of use-cases. One of them being making cool demos.... not necessarily what game development might prioritize. I hope it'll all work out, but it's hard to plan. That's for sure.

 

Asked this couple of times on forums before but hopefully drawmeshinstanced works as we did all our vegetation rendering in a demo using it...

 

DrawMeshInstanced works but DrawMeshInstancedIndirect is not supported at the moment AFAIK.

There is a ShaderGraph node provided by @LennartJohansen but ShaderGraphcustom node API has changed and looks like they are not working in the latest versions.

Anyway, looks like DrawMeshInstancedIndirect is on the roadmap for ShaderGraph

https://forum.unity.com/threads/drawmeshinstancedindirect-and-shader-graph.720638/#post-4834331

 

I'm not sure whether this thread is still monitored, but it looks like as of Unity 2019.2, Realtime GI lighting no longer works at all in HDRP. I've reported this as case #1188797 (sample project attached). The issue persists in 2019.3 as well. (Note that Realtime GI worked fine in HDRP under 2019.1.14)

Is this known by the HDRP team? Is this going to be fixed on 2019.2? Is there just something I need to change in my project to get Realtime GI working in HDRP? Right now it's completely broken, easily reproduced in a brand new project under 2019.2.6 or the latest 2019.3 beta.

 

It seems Decal is not working in player build with HDRP 7.1.2 + 2019.3.0b5. I have it working in the editor and play view but not in the build

 

It is not visible at all or is just showing only at really close distances ! Can you check this !?

P.S. - i am having issues with decals as well !

 

Not visible at all, I am trying some different settings now, to see if it's the settings affected it.........

 

the current work around solution is to create a shader graph decal shader

 

Decals were always fickle. I'd have them just stop showing (depending on view angle) when they should and so forth. Never been that stable.

 

How did you even manage to get it to run? Mine crashes the standalone build with 7.1.1 or 7.1.2 with anything b4 or later.

 

testing with 7.1.2

 

Hey guys, Indirect Intensity of any light with Realtime GI does nothing, could you do something about it? Emissive materials works.

https://issuetracker.unity3d.com/is...-using-realtime-global-illumination-with-hdrp

Still the same in 7.0.1

 

I am actually still on 6.9.0 and 2019.2 because i can not switch to 7.x.x yet but i can run a build with these versions yes !

 

How can I properly sample a texture in Custom Expression? Right now I'm getting this error http://prntscr.com/pllc52

 

Prefab isolation mode lighting is completely broken making it practically unusable in Unity 2019.2 with HDRP 6.9.1

 

Is it fixed in 7.x ?

 

Did you use it with an assigned prefab scene or without? If there isn't a prefab mode scene that contains a light you won't get any lighting. In 2020 it uses the current scene and it's lighting if you don't have any assigned

 

Thanks I didn't know those project settings existed, looked like ours was set to a scene with some bad post processing settings. Not confirmed fixed yet, but looks very promising.

 

I'm not sure.
AFAICT you can't use 7.x with 2019.2 and 2019.3 is still in beta so I'm not going to upgrade the project to it yet.

 

@SebLagarde , @LeonhardP

For HDRP create:

- cookies support for spot/rectangular lights
- sun shafts in directional light (when volumetric fog enabled)
- layer-based terrain painting tool with shader-graph support
- grass shader-graph support in Polybrush
- realtime screen-space global illumination
- same or similar workflow procedure for FPS camera as explained here:

https://www.youtube.com/watch?v=5AmI2yOx0Nc

 

It would be nice if before-refraction transparent objects could write to the depth texture. I have a transparent ocean water material, but since it doesn't write to the depth texture, my soft particles are not soft when intersecting with the water (which is practically opaque).

 

Hi,

does anybody know about HDRI skies not being rendered in HDRP but instead it's all black color when running a build on Windows 7 ? Also with the most recent version 7.1.5 the build crashes on Windows 7 as well. The project is developed on Windows 10 and it's working well however !

 

Just found that 7.1.5 has a bug on the StackLit graph, SSR doesn't work correctly when coat is enabled, the coat roughness is inverted.

 

@SebLagarde or anyone who can help

Big question about particles with HDRP: Shuriken ("old" Particle System) will be officially supported by HDRP?

Right now there are no particle shaders working with Shuriken and HDRP... am i missing something?

Thanks!

 

@cfree in case you dont spot it the post above was replying to you.

 

Hi, I had the same problem. I changed my Diffusion Profile to "Assets>Settings>Skin.asset" and that did the trick.

 

all it needs is a diffusion profile that is referenced in the HDRP asset or in a volume diffusion profile override

 

Hello, any idea why the linear fog was removed from HDRP 7?

It is difficult to replicate distance effect with a fog that is calculated with 3 factors. Does anyone have a trick?

 

You removed LINEAR FOG and RUINED MY PROJECT. Thanks guys.

Fog sucks and is more overused than bloom was in 2007... I use linear because it has a 'dont draw fog closer than X units to the camera' option. I no longer have that option, so if I want to gray-out distant things, I get to to gray out close things too, washing out the vibrancy of my art and making it look like S*** at any distance.0. I cant downgrade because Amplify requires the latest HDRP.

 

You have the same distant fog with the new setup. It only seemed easier because you had two values to work with before and now it's one that's just the fog distance. So if you set 2 as the value, you will have fog from 2 meters onward from your camera. You can increase the value to the same you had for your fog start value before when using Linear Forg and everything should be fine.

The default fog now is Exponential Fog and if you enable Volumetric Fog, that works on top of it.

Fog at 2 meters


Fog at 400 meters

 

No, all you've done is diluted the fog so much that you cant see it up close. Attenuation <> start distance.



Does this look like the fog starts 50 units away from me? That'd be somewhere near that big plateau up ahead.

Also, it looks like the latest build ignores project-settings' LOD BIAS entirely. Its broken. I'm having things pop LOD levels right in front of me no matter what number I enter -- 4 used to be great for cinematics but now even crazy numbers like 500 change nothing.

 

I should have made that more clear, my bad. It's supposed to be realistic as everything in HDRP is based on physical values. So fog doesn't really start a distance from you, you just have a range of visibility in that fog. The 50 you input means 50 meters of visibility so it's like the start distance but with a fade/ramp up as it gets to 50 meters. Increase the value until it looks like what you want. Around 100 or so should make it look like the fog start to fade in around 50 meters onward.

Docs - https://docs.unity3d.com/Packages/c....high-definition@7.1/manual/Override-Fog.html

 

So in other words, from now on in order to make distant mountains look far away and gray I'll have to (1) Put them 25,000 units away and destroy my depth buffer's resolution, all in the name of physically correct simulation, or (2) figure out some kind of fog volume cube and set it around the mountain and try to hide the volume's borders or (3) attach some kind of volumetric fog-density cube to the camera and sit it out 50 units or (4) let the smog take over and look so typical for today's games. I don't see what unity gained by removing the 'start distance' and 'end distance' options, but whatever, I was just trying to set up a marketing cinematic for some assets. I surrender on the fog and I'll move on. But I do need the LOD Bias to work before I can record anything. Be sure to put that on the to-do list at least. Now I get to figure out why my reflection probes turn off and on causing big rectangles of bad lighting as I move around the map. Its been a bad day, gentlemen.

 

Myself and I suspect many other people have a need for for that isn't physically correct. I wish that option hadn't been removed.

 

BLOOM is incomplete and useless in HDRP without a threshold slider.
----------------------------------------------------------
Bloom is supposed to pick the brightest pixels, copy them to a down-scaled version of the screen, blur them, and add that back to the main canvas. The HDRP bloom does the blur and adds it back, but they *FORGOT* to pick the brightest pixels!? Without some kind of threshold slider to ignore the darker stuff, HDRP is grabbing ALL the pixels. Its literally supposed to pick the brightest 5% but its grabbing the entire brightness range down to 1,1,1. I challenge anyone to create HDRP bloom that intensely glares bright things but doesn't affect the dark areas, because I sure cant. All HDRP bloom can do is a full screen blur, and who needs that? From what other complaints I've read, this has been around since the beginning.
So in this image, I should have blinding glare around the HDRI clouds. I get a little glare, but notice that the dark areas under the ledges are just as blurred. So... full screen blur like I say. Up the scatter slider and it just causes a muddy full-screen wash-out by spreading the blur distance. It sure would be nice to get ordinary bloom (Copyright 2002, the first and most common post FX ever). Compared to some of the more weird and specialized post FX, I think everyone would agree that this one is critical.