Search Unity

  1. Calling all beginners! Join the FPS Beginners Mods Challenge until December 13.
    Dismiss Notice
  2. It's Cyber Week at the Asset Store!
    Dismiss Notice

Feedback Wanted: Lightweight Render Pipeline

Discussion in 'Graphics Experimental Previews' started by phil_lira, Sep 28, 2018.

Thread Status:
Not open for further replies.
  1. huwb

    huwb

    Joined:
    Oct 19, 2013
    Posts:
    11
    @castana1962 @Andre_Mcgrail

    I hear similar-sounding issues from users of one of my projects on Occulus Rift, where refractions look wrong, with flipped background texture. If I glean any information then I'll share it. Thought I'd check in here.

    @castana1962 if you haven't already could you report a bug for it? Through the unity bug report i guess. Could you report back the bug number?
     
  2. Mehrdad995

    Mehrdad995

    Joined:
    Jul 17, 2013
    Posts:
    16
    Hey I've found the solution
    For those who still use ASE 1.6.3 the template needs to be changed to match the new syntaxes
    this is the fixed template that I managed to get it to work on the latest Unity version (2019.1.0b8)
    I have commented out the old parts and added the fixed ones beside them

    Code (CSharp):
    1. Shader /*ase_name*/ "Hidden/Templates/LightWeightSRPPBR" /*end*/
    2. {
    3.     Properties
    4.     {
    5.         /*ase_props*/
    6.     }
    7.  
    8.     SubShader
    9.     {
    10.         Tags
    11.         {
    12.             "RenderPipeline" = "LightweightPipeline"
    13.             "RenderType"="Opaque"
    14.             "Queue"="Geometry"
    15.         }
    16.      
    17.         Cull Back
    18.         HLSLINCLUDE
    19.         #pragma target 3.0
    20.         ENDHLSL
    21.         /*ase_pass*/
    22.         Pass
    23.         {
    24.             /*ase_pass_options:Name=Misc Options
    25.                 Option,_FinalColorxAlpha:Final Color x Alpha:true,false
    26.                 true:SetDefine:ASE_LW_FINAL_COLOR_ALPHA_MULTIPLY 1
    27.             */
    28.             Tags
    29.             {
    30.                 "LightMode" = "LightweightForward"
    31.             }
    32.             Name "Base"
    33.             Blend One Zero
    34.             ZWrite On
    35.             ZTest LEqual
    36.             Offset 0,0
    37.             ColorMask RGBA
    38.             /*ase_stencil*/
    39.             HLSLPROGRAM
    40.             // Required to compile gles 2.0 with standard srp library
    41.             #pragma prefer_hlslcc gles
    42.          
    43.             // -------------------------------------
    44.             // Lightweight Pipeline keywords
    45.             #pragma multi_compile _ _ADDITIONAL_LIGHTS
    46.             #pragma multi_compile _ _VERTEX_LIGHTS
    47.             #pragma multi_compile _ _MIXED_LIGHTING_SUBTRACTIVE
    48.             #pragma multi_compile _ _SHADOWS_ENABLED
    49.             #pragma multi_compile _ _LOCAL_SHADOWS_ENABLED
    50.             #pragma multi_compile _ _SHADOWS_SOFT
    51.             #pragma multi_compile _ _SHADOWS_CASCADE
    52.             #pragma multi_compile _ FOG_LINEAR FOG_EXP2
    53.      
    54.             // -------------------------------------
    55.             // Unity defined keywords
    56.             #pragma multi_compile _ DIRLIGHTMAP_COMBINED
    57.             #pragma multi_compile _ LIGHTMAP_ON
    58.      
    59.             //--------------------------------------
    60.             // GPU Instancing
    61.             #pragma multi_compile_instancing
    62.      
    63.             #pragma vertex vert
    64.             #pragma fragment frag
    65.      
    66.             /*ase_pragma*/
    67.  
    68.             //#include "LWRP/ShaderLibrary/Core.hlsl"
    69.             #include "Packages/com.unity.render-pipelines.lightweight/ShaderLibrary/Core.hlsl"
    70.  
    71.             //#include "LWRP/ShaderLibrary/Lighting.hlsl"
    72.             #include "Packages/com.unity.render-pipelines.lightweight/ShaderLibrary/Lighting.hlsl"
    73.  
    74.             //#include "CoreRP/ShaderLibrary/Color.hlsl"
    75.             #include "Packages/com.unity.render-pipelines.core/ShaderLibrary/Color.hlsl"
    76.  
    77.             //#include "CoreRP/ShaderLibrary/UnityInstancing.hlsl"
    78.             #include "Packages/com.unity.render-pipelines.core/ShaderLibrary/UnityInstancing.hlsl"
    79.  
    80.             //#include "ShaderGraphLibrary/Functions.hlsl"  
    81.             #include "Packages/com.unity.shadergraph/ShaderGraphLibrary/Functions.hlsl"
    82.  
    83.          
    84.             CBUFFER_START(UnityPerMaterial)
    85.             /*ase_globals*/
    86.             CBUFFER_END
    87.             /*ase_funcs*/
    88.                  
    89.             struct GraphVertexInput
    90.             {
    91.                 float4 vertex : POSITION;
    92.                 float3 ase_normal : NORMAL;
    93.                 float4 ase_tangent : TANGENT;
    94.                 float4 texcoord1 : TEXCOORD1;
    95.                 /*ase_vdata:p=p;n=n;t=t;uv1=tc1.xyzw*/
    96.                 UNITY_VERTEX_INPUT_INSTANCE_ID
    97.             };
    98.  
    99.             struct GraphVertexOutput
    100.             {
    101.                 float4 clipPos                    : SV_POSITION;
    102.                 float4 lightmapUVOrVertexSH        : TEXCOORD0;
    103.                 half4 fogFactorAndVertexLight    : TEXCOORD1;
    104.                 float4 shadowCoord                : TEXCOORD2;
    105.                 float4 tSpace0                    : TEXCOORD3;
    106.                 float4 tSpace1                    : TEXCOORD4;
    107.                 float4 tSpace2                    : TEXCOORD5;
    108.                 float3 WorldSpaceViewDirection    : TEXCOORD6;
    109.                 /*ase_interp(7,):sp=sp.xyzw;wn.x=tc3.z;wn.y=tc4.z;wn.z=tc5.z;wt.x=tc3.x;wt.y=tc4.x;wt.z=tc5.x;wbt.x=tc3.y;wbt.y=tc4.y;wbt.z=tc5.y;wp.x=tc3.w;wp.y=tc4.w;wp.z=tc5.w;wvd=tc6*/
    110.                 UNITY_VERTEX_INPUT_INSTANCE_ID
    111.                 UNITY_VERTEX_OUTPUT_STEREO
    112.             };
    113.  
    114.             GraphVertexOutput vert (GraphVertexInput v/*ase_vert_input*/)
    115.             {
    116.                 GraphVertexOutput o = (GraphVertexOutput)0;
    117.      
    118.                 UNITY_SETUP_INSTANCE_ID(v);
    119.                 UNITY_TRANSFER_INSTANCE_ID(v, o);
    120.                 UNITY_INITIALIZE_VERTEX_OUTPUT_STEREO(o);
    121.      
    122.                 /*ase_vert_code:v=GraphVertexInput;o=GraphVertexOutput*/
    123.                 v.vertex.xyz += /*ase_vert_out:Vertex Offset;Float3;8;-1;_Vertex*/ float3( 0, 0, 0 ) /*end*/;
    124.                 v.ase_normal = /*ase_vert_out:Vertex Normal;Float3;10;-1;_Normal*/ v.ase_normal /*end*/;
    125.  
    126.                 float3 lwWNormal = TransformObjectToWorldNormal(v.ase_normal);
    127.                 float3 lwWorldPos = TransformObjectToWorld(v.vertex.xyz);
    128.                 float3 lwWTangent = TransformObjectToWorldDir(v.ase_tangent.xyz);
    129.                 float3 lwWBinormal = normalize(cross(lwWNormal, lwWTangent) * v.ase_tangent.w);
    130.                 o.tSpace0 = float4(lwWTangent.x, lwWBinormal.x, lwWNormal.x, lwWorldPos.x);
    131.                 o.tSpace1 = float4(lwWTangent.y, lwWBinormal.y, lwWNormal.y, lwWorldPos.y);
    132.                 o.tSpace2 = float4(lwWTangent.z, lwWBinormal.z, lwWNormal.z, lwWorldPos.z);
    133.                 float4 clipPos = TransformWorldToHClip(lwWorldPos);
    134.  
    135.                 clipPos = TransformWorldToHClip(TransformObjectToWorld(v.vertex.xyz));
    136.                 OUTPUT_LIGHTMAP_UV(v.texcoord1, unity_LightmapST, o.lightmapUVOrVertexSH);
    137.                 OUTPUT_SH(lwWNormal, o.lightmapUVOrVertexSH);
    138.  
    139.                 half3 vertexLight = VertexLighting(lwWorldPos, lwWNormal);
    140.                 half fogFactor = ComputeFogFactor(clipPos.z);
    141.                 o.fogFactorAndVertexLight = half4(fogFactor, vertexLight);
    142.                 o.clipPos = clipPos;
    143.  
    144.                 #ifdef _SHADOWS_ENABLED
    145.                 #if SHADOWS_SCREEN
    146.                     o.shadowCoord = ComputeShadowCoord ( clipPos );
    147.                 #else
    148.                     o.shadowCoord = TransformWorldToShadowCoord ( lwWorldPos );
    149.                 #endif
    150.                 #endif
    151.  
    152.                 return o;
    153.             }
    154.      
    155.             half4 frag (GraphVertexOutput IN /*ase_frag_input*/) : SV_Target
    156.             {
    157.                 UNITY_SETUP_INSTANCE_ID(IN);
    158.      
    159.                 /*ase_local_var:wn*/float3 WorldSpaceNormal = normalize(float3(IN.tSpace0.z,IN.tSpace1.z,IN.tSpace2.z));
    160.                 /*ase_local_var:wt*/float3 WorldSpaceTangent = float3(IN.tSpace0.x,IN.tSpace1.x,IN.tSpace2.x);
    161.                 /*ase_local_var:wbt*/float3 WorldSpaceBiTangent = float3(IN.tSpace0.y,IN.tSpace1.y,IN.tSpace2.y);
    162.                 /*ase_local_var:wp*/float3 WorldSpacePosition = float3(IN.tSpace0.w,IN.tSpace1.w,IN.tSpace2.w);
    163.                 /*ase_local_var:wvd*/float3 WorldSpaceViewDirection = SafeNormalize( _WorldSpaceCameraPos.xyz  - WorldSpacePosition );
    164.  
    165.                 /*ase_frag_code:IN=GraphVertexOutput*/
    166.              
    167.                 float3 Albedo = /*ase_frag_out:Albedo;Float3;0*/float3(0.5, 0.5, 0.5)/*end*/;
    168.                 float3 Normal = /*ase_frag_out:Normal;Float3;1*/float3(0, 0, 1)/*end*/;
    169.                 float3 Emission = /*ase_frag_out:Emission;Float3;2*/0/*end*/;
    170.                 float3 Specular = /*ase_frag_out:Specular;Float3;9*/float3(0.5, 0.5, 0.5)/*end*/;
    171.                 float Metallic = /*ase_frag_out:Metallic;Float;3*/0/*end*/;
    172.                 float Smoothness = /*ase_frag_out:Smoothness;Float;4*/0.5/*end*/;
    173.                 float Occlusion = /*ase_frag_out:Occlusion;Float;5*/1/*end*/;
    174.                 float Alpha = /*ase_frag_out:Alpha;Float;6;-1;_Alpha*/1/*end*/;
    175.                 float AlphaClipThreshold = /*ase_frag_out:Alpha Clip Threshold;Float;7;-1;_AlphaClip*/0/*end*/;
    176.      
    177.                 InputData inputData;
    178.                 inputData.positionWS = WorldSpacePosition;
    179.  
    180.                 #ifdef _NORMALMAP
    181.                     inputData.normalWS = TransformTangentToWorld(Normal, half3x3(WorldSpaceTangent, WorldSpaceBiTangent, WorldSpaceNormal)); //TangentToWorldNormal(Normal, WorldSpaceTangent, WorldSpaceBiTangent, WorldSpaceNormal);
    182.                 #else
    183.                     #if !SHADER_HINT_NICE_QUALITY
    184.                         inputData.normalWS = WorldSpaceNormal;
    185.                     #else
    186.                         inputData.normalWS = normalize ( WorldSpaceNormal );
    187.                     #endif
    188.                 #endif
    189.  
    190.                 #if !SHADER_HINT_NICE_QUALITY
    191.                     // viewDirection should be normalized here, but we avoid doing it as it's close enough and we save some ALU.
    192.                     inputData.viewDirectionWS = WorldSpaceViewDirection;
    193.                 #else
    194.                     inputData.viewDirectionWS = normalize ( WorldSpaceViewDirection );
    195.                 #endif
    196.  
    197.                 inputData.shadowCoord = IN.shadowCoord;
    198.  
    199.                 inputData.fogCoord = IN.fogFactorAndVertexLight.x;
    200.                 inputData.vertexLighting = IN.fogFactorAndVertexLight.yzw;
    201.                 inputData.bakedGI = SAMPLE_GI(IN.lightmapUVOrVertexSH, IN.lightmapUVOrVertexSH, inputData.normalWS);
    202.  
    203.                 half4 color = LightweightFragmentPBR(
    204.                     inputData,
    205.                     Albedo,
    206.                     Metallic,
    207.                     Specular,
    208.                     Smoothness,
    209.                     Occlusion,
    210.                     Emission,
    211.                     Alpha);
    212.  
    213.                 // Computes fog factor per-vertex
    214. #ifdef TERRAIN_SPLAT_ADDPASS
    215.                 ApplyFogColor( color.rgb, half3( 0, 0, 0 ), IN.fogFactorAndVertexLight.x );
    216. #else
    217.                 //ApplyFog( color.rgb, IN.fogFactorAndVertexLight.x );
    218.                 MixFog( color.rgb, IN.fogFactorAndVertexLight.x );
    219. #endif
    220.              
    221.                 #if _AlphaClip
    222.                     clip(Alpha - AlphaClipThreshold);
    223.                 #endif
    224. #if ASE_LW_FINAL_COLOR_ALPHA_MULTIPLY
    225.                     color.rgb *= color.a;
    226. #endif
    227.                 return color;
    228.             }
    229.             ENDHLSL
    230.         }
    231.  
    232.         /*ase_pass*/
    233.         Pass
    234.         {
    235.             /*ase_hide_pass*/
    236.             Name "ShadowCaster"
    237.             Tags{"LightMode" = "ShadowCaster"}
    238.  
    239.             ZWrite On
    240.             ZTest LEqual
    241.  
    242.             HLSLPROGRAM
    243.             #pragma prefer_hlslcc gles
    244.      
    245.             #pragma multi_compile_instancing
    246.      
    247.             #pragma vertex vert
    248.             #pragma fragment frag
    249.      
    250.             //#include "LWRP/ShaderLibrary/Core.hlsl"
    251.             #include "Packages/com.unity.render-pipelines.lightweight/ShaderLibrary/Core.hlsl"
    252.  
    253.             //#include "LWRP/ShaderLibrary/Lighting.hlsl"
    254.             #include "Packages/com.unity.render-pipelines.lightweight/ShaderLibrary/Lighting.hlsl"
    255.  
    256.             /*ase_pragma*/
    257.             //uniform float4 _ShadowBias;
    258.             uniform float3 _LightDirection;  
    259.          
    260.             CBUFFER_START(UnityPerMaterial)
    261.             /*ase_globals*/
    262.             CBUFFER_END
    263.             /*ase_funcs*/
    264.                  
    265.             struct GraphVertexInput
    266.             {
    267.                 float4 vertex : POSITION;
    268.                 float3 ase_normal : NORMAL;
    269.                 /*ase_vdata:p=p;n=n*/
    270.                 UNITY_VERTEX_INPUT_INSTANCE_ID
    271.             };
    272.  
    273.             struct GraphVertexOutput
    274.             {
    275.                 float4 clipPos : SV_POSITION;
    276.                 /*ase_interp(0,):sp=sp.xyzw;*/
    277.                 UNITY_VERTEX_INPUT_INSTANCE_ID
    278.                 UNITY_VERTEX_OUTPUT_STEREO
    279.             };
    280.  
    281.             GraphVertexOutput vert (GraphVertexInput v/*ase_vert_input*/)
    282.             {
    283.                 GraphVertexOutput o;
    284.                 UNITY_SETUP_INSTANCE_ID(v);
    285.                 UNITY_TRANSFER_INSTANCE_ID(v, o);
    286.                 UNITY_INITIALIZE_VERTEX_OUTPUT_STEREO(o);
    287.  
    288.                 /*ase_vert_code:v=GraphVertexInput;o=GraphVertexOutput*/
    289.  
    290.                 v.vertex.xyz += /*ase_vert_out:Vertex Offset;Float3;2;-1;_Vertex*/ float3(0,0,0) /*end*/;
    291.                 v.ase_normal = /*ase_vert_out:Vertex Normal;Float3;3;-1;_Normal*/ v.ase_normal /*end*/;
    292.  
    293.                 float3 positionWS = TransformObjectToWorld(v.vertex.xyz);
    294.                 float3 normalWS = TransformObjectToWorldDir(v.ase_normal);
    295.  
    296.                 float invNdotL = 1.0 - saturate(dot(_LightDirection, normalWS));
    297.                 float scale = invNdotL * _ShadowBias.y;
    298.  
    299.                 positionWS = normalWS * scale.xxx + positionWS;
    300.                 float4 clipPos = TransformWorldToHClip(positionWS);
    301.  
    302.                 clipPos.z += _ShadowBias.x;
    303.                 #if UNITY_REVERSED_Z
    304.                     clipPos.z = min(clipPos.z, clipPos.w * UNITY_NEAR_CLIP_VALUE);
    305.                 #else
    306.                     clipPos.z = max(clipPos.z, clipPos.w * UNITY_NEAR_CLIP_VALUE);
    307.                 #endif
    308.                 o.clipPos = clipPos;
    309.                 return o;
    310.             }
    311.      
    312.             half4 frag (GraphVertexOutput IN /*ase_frag_input*/) : SV_Target
    313.             {
    314.                 UNITY_SETUP_INSTANCE_ID(IN);
    315.  
    316.                 /*ase_frag_code:IN=GraphVertexOutput*/
    317.  
    318.                 float Alpha = /*ase_frag_out:Alpha;Float;0;-1;_Alpha*/1/*end*/;
    319.                 float AlphaClipThreshold = /*ase_frag_out:Alpha Clip Threshold;Float;1;-1;_AlphaClip*/AlphaClipThreshold/*end*/;
    320.              
    321.                 #if _AlphaClip
    322.                     clip(Alpha - AlphaClipThreshold);
    323.                 #endif
    324.                 return Alpha;
    325.             }
    326.             ENDHLSL
    327.         }
    328.      
    329.         /*ase_pass*/
    330.         Pass
    331.         {
    332.             /*ase_hide_pass*/
    333.             Name "DepthOnly"
    334.             Tags{"LightMode" = "DepthOnly"}
    335.  
    336.             ZWrite On
    337.             ColorMask 0
    338.  
    339.             HLSLPROGRAM
    340.             #pragma prefer_hlslcc gles
    341.  
    342.             #pragma multi_compile_instancing
    343.  
    344.             #pragma vertex vert
    345.             #pragma fragment frag
    346.  
    347.             //#include "LWRP/ShaderLibrary/Core.hlsl"
    348.             #include "Packages/com.unity.render-pipelines.lightweight/ShaderLibrary/Core.hlsl"
    349.  
    350.             //#include "LWRP/ShaderLibrary/Lighting.hlsl"
    351.             #include "Packages/com.unity.render-pipelines.lightweight/ShaderLibrary/Lighting.hlsl"
    352.  
    353.             /*ase_pragma*/
    354.          
    355.             CBUFFER_START(UnityPerMaterial)
    356.             /*ase_globals*/
    357.             CBUFFER_END
    358.             /*ase_funcs*/
    359.  
    360.             struct GraphVertexInput
    361.             {
    362.                 float4 vertex : POSITION;
    363.                 float3 ase_normal : NORMAL;
    364.                 /*ase_vdata:p=p;n=n*/
    365.                 UNITY_VERTEX_INPUT_INSTANCE_ID
    366.             };
    367.  
    368.             struct GraphVertexOutput
    369.             {
    370.                 float4 clipPos : SV_POSITION;
    371.                 /*ase_interp(0,):sp=sp.xyzw;*/
    372.                 UNITY_VERTEX_INPUT_INSTANCE_ID
    373.                 UNITY_VERTEX_OUTPUT_STEREO
    374.             };
    375.  
    376.             GraphVertexOutput vert (GraphVertexInput v/*ase_vert_input*/)
    377.             {
    378.                 GraphVertexOutput o;
    379.                 UNITY_SETUP_INSTANCE_ID(v);
    380.                 UNITY_TRANSFER_INSTANCE_ID(v, o);
    381.                 UNITY_INITIALIZE_VERTEX_OUTPUT_STEREO(o);
    382.  
    383.                 /*ase_vert_code:v=GraphVertexInput;o=GraphVertexOutput*/
    384.  
    385.                 v.vertex.xyz += /*ase_vert_out:Vertex Offset;Float3;2;-1;_Vertex*/ float3(0,0,0) /*end*/;
    386.                 v.ase_normal = /*ase_vert_out:Vertex Normal;Float3;3;-1;_Normal*/ v.ase_normal /*end*/;
    387.                 o.clipPos = TransformObjectToHClip(v.vertex.xyz);
    388.                 return o;
    389.             }
    390.  
    391.             half4 frag (GraphVertexOutput IN /*ase_frag_input*/) : SV_Target
    392.             {
    393.                 UNITY_SETUP_INSTANCE_ID(IN);
    394.  
    395.                 /*ase_frag_code:IN=GraphVertexOutput*/
    396.  
    397.                 float Alpha = /*ase_frag_out:Alpha;Float;0;-1;_Alpha*/1/*end*/;
    398.                 float AlphaClipThreshold = /*ase_frag_out:Alpha Clip Threshold;Float;1;-1;_AlphaClip*/AlphaClipThreshold/*end*/;
    399.              
    400.                 #if _AlphaClip
    401.                     clip(Alpha - AlphaClipThreshold);
    402.                 #endif
    403.                 return Alpha;
    404.             }
    405.             ENDHLSL
    406.         }
    407.      
    408.         /*ase_pass*/
    409.         Pass
    410.         {
    411.             /*ase_hide_pass*/
    412.             Name "Meta"
    413.             Tags{"LightMode" = "Meta"}
    414.             Cull Off
    415.  
    416.             HLSLPROGRAM
    417.             // Required to compile gles 2.0 with standard srp library
    418.             #pragma prefer_hlslcc gles
    419.  
    420.             #pragma vertex LightweightVertexMeta
    421.             #pragma fragment LightweightFragmentMeta
    422.  
    423.             #pragma shader_feature _SPECULAR_SETUP
    424.             #pragma shader_feature _EMISSION
    425.             #pragma shader_feature _METALLICSPECGLOSSMAP
    426.             #pragma shader_feature _ _SMOOTHNESS_TEXTURE_ALBEDO_CHANNEL_A
    427.             #pragma shader_feature EDITOR_VISUALIZATION
    428.  
    429.             #pragma shader_feature _SPECGLOSSMAP
    430.  
    431.             //#include "LWRP/ShaderLibrary/InputSurfacePBR.hlsl"
    432.             #include "Packages/com.unity.render-pipelines.lightweight/Shaders/LitInput.hlsl"
    433.  
    434.             //#include "LWRP/ShaderLibrary/LightweightPassMetaPBR.hlsl"
    435.             #include "Packages/com.unity.render-pipelines.lightweight/Shaders/LitMetaPass.hlsl"
    436.  
    437.             ENDHLSL
    438.         }
    439.     }
    440.     CustomEditor "ASEMaterialInspector"
    441. }
    442.  
     
  3. GameDevCouple_I

    GameDevCouple_I

    Joined:
    Oct 5, 2013
    Posts:
    2,183
    can anyone tell me if LWRP is getting compute shader support at any stage?
     
  4. Grimreaper358

    Grimreaper358

    Joined:
    Apr 8, 2013
    Posts:
    574
    This is said to be in 2019.1.
     
    GameDevCouple_I likes this.
  5. equalsequals

    equalsequals

    Joined:
    Sep 27, 2010
    Posts:
    105
    What would you be using the Computer Shaders for? In our branch (4.10 equivalent, 2018.3) we dispatch Compute to handle some Indirect Instancing, so even now it's possible.
     
  6. GameDevCouple_I

    GameDevCouple_I

    Joined:
    Oct 5, 2013
    Posts:
    2,183
    Mostly for metaballs simulation currently, but could have other uses in this project too.
     
  7. Andre_Mcgrail

    Andre_Mcgrail

    Unity Technologies

    Joined:
    Dec 9, 2016
    Posts:
    164
    Currently there is nothing stopping you from using compute shaders, we just avoid using them in the base pipeline due to the fragmented support on mobile hardware.
     
    GameDevCouple_I likes this.
  8. GameDevCouple_I

    GameDevCouple_I

    Joined:
    Oct 5, 2013
    Posts:
    2,183
    Thanks, does this mean that VFX graph is working for LWRP then on platforms supporting it? Such as OpenGL ES 3.1 platforms?
     
  9. bitinn

    bitinn

    Joined:
    Aug 20, 2016
    Posts:
    554
  10. GameDevCouple_I

    GameDevCouple_I

    Joined:
    Oct 5, 2013
    Posts:
    2,183
  11. Andre_Mcgrail

    Andre_Mcgrail

    Unity Technologies

    Joined:
    Dec 9, 2016
    Posts:
    164
    Yes, we now have support for unlit VFX graphs in LWRP in >5.8.x(19.1) and >6.6.x(19.2) this has only just been put in so expect some issues, I have seen it running on both android and iOS though with my own eyes :)
     
    Noisecrime and GameDevCouple_I like this.
  12. GameDevCouple_I

    GameDevCouple_I

    Joined:
    Oct 5, 2013
    Posts:
    2,183
    That is epic, really looking forward to playing with this in current project! THanks!
     
  13. Pivetta

    Pivetta

    Joined:
    Oct 11, 2013
    Posts:
    15
    Hi!
    After my googling I couldn't find anything about that.
    I have some meshes being displaced over time by a shader made with ShaderGraph
    When I have multiple in the scene unity tries to batch them and they get messy, the vertices are rendered in crazy places - funny enough from some view angles they get back to normal (I didn't use any view based propriety)

    I just solved by making a new instance of the material on runtime.
    Is this kind of an issue or it's a normal behavior?

    In my case I was making wind whirls by pushing vertices around

    Working clean:

    Broken:
     
  14. equalsequals

    equalsequals

    Joined:
    Sep 27, 2010
    Posts:
    105
    If the meshes are batched their positions change in local space. This will cause issues like the one you are seeing. You either have to disable batching on these objects or do something like encode the original positions in the mesh somehow and adjust in the Shader.
     
  15. sebastiansgames

    sebastiansgames

    Joined:
    Mar 25, 2014
    Posts:
    114
    Someone else asked if culling layers for base cam would be supported and I’d second that question. I really don’t have words to express how shocked I was to read that LWRP wouldn’t support camera stacking. What?! That’s always been how Unity has worked and is a vital part of the workflow. It’s like saying well game objects won’t have transforms or we’re doing away with components. I’ve been playing with LWRP for a while and had no idea this was a limitation until diving deep into this buried thread. You guys gotta put that limitation FRONT AND CENTER underlined in bold at the top of LWRP docs: no camera stacking! It’s a big deal and makes the whole pipeline mostly useless to me.

    I understand you can get even more amazing performance from optimizing to one camera- I don’t care. My projects work fine. I need the ease of use I expect with Unity to slap a camera on there when I need to to render a UI or a different perspective or a particle effect or whatever. I don’t want my engine telling me nope that’s a hack and will cost performance. I know it will cost performance but as the developer I am making that choice.

    My opinion is that ultra performance single cam setup should be saved for the micro/tiny pipeline or whatever it’s called. Incredibly frustrating.
     
  16. bitinn

    bitinn

    Joined:
    Aug 20, 2016
    Posts:
    554
    A quick question: are "Receive Shadow" on Mesh Render missing for a reason? I don't see they in LWRP 4.x, but they are present for built-in pipeline.

    (Yes I am on 4.x, but let me know if it is fixed on 5.x?)

    Screen Shot 2019-04-05 at 21.53.13.png Screen Shot 2019-04-05 at 21.53.56.png
     
  17. StefDevs

    StefDevs

    Joined:
    Jan 20, 2014
    Posts:
    13
    They're building new workflow for camera stacking use-cases for initial full release, so what's the issue exactly? Even if they weren't, LWRP is clearly marked as preview and not production ready and so I don't think it's fair in any way to be upset about a missing feature. The built-in render pipeline did not disappear.

    Personally I'm very happy with how they appear to be addressing it for 2019.1.
     
  18. sebastiansgames

    sebastiansgames

    Joined:
    Mar 25, 2014
    Posts:
    114
    I agree that getting upset is not helpful at all. So I apologize -- I was, however, pretty emotional about this announcement because I've personally invested a lot of blood, sweat and tears in a long term project using this tech, where if the decision is made to forego camera stacking... I'll start writing my obituary. Re your point about 'full release' v 'initial release' -- yes, understood that this is in development. However as devs with long term projects what choice do we have but to take a chance on future pipelines that are slated to mature when we imagine our projects coming to maturity? There is certainly the built-in render pipeline -- but for how long? Will it still be supported 2 years from now? Built-in is not compatible with the new features Unity is rolling out (Shader graph/VFX graph) - will built in continue to be supported? That's also a gamble in my opinion. Either way it's like trying to hit a moving target two years into the future.

    My larger point was about camera stacking in general. We're basically talking about layers. If there's a new culling based layer system instead of camera stacking I'm a happy camper. That's not what I saw in the demo of the layer system. I saw a base cam, an off world cam, and a UI cam (I think there was one other). That is three/four layers.

    Maybe that does wonders for performance, but in my opinion limiting to 3 or 4 engine defined layers cripples the creative toolset and what we can design if our project is more than 'build a 3D world and stick a camera in it.' I know this is still in flux... as a longtime user I'm pleading with LWRP team to consider at least giving us the option to stack cameras (or layers) if we choose certain looks over performance: ie -- you want particles in your UI? Add a particle camera for that. The UI camera can't render them. Or is the answer really just no particles for you?

    Thanks for considering my opinion and apologies for getting riled up.
     
  19. StefDevs

    StefDevs

    Joined:
    Jan 20, 2014
    Posts:
    13
    Oh I see, I think you've misunderstood the new workflow demo. From my understanding, there doesn't appear to be a limit on the number of cameras/layers that you stack, and culling layers would stay just as they are so you can decide what cameras draw what. You can stack as many overlay cameras as you'd like on top of a base camera. I'm not sure exactly how the UI camera differs from the others, and if the workflow supports stacking on top of UI cameras, but I'm sure if nothing else you could use a normal 3D overlay camera to render your UI in the middle of a stack.

    "Base" camera will draw normally after re-initializing the frame buffers or whatever else needs doing at the start of a drawing cycle.
    "Overlay" camera(s) can be used to draw after the base camera without re-initializing frame buffers etc.
    "Offscreen" camera will be used to render to a different buffer specified by the user (ie: render textures)
    "UI" camera I'm guessing will offer a more performant way to draw UI, since there are some optimization opportunities there

    Sorry if I'm butchering this Unity devs :p I stand to be corrected since I'm not actually privy to the wip implementation, this is just what I gather from the demo.
     
  20. sebastiansgames

    sebastiansgames

    Joined:
    Mar 25, 2014
    Posts:
    114
    Fantastic!! I'm hyperventilating reading 'no stacked cameras no stacked cameras' in this thread... but if it works as you say that's great!
     
    StefDevs likes this.
  21. Ziboo

    Ziboo

    Joined:
    Aug 30, 2011
    Posts:
    326
    Hi,

    Just watch the GDC talk : "Empowering Creators with the New Unity Render Pipeline "

    I wanted to know if there is a repo with the samples shown in the talk ? With the new RenderFeatures for LWRP.

    Thanks
     
    createtheimaginable likes this.
  22. bitinn

    bitinn

    Joined:
    Aug 20, 2016
    Posts:
    554
    Is this a free session? I can't find it on Youtube, the GDC vault video wouldn't play for me ...
     
    P_Jong likes this.
  23. Ziboo

    Ziboo

    Joined:
    Aug 30, 2011
    Posts:
    326
    P_Jong likes this.
  24. bitinn

    bitinn

    Joined:
    Aug 20, 2016
    Posts:
    554
  25. foolmoron

    foolmoron

    Joined:
    Jun 22, 2013
    Posts:
    40
    Using the LWRP VR setup for Oculus Go (Android build). Great so far except I get the insane 1h+ compiling shader variants build issue.

    But what's weird is every build after that it still has to go through all the shader variants and do..... something? No idea what it could be doing since nothing changed, but it adds a couple minutes to the build (dominating the total build time) no matter what.

    Is there any way to at least skip the shader stuff when nothing has changed?
     
    fherbst likes this.
  26. foolmoron

    foolmoron

    Joined:
    Jun 22, 2013
    Posts:
    40
    Actually the post processing stack doesn't work at all on Oculus Go with the VR LWRP template. Is this expected or are there other settings to change to make it with with Android?
     
  27. demonixis

    demonixis

    Joined:
    Aug 20, 2013
    Posts:
    93
    @foolmoron the stack is disabled on mobile for now, I don't know when it'll be renabled.
    I switched back to the legacy Forward Renderer, build time are now about 10/15 minutes, which is better than 2 hours. I don't know why shaders are recompiled on each build. No communication about that since I reported the issue more than 6 months ago.
     
  28. GameDevCouple_I

    GameDevCouple_I

    Joined:
    Oct 5, 2013
    Posts:
    2,183
    I also have reported it and it seems to be being ignored. I had an entire thread about it.
     
    fherbst likes this.
  29. Pivetta

    Pivetta

    Joined:
    Oct 11, 2013
    Posts:
    15
    Just another newbie question (I googled it but couldn't find a solution)
    Is there a way to force sorting order in LWRP?
    I'd like to use a single camera and render the UI elements (working in VR so it's meshes) in front of any other geometry
    Just didn't find much about the subject.
    I bet I am supposed to take a peek into the LWRP source code to get it running.
    I wanted anyways also to remove the light probes rendering and the transparency test from my pipeline.

    Cheers and thanks as always!
     
  30. xanaramus

    xanaramus

    Joined:
    Sep 21, 2018
    Posts:
    2
    Hello everyone! Is there any way to make shader in LWRP that can handle lightmap texture from 3d max?
     
  31. foolmoron

    foolmoron

    Joined:
    Jun 22, 2013
    Posts:
    40
    Yeah I'm about to go back to legacy also Weird how they aren't handling this issue.
     
  32. Thrawn75

    Thrawn75

    Joined:
    Nov 16, 2014
    Posts:
    2,257
    Hi,
    It seems that LWRP doesn't define unity_CameraInvProjection anywhere but it has unity_StereoCameraInvProjection[] instead when running in Single Pass Stereo.
    Is this a bug or intended? /cc @Andre_Mcgrail
     
    Last edited: Apr 10, 2019
  33. equalsequals

    equalsequals

    Joined:
    Sep 27, 2010
    Posts:
    105
    In LWRP Receive Shadows is defined per Material.
     
    P_Jong likes this.
  34. LukWol

    LukWol

    Joined:
    Nov 12, 2015
    Posts:
    12
  35. ahmidou

    ahmidou

    Joined:
    Sep 17, 2012
    Posts:
    81
    So is that LWRP UI for custom pass available yet?
     
    andrzej_cadp likes this.
  36. Voronoi

    Voronoi

    Joined:
    Jul 2, 2012
    Posts:
    282
    Does anyone know if either the LWRP or HDRP will support simply one camera, set to 'Don't Clear' or similar? I would like to use the VFX graph to create artistic effects, like a trail of where particles have been. This creates a nice, smearing effect, and combined with a transparent quad overlay, looks very rich and complex.

    From what I can see in the demo, and my experiments with LWRP and HDRP, there is no equivalent available. Is the Overaly camera rending on top with an alpha layer or is it an 'overlay' as in additive?
     
  37. binaristudios

    binaristudios

    Joined:
    Jun 18, 2018
    Posts:
    2
    @Pivetta Any news on forcing sorting order in LWRP? I am working in AR and struggling with a similar issue.
     
  38. Pivetta

    Pivetta

    Joined:
    Oct 11, 2013
    Posts:
    15
    Had other tasks to go after before this one. I'm putting my hands on it maybe in 2 months.
    If it suit your pursue and works on your setup you could do use the multi camera rendering system they are talking about a few posts before.
     
  39. bitinn

    bitinn

    Joined:
    Aug 20, 2016
    Posts:
    554
    Last edited: Apr 11, 2019
    P_Jong likes this.
  40. alanmthomas

    alanmthomas

    Joined:
    Sep 7, 2015
    Posts:
    171
    This looks absolutely amazing. Is this available in some preview version to try it out? Also, are the overlay cameras able to get their own post processing effects? Something like blurring a single camera and then stacking it on top of an unblurred camera?
     
    Last edited: Apr 12, 2019
  41. iamarugin

    iamarugin

    Joined:
    Dec 17, 2014
    Posts:
    229
    This will be available in 2019.2
     
  42. Jean-Moreno

    Jean-Moreno

    Joined:
    Jul 23, 2012
    Posts:
    435
    Hi there,
    Will there be any easy way to add additional per-light data (e.g. an additional color) that can then be reused in a shader, or does that require to modify a few scripts manually? (e.g. `ForwardLights.cs`)
     
    Last edited: Apr 12, 2019
  43. bitinn

    bitinn

    Joined:
    Aug 20, 2016
    Posts:
    554
    You would be looking at Lighting.hlsl, but I don't think you can add additional data as unity_LightData are set by engine itself.

    Probably easier to use a global shader property? not a pure shader approach unfortunately.

    https://github.com/Unity-Technologi...lines.lightweight/ShaderLibrary/Lighting.hlsl
    https://github.com/Unity-Technologi...eight/ShaderLibrary/UnityInput.hlsl#L102-L105
     
  44. Jean-Moreno

    Jean-Moreno

    Joined:
    Jul 23, 2012
    Posts:
    435
    Well there needs to be both a C# and shader side.
    The main issue to me on the C# side is that I need a way to fill the shader property array with the correct light index, as the list of passed lights isn't necessarily the same for each object; so having a script to fill a global shader property wouldn't work here. Thus I believe it should be plugged somewhere in ForwardLights.cs since this is where the lights data is filled, hence why I'm asking if any way to extend that script are existing/planned or not.
    On the shader side, I could indeed have a global array and retrieve the information there, just as it's done with GetAdditionalLight(), so this part isn't problematic.

    All that being said, I've just watched this LWRP Unity GDC video and learned about the existence of custom forward renderers, and also saw this in the 5.7.0 changelog:
    So maybe this is the way to go? But that'd mean bypassing the default render passes entirely maybe?
     
  45. bitinn

    bitinn

    Joined:
    Aug 20, 2016
    Posts:
    554
    As the class is internal, I doubt it was meant to be extended by users.

    This sounds more promising, I just checked the source, it allow you to inject more light data before ForwardLights' setup stage through RenderingData.

    It however requires you to implement the ScriptableRenderer class, not sure if it's the recommended way as I am still on 4.x, so have none of these luxury :(

    ===

    By the way, I think it depends on how much light color data you need to share, if just a handful of colors, perhaps a global light color array + per material index is easier than implementing the whole renderer. If you want to have per-object light color, perhaps material property is easier...
     
  46. Jean-Moreno

    Jean-Moreno

    Joined:
    Jul 23, 2012
    Posts:
    435
    Yes everything is internal so I can't override anything... too bad! :/
    Does this mean we're supposed to manually write a full custom ScriptableRenderer class if we want to use that feature?

    The color was just an example, I'm mostly exploring possibilities right now.
    But the main idea would be for my Toony Colors Pro 2 shaders, where currently you can define ramp shading on the materials: I'm imagining a different workflow where the ramp settings are actually per light and not per material. Or both! Or implementing negative lights for example.
    And as this would eventually be for the Asset Store, it needs to be flexible and easy enough to setup for users.
     
    chiapet1021 likes this.
  47. bitinn

    bitinn

    Joined:
    Aug 20, 2016
    Posts:
    554
    Certainly looks that way to me, so probably not very applicable if you have to ask your users to use a custom renderer instead of the default forward renderer.

    I haven't used the TCP2's ramp generator yet, but I imagine you pass the gradient as a texture? If so, perhaps a texture array is better. Where you allow users to create a list of ramps, which will then be submit to shader as a global property, then on the material you just set the index to the texture. That's how I would implement it anyway...
     
  48. bitinn

    bitinn

    Joined:
    Aug 20, 2016
    Posts:
    554
    Thx, and I just discovered what actually happened was the Shader GUI would read the _ReceiveShadow property and then set the _RECEIVE_SHADOWS_OFF keyword.

    So instead of MeshRenderer.receiveShadows, we should now use Material.GetFloat("_ReceiveShadows") to get this value...

    https://github.com/Unity-Technologi...t/Editor/ShaderGUI/BaseShaderGUI.cs#L388-L389
     
  49. Jean-Moreno

    Jean-Moreno

    Joined:
    Jul 23, 2012
    Posts:
    435
    What you describe is still a per material value! What I would like to (easily) be able to do is setup a value per light. Anyway let's not hijack the topic too much! :)
    I think to be more accurate you'd be better off using Material.IsKeywordEnabled("_RECEIVE_SHADOWS_OFF")!
     
  50. Andre_Mcgrail

    Andre_Mcgrail

    Unity Technologies

    Joined:
    Dec 9, 2016
    Posts:
    164
    So this is part of a bigger issue, and just to make sure you all know, we are not ignoring the issue, it unfortunately is just severely deep rooted in our code base. The problem is that the SRPs are still largely using code that was created years ago, especially on the shader compilation side, and up until now it could handle what was being thrown at it, but with the introduction of a more open customisable rendering system this is making all the flaws of the old system come to surface, meaning this is simple not a trivial issue. It spreads from our shader compiler, the way our shader lab code works, how the renderer(the actual Gfx Device) looks at data. The other issues are things that are still controlled largely by the builtin renderer, these are the quality settings and graphics tiers that are still injecting shader variants when not needed, and even things like our mesh optimisation needing to go over each shader twice to do it's job.
    In saying this there are somethings you can do in the meantime to make life a little less painful as you should definitely not be seeing 2+hour build times each time you build, I know this because I do anywhere from 5-30 builds every day of projects in LWRP, yes the first build is always the worst, but subsequent builds should be much smoother and to answer the question about subsequent unchanged builds taking time, this is due to the shader stripper, but again this doesn't take more that 2 minutes for a 12k variant shader.

    Things you can try to keep builds quick:
    1) Only build the Gfx APIs you need to use at the time, each API needs its own variants.
    2) Only enable the things you need on the LWRP asset as these will count to the variants that can be stripped and not compiled(saving time).
    3) Use 2019.1 and LWRP, we have made improvements across the board including lowering the variants needed in shaders.
    4) Use shadergraph if you are not aiming for lowest hardware as they only have the variants needed at the rendering side, they are less optimised than the LWRP shaders but this is negligible on anything other than the low end of the mobile spectrum.
    5) If you are using the LWRP shaders, make sure you use a similar texture/material authoring throughout as this will lead to less variants, for example, don't mix Specular/Metallic workflows unless you absolutely have to, try have similar map usage throughout the game, if every material has a BaseMap, NormalMap and EmissionMap, that's one variant, if they are mixed they will tend to raise the count by the power of 2.
    6) IMPORTANT: Disable 'Optimize Mesh Data' in players settings for all but your final builds, this if enabled, will add a stupid amount of time to the shader compilation time.

    Currently on our end we are trying to schedule work to remove SRPs reliance on graphics tiers, solving the bad mesh optimisations slowdown. Work will be done soon for also exposing things such as Shader Complexity, where if you know what platforms/hardware you are aiming for you can lower the shader variant count(shader compiling time) at a cost of performance. Far in the future we are also working to make a Shader and Renderer system that can keep up with the new way SRPs work and also integrate speed ups from the DOTS ecosystem. Trust me we are not ignoring this issue, and it is our biggest one on our list, it is the top priority for the LWRP team.

    It was disabled a while ago as there were a number of servers bugs, these have since been fixed and post should be working now in XR, what version of LWRP are you using?

    For sorting order(render queue) you can offset the default LWRP shaders, for rendering something on top of everything else have a watch of this as it should solve your use case:

    As for light probes, if you don't have them in the scene and don't bake them, they won't exist :) and the transparency test I'm not sure I understand, do you not want to run the transparent pass? or for transparents to ignore depth?

    _InvCameraViewProj might get you what you want, you can find it here. Otherwise I see we don't set it, I'm not sure why this decision was made I will have to get back to you about it, I'm assuming performance reason.

    Yes, it is currently in 19.1, I would suggest grabbing LWRP 5.7.2.

    Not out of the box in LWRP, but a simple post effect could be made that essentially mimics the effect(it would actually be identical) which you are saving the frame after rendering and then starting with that before rendering the next frame, this was removed because obviously when you just want to stack one camera on another this was way too expensive for what it was doing(which is another reason we are changing the camera stacking right now). I get your point though, and recently when playing around doing some audio visualisation stuff I really wanted this feature, so I might look into making a quick effect myself.

    No easy way, the simplest would be creating your own ScriptableRenderer based off our forward renderer, but also LWRP still relies on some old Unity code for setting this stuff, which we are working to remove since right now it's still not fully customisable(even for us unless we change engine C++ code which isn't the point of SRPs).

    This is the exact thing we created the ScriptableRenderer for, the idea that you can completely customise the renderer without having to re-create a whole SRP by hand. Would be interested in hearing your thoughts on if it would work well for you, currently our 2D team are using it for making a 2D renderer in LWRP, and soon we will be using it to make a Deferred renderer, seeing a Toon renderer get made would be super cool to see.
     
    ekakiya, hippocoder, fherbst and 5 others like this.
Thread Status:
Not open for further replies.