Feedback Wanted: High Definition Render Pipeline

Hi,
it is almost impossible to build without Shader Variant stripping, we have remove it from the UI so people can't disable it (and see infinite build time).

We still have work to do to be more agressive on shader variant we removed.

 

Hi, I am not sure about which version people refer to, maybe we have get one version at some point that was broken but it have been fixed quickly. Anyway, shader stripping is always on and can't be disable in recent version.

Also to cut your build time A LOT, I suggest to disable "Debug Display" option in HDRP asset. This will prevent you from debugging, but can save 30% of your build time.

We need all the shader variant for various reasons. If you are a coder and know what your game is using, you can remove unused multi-compile in lit.shader and replace them by define. you will save a lot of time.
The issue with build time is that as a general engine, we can't tweak our variant for your game, so we need to compîle all variant . We have added option in HDRP asset to allow to cut shader variant not use (Decals, light layers etc...).

 

hmm... That is indeed unfortunate. One solution could be to not apply contact shadow if we detect that we are emissive. (easy to do, just do if (builtindata.emissiveColor > 0) dont apply contact shadow in lightEvaluation.hlsl). However I pretty sure other will come to ask the opposite .

 

We can't reproduce this. But I would advice to not play with 2019.1 and 5.x.x we currently focus on 2018.3 and 4.x.x

 

Hi sorry I am not sure to understand if you have a question or what is your question.

SSS apply to diffuse lighting, not specular lighting.
The dual specular you refer too is specular lighting, so independent of SSS.

Lit shader support a single lobe for specular for performance reasons.
StackLit shader support dual lobe for specular but isn't targeting game.

 

Hi, I would advice to not play with 2019.1 and 5.x.x we currently focus on 2018.3 and 4.x.x

 

Hi, We indeed haven't consider the case of flight simulator in our implementation. So expected that thing get broken

 

Hi,
yes I can be surprising. But here is some comment
- HDRP vs Builtin can be compare, an empty scene is not the best comparison, but I will say a unity scene convert to HDRP isn't either. What you need to compare if what you can achieve. HDRP have way more features and can support way more lights (you can go up to 500 lights and it still perform correctly compare to Builtin).
- HDRP IS slower currently due to various copy we are performing that we can't remove as low level 3D API function are not yet expose + HDRP perform a depth pyramid and a color pyramid all the time (this is use for distortion, refraction, SSR etc...). We haven't added yet option to disable it, and this explain this slowdown. But have in mind that if you use these features, you will require it. So if you use HDRP to have the same feature as Builtin, then indeed there is a waste of effort here.
- Please always use millisecond and not FPS (but sadly Unity is bad at providing these numbers...)

So you are right. Currently with empty scene builtin is faster. Later we will expose more option to disable undesired effect and allowing to reach same performance on empty scene. But ultimately, you don't care once you will have a game (but you care for secondary camera).

 

Yes, builtime are long. Fontainbleau demo take around 40 min, and around 1H30 on PS4.
https://forum.unity.com/threads/pho...eal-world-objects-into-digital-assets.521946/

FPS Sample game can take also one or two hours.

Be sure we are worried about that but to the question why Builtin (or LW) is faster. It is because they support way less features than HDRP do. And in particular as HDRP support both forward and deferred renderer at the same time, this add a lot of variant. If you customize buitlin Unity with your own shader, you can get into the same issues. Adding multicompile in .shader cause a lot of variants.

We are working on being more agressive on shader variant removal, but it will always require hint from the users. We can't decide for him what he want to use, and this is why by default there is various option enabled (like decals).

 

Check the Depth Range in the Volumetric Lighting Controller of your Scene Settings. The range is [0.5, 64] by default. Looking at your cube size, I guess the fading you're seeing is the maximum depth range.

 

I tried but I don't notice any performance drop with Unity 2018.3.0b9 and HDRP 4.1.0 .

Edit: I found the culprit : If you have realtime probes it will indeed cause huge performance drops. I will not got in depth in the details, but basically convolution will be done multiples times per probe with this setting, and that's the root of the issue. A fix will come in the near future, but I can't give an ETA for it.

 

1. The mask is similar to the mask map used in HDRP lit:

R. Metallic
G. Occlusion
B. Height (instead of detail mask)
A. Smoothness​

2. Could you maybe share a repro scene or describe a bit more the issue. I never encountered this.
3. Yes, distortion affects its own surface. Maybe you should more look into refraction for the effect you showed in the other post.

 

EvaluateAtmosphericScattering() is not broken, but you appear to use it wrongly

Calling it with two argument is more ment to be used with opaque objects. It returns the color and opacity of the fog, and so, was coloring your triangles in a full uniform color :
https://github.com/Unity-Technologi...ericScattering/AtmosphericScattering.hlsl#L34

The implementation with 3 arguments is ment to be used with transparent objects : https://github.com/Unity-Technologi...definition/Runtime/Material/Material.hlsl#L64

But in your case, you were providing the wrong blend mode. Your shader is using a soft blend : Blend SrcAlpha One .
But your declared #define _BLENDMODE_ALPHA 1 , so the fog evaluation was wrong.
Replace it by #define _BLENDMODE_ADD 1 and it will fix your issue:

 

We have a fix for this that is coming. It will add a "Max Fog Distance" parameter that you can set to "Infinity" if needed. It's already in our master branch, so expect it to be available in the next release of the package.

 

I tested and could reproduce this. Thanks for reporting.

 

That one

 

@Reanimate_L Check your probe setup, refraction falls back to the local probe if the ray trace fails to find proper value in the buffers. We already reduced some issues with refraction in the current version, but can't do much more without impacting performances ...

 

Thanks. We already get this error reported. Fix in progress: https://github.com/Unity-Technologies/ScriptableRenderPipeline/pull/2428

 

Hi.

Cost of realtime reflection probes depends on your scene content + your resolution. It is up to you to control what you render in your probe (disable decals, have only a single cascade shadow etc...).

The current extra cost that we are aware is that builtin unity is still performing its own convolution (a gaussian blur), before HDRP can do its own (GGX blur). We will solve this issue in 2019.1

 

Sorry but I am confused by your description, I don't understand the issue.

 

Hi.
Sorry but we but there is not enough information here to be of any help.

 

Distortion and refraction use the same fading at edge (in 4.1.0), which version are you using? There is no improvement plan for now after 4.1.0

 

Hi, Sorry I don't understand the question / problem.

>Added SunShafts FX as a post processing which was already included in V-Fog itself

What is Sunshaft FX or V-Fog ? Suppose it is your own plugin ?

 

It's when you overlay multiple objects with distortion. In Add mode, the newly rendered object will accumulate it's value to the previous one, while in Multiply mode, it will multiply with the previous one.

 

Hi,

Look at deferred.shader for an example

These lines:

// input.positionCS is SV_Position
float depth = LOAD_TEXTURE2D(_CameraDepthTexture, input.positionCS.xy).x;

PositionInputs posInput = GetPositionInput_Stereo(input.positionCS.xy, _ScreenSize.zw, depth, UNITY_MATRIX_I_VP, UNITY_MATRIX_V, uint2(input.positionCS.xy) / GetTileSize(), unity_StereoEyeIndex);

BSDFData bsdfData;
BuiltinData builtinData;
DECODE_FROM_GBUFFER(posInput.positionSS, UINT_MAX, bsdfData, builtinData);

With these line you have the GBuffer data. If you only use the normal from GBuffer (bsdfData.normalWS), then the compiler will remove all unneeded texture fetch

 

Color pyramid will be accessible via shadergraph in near future