my project uses LWRP with Lightmap in Linear Color space. (Unity 2019.1.0f2, LWRP 5.7.2)
It works fine in the editor and Standalone build, but on Android the scene looks darker and almost black on lightmap area.
So, if my project was built using linear color space and successfully ran on the target device, it means the device does support linear rendering. I’m not sure why my scene looks darker on Android device.
Some other people in this thread said that Android doesn’t support Lightmap properly on Linear color space, but not sure if that’s a verified answer. It would be really helpful if you could verify this issue.
I think I just ran into this issue as well (or something similar). Trying to use ScriptableRendererFeature/ScriptableRenderPass to achieve object selection without raycast/colliders by rendering each object with a narrow FOV camera and a unique color using an OverrideMaterial with my custom shader in the pass.
This is working really well, but when I try to augment the color to also encode the depth to get a world position of the selection, I’m noticing that the depth buffer is always returning nothing. Was trying to use the R and G channels to identify the object, and then the B channel to store the Linear01Depth (which I could then convert to world coordinates back in C# using the near/fear clip plane values).
Do I need to make a custom depth pass on my feature as well, or any ideas why the depth texture would always return 0 for me on my custom feature/pass?
Strangely, if I look at the Frame debugger, it shows valid data in the depth texture for the camera. Reading this data straight from the texture and setting all channels of the color to the depth texture still results in nothing (When I would expect it to render the depth texture in red)
I’d also like to ask again about the Colorspace issue. We are using LWRP to develop for Oculus Go & Quest (so, Android VR), and the scene becomes a lot darker (like would be expected with wrong color space). What’s the current status of this? I’m finding very disparate information online.
We are trying to modify the lightning attenuation function that looks very bad on device, but since 2019.1 each time the editor is opened the LWRP files are overwritten. Which is the workflow to modify LWRP?
Issue is how we can reference the renderers in a renderer feature. Renderers live only in scene and the feature as scriptable object is not bounded to any scene.
If we expose a way to inject render passes, say in, the BeginCameraRendering would that solve your problem?[/QUOTE]
Correct. Each of those render passes will call context.DrawRenderers and sorting will happen per DrawRenderers.
We have planned to expose more control of the “built-in” passes in LWRP renderers so you could choose different filtering/drawing settings when rendering the opaque/transparent passes.
Thanks for sharing it. Seems like it doesn’t repros on windows but I can reproduce it on MacOS. Will poke around.
Do you know if this is a regression introduced recently?
Also, I find my custom shader based on LWRP shader library works, while LWRP default Lit / Unlit shader doesn’t.
The green ones are LWRP Lit and Unlit, the rest is a custom shader using LWRP library (hence same SRP batch):
(I can’t reproduce this issue with a new project, not idea why.)
(Another observation: LWRP shaders are not searchable when you create a ShaderVariantCollection and try to add them, so I can only create they by using the “Save to asset” option under Graphics settings.)
Hi, thanks for your reply!
As I have mentioned in this post , postprocessing causes the scene to be look darker. The same scene, LWRP and lightmap in linear color space rendered just fine on an Android device when the postprocessing layer component attached to a camera was disabled.
I’ll do some more tests and if the problem becomes more specific, I’ll submit a report then. Thank you!
Unfortunately I have the issue without using lightmaps at all…
I still tried what you suggested (clear lighting cache, baked Lightmaps and then killed them again), but the problem persists.
Looks like my post causes misunderstanding to you, sorry. It was the postprocessing component that causes the darker look on Android device, at least in my case.
I received reply from QA confirming this bug and it has to do with LWRP Lit/Unlit shader on Metal API and color gamut Display P3 support. When all 3 conditions are met, the build will render material as black.
Just something to keep in mind before fix is released.
I imagine this is going to be a per-model, rather than global setting, right? For example a drop-down menu in the “Model” Inspector tab, where I can specify what mesh components should be kept for that particular model.
I’m experiencing a big difference in expected editor behaviour when using LWRP materials.
I’ve built a level editor tool which relies on the editor selecting objects through culled back faces.
However with LWRP materials, the editor selects the culled object instead.
The LWRP is a fantastic new addition, really useful to have this level of control!
Editor suggestion: I’ve just started upgrading a project to LWRP in 2018.4 (so using 4.10-preview) and the profiler groupings are a bit awkward to monitor as the render pipeline is inside the scripts grouping.
Would it be possible to add in a new grouping in the profiler for the render pipeline? Currently its all grouped within scripts and means when doing “general” profiling the rendering (green) section looks less taxing and the scripts section (blue) looks more taxing in the profiler than you would expect.
Ah, just checked it and the “RenderPipelineManager.DoRenderLoop_Internal” is under scripting category. I’ll check what can be done. The other LWRP rendering markers are under “Rendering” which is expected.
So now that Unity announced that the LWRP is production ready I decided to check it out again on 2019.1.2f, testing both the verified (v5.7.2) and latest version (v5.13.0).
Can anyone comment on why the LWRP is still allocating around 1KB of garbage every frame (in a build)? Currently, without the preview of incremental garbage collection turned on, the LWRP’s aggressive memory allocation causes frequent GC spikes in the default or empty scene. For comparison, in a similarly empty setup built-in doesn’t allocate at all.
This issue was [brought up over a year ago]( Feedback Wanted: Lightweight Render Pipeline page-3#post-3449645), and it seems very little has been done in the area since. Personally I would never consider using something that allocates such a large amount of garbage per frame. Is making the LWRP GC free on the roadmap? It seems to me that matching performance with built-in would be at least a minimum for what is considered to be production ready.
As an aside, in a fresh project trying to make a build after installing LWRP v5.13.0 will end in a failure to build. I needed to remove and reinstall the LWRP before I could get it to build successfully, and even then I ended up with Non matching Profiler.EndSample errors when it did. I know this version isn’t “verified” for 2019.1, but it doesn’t particularly inspire me with confidence in the production ready status of this package.
