Feedback Wanted: Lightweight Render Pipeline

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

 

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).

 

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

 

increased Light count limit

 

hows that? i create 2000 spheres with 8 lights (LRP limit)
with deffered i get 40 fps
with LRP i get 10 fps

both have same ammount draw calls

here is the test if you want test yourself https://pastebin.com/neWWK5aZ

 

Hang on, i think i missread your previous post. are you asking about what is the advantage of the current LWRP over built in deferred? or the opposite ?

 

yes i'm asking what is the advantage of the current LWRP over built in deferred? its seems 4 times slower with 8 lights, i will test it on android now.

 

LWRP is still forward rendering, it's not going to magically make it faster than deferred lighting.

But it does:

- Gives you more control when working with different devices, as quality setting is now an asset.
- In real-world project it's likely going to give better result than current built-in pipeline due to specialization and less overall complexity (LWRP for mobile, and HDRP for console/pc).
- Mobile has troubles working with deferred pipeline, so a better forward rendering is also desirable (better trade-offs).

But at the moment:

- If you read this thread and you will see it's not all success story, mostly because of bugs and because built-in pipeline has been optimized for so long.

TL;DR, you might want to watch this video:

 

Yeah i totally missread then. the current LWRP actually are not faster than built in deferred. basicallt what bitinn said.
Just ignore my first respond, sorry

 

Eh?

LWRP is much faster than builtin, but probably you're not seeing it because you're capped in other ways. SRP allows you to spend a lot less CPU time. Bandwidth of LWRP is way, way less than builtin deferred so it should be faster there too.

Can clarify your claims there's no perf difference between LWRP and Builtin deferred? because that's nuts.

Bascially, if you're using standard shader then I would probably agree that for some platforms the performance would be based on how good the GPU is, but if you're not, I can't see a single situation where builtin would ever be faster.

 

This is because you should be using HDRP not LWRP. Your test is designed to break LWRP and is illogical until LWRP has a deferred-lite option.

If you use Builtin with the same feature set as LWRP you will find LWRP performs as expected.

 

yes its using same feature set as Builtin. LWRP works 4 times slower with 8 point lights than deffered. Perhaps because its early preview so developers didn't optimize it yet as @bitinn said

If you think its faster, please give us demo with same setups, where LWRP works faster than deffered, you can edit my source code or make your own setup

 

There are tons of things you can't test easily with a simple test case though:

- Deferred lighting performance is dependent on number of pixels it illuminates, forward rendering does it per-object. How much care did you take to make sure it's a fair comparison?

- LWRP is supposed to help you spend less drawcalls, but not magically reduce drawcalls, if it still take the same number of drawcalls as deferred, I argue you need to take more care to set things up (after all, it's a trade-off between quality and performance).

- Actually, I highly recommend people to try converting some demo scenes from Unity official tutorial, and see how LWRP would performance in a simple game. (And I think Unity engineer will be glad to improve them, as they are much closer to real-world examples).

- We are really talking about pipeline changes here, which means, under the same condition that's preferable to forward rendering, the LWRP should perform better given appropriate quality settings (where the pipeline asset comes into play). And it should minimize quality lose, and save you from manually changing the core rendering of Unity.

That's I think what LWRP would do, and to be honest, what I need (I am not developing for mobile, but I would love to spend less time in Intel GPA just to get a stable FPS in Intel GPU...)

 

I mean in term of per pixel light counts, since the current LWRP are forward shading

 

Hi,
So I'm glad to see the issues that had mysteriously disappeared from the issue tracker are now back. Now though, I do wonder about something else. Your severity and priority system.

I've been told in this topic that directional light culling issue isn't even in your roadmap yet.
https://issuetracker.unity3d.com/issues/lwrp-light-layer-culling-not-working
But its severity is '3' and very high priority '7' ?
I'm already quite lost (I mean, 7 is higher priority than 1 or 2 right ?)

Then I see these two.
https://issuetracker.unity3d.com/is...-render-texture-causes-ugui-disappears-on-ios
https://issuetracker.unity3d.com/is...nder-texture-gives-black-screen-only-on-build
Which have both similar strong consequence (unable to play in standalone) and that have a very different severity level (3 against 0, even if the one with 0 has more votes than the light layer culling one).

Is there any reasonable explanation of what all of that means ? I don't see much logic there and it's very confusing.

 

@Tim-C so in what scenarios i should go for LWRP?
If i don't need forward rendering features, and i make game for low end pc/mobile phones should i stick with deffered or go for LWRP for best performance?

LWRP using 10mb VRAM and deffered 20mb seems not big difference. With 1 directional light they both give same performance on low end pc.

 

I think you'll find that's a very contradictory statement. If you are designing a game for mobile it's in your best interests to avoid deferred and change your design so that it uses as few lights as possible, baking what you can.

 

I mean... If anything... If you're doing, like, other effects... I would bet a projector or a texture would be more your speed.

 

Sorry didn't understand a word you said.

 

LIKE what you see over here? How many vertex lights could you have, by the way? That could help too.

 

Hi,
I created new projects with unity 2018.2.0f2 with LWRP for VR template. it's work. but I update rendering pipeline to 3.0.0 then it's not Work. also, Empty projects with LWRP 3.0.0 with unity 2018.2.1f1 not work. When I run app In oculus -go then device get a freeze.

I'm not using any postprocessing or anti-aliasing script and also disable option MSAA in camera.

Please suggest me can I use LWRP for production (Gear VR / GO ).

Best_regards,
Play_edu

 

When i tried your demo of the village used as lighting tutorial lw get much more fps than standard but when i tried it in my own project i get about the same fps and with much worse graphics, in my project i use VR with htc vive. I use 2018.2 lw 3.0 and forward rendering

 

Quick question 1, if I happen to observe performance lost when trying to convert Unity tutorial scene, does it count?

Quick question 2, I saw 3.1.0 is up on GitHub, generally how long does it take to publish on package manager? I want to test it out, as it potentially fixed one of my issue.

 

Thx, but we are trapped in this situation:

- We want to use 2018.2, but LWRP bug fixes are only landing in 2018.3 branch.
- I know Unity team will eventually backport fixes to 2018.2 branch, but they depend on the severity of bug.
- So far, we have been "living through" these issues. Basic problems like "not able to preview any materials/models" on 2018.2 with macOS and Metal Editor.

I interpreted this quote as LWRP would be leaving preview soon (API stabilizes). So I was thinking: great, maybe we can stick with 2018.2 for now, and wait for the bugfix to drop.

But if LWRP team is still working on 2018.3 issues, I just don't know when that fix would come... It made convincing people much more difficult.

 

I know it is unfortunate really, but the following reply a little earlier in the thread does make it fairly clear that the time when things can settle down and you can stick with a certain version of Unity without missing out on a lot of important pipeline developments is not here yet.

 

Ah I was wondering about that, because up until very recently I had assumed that major pipeline package versions did have a strong relationship to Unity versions. Then recently because 3.0.0 was available for 2018.2, I thought I was wrong, but now I guess I was right after all.

Speaking of which, what happens to pipeline version numbers when we move on to the Unity 2019 cycles? Do the package versions just keep increasing in a normal way, so that for 2019.1 the suitable pipeline versions will be version 4 or 5 (and will LTS unity versions have their own version, eg pipeline v4 for 2018.4, or do .4 LTS unity versions stick with version 3 of pipelines)?

 

Thx, I know, he was replying to me in that quote; but read Tim-C's next reply right after it. I thought they have made some adjustment on roadmap. I realize there are a lot of development to be done, and I don't blame them. But the current 2.0 branch isn't workable for me, at least.

So my feedback is, if you want people to adopt early, you probably need to maintain 2 branches and not just fix on master as it depends on a 2018.3 beta that isn't released yet (even if it did, I am more wary of using a beta version editor for production, given my experience testing beta 2018.1/2018.2)

Basically, a lot of things are changing, that's both good and bad: good for future of unity, bad if you want to make a decision now.

 

Make it run on the hololens, right now any build using LWRP even a cube will crash.

 

Ah I see. I think his subsequent post did include news and a change of plans, but really this change is about their focus for the remainder of 2018, not what they can give you straight away, and far more likely 2018.3, not what you need for 2018.2, at least not for a while. And by the time they are nearly done with this, 2018.3 will probably be final release anyway.

Personally I treat the pipelines this year in a very similar way to how I treat editor betas, they are not production ready and although Unity want people to try them, they are in preview state for a reason. And whether it makes sense to use the pipelines for a real project now, really depends on intended release date of the project. Unless I was very confident that a pipeline already does what I need and works on the platforms I need already, I dont think I would consider using them for a product that is intended to be released before 2019.1. If things go really well in the coming months then maybe I could be more optimistic and target 2018.3 instead, but there is more risk with that, and I certainly wouldnt target 2018.2, sorry.

 

Oh one last comment from me on this. I cant quite tell from some of your posts whether you are talking about specific things that havent been backported to 2018.2 branch of pipelines yet, or whether you are not seeing any activity at all on this front?

eg if I look at the following list of commits for the 2018.2 branch on github, I do see some LW fixes backported earlier in July.

https://github.com/Unity-Technologies/ScriptableRenderPipeline/commits/release/2018.2

 

Certainly there are updates, but here are things I think can be improved (without adding more code):

- Changelog update: there are so many branches on the SRP, it's impossible to know which one is the latest 2018.2 branch, AFAIK, quite a few recent 2.0-preview release doesn't have changelog item, I have no idea what's changed, all I know is they don't include the fix I am looking for.

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

- Document known issues: sure, they are up on issue tracker, but even when issues are marked as fixed, it's impossible to know they will be included in 2.0-preview release due to current backport policy (only critical fix).

- LWRP feature roadmap: I wonder about this myself, are there any known missing features for LWRP forward rendering? To me, the LWRP asset seems to offer a complete set of features for mobile and low-power device already.

- Will LWRP for 2018.2 be useable and supported? The team already suggest it would, but many people think otherwise. I think this demonstrates a communication gap.

That said, I am not mad about LWRP team working on features. I just want LWRP team to commit on 2018.2 support, and if they must go for 2018.3, I can totally understand too. I just have to plan accordingly, as you suggested.

 

Well, the concept of useable is quite broad, and its not the same thing as supported. It will be useable for some people/projects/requirements/levels of experience and not for others.

As for supported, in terms of supported as in a fully supported system that people should expect to work as well as full releases of other parts of Unity, no. There are multiple indications that show that although there are people from Unity here who are responding to issues and backporting certain fixes, the system is not considered production ready or fully supported:

• The releases are still tagged as preview
• Ongoing API refactoring has been mentioned
• Both 2018.3 and 2019.1 have been mentioned recently in terms of achieving certain things and reaching certain milestones

Really the preview tag is the biggest guide, with the subsequent points I mention just providing clues about expected timescales of when things will go beyond preview release.

 

Thx for your suggestion but this is reading between the lines and I will refrain from further argument

 

I dont consider it an argument and honestly the preview tag means something specific and really isnt reading between the lines. Some of my other points involve a little reading between the lines but honestly not much, and the 2018.2 blog post was quite clear about both pipelines being in preview state.

Now if I could just find the proper official explanation of exactly what preview tag means, I could more easily demonstrate what I am on about, but right now I cannot.

 

OK I found what I was looking for to help explain:

https://blogs.unity3d.com/2018/05/09/unity-packages-life-cycle/

 

I see your point and blog post, but I am going to disagree on 2 parts:

- Since there are only 2 states: preview and released, a binary choice, there are always going to be users asking, "is this closing in on release yet?" aka "is it going to be officially supported?"

- Now, we know this package has some issues that are fixed or being fixed. We want to try out the fixes, but we can't, because this branching politics.

What you are saying comes down to: don't use a preview package if you want support or are unable to just fork your own code. Cool, I get that.

But here is the thing:

- LWRP has been in preview for a long time.
- LWRP team said they want to feature freeze.
- LWRP team wants people to test it out and report bugs.

So here we are, trying things out.

TL;DR: If LWRP team want to stop people from trying out LWRP on 2018.2, they could say it, or close 2.0-preview branch, but they didn't. Preview is the status quo, but I am asking about the roadmap.

 

Honestly I want people to try things, but whether it makes sense for a person to do so, especially with the main project, really comes down to what they mean by support. I dont believe it helps anyone to lure them into a false sense of security when it comes to important topics like support.

I dont mind nuanced details either, I just dont think concepts like support are a great fit for that, and it is sensible for them to be clear about what preview release state means in terms of support and promises to users. I myself often have a wonderful time with HDRP, but I know what the risks are and I really dont see it as that much different to being prepared to risk using a beta of the Unity editor. In fact in one sense it is even more risky, because at least we usually know roughly when a beta will turn into a final release, whereas some packages might remain in preview for a very long time.

Honestly, I'm not even really disagreeing with you much about any details, I just wanted to explain how I see the situation, and to try to understand exactly what sort of support you need and are hoping for with 2018.2 and LWRP. I dont see any reason to think they would want people to stop using LWRP with 2018.2, or close the 2018.2 branch. But I think, without going into every detail, they have given clear indication that plenty is still going to change in the months ahead, and that in some respects the 2018.2 branch of LWRP will be left behind. I dont think its simply a question of 'branching politics' either, sometimes its because there are things in the next version of Unity (in this case 2018.3) that they actually need to make LWRP work, sometimes its a technical matter. But yes, in other regards it is probably a question of resources, and certainly a decision has been made in the past that they arent going to try to port all the changes in a packaged system to the previous version of Unity, at least not during this phase of big changes to pipelines. Maybe this picture will change a fair bit next year, and I can see some reasons why you want the reality to be different now. But I have honestly seen no indication from Unity staff that it will change to the extent you require, and I dont think there is much of a communication gap about this broad point.

But a lot of the reason I keep responding to you is not to argue, its because I share your interest in technical communication between those who are developing Unity and those that use it. I like the amount of communication we get from various Unity people on this forum in relation to pipelines, but there is always room for more, especially when we are trying to learn about the timescales etc of very specific things, as opposed to the broad points I have tended to make here in recent posts. I'm afraid I do usually end up having more to say about areas where I disagree with something someone said, than all the things I do agree with them about. I am sorry about that, it just ends up this way because there is no real need for me to make any points if I already agree with every detail! So yeah, I would love their to be a pipeline-specific roadmap, and some way to cover backporting stuff better in the changelog and stuff like that.

Speaking of detail, I think if you mention the specific things you need to be backported to 2018.2 in order to use LWRP how you want in the next few months (while 2018.3 is in beta) then there is probably a better chance of you getting official responses that give you the exact answers you need. Because without getting into that level of detail, I really think the most likely responses are more like the stuff I have been droning on about today, that preview != full first class support, that some big changes are planned as part of the mission to concentrate on getting the current features stable and production ready, and that backporting is only planned for certain classes of bugfix.

edit - and very sorry for the long post. I dont think there is much left I could possibly say now, so you will finally get a rest from my opinions!

 

@phil_lira , @Tim-C To address the request for LWRP feedback -
from my humble point of view the following two features would be very welcomed:
- fully working combination WebGL2 - LWRP - PostProcessing(within limits given by WebGL2, not LWRP)
- some kind of AO (or similar AO-faking effect) supported by LWRP as a part of PostProcessing package

Again, its from my very personal point of view - we are working on interactive architectural visualizations of historical buildings, where the above mentioned features (AO!) would help us;
however I believe there are many like us out there

Of course I can not resist to ask - can we hope to see this fit in 2018.3?

Thanks for a good job so far and happy summer holiday coding