Feedback Wanted: Lightweight Render Pipeline

Been looking into the LWRP now, and if I'm not mistaken, the thing that strikes me as problematic is that if I want to make a smaller change/addition I more or less need to copy the whole thing in order to retain the featureset. This is fine once, but it will in the end mean quite a lot of work trying to maintain it and keep it up to date with the official changes.

I would prefer the LWRP to be a bit less object oriented, and more library-like. So that methods like for instance SetupShadowReceiverConstants are not private methods of the pipeline class, but rather public utility functions of a support class. That way one can keep a pretty small custom core pipeline class, and reuse most of the LWRP functionallity except for the things you want to specifically change.

At least the methods and fields should be protected rather than private so that I can inherit the LWRP and call the functions from a subclass. Allthough in my view this is not as good as a utility library part of the same package.

 

The thing that concerns me the most with the ScriptableRenderPipelines is that to change and modify them, that still seems to require a pretty indepth amount of graphical programming knowledge.

There doesn't seem to be a suitable mid-range between the HDRP and the LWRP, meaning a very black and white choice for people unable to modify them.

 

But that's just the nature of things. Some things will always require a little more specialisation. You can't expect every racing driver to also be a top quality mechanic, at least not until AI is good enough to fill in the blanks.

Seems to me that I could achieve most of builtin Unity with LW give or take a few quality tweaks. I would like to for instance add tessellation so I'll be looking into that.

 

The problem is the current renderer is just way more dynamic. Thus moving to the scriptable render pipelines is a loss of function and ability for the engine.

Yes, we get some performance and graphic improvements (in theory), but for a lot of indie developers, these pipelines are just going to block them in more than the original rendering engine does.

 

I have no problem with it requiring deep graphics programming skills. But the current architecture seems too rigid in my opinion, making it time-consuming to maintain smaller customizations over time, while still staying up to date with Unity's improvements.

 

But making SRP exactly like the existing builtin engine will cause the same problems. What SRP asks you to do is make a decision, and then use shader graph to continue.

That you're posting on lightweight means you want performance. But at the same time you want all the old features. That does not make sense. The reason LW is faster is because it does not do what the existing engine does. It does a lot less, and what it does do, it does differently. It is not necessarily faster either.

That's my findings so far though, I'm sure you might find things different from your game's perspective. Tried the shader graph?

 

but won't the old basic setup be available as a choice as well? (i thought i read that somewhere). And I'm sure the asset store will be brimming with other "User created Pipelines" ... in the near future.

 

This sounds much like Valve's implementation for Single Pass with shadows? Very excited for the render pipeline and what magicians are going to do with Unity.

 

I just tried to get my Editor Extension running with SRP and apparently the camera events OnPreCull, OnPreRender and OnPostRender are not triggered. The manual seems to provide no information if these events have been deprecated.

@Tim-C: Shall I report this as a bug or is there a new way to subscribe to these events?

Edit: Reported as Case 1004625.

 

So basically artists of a 2d game can author content in 1x and scale down, as expected, on each screen, at runtime(because the renderer is accessible at runtime), while having a guarantee that the UI will stay crisp?

 

[Potential bug]: Seems as if the Environment Lighting settings in the Lithting Window does nothing. And whenever I hit play they are reset to the default settings of skybox + intensity 1.

 

I have seen a mention that this is fixed in 2018.1b9.

 

Is there some info on how to setup the lightweight render pipeline in a new project? In a new project I have tried to right click to create the lightweightrender asset, but there is no option there. I have also tried dragging and dropping the asset from the lightweightandshadergraph project into a new project and it does not seam to recognize it. What am I missing?

Thanks

 

Open up the package manager (Window menu) and make sure the LWRP package is added to your project. Or you can clone the repo from github into your project. If you want to edit the code that is.

 

These steps are based off of 2018.1b8 and are really easy to follow:

1) Open the Package Manager (Window -> Package Manager)
2) Select 'All' and then select 'Render-pipelines.lightweight' and then 'Install'.
3) Once the installation as (successfully) finished, go to the Project Window and 'Create -> Rendering -> Lightweight Pipeline Asset'.
4) Open the Graphics Settings Window and set the newly-made Lightweight asset as the Scriptable Render Pipeline Asset.
5) Done! However, some of your materials might render in error-magenta and you might want to update these to use shaders that are compatible with the Lightweight Render Pipeline. You can do this manually (By selecting the desired Lightweight Shader in a Material's Inspector's Shader Menu; a set are included in the LW package when it is installed) or by using the Upgrade Material Tool (Edit -> Render Pipeline -> Upgrade Materials to Lightweight Materials).

 

@Andy-Touch: Do you have any information regarding the problem mentioned in my previous post?

 

Nope; probably better for someone more knowledgable (like @Tim-C) to respond.

 

Hi,

I just installed Unity 2018.1.0b9 and made a new project with LightWeight Pipeline (Both VR n normal ) ... but the moment the unity opens it gives an error

Shader error in 'LightweightPipeline/Standard (Physically Based)': failed to open source file: 'LWRP/ShaderLibrary/LightweightPassLit.hlsl' (on metal)

Compiling Vertex program
Platform defines: UNITY_NO_DXT5nm UNITY_ENABLE_REFLECTION_BUFFERS UNITY_NO_CUBEMAP_ARRAY UNITY_USE_DITHER_MASK_FOR_ALPHABLENDED_SHADOWS UNITY_PBS_USE_BRDF1 UNITY_SPECCUBE_BOX_PROJECTION UNITY_SPECCUBE_BLENDING UNITY_ENABLE_DETAIL_NORMALMAP SHADER_API_DESKTOP UNITY_LIGHT_PROBE_PROXY_VOLUME UNITY_LIGHTMAP_DLDR_ENCODING


I cant see any object in the scene and the Lightweight shaders are in the section of FAILED TO COMPILE .... Please tell me how to solve this problem.

I tried switching the platform to Android and Standalone but all the same

 

I was attempting to build the Lightweight Render Pipeline for Google Daydream, but I am running into a shader compiler error. Specifically:

Code (csharp):

1.  
2. Shader error in 'graphs/PBRMetallicShaderGraphExample': Did not find shader kernel 'ShadowPassFragment' to compile (on gles3)
3.  

Is gles3 not supported yet, or is there a way to get it to work? Will using the LWRP be viable on Daydream/GearVR any time soon? I am very interested in the extra flexibility of the LWRP for mobile VR because it requires careful balancing of quality/performance, and I've been running into a few issues that are a headache to work around with the built-in renderer (like how it turns off vertex lights when lighting is baked).

 

It looks like recent updates to the LWRP have moved from doing the directional shadow sampling in the shader to doing a pre-pass similar to the built in Unity forward renderer. While there are obviously performance benefits to this, (as is why Unity did it to begin with) it's terrible for VR as it fights against MSAA. It's been a long time problem with Unity for quality VR. I know several devs have chosen to reimplement lights and shadows themselves, or use some kind of nearest depth fixup hack like I posted here (and used variants of in two shipping PSVR titles):
https://forum.unity.com/threads/fixing-screen-space-directional-shadows-and-anti-aliasing.379902/

Though, it kind of doesn't matter since MSAA hasn't worked in the LW pipeline for months ...

 

Thanks guys, that is exactly what I was looking for.

 

VR realtime shadows seem broken right now with 1.0.0-beta. It renders fine in editor view but in headset it seems like the worldspace is broken. Reproduced in 2018.1.0b8 and 2018.1.0b9. Blank project with LWRP package imported.

 

That's the new screen space shadows being broken in single pass.

 

Has anyone else tried subtractive mixed mode lighting with the LWRP mixing baked and realtime shadows?

If I have lightmap static enabled on a renderer it won't receive realtime shadows.

Pretty easy to reproduce:

Set your lighting settings to Mixed Lighting - Baked - Subtractive.
Set your directional light to mixed mode.
Create a plane, set it to lightmap static, assign a material with LW standard shader.
Create a cube, set it to lightmap static, place it so it casts a shadow onto the plane, assign a material with LW standard shader.
Create a sphere, place it so it casts a shadow onto the plane, assign LW material.

The sphere won't cast a shadow onto the plane. If you turn off lightmap static on the plane, the sphere casts a shadow appropriately.

 

According to the comparison chart (https://blogs.unity3d.com/2018/02/2...er-pipeline-optimizing-real-time-performance/) Subtractive Mixed Mode is not supported on LWRP.

 

Ya, I saw that comparison matrix.

It conflicts with this comparison matrix and the code itself:

https://docs.google.com/document/d/1MgoycUhS9xQKXxbTy1yHt7OCByI10rds3TyRBCSlFmg/edit?usp=drivesdk

The code shows it is only attempting subtractive shadows, for the main light.

 

Yes, I did upgraded it through the package manager starting from the Lightweight template. I had better luck starting from a blank 3D project, adding the lightweight pipeline through the package manager, and then creating and assigning a pipeline asset in the graphics tab.

I was able to successfully get Google's "HelloVR" scene to build for both my Daydream devices, but all I get on device is a dark blue-ish color and a constant stream of this error:

Code (csharp):

1.  
2. OPENGL NATIVE PLUG-IN ERROR: GL_INVALID_OPERATION: Operation illegal in current state
3. (Filename: /Users/builduser/buildslave/unity/build/Runtime/GfxDevice/opengles/GfxDeviceGLES.cpp Line: 336)
4.  

Standard Unity Unlit materials seem to render normally if I assign them, but anything with a lightweight pipeline material is invisible on device.

I don't get that error with multi-pass VR, but I get a black screen and a message saying that scriptable render pipelines requires single-pass stereo.

I have been playing with some of the other settings but haven't found anything that made a difference. I am open to suggestions, otherwise I will keep trying it as newer versions of the pipeline are released and see if I can get it going.

 

I am having the same exact issue when trying to create a new project using the LightWeight VR Pipeline Template in 2018.1.0b9

 

Open the package manager window and upgrade the Lightweight Render Pipeline and the shader graph to the latest version.

 

To be clear, the comparison chart is wrong. The shaders for the LWRP clearly show that the only mixed mode lighting that it supports is subtractive, and on my local machine this doesn't appear to be working.

https://github.com/Unity-Technologi...ightPipeline/LWRP/ShaderLibrary/Lighting.hlsl

Look at LightweightFragmentPBR, which is the LW standard fragment entry point, which in turn calls MixRealtimeAndBakedGI which uses _MIXED_LIGHTING_SUBTRACTIVE

 

Thanks!

 

Thanks for making this available to me, I will try it out.

This fixed the issue, many thanks.

 

is shadowmask will be supported in 2018.1?

 

LW 101-beta 2018.1.0 beta 9
It seems lightbounce from lightmap not working.
Skybox environment light are working fine, but lightbounce from direct light doesn't work.
Happened in PGLM and Enlighten, lightmap mode subtractive.
is this known issues?

 

Okay found a workaround for my issues, For some reason in need to increase the Indirect Intensity and Albedo Boost to 2 or more to make the lightbounce working again

Also need to increase the indirect multiplier on light settings, Hmm. . . .

 

My feedback on Lightweight Pipeline, tested on Android (LG G4, Android 6.0)

1. The UI won't show, not supported yet?
2.1 I got 40-50 fps using my 5-second camera-movement benchmark. (flying over some trees and units)


2.2 The same "benchmark" is currently giving me ~20 fps on standard-pipeline (forward rendering, 1 directional light)
I really have to optimize my scripts and drawcalls in general. I wanted to note this, because the average performance gain is quite high, in my opinion.


3.1 Transparency doesn't work yet? Not sure because my shader had vertex-movement (wind effect) and didn't convert. I used default lightweight shader instead. As you can see the leaves won't render transparent and the shadows are affected too. This needs to be noted when you compare performance. (of course this is faster)



3.2 My Trees usually look like this:




4.1 This tree looked especially buggy. It shows/hides depending on zoom (seems to be dependend from the shadow distance) and flickers when zoomed out.





Overall I'm excited to see results from others. I might give the Visual Shader Graph a chance, afaik it's supported for Lightweight. I'd be happy to see the existing issues resolved because even considering the missing transparency, the performance looks promising.

 

That's interesting but IMHO the test is not 100% accurate because too many things doesn't even work like transparency, UI....

 

Thanks, saw the fix in the bug fix branch.

 

Seems like 1.1.0-beta requires a version of Unity newer than the publically available 2018.1.0b9?

Code (csharp):

1. `UnityEngine.Experimental.Rendering.RenderPipeline' does not contain a definition for `BeginCameraRendering'

 

Thanks a lot for your Feedback on my Feedback.

1. Do you mean I submit a bug report with that buggy tree?
I'd strip the project down a bit.
2. "Before running the upgrader" So can I just upload the 2017.3 project?

Edit: I just submitted both, a non-converted 2017.3 project, and a 2018.1b7 project that reproduces the bug. Added a pingPongCamera etc. Projects contain only some trees and some text. Really stripped down. It only happens on android, so I packed the apk to test it, apk is included. Hope it helps