- 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
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
Thanks for your answer.
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.
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?
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)
To turn thisâŚ
Into THIS!
Or What I meantâŚ
THISâŚ
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âŚ
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.
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).
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
Whats the advantage over deffered rendering path? i see no perfomance increase, they both work very similar wayâŚ
increased Light count limit