Feedback Wanted: Lightweight Render Pipeline

  1. Batching On && PostProcessing off 2) Batching off && PostProcessing on.
    Makes the FPS difference.

Sorry if I am being annoying, but I have several questions regarding LWRP before implementing it into our game.
1 - Our game is primarely 2D in a retro style, but has a lot of 3D stuff in it, including full 3D sections. Because of that, we need a functionality similar to Pixel Perfect package. Pixel Perfect package in itself doesn’t work on LWRP and it got confirmed that it wouldn’t in the future, since there’s going to be a dedicated 2D Render Pipeline (which is pretty much unnacceptable to us). As such, where in scripts LWRP sets its resolution and camera bounds?
2 - Do I properly understand that there’s no Grab Pass in LWRP, yes? Some of our effects (like color inversion, sine distortion and screen overlays) depend on it. What would be the best way to port them?

Of course we can stay on the legacy renderer, but it would honestly be a bit sad, staying there and not getting more performance and more features (especially from shadergraph)

@Tim-C So sorry for bothering, but again, is directional light culling mask meant to work in LWRP ? If yes, what is the status of this feature that currently isn’t working ?

Answer is still pending for all those threads. For some it’s been for months :frowning:

Feedback Wanted: Scriptable Render Pipelines page-17

Furthermore I’m worrying because I see all strong issues I had on LWRP disappearing from the issue tracker for no explanation, for example:
-Unity Issue Tracker - [LWRP] Directional Light Culling Masks don't work properly
is considered as a duplicate and redirects to
-Unity Issue Tracker - [LWRP] Light layer culling not working
which does not exist anymore.

But I also have those who disappeared:

My question is: where are they? We have no any visiblity on that anymore. And the lack of clarity is very frustrating :confused:

Thanks for your answer.

1 Like

As in LWRP we do not store a DepthNormals texture(only a depth) we don’t have the ability to use any of the current AO effects in the Post Processing, we have looked into a few options, but trying to find something that is efficient and doesn’t look too ‘Old School’ is tricky, it’s on our list but lower on the priority right now.

Looking at the error message you have there you don’t seem to have a SRP loaded, if using the Shadergraph you need to use either LWRP, HDRP or a custom one. If you have pulled a SRP into your project via package manager then also make sure to create a new render pipeline asset via the project windows ‘Create/Rendering/Lightweight Pipeline Asset’ then assign this asset in the Graphics Settings.

Looking at that thread it looks as though it hasn’t been updated fully to work with even the builtin pipeline so chances for LWRP to work is slim, but if it works with builtin in 2018.1/2 then it will work with LWRP as we don’t handle light mapping any differently(aside from the missing mixed mode support currently)

So we are currently stabilising the API now, we are also working on the pluggable renderers and pass injection, these two things will make modifying the pipeline much, much easier, for example in the BoatDemo I’m working on, I easily removed a camera that was rendering just some water FX objects into a render texture, now it happens builtin to LWRP, this means it’s just part of the pipeline, no extra culling or setup, I’m planning on also porting over the planar reflections to see the speedups we can gain there. It’s so far a very nice system.
But yes, the API will be changing a fair bit for the rest of the year while we refine it to be what we think is a nice base to then go forwards with.

I’ve been using 3.0.0 on OSX Metal primarily, also iOS and Android with a mix of VR, things have been going fine, in saying that end of last week the HDRP team pushed code to the SRP repo that now makes 3.x.x only work in 18.3, as the SRPs are in preview we don’t plan to back port so hopefully we will release the 18.3 beta soon.

I agree with this, but right now if you cannot see it on the public tracker then it hasn’t been submitted. I just looked at your scene lighting bug and see it hasn’t been through our first pass, I’ll make sure it’s added to our LWRP project.

We are working on it, there are a few terrain changes happening, first is getting the new GPU instanced terrain working, then updating the tree shaders, I cannot give you an ETA as we are doing a large push on documentation and to lock down the API so that we won’t break anything people decide to start adding to LWRP.

I haven’t got a daydream capable device on hand but will look into this with the XR team, I have recently tested on the Oculus GO and basic scenes are working, though once using more advanced setups I am getting no rendering at all. If you haven’t done so already try building up from a simpler set of features to see where you are encountering issues, big things to look out for doing VR with LWRP right now is, no MSAA, no PostFX, make sure only 1 directional light in the scene and disable all shadows on additional lights.

This is a regression due to a major refactor recently, we are working on a much more solid test automation setup right now which will stop these issues from reappearing.

3 Likes

No, it has not been implemented yet, it is on the list but not planned on the roadmap.

Thanks for bringing this up, internally we have shifted all package bugs to a separate grouping, this seems to have disabled their public tracking, looking into this now.

Oh… That? Old news… But if I were, to say, make light lighting a lot more interesting… What shader would THAT be to edit our forward lighting… I KNOW it would be in the LWRP folder, but what shader?

Shadows in LWRP do not work properly in large scenes.

Objects far from the origin stop casting shadows, even if the directional light and camera are near the object. Extending the LightWeightAsset’s Directional Shadow distance can increase the shadow render distance, but the resulting shadows become very blurry. The Distance setting should be relative to the camera, not relative to the world origin.

Cascade shadows are unfortunately broken currently, for now as a workaround turn off cascades on the LWRP Asset.

Sorry I don’t quite understand what you are asking here, are you wanting to do custom lighting in a shader?

1 Like

Yeah… To edit it… To make it more interesting… What script ACTUALLY produces the lighting we see with lightweight?

Thx for all your answers, but I find this part confusing:

Are you saying LWRP-2.x and 3.x are not 2 different branch? Will we need to move onto 2018.3 for a better version of LWRP?

(EDIT: “Better” = “Suitable for production”, not necessarily more features)

3576007--288753--Unity Firing.png
To turn this…
3576007--288754--Ideal Firing.png
Into THIS!

Or What I meant…
3576007--288755--Orange Phong.png
THIS…
3576007--288757--My light.png
To THIS!

Try multiplying the color by another color.

I DO have a idea on how to go around it… darken the texture, Hardlight(b < .5 ? (2 * a * b) : (1 - 2 * (1 - a) * (1 - b))), and multiply it with the texture… Now if I can find the script that generates the lighting in LWRP… and bloom’s next after that…

1 Like

Both images had the static batching on and postprocessing on

As LWRP is still a preview / in development feature we constantly changing API and similar. This means that we are not able to backport all changes to the 2018.2 / 2.x.x stream (we are porting critical fixes). This means that until we are out of preview mode the latest and greatest LWRP will be whatever the cutting edge version is.

Once we leave preview this will change and we will aim to backport more fixes / stability changes so that you can lock in a specific stream for your project.

News:
In LWRP land we are switching from feature development to stabalisation / bugfixing / documentation mode for the next few months. This means that what is in the git repository is a (close) to scoped version of LWRP as it will be in the 19.1 release. We are switching modes as we want to ensure that what we have of LWRP is production ready and can be used by everyone out there in the real world. Once we finish the ‘making it awesome’ work we will switch back to feature development for LWRP (deferred LW anyone?), but that probably won’t be until next year.

How can I help?
Log bugs, tell us where our API sucks, tell us what is lacking in docs, tell us what would help you be successful with LWRP.

Looking forward to the feedback.

4 Likes

That’s great news! I was thinking it would take 2018.3 at least to stabilize LWRP API, but you just convinced me to use it in my current project. LW with deferred would be great, but I would kill for making standard PBS base performant on Intel GPU, that’s really my main goal for trying out LWRP (less complexity and better control on trade-offs).

On the subject of bugs, I am hoping it’s easy to confirm bug 1062911 on fogbugz (I understand QA are busy): but I observe the same issue in both Scene view and Material preview with Metal API using 3.0.0-preview/2.0.6-preview, not sure I should open another ticket on this or try some other version of LWRP (like the latest 2.0.8-preview).

3577772--289035--Screen Shot 2018-07-27 at 21.00.37.png

There is currently a PR waiting to fix the cascade shadow issue thats been plaguing the latest version of LWRP, we are hoping to get a new package out next week that will contain the fix, currently just waiting for out automated tests to give us the green :slight_smile:

1 Like

Whats the advantage over deffered rendering path? i see no perfomance increase, they both work very similar way…

increased Light count limit