Feedback Wanted: Lightweight Render Pipeline

I've been trying to find which commit was done to fix this, do you have any ideas?
thanks

 

You're somewhat correct. multi_compile exists for things that can be toggled systemically (read: at run-time) and thus stripping must be dealt with at the Scriptable Shader Variant Stipping phase in the build process. If you use shader_feature, that implies that this is an author-time selection of features for that Material, so if no Materials use a given variant it gets stripped automatically.

Simply changing to shader_feature may end up inadvertently removing variants that get changed systemically, which can lead to unexpected behaviour.

Also, what you mention about run-time shader compilation isn't technically correct. Shader programs vary based on hardware so you will incur a run-time compile regardless. It's better to think of the build-time Shader compilation as something of an Intermediate Language. I think historically the only time this wasn't true was for console games when you knew exactly what the hardware needed.

 

so as long as my shader variant collections define all the required variants we should be okay ?

 

As per the Documentation I don't think that is definitively true, but I could be wrong. Because of Asset Linkages, I'd imagine in the fully automated process that the ShaderVariantCollection would validate it being included, I'm unsure if the new Scriptable Shader Variant Stripping bit in SRP could override some of that though.

That said, if you aren't seeing issues you most likely are safe, as I'd imagine a missing Shader Variant would be quite obvious at run-time.

 

Sorry to bump this, it got lost on the previous page and hoping someone can respond to this, are there any other suggestions on how to get more than one light rendering?

 

Only Point and Spot are currently supported as additional lights. LightweightRenderPipeline.cs

 

Unity 2019.1 and 2019.2 do not work with LWRP 5.2.3 - 5.6.1 on Android and Editor. When using 5.2.3 it's not possible to have 2 cameras (1 for UI) on Android device, because the background color doesn't get cleared thus you only see a blue screen with the elements rendered in the most top camera. With LWRP 5.3.1 and upwards this behaviour is even reproducible in the editor game view which means you can't play in the editor at all due to background color non clear bug.

Is there any fix planned?

 

It's not a bug, LWRP does not support Camera Stacking:

 

Oh I didn't see that comment, thx. But it is working in 2018.3 and 4.X is there a reason why this was removed?

 

Ah right, thanks for letting me know. Apologies for not reading the notes properly.

 

Check the last 2 or 3 pages, there is conversation about it. tldr; Camera stacking is hack-ey and not good for performance. They are working on better solutions that will hopefully fulfill camera stacking use cases.

 

This might be too difficult to answer, but I was just wondering if there is an high level estimate on when you're hoping LWRP to come out of preview or any roadmap information you're able to share like 'it's hoped that it will come out or preview by 2019.1 or perhaps by Summer 2019 type estimate?? I know how hard this kind of question is to answer so sorry for asking anyway. But we're assessing our tool chain for a new project and I would really really like to use LWRP to gain features like the post processing v2, shader graph and to be generally setting up a new project to be more future proof on the way Unity is headed.

However being in preview and deciding to go with it is currently a little risky for us, we're at a bit of a crossroad where we'd have to take a leap of faith that it will be solid enough for us to use by the time our internal milestones roll around, or whether we stick with the built-in renderer. It's a hard choice because either direction will vastly change what shaders, post-processing effects we use and develop, what materials and colour settings for environments. Once we choose one it will be harder to switch. Any info on a bit of a roadmap even if it was loose would greatly help us gauge the risk, thanks!! =)

 

From a few pages back:

 

LWRP, SRP Core, and Shader Graph are/will be out of preview with Unity 2019.1 Public Release

 

Ohhh wow!! Thanks so much for sharing that detailed roadmap and confirming that all of that is coming out of preview in 2019.1. Very excited to hear all of that. Ok, we’re in on LWRP for our new project super excited to take it for a spin thanks!

 

@phil_lira Is it a known issue that AlphaTest is ignored during Light Baking?



I was able to repro this in 4.x and 5.2.3. I have not tested against any of the 6.x versions.

Edit: a word

 

render loop call CetComponent cause gc, can avoid the problems?

 

wait aren't the render pipelines meant to be production ready by 2019.3 not 2019.1?

 

My understanding is that LWRP will be out of preview (production ready) for 2019.1 and HDRP is targeting 2019.3 for being out of preview. LWRP is no longer shown as a preview package in the 2019.1 beta.

 

Just an update that the issue is not reproducible in LWRP 6.5. I have been diffing the files and making changes locally to anything that seems suspect, but to no avail. I'm curious if this might be a bug in the Lightmapper itself in the context of SRP. I was unable to reproduce the behavior in the built-in Renderer in our affected version, 2018.3.7.

Edit 1: Filed a bug. Case # 1135899

Edit 2: For posterity, this appears to be an issue with the Lightmapper as I had tested against 2019.1b2 and 2019.1b5 + newer and between b2 and b5 the same LWRP package begins to effectively respect cutout. Since the bug affects preview versions of the Package my guess is that no back port of a fix will be administered to 2018.3.

 

Are culling layers for the base camera still supported?

 

Looks great.

 

Looks like a great setup and really straight forward to use.

 

The first thing that jumps out to me here is that the usage of additional GameObjects seems unnecessary as you yourself mention that in most general cases they will have the same position and rotation anyway. I would lobby for elimination of redundant data at every opportunity.

 

Wouldn't the cameras have to be a component then? Since gameobjects in unity has to have at least a transform. While I was watching the video, I didn't look at the hierarchy at first so I was thinking the cameras were hidden and controlled through the UI until he started selecting them in the hierarchy.

 

Not necessarily. A Camera is really just a World to Camera and a Projection matrix once you get right down to it. (I'm absolutely oversimplifying here for the sake of argument.)

If you wanted to right now you could write an additional Pass which changes those matrices (and perhaps some other scaffolding) and you would have a cheap 'Overlay' Camera.

VR already does this in different ways depending on the mode, but for instance MultiPass it simply renders left eye and then right eye from 2 'virtual' Camera positions. You don't need 2 GameObjects or Transforms to do this at all.

 

Ah, so it could be something similar to adding camera components to the main camera?

 

Just pulled LWRP 5.7.2 from the package manger (2019.1.0b7), and it appears IBeforeCameraRender can no longer be found. Is this a regression, or has it been deprecated?

 

IAfterOpaque is missing too. I'd like to know if there is any way to inject custom pass in 5.7.X.

 

My suggestion would be to let the Additional Camera Data Component house this data. The UI could be reflected nearly identically in the Camera Inspector as @martint_unity showcases in the video.

 

I understand the desire for a lack of redundant data, but I personally would prefer that each Camera be a component that can be attached to the same GameObject or different ones. I can think of several use cases where a user might not want the overlay camera at the exact same position / rotation.

GameObjects, although not nearly as light as Entities, are fairly lightweight and having a few extra ones for a Camera setup is no big deal imho.

 

As a year-long LWRP user, currently on 2018.3, I would like to see 2 things:

- What's the upgrade path from 2018.3 to 2019.1? (Shader Graph included)

- What's the upgrade path from 2019.1 to future release?

I assume:

- LWRP 4.x is dead, nowadays all my reported bugs are only fixed on 5.x or 6.x;

- LWRP 5.x is for 2019.1, and 6.x is for 2019.2, but then what's the plan on maintaining 2 stable packages?

- When 2019.2 comes out what happen to LWRP 5.x?

All these talks on LWRP roadmap are great, all these sharing packages early are good, but where are the support and migration plans?

 

LWRP does not work on the oculus go, as has been mentioned by various users over a big period of time here:

https://forum.unity.com/threads/lwrp-not-working-on-oculus-go.563110/

and here:

https://forum.unity.com/threads/lwrp-and-oculus-go.546417/

Can someone please respond regarding this, its worrying that the keynote talks about LWRP being out of preview yet it is not functioning on some platforms...

 

Looks good to me I think. Should cover my camera stacking use-case as far as I can tell. Looking forward to it!

 

I have same questions

 

bueno.

 

Should work fine

 

EDIT: it doesnt work on 2019.1

 

Does that mean that we won't have a chance to use the production ready LWRP if we stick with Unity2018? Or there will be some degrees of backports, so it will be production ready but with less features?

IMO, it won't make any sense if LWRP is production ready only for Unity2019, which isn't production ready itself

 

Known Issues in 2019.1.0b8 under investigation
Scripting Upgrade: Crash on loading scene after project upgrade form 2018.3 to 2019.1

What happens if i upgrade to 2019.1 beta, my project scene all reference objects timelines scripts shader settings resets losing data ? Thats why most people stuck with old unity (2018,2017,5.6 etc. ((anti beta team v4 ))).

 

Unity has already noted that support for 4.x (2018.3) has stopped. I would not count on back-ports.

2019.1 will be production ready once it exits beta. This will likely be within the next few months if previous releases are any indication.

 

Either make a copy before upgrading, use version control, or don't upgrade until the issue is resolved. Betas are prone to issues like this and are to be used at your own risk.

 

Unity 2019 is the latest tech stream, and it can't be considered as production ready till 2019.4 LTS(Or at least 2019.3). Technicall speaking Unity2018 isn't production ready yet either, although the LTS version of it is coming in the next 2 months.

 

I'm not one to typically argue semantics, but there seems to be some confusion around that nomenclature. It seems vernacular like "Production Ready" and "Stable" are being conflated here.

As per the Blog post about TECH/LTS: https://blogs.unity3d.com/2018/04/0...g-the-tech-and-long-term-support-lts-streams/

"For those of you starting or in the middle of production, or just looking for the latest features, we offer the latest version of Unity with all the new features in the form of the TECH stream. For those of you who are nearing the end of production or are operating a live game, we have the LTS stream in which only bug fixes are added."

From that paragraph it's pretty clear that TECH streams, out of Beta, are Fully Tested, Production Ready (read: can be used in Production) and LTS is what you want to try to ship on, for Long Term Support.

 

Yeah, I read that blog post, and understand what it says. Unity did a great job and made very impressive progress for the last 2 yeast. But what I'm trying to say is in practise, x.1 or x.2 version are generally too buggy to use for projects that is gonna to be released before Unity x.3 version.
And Unity advertised about LWRP in GDC 2019 that it will be production ready in 2019 Q1, but if it's only avaliable for unity 2019, that might mean for us to give it up totally. So what I need is a clearification that if we'd better not to use LWRP if our project is going to be released Q3-Q4 this year and do not want to put it on risk to release it with Unity2019.2. Because for LWRP 4.10 for its current state, we've already encountered some issues(well known issues that are fixed at 5.x/6.x branches) and don't think it's a good idea to convert the whole project to use this version of LWRP​

 

As Unity has stated, as of v5.x LWRP is no longer a Preview Package (read: Production Ready). When 2019.1 exits Beta (possibly sometime in the next few weeks), it will be Fully Tested (read: Production Ready).

Unity has stated they are no longer supporting 2018.x for LWRP. So to use Production Ready LWRP you will have to be using at least 2019.1.

 

Thanks, just wanna to be sure that 2018.x won't have chance to use Production ready LWRP.