A Unity ID allows you to buy and/or subscribe to Unity products and services, shop in the Asset Store and participate
in the Unity community.
Discussion in 'Graphics Experimental Previews' started by phil_lira, Sep 28, 2018.
I've been trying to find which commit was done to fix this, do you have any ideas?
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.
This is a mock-up of our new workflow for working with cameras. Please give your thoughts about this.
Are culling layers for the base camera still supported?
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?
- 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:
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
I'm not sure what you are referring to here, the new modular render pass stuff? we are working on putting together a post about it along with some videos showing some use cases.
Yes this is a known issue, this is unfortunately due to the lighting system being reliant on hardcoded strings to find properties in the shader, in SRP/LWRP we wanted to not follow the past because it had some bad ideas, but this means we need to fix this by making the lighting system a bit smarter in which properties it uses for baking this information. Also in the mean time we tried to be smart by letting existing material upgrade and keep the existing properties, this is not ideal at all but was all we could do in the time. We have a high priority bug open for this and will be working on it in the coming weeks.
Yes they are, in the video the property is not seen as it is collapsed in the 'Rendering' group.
This is a good point, but a you mention lower down the page about a custom pass and just changing the matrices, we will be posting a video showing this workflow. We essentially have a configurable pass system for this that you can override the base camera matrices, mainly FOV and clipping planes, but this is one way we are solving some of the multi camera usage in LWRP without having multiple cameras since that is more excessive than whats needed.
Yes this has been depreciated, now the way to achieve this is pipeline callbacks, the manual page doesn't have much in the way of info right now(must get on to that) but here you will find my usage in the planar reflections which I had to update from IBeforeCameraRender to the new system.
This is also depreciated, it is replaced by the new RendererFeature system, we will again be doing a post showing usage of this, the new way is much nicer and will also help us to move forward with nicer tooling down the line.
Currently it's a straight forward package update, there are some kinks such as some depreciated APIs of you have been making custom rendering hooks, some shader changes were done so there might be some API issues there too. But outside of that it should be fairly painless.
This will be smooth, we will be keeping the path clean all the way through will upgrading between breaking changes(0.x.0) releases will be handled with either auto API upgraders otherwise we will be providing very comprehensive upgrade guides each release if anything is needed.
Correct, and currently 5.x.x is our priority right now, and also right now 5.x.x and 6.x.x are in sync so fixes and features are implemented in both versions, as the 19 tech stream continues we will slowly leave 5.x.x behind but this won't be until we hit some breaking changes that don't get back ported to 19.1, but the idea is that you don't want to stay on the first version of a tech stream, and ideally you will keep updating until 19.4 and both unity and LWRP will be supported for 2 years after that point.
Also I do want to apologise to all of you on the lack of communication and information lately, we are a small team and with 19.1 coming to a release soon and GDC, we wanted to make sure we get a good, solid foundation tech wise for LWRP done, this means we have been working around the clock trying to make sure this happens. In the coming weeks up to 19.1s release we will be making sure we get as much documentation done and plenty of examples with accompanying videos to help explain the new features and APIs that have recently changed.
Should work fine
Anyone reading this, it works fine on 2019.1 but not 2018.3 so upgrade if you are experiencing this