Feedback Wanted: Scriptable Render Pipelines

happens to me when they are selected

 

MipMap prefiltering? is that a new texture preprocessor?

Oh also is all shadow filtering algorithm that available in Core supported in HDRP?

 

You can also try different shadow filtering options, unfortunately there's no handy selector so you need tweak the HDRP code itself to swap them atm:

These are the places he mentioned:
https://github.com/Unity-Technologi...ion/HDRP/Lighting/LightLoop/LightLoop.cs#L127
https://github.com/Unity-Technologi...tor/Lighting/AdditionalShadowDataEditor.cs#L7

and for the shadow filtering options, you can see every possible alternative here:
https://github.com/Unity-Technologi...ipelines.core/CoreRP/Shadow/ShadowBase.cs#L77
so basically current alternatives are PCF with 5 variants, VSM, EVSM with 2 variants, MSM with 2 variants, PCSS and custom.

HDRP 3.0.0 defaults to PCF variant V2 for point and spot lights and PCF variant V3 for directional light.

 

I think there's an option to disable it on the pipeline asset, I keep it on because I like to use it. Not sure what the key is to turn it on from the keyboard but on the Xbox controller its the two thumbsticks, you press those down and you get the debug window in-game (it works with builds on the supported platforms for HDRP - also by pressing the button X on a setting it will stick it to the right of the screen ) LWRP doesn't have the same debug window yet (If you press the same button it get activated but you can't see anything).

 

Got this in HDRP

Code (CSharp):

1. ArgumentException: Getting control 36's position in a group with only 36 controls when doing ExecuteCommand
2. Aborting
3.  

 

Is it really worked? i try PCSS but there's no effect at all and all Moment shadow are failed to compile.

 

Thanks, that solves part of the problem. But what I didn't notice before is that with my conversion, the billboards don't face the camera but are stuck facing in one direction.

Legacy pipeline:

Code (CSharp):

1. output.pos = mul(UNITY_MATRIX_P, float4(UnityObjectToViewPos2(input.center), 1.0f) + offset);

Converted to HD SRP with camera relative rendering:

Code (CSharp):

1. output.pos.xyz = TransformObjectToWorld(input.center.xyz);
2. output.pos.xyz = TransformWorldToView(output.pos.xyz) + offset.xyz;
3. output.pos = mul(UNITY_MATRIX_P, float4(output.pos.xyz, 1.0f));

However, I am not sure if this is the proper way to do this as the last line of code doesn't use one of the build it HD SRP functions. Is this still compatible for camera relative rendering and future proof?

 

How expensive is geometric specular AA?
I really like it, its a long waited solution for flickering with TAA, but i need to know if i can spam it everywhere.

 

How to setup specular map? Where to plug it ?

 

How do you add fog support to a Custom Unlit Transparent Emissive shader for the HD SRP?

Using EvaluateAtmosphericScattering() and _ENABLE_FOG_ON_TRANSPARENT and UNITY_MATERIAL_UNLIT, does not have any effect.

 

Code (CSharp):

1. ArgumentException: Getting control 36's position in a group with only 36 controls when doing ExecuteCommand
2. Aborting
3.  

2018.2.6 and HDRP 3.0.0 (standard installation in package manager)

 

In RenderDoc, both GetPositionInput() and EvaluateAtmosphericScattering() are jumped over when singe stepping through the code. I am not sure if this is because that code is ignored or that RenderDoc is unable to step into 3rd party functions. Looking at the assembly, it looks like those functions are indeed missing. Strange because the compiler doesn't throw an error.

I am not sure where to check in RenderDoc that _AtmosphericScatteringType is correctly initialized.

The blend mode is present as a shader feature.

Below is the full shader I am using. Here is also a small repo:
https://drive.google.com/file/d/1Sn6gIIK6li6fXM05Jo_JOlnHZl2yltXp/view?usp=sharing

The GameObject containing the OmniSimple shader is called CityLightsAmber0 and CityLightsWhite0. Note that the shader needs custom vertex data and cannot be applied to a regular mesh. So the repo is indeed required.

The camera controls in game mode are the same as with the Editor.
You can see a spherical shadow effect and incorrect blending with the cube.

Code (CSharp):

1. //This shader contains a failed attempt to get fog (atmospheric scattering) to work.
2. Shader "Lights/OmniSimple"{
3.  
4.     Properties{
5.  
6.         _MainTex ("Light Texture", 2D) = "white" {}
7.         [HDR]_FrontColor ("Front Color", Color) = (0.5,0.5,0.5,0.5)
8.         _MinPixelSize ("Minimum screen size", FLOAT) = 5.0
9.         _Attenuation ("Attenuation", Range(0.01, 1)) = 0.37
10.         _BrightnessOffset ("Brightness offset", Range(-1, 1)) = 0
11.     }
12.  
13.     HLSLINCLUDE
14.     #pragma target 4.5
15.     #pragma glsl_no_auto_normalization
16.     #pragma enable_d3d11_debug_symbols
17.  
18.  
19.     #pragma shader_feature _SURFACE_TYPE_TRANSPARENT
20.     #pragma shader_feature _BLENDMODE_ALPHA
21.     //#pragma shader_feature _ _BLENDMODE_ALPHA _BLENDMODE_ADD _BLENDMODE_PRE_MULTIPLY
22.     #pragma shader_feature _ENABLE_FOG_ON_TRANSPARENT
23.     #define UNITY_MATERIAL_UNLIT // Need to be define before including Material.hlsl
24.  
25.     #include "CoreRP/ShaderLibrary/common.hlsl"
26.     #include "HDRP/ShaderVariables.hlsl"
27.     #include "HDRP/Material/Material.hlsl" //For fog.
28.     #include "lightFunctions.cginc"
29.  
30.  
31.     uniform sampler2D _MainTex;    
32.     float _MinPixelSize;
33.     half _BrightnessOffset;
34.     float _Attenuation;
35.     half4 _FrontColor;
36.  
37.     //These global variables are set from a Unity script.
38.     float _ScaleFactor;
39.  
40.     struct vertexInput {
41.  
42.         float4 center : POSITION; //Mesh center position is stored in the position channel (vertices in Unity).
43.         float4 corner : TANGENT; //Mesh corner is stored in the tangent channel (tangent in Unity). The scale is stored in the w component.
44.         float2 uvs : TEXCOORD0; //Texture coordinates (uv in Unity).    
45.     };
46.  
47.     struct vertexOutput{
48.  
49.         float4 pos : SV_POSITION;
50.         float2 uvs : TEXCOORD0;
51.         half4 color : COLOR;
52.  
53.         //This is not a UV coordinate but it is just used to pass some variables
54.         //from the vertex shader to the fragment shader: xyz = world space pos. w = gain
55.         float4 container : TEXCOORD1;
56.     };        
57.  
58.     vertexOutput vert(vertexInput input){
59.  
60.         vertexOutput output;
61.         half gain;
62.         half distanceGain;
63.         float scale;
64.         float3 positionWS;
65.  
66.         //Get a vector from the vertex to the camera and cache the result.
67.         float3 objSpaceViewDir = ObjSpaceViewDir2(input.center);
68.  
69.         //Get the distance between the camera and the light.
70.         float distance = length(objSpaceViewDir);
71.  
72.         output.color = _FrontColor;
73.  
74.         //Calculate the scale. If the light size is smaller than one pixel, scale it up
75.         //so it remains at least one pixel in size.
76.         scale = ScaleUp(distance, _ScaleFactor, input.corner.w, 1.0f, _MinPixelSize);
77.  
78.         //Get the vertex offset to shift and scale the light.
79.         float4 offset = GetOffset(scale, input.corner);
80.  
81.         //Place the vertex by moving it away from the center.
82.         //Rotate the billboard towards the camera.
83.         //output.pos.xyz = TransformObjectToWorld(input.center.xyz + offset.xyz);
84.         //output.pos = TransformWorldToHClip(output.pos.xyz);
85.         positionWS = TransformObjectToWorld(input.center.xyz);
86.         output.pos.xyz = TransformWorldToView(positionWS) + offset.xyz;
87.         output.pos = mul(UNITY_MATRIX_P, float4(output.pos.xyz, 1.0f));
88.  
89.         //Not sure if positionWS is correct already,or need to calculate like this:
90.         //positionWS = GetCameraRelativePositionWS(positionWS);
91.  
92.         //Far away lights should be less bright. Attenuate with the inverse square law.
93.         distanceGain = Attenuate(distance, _Attenuation);
94.  
95.         //Merge the distance gain (attenuation), and light brightness into a single gain value.
96.         gain = (_BrightnessOffset - (1.0h - distanceGain));
97.  
98.         //Send the gain and positionWS to the fragment shader.
99.         output.container = float4(positionWS, gain);
100.  
101.         //UV mapping.
102.         output.uvs = input.uvs;
103.  
104.         return output;
105.     }
106.  
107.     half4 frag(vertexOutput input) : SV_Target{
108.  
109.         //Compute the final color.
110.         //Note: input.container.x fetches the gain from the vertex shader. No need to calculate this for each fragment.
111.         half4 col = 2.0h * input.color * tex2D(_MainTex, input.uvs) * (exp(input.container.w * 5.0h));    
112.  
113.         //input.positionSS is SV_Position    (float2 positionSS, float2 invScreenSize, float deviceDepth, float linearDepth, float3 positionWS)
114.         //PositionInputs posInput = GetPositionInput(input.pos.xy, _ScreenSize.zw, input.pos.z, UNITY_MATRIX_I_VP, UNITY_MATRIX_V);
115.         PositionInputs posInput = GetPositionInput(input.pos.xy, _ScreenSize.zw, input.pos.z, input.pos.w, input.container.xyz);
116.  
117.         //This does not have any effect.
118.         col = EvaluateAtmosphericScattering(posInput, col);
119.  
120.         return col;
121.     }
122.     ENDHLSL
123.  
124.     SubShader{
125.  
126.         Tags {"RenderType"="Transparent"}
127.  
128.         Pass
129.         {
130.             Name ""
131.             Tags{ "LightMode" = "ForwardOnly" }
132.             Blend SrcAlpha One
133.             AlphaTest Greater .01
134.             ColorMask RGB
135.             Lighting Off
136.             ZWrite Off
137.             HLSLPROGRAM
138.                 #pragma vertex vert
139.                 #pragma fragment frag
140.             ENDHLSL
141.         }
142.     }  
143. }
144.  

 

Are the shadows in the HDRP not supposed to be some kind of better Percentage Closer soft shadow implementation that will look nicer? I don't feel like I'm seeing that.

 

it's been discussed above, that by default it was PCF. other shadow filtering tech are implemented already you just need to change it manually for HDRP codes to switch it

 

Thanks for the answer, but I don't really understand how? How do you programmatically interact with the pipeline? I can't find anything about it in the documentation. Sorry if that is a stupid question.

EDIT: Sorry yeah I saw one of the answers above that they are reworking it. I guess this will just all be sorted out by 2018.3 and be accessible in the UI, I guess I'll just wait for that.

 

yeah that might be the best, switching stuff in hdrp are confusing. .

 

Hello I have been having fun playing with the rendering pipelines. I realize this is probably already being worked on but I previewed the new version in the package manager and when I tried to use the HDRP it informed me windows 8.1 is not currently supported and no rendering would occur.

 

Is GPU instancing for shaders created through shader graph still planned for the HDRP? I just tested Unity 2018.3.0b1 and it still doesn't support this.

 

Option for GPU instancing will at least show up with the upcoming HD Lit (Master) Graph, I didn't test the instancing in practise but I do expect it to work if it works on regular HD Lit. I tested this by manually merging sg/lit-master-node additions to SRP master and ran it on 2018.3.0b1. Main reason why I tested it though was because Shader Graph shaders don't work on HDRP forward only -mode at all. I've tried to ask about the plans on that trice here but haven't gotten any answer. Fortunately since HD Lit Master does work really nicely in forward, lack of traditional SG shader support on forward is going to be a non-issue for me.

Now the real question is, when should we expect HD Lit Master to be included on the main SRP? It's not even in the PR's yet, which leads me to believe it's still really far off.

 

I got the VFX branch working with 2018.3 beta, thanks for making this available, looks good!

 

HDRP 3.3

Missing "OnAwake" which is working in debug mode

 

What does it mean "OnAwake" ?

Why is res greyed out? Can't you increase it ?

 

on awake means probe is baked once on awake, with this new ui it defaults to "every frame".
res is selected in HDRP asset globally as i understand.

 

Any ETA on RenderPipeline shaders for the terrain? I sort of figured they might arrive with the 2018.3 beta, but not as far as I can tell.

EDIT: Just saw elsewhere that it will come with HDRP 3.4.0 release.

 

You can download new hdrp from github.


Or you can use layerd lit shader for terrain

 

Thanks! I'll give this a go tonight.

 

Im failing to extract _EmissiveColor from a property block

Code (CSharp):

1.     public EmissiveMaterialAnimator(MeshRenderer renderer, int index, float fadeTime, bool initState = false)
2.     {
3.  
4.         this.fadeTime = fadeTime;
5.         this.index = index;
6.         this.renderer = renderer;
7.         this.propertyBlock = new MaterialPropertyBlock();
8.         this.initialpropertyBlock = new MaterialPropertyBlock();
9.  
10.         renderer.GetPropertyBlock(initialpropertyBlock, index);
11.         renderer.GetPropertyBlock(propertyBlock, index);
12.         propID = Shader.PropertyToID("_EmissiveColor");
13.         blackcolor = new Color();
14.         initialcolor = propertyBlock.GetColor(propID);
15.         currentcolor = initState ? initialcolor : blackcolor;
16.     }

If i pull the same property from the renderer itself it works.
If i pull _EmissiveColorMap from propertyblock it works.
Only _EmissiveColor doesnt work. Is this a bug?

UPD:

Despite the GetColor and GetVector returning zeroes, if you apply the block it applies the correct initial color. Meaning the value is there, just the GetColor is broken.

 

Hoe to set up SSR? (screen space reflections) in HDRP?

 

they are broken atm, even if you enable in code, they are all messed up

 

Hey guys, now after updating to 2018.3b01, i get the following error:
ArgumentException: ComputeBuffer.SetData() : Accessing 15600 bytes at offset 0 for Compute Buffer of size 15360 bytes is not possible.
(And my assets are not displayed, similar to not having the pieline asset in the project.)

Do you have any idea?

Here is one of the full error descriptions:

ArgumentException: ComputeBuffer.SetData() : Accessing 15600 bytes at offset 0 for Compute Buffer of size 15360 bytes is not possible.
UnityEngine.ComputeBuffer.SetData (System.Array data) (at C:/buildslave/unity/build/Runtime/Export/ComputeShader.bindings.cs:124)
UnityEngine.Experimental.Rendering.HDPipeline.ShadowSetup+<>c.<.ctor>b__7_0 (UnityEngine.Experimental.Rendering.ShadowContext sc) (at C:/Users/Onat Hekimoglu/Documents/Slow Bros/SRP/ScriptableRenderPipeline/com.unity.render-pipelines.high-definition/HDRP/Lighting/LightLoop/LightLoop.cs:105)
UnityEngine.Experimental.Rendering.ShadowContext.SyncData () (at C:/Users/Onat Hekimoglu/Documents/Slow Bros/SRP/ScriptableRenderPipeline/com.unity.render-pipelines.high-definition/HDRP/CoreRP/Shadow/ShadowBase.cs:630)
UnityEngine.Experimental.Rendering.ShadowManager.SyncData () (at C:/Users/Onat Hekimoglu/Documents/Slow Bros/SRP/ScriptableRenderPipeline/com.unity.render-pipelines.high-definition/HDRP/CoreRP/Shadow/Shadow.cs:1637)
UnityEngine.Experimental.Rendering.HDPipeline.LightLoop.PushGlobalParams (UnityEngine.Experimental.Rendering.HDPipeline.HDCamera hdCamera, UnityEngine.Rendering.CommandBuffer cmd) (at C:/Users/Onat Hekimoglu/Documents/Slow Bros/SRP/ScriptableRenderPipeline/com.unity.render-pipelines.high-definition/HDRP/Lighting/LightLoop/LightLoop.cs:2402)
UnityEngine.Experimental.Rendering.HDPipeline.LightLoop.BuildGPULightLists (UnityEngine.Experimental.Rendering.HDPipeline.HDCamera hdCamera, UnityEngine.Rendering.CommandBuffer cmd, UnityEngine.Rendering.RenderTargetIdentifier cameraDepthBufferRT, UnityEngine.Rendering.RenderTargetIdentifier stencilTextureRT, System.Boolean skyEnabled) (at C:/Users/Onat Hekimoglu/Documents/Slow Bros/SRP/ScriptableRenderPipeline/com.unity.render-pipelines.high-definition/HDRP/Lighting/LightLoop/LightLoop.cs:2350)
UnityEngine.Experimental.Rendering.HDPipeline.HDRenderPipeline.Render (UnityEngine.Experimental.Rendering.ScriptableRenderContext renderContext, UnityEngine.Camera[] cameras) (at C:/Users/Onat Hekimoglu/Documents/Slow Bros/SRP/ScriptableRenderPipeline/com.unity.render-pipelines.high-definition/HDRP/RenderPipeline/HDRenderPipeline.cs:1145)
UnityEngine.Experimental.Rendering.RenderPipelineManager.DoRenderLoop_Internal (UnityEngine.Experimental.Rendering.IRenderPipelineAsset pipe, UnityEngine.Camera[] cameras, System.IntPtr loopPtr) (at C:/buildslave/unity/build/Runtime/Export/RenderPipeline/RenderPipelineManager.cs:33)
UnityEngine.GUIUtilityrocessEvent(Int32, IntPtr)

 

SSR update is now at SRP master, so you can try it out if you are willing to grab that manually.

I've also pushed an experimental branch which is based on current master but has following extra things merged: HD Lit (Master) Graph for Shader Graph, texture filtering for HDRP and VFX editor package (use only for testing these feats):
https://github.com/0lento/ScriptableRenderPipeline/tree/experimental
of course HD Lit Terrain, SSR and MSAA for HDRP forward-only are included in this as they got recently merged to master.

 

Hi tried it out and got it working. Had some fun getting a Gaia made landscape working with the HDRP and some water reflections with SSR (though they look a bit off to be honest).
Thanks for linking the experimental branch.

 

Why hdrp 3.4.0 not available as update through package manager in unity?

 

This version is not ready for release yet, but you can grab it from github
https://github.com/Unity-Technologies/ScriptableRenderPipeline

 

it's not even released yet: https://github.com/Unity-Technologies/ScriptableRenderPipeline/releases
github master contains upcoming 3.4.0 feats but Unity still keeps adding things for it.

 

How come changes in HDRP are not introduced in 2018.2.8 ? It's still 3.0.0 only.

 

Because things are still changing on the closed Unity c++ side of things in relation to graphics/render pipelines, so only certain versions of the HDRP are compatible with a particular version of Unity.

This is not a new phenomenon, I'm sure it was the same with, for example, Unity 2018.1 and what versions of the HDRP can run on it. Some recent HDRP features tend to get backported to older branches of HDRP eventually, but the general rule is that if you want to use the latest HDRP, you have to use the latest Unity, and during Unity beta phases that means using the Unity betas.

A very obvious example would be the new VFX for HDRP, initial support for which has only been added in 2018.3 and so it wont be working on Unity 2018.2.

 

I feel like 3.0.0 ever working on 2018.2 was a mistake that slipped (they had 1.x for 2018.1 and 2.x for 2018.2 and now 3.x for 2018.3).

They can't backport all new SRP changes to the older engine versions as they would require actual engine and it's API changes (you can't change the API once the major engine version is released, all 2018.2 versions from 2018.2.0 to 2018.2.8 use same API for compatibility reasons).

edit->elbows typed faster

 

Yes it was a mistake and people from Unity said so on this forum.

 

While playing with SRP repo from github, I've faced this small annoyance (nothing major):

When I fetch the remote changes to the repo, I always get greeted by these brances being new regardless if there are zero changes:


The issue is actually rooted on me using Windows as git makes distinction between hdrp and HDRP on it's refs but windows can't do the same and these refs are stored using windows folder structure. So you either get this on your local repo: .git\refs\remotes\upstream\HDRP or this: .git\refs\remotes\upstream\hdrp but can't have both while using windows and this confuses git.

for example if I change the HDRP in the .git/refs to be named hdrp, I'll get following list when running git fetch:


I don't think there really is anything one can do for this from user side. It would be nice if Unity could maybe stick to HDRP as the naming convention so this wouldn't happen? again this is a really really minor thing, just wanted to mention it.