Feedback Wanted: Lightweight Render Pipeline

I've had a strange issue where our iOS builds basically weren't rendering anything other than UI. Looking at TypesInScenes.xml (in Data/Managed within the build folder) showed that no instance of ForwardRendererDataAsset was being included.
I've finally fixed this by switching Renderer Type to custom and creating an new Forward Renderer.
We're on 2019.1.7 / LWRP 5.7.2, on a test branch of our 2018.3.6 / 4.1.0 project in which LWRP has been working well.

 

Same project on iPhone X in Profiler shows 250fps (I know it's still 60, but it's way much faster than Google Pixel 2 XL that runs at 45fps)

 

Should I use version 5 or 6 of the package? The doc main page lead to 6, but I only get 5 in my package manager. Is 6 the beta version? If that is the case, I think it should be marked so.

 

@phil_lira
I was always curious what's up with all those versions numeration? The major versions are changing so fast (from 5.x to 6.x) but It seems (from changelog) that there are no significant amount of features between them. Do you make a major release every time you do an API break?

It seems that you will run out of digits in a few years...

 

I do not understand this: I have gotten enough SRP bug report resolved as "fixed in 2019.2/2019.3", which means it depends on features in Unity that doesn't work in 2019.1, how could the SRP codebase be "exactly" the same?

https://github.com/Unity-Technologi...ity.render-pipelines.lightweight/CHANGELOG.md

https://github.com/Unity-Technologi...ity.render-pipelines.lightweight/CHANGELOG.md

I would say the changelogs are quite different between 5.x and 6.x

 

AFAIK, major release is bumped alongside with unity major release.

Also, minor/patch release might be empty because other SRP project might have changes but LWRP has to bump along with them.

 

I could, but I've failed to create a simple repro case - which is the first thing that QA would ask for. Should I still submit a ticket?

 

It would be great if the engine could "unify" camera hooks like onPreCull, onPreRender and onPostRender. Now, with SRP we have beginCameraRendering, endCameraRendering, which seems functional equivalents but incompatible with each other pipeline (builtin vs SRP).

 

Thanks for the help. I found the problem. It was AA (MSAA) settings. But I got some unexpected results.

So my observations are (Every setup was build 3 times for an Android, I'll explain the reason below):

No light/Baked Light + No MSAA: 60FPS (60FPS after turning screen of and on)
No light/Baked Light + MSAA x2: 60FPS (25FPS after turning screen of and on)
No light/Baked Light + MSAA x4: 60FPS (25FPS after turning screen of and on)
No light/Baked Light + MSAA x8: 60FPS (25FPS after turning screen of and on)

Realtime Light + No MSAA: 60FPS (60FPS after turning screen of and on)
Realtime Light + MSAA x2: 57FPS (24FPS after turning screen of and on)
Realtime Light + MSAA x4: 60FPS (24FPS after turning screen of and on)
Realtime Light + MSAA x8: 60FPS (24FPS after turning screen of and on)

Nice, huh? No. Here's the huge problem (bug?) I found.

Whenever I change pipeline settings, the next build will be capped at 24 FPS. Profler says it's a PlayerLoop > PreLateUpdate.EndGraphicsJobsAfterScriptUpdate > Semaphore.WaitForSignal, which eats ~70% and 30 MS. No performance problems were spotted in the Editor.

Also, the next bug (or feature, IDK guys, it's a production ready pipeline it says) -- Opaque Texture option in LWRP breaks the whole rendering on the Android -- it renders NOTHING. Even if there are no materials which use the _OpaqueTexture. There are no such a problem in the Editor.

Don't ask me how did I get those results. It's a surprise even for me. I will avoid using LWRP for a year, I think. Sorry, but I don't want to be a beta-tester for a RP which is out of preview. I pushed my friends to use LWRP for our new project and we already ran into issues and bugs (not to say about huge constraints in a shader-programming). I'll try to migrate our project to a legacy pipeline before it's not too late. As you said, you are still optimizing it, so thanks.

 

I had some time to test LWRP (2019.1) for my visualization VR PC projects (couldnt get HDRP working with SteamVR). These are the things that I noticed that are not working yet:
1. No real-time shadows on point lights
2. No real-time GI
3. Many SteamVR shaders are not compatible (though found some fixes for this on Steam VR site)

As of right now, I dont think Ill switch to this yet until these are added...

 

I'm having an issue with the LWRP running on Oculus Quest. I've baked lightmaps for the sample scene but when running on device all objects that are lightmap static seem to be getting a completely black lightmap applied. The lightmaps are 1024x1024 ASTC compressed.

Anyone have an idea or seen this before?

Edit: I'm running Unity 2019.1.7f1. Seeing issue with both LWRP 5.7.2 and 5.16.1.

 

I was using the TexturePostProcessor from the Unity FPS sample project and it looks like one of my TextureSettings was stomping on lightmap properties. This appears to be "my bad."

 

@interpol_kun Welcome to the club! Would be great if you can add your experiences to https://forum.unity.com/threads/question-regarding-my-understanding-of-what-beta-is-for.693001.
As a sidenote, I also have a bug report open that changing SRP Assets before building and switching scenes before building hugely influences the outcome for what shader variants are stripped...

And another note for everyone using Android / Android VR with LWRP, yesterday the LWRP team said that they don't have automated testing for Android right now (it's being worked on). Only Editor is automatically tested (plus some manual tests on devices).

 

Hey thanks for the update! It's really nice to read it. Could we define "soon" in a more quantitative way?

 

i have started looking into the lwrp and tried to utilize the depth prepass which would be great on alpha tested textures i guess – because at least when it comes to desktop gpus this would allow me to get rid gf the alpha testing in the lighting pass shader and fully rely on ZTest.
so i have established a custom render pass based on this: https://gist.github.com/Elringus/69f0da9c71306f1ea0f575cc7568b31a
which copies the _CameraDepthTexture into the current BuiltinRenderTextureType.CameraTarget using:
renderPassEvent = RenderPassEvent.BeforeRenderingOpaques;
and:
cmd.Blit(DepthPropertyId, BuiltinRenderTextureType.CameraTarget, blitMat);

this actually does not looks that bad:
actually i can see the depth buffer being filled with the pre rendered depth values.
but:
- the entire screen gets set to be pure black or blue in the "copy color" and/or "final blit" pass – just like source was not set up properly.
- if i look at the steps in between i can see objects being rendered into the framebuffer but their depth test seem to fail:



any thoughts about this?

 

Hi, I'm also wait for this) Any news?

 

Do the "Current Limitation" and "Performance" points, found in the first post, still apply?

 

It would be really useful if the LWRP and HDRP packages added scripting define symbols (like post processing does) so code could conditionally compile based on which package you'd included. This could help 3rd party SDK's (*cough*Oculus*cough*) to conditionally add/remove features and shaders based on render pipeline.

 

diving a bit deeper into LWRP i noticed that additional per pixel light and additional per vertex lights are mutual exclusive (#pragma multi_compile _ _ADDITIONAL_LIGHTS_VERTEX _ADDITIONAL_LIGHTS) – unlike in the built in forward rendering pipeline.
imho this is a big step backwards. as lighting fully depends on the "per object limit" in the settings and the object's pivot. LWRP does not even take into account if a light is visible on screen or not.
so just imagine a large terrain and road and e.g. 8 lanterns. if "per object limit" is set to 2 only the 2 lanterns closest to the pivot of the terrain or road will be taken into account (assuming all lanterns have the same light intensity) – regardless if they are visible and will contribute to the final image or not.
no per vertex lighting of other lights.
and no prioritisation based on visibility of the light.

@phil_lira are we supposed to solve this our own using scripts?

 

Hey Phil & Andre,

Any news/estimates/roadmap on AO for LWRP? This is still painfully missing and holding up the switch to LWRP and the mobile port.

Sorry for nagging!

 

Hey forum, I reported this issue and the official reply was that it won't be fixed in the near future so I'm letting you all know in case you are planning to do something similar.

Basically, the shadow bias for spotlights breaks when they face upwards and are very close (0.5 units) from objects:


(there is a 2nd cube in the front set to shadows only, as outlined by its collider, the problem happens regardless of the shadows only setting, it is used here just to make it clearer)

THIS IS NOT A BUG IN LWRP, IT AFFECTS ALL OF UNITY (as stated by unity staff).
But this bug together with the current lack of shadows for point lights and the 4 lights per object limitation of LWRP makes it imposible to have fancy fires, torches or any light source created by players since this artifacts and weirdness will immediately appear.

Bug report: https://fogbugz.unity3d.com/default.asp?1164142_ehn3n7c39eraa6u0

 

Is there a bug report logged so we can track it?

 

Yes but it is closed: https://fogbugz.unity3d.com/default.asp?1164142_ehn3n7c39eraa6u0

Added it on the original post too.

 

Hi!

I have some question in relation to skin tone shading with LWRP (we use UMA for the avatar system with the SRP branch).

We are developing our base model character and are looking for a solution how to get skin tone shading that is similar to the reference as in the image below:
View attachment 443579

Any ideas how to get more close to this look?

Long term we want to aim as much as possible for soft subsurface skin tones. Any kind of real-time subsurface shading hack would be a great solution for us. This is the long term references we are aiming for:
View attachment 443582

We have also been looking at external packs for skin tone shading with LWRP:

https://assetstore.unity.com/packages/vfx/shaders/nodes-for-shader-graph-124611
https://forum.unity.com/threads/nodes-for-shader-graph.543519/

https://assetstore.unity.com/packages/vfx/shaders/pidi-pbr-skin-eye-shader-106600

Any experience with them?

Would be greatful for any suggestion how to move in the direction of the reference images above?

Many thanks!

Bartek

 

I want to know why the postprocess v2 PostProcessEvent.BeforeTransparent doesn't work in unity 2019.1.4f with lwrp version 5.16.1? i saw the lwrp's code that the OpaquePostprocess pass doesn't enqueue and do, it just setups(ForwardRenderer.cs in Setup function)..

Code (CSharp):

1.             if (hasOpaquePostProcess)
2.                 m_OpaquePostProcessPass.Setup(cameraTargetDescriptor, m_ActiveCameraColorAttachment, m_ActiveCameraColorAttachment);

i tried to fix the issue adding a EnqueuePass(m_OpaquePostProcessPass) after the setup and make it works on pc editor, but the screen will split when build an assetbundle andriod build..

 

Okay. I deleted the Vulkan from the project settings Graphics API. Now there are no FPS drops even after turning screen on and off and changing pipeline settings. Here's the profiler snap from the Vulkan build where FPS drops are presented. Here's the quality settings preset and here's LWRP asset I use for mobile quality.

Yup, Vulkan-only bug. No such a behaviour on OpenGLES3.

I don't know why Vulkan is being added to project by default (and moved on top of graphics API list), but it seems all the problem I had previously are related to Vulkan only. I will tell you if OGLES3 will be buggy in future.

@phil_lira is that good for you?

 

Any ideas on how get rid of normals not updating with blendshapes?

Here is an example:



The one on the left is from the gif and the one on the right is the same frame of the animation but as a static obj object in unity. It's clearly some issue with unity normals on blendshape animations. We have tried all kinds of settings on the blendshapes in Unity. Smoothing groups, angled etc. And the gif is of the best combination of settings.

Any suggestions?

 

@Bartek_Gudowski_Friend_Factory https://issuetracker.unity3d.com/issues/blendshapes-normals-are-broken-when-upgrading-the-project

 

Made it..I pick the depthtexture and Enqueuepass the pass in the lwrp asset and the opaquepostprocesspass works on android mobile phone.~

 

Is the LWRP being renamed to the Universal Pipeline?

https://github.com/Unity-Technologies/ScriptableRenderPipeline/tree/LwrpToUniversal

 

Hi,
I'm using 2019.3.0a7 with LWRP and waiting for camera stacking funcionality.
As an alternitive, I'm seting up my UI with multi layered screen space - camera canvases, but it's not the best way and very restricted.
Can I use camera stacking from package manager in Q4 2019 ?
thank you.

 

For workaround, you can force the lwrp to enable camera stacking by commenting out 3 lines of code in ScriptableRenderer.cs of LWRP
Inside GetCameraClearFlag method:
cameraClearFlags = CameraClearFlags.SolidColor;
...
...
if(Application.isMobilePlatform)
return ClearFlag.All;

By commenting out these 3 lines of code, the camera stacking is enabled, just make sure to set UI's camera to Depth clear flag, and toggle off the Opaque and Depth Texture setting, you'll be able to use ScreenSpace-Camera mode.
But maybe you'll encounter problem in some conner case, but I didn't meet any yet.

 

Hi guys, I came across a problem that the terrain using terrain/lit shader is black and dont work with directional light when it was on mobile phone using assetbundles and choose the draw instanced. however, it works right on pc editor using assetbundles. I found that the cause is the _TerrainNormalmapTexture is missing when it was on mobile phone.The first picture is the draw call on pc editor and the second one is on mobile.I just want to know how to make sure this _TerrainNormalmapTexture is right here when it is on mobile phone. Because of this problem, I have to toggle off the draw instanced now.

 

>liiir1985
It works for me. thank you!

I have one more question.
If I enable post prosessing, it forces LWRP to use depth dexture, so I got black screen when i run my app in zenfone with vulkan api.
And it also doesn't work with vfx graph.

I want to create my ui with multi camera stacking with vfx graph and post processing.
Unity's future stable LWRP release will solve this problem?

 

For that you'd better wait for future release, LWRP has camera stacking on its roadmap and should be ready at 2019.3

 

Hello, just curious when the light limitation in LWRP is going to be lifted?

We were aware of the 4 light limitation, but we expected this to be determined by the main camera(s) position. Our problem is, we don't control how many lights come into our project, as we bring through architecture models from Revit, Rhino, Sketchup FBX and much more. Currently, it seems the first set of lights loaded work, but after we have reached the limit, the rest don't light up anything at all, even if you are closer to those lights than the ones that are turned on.

We are considering rolling our own light 'LOD' system. but in some testing cases, we turned off every light manually and left just the one we were next to on, and it still results in that light remaining off, regardless of priority, strength, and range.

Thanks

 

Hello,

I've been experiencing problems with shader graph materials rendering specular highlights incorrectly on mobile devices (iOS and Android) on LWRP. It looks like there's a precision problem of some sort, and maybe some lighting calculations based on absolute values rather than values relative to the current camera FOV and scene/object size. I'm now using 2019.2b6, LWRP and Shader graph v 6.7.1, but the problem has been around at least since 2018.3, probably longer.



More information and detail here in a separate thread I started about this:
https://forum.unity.com/threads/lwr...-specular-problems-on-ios-and-android.700688/
There's also a bug report I initially filed about this, 1143049

It also seems that it could be related to this specular rendering problem:
https://forum.unity.com/threads/lwr...hlights-on-android-with-large-objects.698249/

Any advice on how to get around this, or updates on the progress of these bugs?

 

See https://forum.unity.com/threads/lightweight-render-pipeline-is-evolving.707720/

 

hey
I have quick question ..
Why 'LWRP' does not exist in the namespace 'UnityEngine.Experimental.Rendering' ??

 

@thabetarqawi "LightweightPipeline" should be what you're looking for. (I think "HDPipeline" is the HDRP one).

 

LWRP isn't in preview/experimental anymore since 2018.3. HDRP will be out of Preview in 2019.3

 

I am getting this error a lot and it is preventing Terrain Detail meshes from rendering properly (they are pink), I think it is related to or stalling the conversion of internal Grass/Vertex lit shaders to SRP versions?

I will submit a bug report with an example of it also as it's a bit of a problem if you are using Unity Terrain in a project that is being upgraded

 

I have an example where nothing else is holding up the shader compiling or whatever it is doing.. just 999+ errors and counting saying

Code (CSharp):

1. Shader properties can't be added to this global property sheet. Trying to add _GrabTexture (type 3 count 1)
2. UnityEngine.GUIUtility:ProcessEvent(Int32, IntPtr)
3.