Feedback Wanted: Lightweight Render Pipeline

[bitinn]

@bitinn

Is there any workaround for the 16 lights limit? Given the lack of both deferred path and realtime GI (hence no realtime light probe neither), I don’t know how to make an interior or night time scene where there are potentially more than 16 light source in view. (I can’t use baked light in this case due to working with a dynamic scene)

Another question is does LWRP 4.0.x still support SH lights? I believe it was working in 2018.2, but somehow with 2018.3b I can only get pixel/vertex light to work. (The additional light slider on LWRP asset used to cap the number of pixel/vertex lights per object, but now it seems to cap the number of all lights per object, including SH lights, so visible lights are always pixel or vertex now?)

Basically I am looking at SampleSHPixel but I am not sure how many additional lights are available per object exactly, is it still 1 + 8 (1 directional + 4 point/spot + rest is SH)? or is it 1 + 4 (no SH)?

https://github.com/Unity-Technologies/ScriptableRenderPipeline/blob/master/com.unity.render-pipelines.lightweight/ShaderLibrary/Lighting.hlsl#L332

UPDATE: I have posted some screenshots to illustrate my problems in a reddit thread.

https://www.reddit.com/r/Unity3D/comments/9rhxcr/lwrp_how_does_sh_light_work_any_workaround_to_the/

I have figured out the reason for my problem: SH lights are sampled from Light Probe and since Light Probe is baked only, I can’t have real-time SH lights neither.

However, I ran into another issue:

I can’t seem to get Emissive to work using Baked GI, somehow with LWRP, Light Probes aren’t including static emissive objects. LWRP Lit shader doesn’t offer a GI option for Emission, I am assuming they are default to “Baked”? Or are they default to “None”?

EDIT: asked on Reddit, unfortunately no one has a clue so far.

https://www.reddit.com/r/Unity3D/comments/9tstc3/lwrp_does_emissive_material_contribute_to_baked_gi/

EDIT2: I think this is a bug too? because in code BakedEmissive flag is set.

https://github.com/Unity-Technologies/ScriptableRenderPipeline/blob/7752bc7b10c39d4f903b981d00e46af44515dde0/com.unity.render-pipelines.lightweight/Editor/ShaderGUI/LitShaderGUI.cs#L228-L232

[Tesrym]

There is a limit of 16 lights?? You need to tell me how I can get those, because 4 is all I get.

[Tesrym]

On the topic of baking lights, light bounces breaks when upgrading from 4.0.1 to 4.1.0.
Only directional lights bounce on 4.1.0.

[bitinn]

@Tesrym

There is a limit of 16 lights?? You need to tell me how I can get those, because 4 is all I get.

well, it’s 16 visible lights on screen, but only 4 per object so far.

(the doc somehow claim 8 light per object, but it’s not possible with LWRP asset yet)

[bitinn]

@Tesrym

On the topic of baking lights, light bounces breaks when upgrading from 4.0.1 to 4.1.0.
Only directional lights bounce on 4.1.0.

That would explain my problem with Baked GI, I am hoping LWRP team somehow maintain a known issue page somewhere (say trello?) because it’s pretty time consuming to prepare a bug report, I don’t want to waste anyone’s time submitting known issues.

EDIT: seem to be the case, no emission or baked point light bouncing in GI. My issues are now reported as case 1097667 and 1097669…

[Karearea]

@Andy-Touch

Blurry Refractions (Grab Pass-Like):

Thanks for these samples- super useful.

Just a note with HDR active, if highly emissive objects (or very bright specular objects) pass in front of a surface with this blur effect, they are blurred into the RT and show as a fringe.

Adding

opaqueDesc.colorFormat = RenderTextureFormat.Default;

…to BlurGrabPass.cs on line 91 immediately after opaqueDesc is declared fixes it.

[Captain_Flaush]

Hello,

Been testing the LRP for a few weeks now. The main bug that really bothers me is that dynamic lights do not work the same on PC and mobile both on 4.0.1 an 4.1.0. Originally I thought that not all the dynamic lights get rendered on mobile, but after some tests, I’ve noticed that their falloff is very different on mobile. I’ve built a simple scene to test this.

• Here is a screenshot from PC
  
  
  - Here is a screenshot from Mobile
  
  

In this case the material used is the default Lit Material on a plane, howver it reproduces with Shader Graphs materials as well.

Thanks,
Mihai

[bitinn]

Watched UniteLA roadmap and finally see 2019.1 for a stable LWRP.

I just hope 2018 LTS won’t be stuck between a semi-outdated version of LWRP that no Asset Store packages will support (anything that rely on the core shader for shader generation, like Amplify Shader Editor or Toony Colors Pro 2)

[phil_lira]

Hey guys,

Sorry for being away for a while. I’ll catch up on the thread and reply individually, by first let me say a couple of words on state of LWRP:

While being experimental some breaking changes will still happen unfortunately. This is not the ideal scenario as we don’t have a way on package manager to require a beta version of Unity. These changes are necessary so we evolve the API based on the feedback received and I apologize for the inconvenience. The good news is that LWRP and SRP Core is coming out of experimental in 19.1. After that no more breaking changes.

Here’s some Known Issues & Limitations that are on my radar at the moment. There are more issues being looked at but these are the ones I remember on top of my head that people reported in this thread or to me from other sources.

• Light layer culling is not working for the Main Light. This requires engine changes. I have a PR waiting on LWRP side for those engine changes to go in. It requires engine changes and hopefully going to be available soon via new Unity version. LWRP will use the light assigned in as Sun in Light Settings as Main Light, otherwise the brighest directional light. Then light layer culling will work for all lights.
  - PostProcessing is not working with VR and LWRP. This is fixed now in postprocess package and a PR to re-enabled it in LWRP is inbound.
• Additional directional lights are not supported yet. We haven’t started working on this yet, but most likely will be in for 19.1. All lights will be shaded in a single pass.
• Light limits are at the moment 4 per-object lights and 16 visible lights. The limit will be increase for GLES3.1+ and all non-gles platforms. Most likely for 19.1. We will also look at increasing the limit on GLES2.0 and GLES3.0, but later, probably after 19.1.
  - Tile clearing issues on mobile GPUs (causing random artifacts/trash in screen) when using multiple cameras or not rendering to full screen. There’s a PR waiting for engine changes to go in.
  - Particles Shaders issues or missing features. We finishing testing this and should have a fix soon.
• There are some rendering issues when not using the default viewport (0, 0, 1, 1). Haven’t started looking at those yet. They will be fixed at some point before 19.1
• **There are some rendering issues when using multiple cameras depending on the effects enabled or platform. **Haven’t started looking at those yet. They will be fixed at some point before 19.1
  - Terrain shaders are not fully ported to LWRP. We have no ETA on it yet. Sorry about the inconvenience.
  - Shader Variants / Build time - We are constantly looking at strip and optimize the amount of variants without introducing performance regressions. My advice for now is to avoid UsePass in your shaders as the stripper is not properly stripping those and double check if you have custom shaders that your shader uses the updated LWRP shader variants (changed in 4.0.0 version).

Thanks a lot for everyone using LWRP and providing feedback. This is crucial to deliver a nice product for everyone.

[phil_lira]

@richardzzzarnold

I can’t see from the log you’ve posted where’s the additional data coming from. I’ve asked around for more info but to help you better here it will be better if you can open a bug report for this.

[phil_lira]

@Spyder_Nic

Are the SortingGroup for sprites fixed?

See @Tendro 's post https://discussions.unity.com/t/692265 page-6#post-3541371

Not yet. We have a couple of reports on it already like this one: https://issuetracker.unity3d.com/issues/sortinggroup-component-does-not-sort-when-lwrp-is-in-use

This is most likely going to be fixed in 19.1

[phil_lira]

@bitinn

(cont. from previous post)

Benchmark (1 light vs 4 lights vs 4 lights + FXAA vs 4 lights + SMAA medium)

I always thought PBS is much more complex than simple Blinn-Phong, but it seems even with additional environment sampling, PBS isn’t much slower on Intel GPU Laptops (when you compare it to Post Processing’s performance hit).

The SimpleLit shader has less ALU and texture samples that the physically based one. In your case, since you don’t seem to have textures there the diff will be only in ALU. If your game bottleneck is not shader ALU then not visible performance difference will be seen.

[phil_lira]

@mangax

Sorry if it sounds off topic, but i was wondering why the option to bake indirect lighting is disabled in LWRP…
is this a sacrifice we have to take by switching to LWRP?

personally i would want to have some sort of baked indirect lights… it make scenes more beautiful to look at than baked shadows.
that being said, i wonder why it is not an option to have baked lightmaps to contain both shadows and indirect lights at same textures!

It just because LWRP is lacking occlusion probes to propertly support mixed lighting. Occlusion Probes is in the backlog for 19.1. With that both subtractive and baked indirect mixed light modes will be supported.

[phil_lira]

@bitinn

I saw Andy’s talk on Unite LA today and wondering if we might face a situation where 2018.3 goes into stable while LWRP continue to be in Preview.

I am fine with the lack of some major features but it would be pretty bad to not have a stable release of LWRP for 2018.3 or 2018.4 LTS: this is the version of Unity we are inevitably going to use for current project (we are using 2018.3b in production at this point, since we want to use latest LWRP there isn’t any alternative.)

@Pr0x1d

Hello I would like to see if its something I have bugged or its actual bug in LWRP, I have grass with Transparent Alpha material and when I activate receive shadows it just takes shadows for opaque shaders behind actual transparent material, had this bug on terrain grass shader aswell, but it was working from time to time but by putting the transparent material it just breaks it. Any fixes outhere caus I could not find any. Thanks

(With receive shadows true)

(With receive shadows false)

That’s because LWRP doesn’t support transparent materials to cast shadows. They can only receive shadows. Alpha cutout materials can cast shadows though. You can have the desired effect by settings grass to be cutout + alpha mask/ alpha-to-coverage?

[phil_lira]

@jpease

There’s a very simple issue: by default, MSAA doesn’t work at all. That setting on the LWRP asset is ignored.

This issue can be worked around by forcing an intermediate render texture to be used (such as by enabling HDR or by editing the RequiresIntermediateColorTexture method) but I doubt that’s part of the intended workflow for users of the LWRP to get antialiasing.

This was fixed in 5.0.0-preview and backported to 4.1.0-preview. Let me know if you are still experiencing this issue.

[phil_lira]

@yonek_idreams

I was wondering if for a game that is optimize to run on mobiles using the “build-in” render pipeline would benefit from switching to LWRP. Assuming the visual result would not change on LWRP.

Built-in and LWRP can’t match visually anymore. The main difference is the light attenuation being physically based in LWRP. If you, however, only directional lights then it should be close enough unless you are using features not supported atm in LWRP.

As for performance, it also depends on your game.

• If you have multiple lights and a moderately complex scene LWRP should perform better in 19.1 and 18.3 (RC).
• If you have just a single directional light and the game is fill-rate bound LWRP and Builtin should have same performance.
• If you have just a single directional light or unlit game and the game is driver or CPU bound: At the moment they should have same performance, however we have a new renderer batcher in SRP that’s disabled by default because we have some issues on iOS. We are fixing those issues atm and enable the batcher. In that case, with the new batcher, LWRP should be faster. This new batcher is what made possible the Megacity to run on mobile with LWRP.

Of course is very hard to claim that on all scenarios and all platforms, but we are progressing towards getting better performance with LWRP.

[phil_lira]

@Halfspacer

Just tested, there seems to be no MSAA when building for Oculus Go despite 4x MSAA ticked in the LWRP asset and enabled on the cameras Is there any ETA on when this is fixed?

What version of LWRP are you using?

[phil_lira]

@Captain_Flaush

Hello,

Testing LWRP 4.0.1 on Unity 2018.3.0b7 on several devices and if I activate shadows on the main light, I get total chaos.
Reproduces on:
Sony Xperia Z (Adreno 320)
Nexus 5 (Adreno 330)
Huavei P20 Lite (Mali-T830 MP2)

Thanks,
Mihai

Could you open a bug report for this issue? We’ll take a look as soon as possible.

[phil_lira]

@sstrong

Is there a matrix of which SRP version is supported / go with which Unity builds? For an asset dev it can be a little difficult knowing if we need to include multiple LWRP packages to support different versions of Unity.

Sorry about this. There’s no dependency tracking and it’s a little bit hard to figure out because multiple teams are pushing work to engine that might break API and require new package. (HDRP, VR, Mobile, LWRP).

[phil_lira]

@bitinn

I also think this is a bug in LWRP 4.0.1 preview: changing the additional lights dropdown to vertex lighting shouldn’t disable the per object limit slider.

Thanks for catching that. I’ve fix this and another minor issue in the UI of the pipeline asset. The fix should be in for the next package.