Feedback Wanted: Lightweight Render Pipeline

@phil_lira Is LWRP still targeting Forward renderer only?

 

@phil_lira I've got a separate thread that is tangentially related to this, and am curious if you had any insight. Essentially, where I see a shortcoming in the SRP API currently (2018.1 Git branch) is the ability to get further subsets of FilterResults from our CullResults.visibleRenderers. For instance, I'd like to take the results of a Cull and then specify an additional set of Planes to check against, and perhaps a Point+Radius. Is this something that is on the road map or possibly even exists now in an obscure manner?

I imagine you'd need to do something like this for multiple shadow sources since currently the interpolators in LW are full up for a single Pass that conforms to SM2.0.

 

So far this looks very good! We had some nice performance improvements. Just sad that a lot of shaders and post-processing scripts/shaders are not compatible, but it's a necessary step. One question, do we "have" to use Post-Processing Stack V2 framework to scrip post-processing? Or better yet - is there a way to easily port them to LWRP?

 

Hi, could you please elbborate on your performance improvements? Are you using 3D? I've read some other accounts saying that their LWRP experiments resulted in the same/worse performance that the normal pipeline. I'm trying to decide whether it is worth trying to port everything over to LWRP.

 

We're using LWRP for 2D with a little grain of 3D. We don't use a lot of custom shaders for sprites/several 3D objects. We've had about 15% of performance improvements compared to Vanilla Unity. Don't know about full 3D scenes, but it's working quite ok on 2D for us.

 

In order to get fog to work in a custom shader (transparent object with z-write off), previously, these code snippets were required:

Code (CSharp):

1. #pragma multi_compile_fog
2. UNITY_FOG_COORDS(2)
3. UNITY_TRANSFER_FOG(output, output.pos);
4. UNITY_APPLY_FOG_COLOR(input.fogCoord, col, half4(0,0,0,0));

With the LW SRP, this still seems to work. Is that by design or will this functionality be removed later?

 

As it's Experimental, I'd say that you should expect that anything could change.

That being said, provided that Unity doesn't drastically change the way fog works and is laid out in it's CBuffer, you're probably going to be safe.

 

Hi all,

thanks for this exciting new feature in Unity. With the release of 2018.1, I am eagerly trying out new features in my early-stage project. I would like to share my results and ask some questions as well!

I have made a simple test for the LWRP as follows:
1) I took a fairly standard mobile scene (the demo scene "floating port" from the Polygon Mini Fantasy asset on the store).
2) I created 2 additional copies of all objects, moved them around a bit. I also disabled all but one directional light. This results in a typical scene with around 170k verts with realtime lighting.

3) I created several scenes with various light and post-processing settings and tested all on a Sony Xperia Z2 tablet (Full HD, Snapdragon 800 series, Adreno 330, GLES 3.0). This device is from 2013 and up to 6x slower than my Samsung S8 in typical unity projects, and a good reference for midrange devices for my purposes.

4) I set up a standard and a LWRP project with typical "medium" settings. Medium quality settings for LWRP, Progressive Lightmapper, Shadowmask GI, medium resolution lightmaps.

My initial results of LWRP vs. Standard Pipeline (Forward) are as follows:

Scene 1: no static objects, 1 realtime directional light w/ soft shadows. 170k verts, 80k tris.
Standard Pipeline: ~37 FPS
LWRP: ~ 39 FPS

Scene 2: 66% static objects (both copies of original were marked static, original left as dynamic). 1 mixed directional light.
Standard Pipeline: 58-60 FPS (70k verts in editor stats)
LWRP: ~41 FPS (still 170k verts in editor)

Scene 3: 66% static objects (same as scene 2), postprocessing enabled (colorgrading ACES only)
Standard Pipeline: 15 FPS
LWRP: ~29 FPS

Scene 4: same as 3, but bloom, fast FXAA and vignette enabled.
Standard Pipeline: 10 FPS
LWRP: ~22 FPS.

In all 4 scenes, Gfx.WaitForPresent was the #1 activity, indicating a GFX-limited scenario. LWRP rendering was 10-25% of time spent on the CPU.


My conclusions and questions:
1) There seems to be almost no benefit to static objects and light maps in the LWRP. In fact, from the blog posts and unity tips, LWRP seems to be made for real-time shadows ONLY, and mixed mode lights are not really supported? This is a bit of a bummer, since the majority of my planned scenes would be static, and this allows for a reliable 60 FPS even on lower midrange devices.

2) Once you get the LWRP to perform as you want it, post processing is fairly cheap (25-30% impact) compared to the prohibite cost in the forward renderer in the classic pipeline. In fact, LWRP with FXAA and color grading was still faster than the old forward pipeline with only color grading and static object optimization.

My questions are the following:
a) How can I optimize static objects in the LWRP? I would like beautiful, soft, ambient-occluded shadows for static-on-static objects, while getting the benefit of not needing real-time lighting (60 FPS in the example above).

b) if this is currently not possible, are baked/static lights with performance benefits a planned feature for the LWRP, or is the philosophy behind the LWRP to get good performance with only real-time lighting?

Thanks all!
Daniel

 

I'm trying to build for mobile VR using shader graph too. But it seems doesn't work. I'm using Unity 2018.1.0f2. It's that an error? If I compile for cardboard and Shadergraphs, I get an app for cardboard with a black splited screen. I can compile for cardboard in Unity 2018 and see the scene (without Lightweight RP (VR)/ shadergrap), but it look like that it's not compatible with shadergraph.

if it's true, when I will be able to build it?

 

From what I observed, Before I jammed in our LWRP, I had some custom shaders for deferred and lensflare that makes...
These...
into these
upon plugging in a render pipeline, our options for switching these shaders, deferred and lens flare as our examples, are taken out. If I want to switch these shaders around in this new system, how would I do so?

 

I bet that by the time that the standard rendering pipeline is phased out, studios will be able to choose between dozens of custom SRP's,
That will be an advantage for Unity and small studios, get a pipeline that suites your needs and optimize it a little to make it perfect. all without without many years of engineering effort.

 

Hi I'm using Unity 2018.1.0f2 + LightWeight render pipeline + gear VR .
App not working and showing black screen. but if I switch to unity normal render pipeline then its work.

 

The same problem - created brand new project with specifying the LWRP for VR as an option. The project then was built without any modification to it except switching to Android in build settings. After running it on the GearVR it crashed, so I tested whether it would work by removing the Scriptable Pipeline in Graphic Settings, building it again and starting it again. Everything was running correctly with the built in renderer pipeline (the materials were pink (magenta), yet that was normal).


https://forums.oculusvr.com/community/discussion/64935/gear-vr-with-lightweight-pipeline-not-work

This is the link to Play_Edu's thread on the oculus forum.

Could someone help out with that?

Edit**
Apparently if I switch it to Single Pass (Preview) in XR Settings, it runs after build, but none of the LIGHTWEIGHT shaders are working - Unlit materials are showing, yet the ones using the LightWeight Render Pipeline shaders are hidden from the Camera.

Edit****
For anyone curious - this is a problem with Unity 2018.1, Android and the SRP.
More info -> https://github.com/Unity-Technologies/ScriptableRenderPipeline/issues/1304
Hopefully they will fix it soon!

 

It would be great to have an optimized motion blur image effect for LWRP(or possibility to use motion vectors).

 

Agreed, this is the modification I’m most hoping someone more savvy with this sort of thing will make to the LW SRP.

 

More findings. Take a look at the next image:

The scene is the same. Unity configured on iOS, no light in the scene, just the skybox (procedural material). On the left you have the standard shader lightweight render on 2018.1 and on the right the standard shader on legacy render on 2017.1. As you will see the PBR shader on LWP has some weird issue with the IBL lighting, indeed if you use the standard simplified lighting you have exactly the same results.

 

Could someone help me out here? When I add the Lightweight Render Pipeline to the Graphics Settings I get this error

 

@Hornelch, thanks for posting those stats.

With regards to scene 2 it seems that the standard pipeline is faster due to batching. After researching this, I wanted to ask your opinion on how this merge request from 2 days ago helps to improve performance with LWP: https://github.com/Unity-Technologies/ScriptableRenderPipeline/tree/lw/enable-dynamic-batching.

Like most I have a concern around switching to LWP because of batching performance, as I rely both on Unity's static batching and plugins and scripts that implement additional batching of both static meshes and skinned mesh renderers (I'm currently testing Mesh Baker for example).

The concern is that all the measures I have in place will either be wasted effort or possibly even need to be reverted, however the improved performance surrounding post-processing from your benchmarks definitely makes me interested enough to try it out and benchmark myself.

 

Is anyone having issues with STEAMVR and LWRP-VR, The SteamVR controllers don't seem to want to render using the updated lightweight shader.

 

I'm using the 2018.1 * LWRP 1.1.5. I have baked lights in my scene along with one real time directional light.
The directional light has a culling mask set so it should not be affecting my static scene objects but the mask is being ignored. Is there any work around for this?

 

Can someone please help me out? I cannot use the new LWRP in 2018.1.0f2 at all.

 

Did you install the Lightweight Render Pipeline? You can install it from the Package Manager or create a new project with the Lightweight Template

 

Doh! That seems to have done the trick. Thanks!

 

Ah okay, at least i know that was on the roadmap. But just curious why not something like forward plus or hybrid forward?

 

Also... If we could get refraction... That would be awesome

 

will this PR be going into any preview package anytime soon? It sounds like it will make writing shaders easier due to the structs

 

Point Light > Shadow Type > Hard Shadows | Soft Shadows
"Realtime shadows for point lights are not supported. Either disable shadows or set the light mode to Baked."

It is supported in the HD Rendering pipeline. Will this be supported in the Lightweight RP?

Im asking because it mentions existing support for "Realtime Point Light" for "Lightweight Pipeline" in a table here:
https://blogs.unity3d.com/2018/02/2...er-pipeline-optimizing-real-time-performance/

And HDRenderPipeline/Lit doesnt really support Sprites, so its impossible to test realtime 2D Sprite lighting with Point lights and available shaders, right?

 

I started from the LWRP template and started to notice after awhile a significant reduction in resolution. I went through the settings to try and bring the Game window image up to the fidelity of the Scene window but was not able to. Is this the intended fidelity of LWRP?

 

You have scale 1.5x in the second image. (it's the scroll bar at the top). Drop it down to 1x.

 

You are right, combined with the "Low Resolution Aspect Ratios" checkbox that was making it so I couldn't reduce below 1.5x. Thank you for the help.

 

That would be brilliant thanks!

 

Just to give some feedback to you,

I just had a new project in 2018.2 with a terrain, when I passed to the lightweight pipeline , it went pink ( that was supposed to pass, but I would expect a promtp asking for upgrade shaders when possible)

However, I create a new tree and it was pink, I create a new project with LWRP and added a terrain and a tree, and the tree is pink, I would expect to have a LWRP ready shader with the tree.

Really good work with this version guys, Look to get more updates!

 

I'm having an issue with LWRP:

Fiddling with the settings on the Scriptable Object doesn't seem to have any effect.

 

I have encountered a severe problem on LWRP. I don't know what am I doing wrong, but I can't make UI Canvases to render in build. Come see the screenshots. On build the background image (through camera-space canvas) fails to render, resulting in incorrect image.

 

I had all UI fail to appear in the build while there’s a second camera active anywhere (I had a few with RenderTexture targets alongside my main camera)

 

Well, guess that's the problem then. I have the second camera render the Depth texture of the cube and project it as a shadow. That's definitely a bug, hope it'll be fixed soon.

 

Is this still incoming @phil_lira ?

 

Hi there Unity,

I've been experimenting with LW RP lately in Unity 2018.1.1f1 using the package manager. Its a great update, but there are two issues that I noticed:

1) As I use "Instanced Properies" in any of the LWRP shaders, the shader code does not compile. I'm using Amplify shader editor to create the shaders. Is this a known issue or is it something I need to pick up with the Amplify team?

2) When I add the new post processing stack to my camera (without any post processing effects enabled) the camera will render a depth pass which adds significant amount of draw calls. Since we are planning on only using Bloom and Vignetting it feels like rendering a depth pass is unnecessary overhead.

Thank you very much in advance,
Laurens 't Jong

 

I'm noticing an issue where instancing seems actually slower with LWRP even with the built-in shaders.

I just create a test scene with 1000 instances of the Stanford bunny (each having some 34k verts). Each has slightly different position but otherwise is identical to the prefab it is spawned from.

They all use an identical material.

When I flip instancing on that material perf takes a hit despite this being what I would assume to be a nearly ideal case for instancing.