Feedback Wanted: Lightweight Render Pipeline

It works properly when I used Standard Shader but there is depth problem on semi-transparent textures due to disabled ZWrite value . So I modified the Standard (Physically Based) lwrp Shader and change the ZWrite value to on (already set Surface Type to Transparent and Blending Mode to alpha). This thing resolve depth issue but I am facing base problem mentioned above (Fade In-Out Effects issue).

I am not a native speaker so if you have any confusion please let me know

 

I seem to be experiencing a huge frame drop when using the Lightweight Render Pipeline on some Android devices but not others, I can't tell if it's just better hardware or the variableness of so many different android devices. Seemingly older hardware can run fine, and a newer android device has its frames reduced to 2FPS from 30. I know it's the pipeline because of our source control, on the version I have where I implemented it, the frame drop occurs, but not on the commit before it.

Could I be possibly doing something wrong or missing something? Lightweight is supposed to be FASTER not slower on mobile, what gives? All I've done is create a new LWRP asset, and assign in in the Graphics settings pipeline. I've also done the Edit > Render Pipeline > Upgrade project materials to lightweight materials, and all my shaders are set to the Lightweight versions, but I've done nothing past this.

 

I'm having trouble with a couple of models on Android Galaxy 8, os=8.0.
The display shows shadows, but not the model. Everything looks good on Windows 10.
Unity 2018.1.6f1 LWRP
I'll update this once I finish downloading 2018.1.9f1 (downloading it now) and try it out there.
Some models display well, others not. Simple models.
Also, no audio on Android.

Update:
I installed and used 2018.1.9f1 and still having problems with some models.

(I'm embarrassed to say that the audio worked after turning up the volume on my wife's Galaxy, I don't have my own smart phone).
The dark red oval shows where a house should be, the shadow is there and I can crash the rocket into it, so the box collider is there.


Missing model draw, but shadows appear (ignore the rocket debris from previous attempts)

 

Hmmm, the reflection probe seems to have its x and z swapped somewhat in the Android version (2018.1.9f1 LWRP Shader Graph Reflection Probe)
On Windows 10, my water reflections are correct and flow downward (-z direction) but on the Android they stretch to the right of the reflected object.
(I should say that when the project type is switched to Android, Play mode shows the reflections go to the right) I have checked that the reflection probe is still following the camera correctly.
(Looks like Dropbox is not a good way to share photos)


The Windows Platform


Android Platform


And, here's my WaterShader graph

 

Here, I uploaded the photos to photobucket.
I should note that the material using this shader graph is assigned to a plane with a scale of x=4, y=1, z=2


Windows Platform


Android Platform


And the WaterShader shader graph

 

Thank you Phil, Tim and Andre for replying, I really appreciate it.

I am looking forward to the next LWRP 2.x-preview release, for now I am bouncing between built-in forward rendering and LWRP, and try to delay my work on custom material/shader for as much as possible (They appear to be the main blockers when switching rendering pipelines.)

====

Personally, I have been using a test scene to compare performance between Built-in Forward and LWRP Forward, and see around a nice 10~20 fps bump on Intel GPU, but it's not without some caveats:

- I am not able to get the same shadow resolution as built-in forward rendering using the same shadow distance: LWRP provide more precise control on directional shadow atlas, but with a maximum of 4096 + my shadow distance (150), I am seeing a lower resolution shadow when compared to the "high resolution" shadow setting from built-in pipeline. I need to shadow distance to around 50 in LWRP, in order to maintain the same shadow quality (see screenshot below).

- The shadow position is offset more in LWRP for unknown reason: I know receive shadow is still broken at the moment. But the extra position offset feel weird to me (see screenshot below). LWRP also gave a darker color for shadow that's illuminated by other point light, no sure this is to be expected.

- LWRP 2.0.8-preview seem to come with it's own Post Processing Stack: That or there is a bug in package manager, as I am seeing a strange error message (see screenshot below), and I have to remove existing Post Processing Stack to fix this error. And strangely, my Post Processing Layer still work after the removal.

- I am not 100% confident about the bump in FPS, but at least we know there isn't any slowdown, so it feel promising: the main reason I am skeptical is due to shadow resolution setting and broken receive shadow - so LWRP got some unfair advantage here. Secondly, macOS will throttle performance due to heat within 30 seconds, so measuring average fps without vsync is not easy.

====

Screenshots:

fps with built-in forward pipeline (using Intel GPA)



fps with LWRP forward (using Intel GPA)



Shadow offset with built-in pipeline:



Shadow offset with LWRP



Shadow resolution in LWRP when using the same shadow distance as built-in pipeline (shadow resolution is set to "high" in built-in; directional shadow atlas is set to 4096; there are only 1 shadow-casting directional light):

 

I run out of attachment limit, so here is the error I got when using both LWRP 2.0.8 and Post Processing Stack 2.0.10, on Unity 2018.2 (removing Post Processing Stack package via package manager, and the error is gone, and post processing still works):

 

Hi Team,
Is there an ETA on GPU instanced shader for particles using LWRP?

Thanks!

 

OKAY!
I figured out the problem with missing models on Android with 2018.1 LWRP
I noticed that some of my "powerups" showed up and some did not. The base models for the powerups used LWRP Standard (physically based) shader, but some had "Enable GPU Instancing" turned on and some turned off. The ones that had it turned off displayed correctly.
So, I turned GPU instancing OFF on the house and it displays correctly on the Android (Galaxy 8, os 8.0)

 

Yeah... The same as material.... Unless I misunderstood that...

 

Pipelines dont have their own copy of post-processing 'built in' as such, but rather packages have the concept of 'dependencies' which automatically tells Unity what other packages need to be used with them, and means you do not need to add these other packages yourself. This is the same with things like Shader Graph, and the shared Pipeline Core that both LW and HD pipelines use.

If you want to see what dependencies a particular package has, you can look in the appropriate Packages folder in the project browser, at the file called 'package', in the dependencies section of that file. eg Packages\Lightweight Render Pipeline\package. So for example with LWRP 2.0.8, these are its dependencies, so your proejct is already using Post Processing package version 2.0.8:

"dependencies": {
"com.unity.postprocessing": "2.0.8-preview",
"com.unity.render-pipelines.core": "2.0.8-preview",
"com.unity.shadergraph": "2.0.8-preview"
},

edited to add - And I believe (but am not 100% sure) that normally it doesnt matter if you also happen to have installed one of its dependencies manually yourself using Package Manager UI etc. But what does matter is that exactly the right version is used, so for example in your case you probably got errors because you were trying to use 2.0.10 version of PostProcessing but LWRP 2.0.8 needed to use PostProcessing 2.0.8. Other circumstances where this stuff can go wrong is if something like an older version of PostProcessing was already in your project via non-package means, eg was installed manually in Assets folder in the past.

 

Thx, but again, I would argue there are things to be improved here:

- If LWRP has any peer dependency* on Post Processing Stack, then Package Manger should really resolve it correctly (it's out of the scope of LWRP team, of course.)

- If LWRP does import** it's own version of Post Processing Stack package, I would like to see it listed in the project list. For now it isn't. (Again, out of the scope of LWRP team, but I expect a flatten dependency like Unity Assets, not a nested hierarchy of packages).

There are of course multiple ways of handling package dependency and I hope Unity model theirs after npm.

*peer dependency as in: LWRP is not dependent on Post Processing but only work with a certain version of Post Processing API, same as the term in npm's package.json definition.

**import as in: If a package is being used, I should see it as a folder under Packages (in this case the Post Processing Stack is still available but not shown in package list or the project manifest, I have no idea why and I know this is not the right venue for such a discussion.)





I have opened a thread for package manager discussion here:

https://forum.unity.com/threads/peer-dependency.543636/

 

Thank you so much, I would love to get an update on this whenever you/they hear anything, as we have some live projects that could benefit from the new pipeline greatly.

We already have some shaders etc written in new pipeline, its just that it cant build. Very excited to finally transition to it when we can!

 

seems like PostProcessing changed its assembly name between 2.0.8 and 2.0.10.
that is a breaking change. MAJOR version should have been incremented if you are following semver

 

Well, Yoshihiro did a cool AO that is not based on HDRP compute shaders, working with LWRP post processing:
https://github.com/beinteractive/LWRPAmbientOcclusion

 

Now if that could be the case for custom bloom...

 

I'm get a bunch of garbage every frame with the LWRP



This is profiling a build, not editor

3.0.0 preview

 

I'm getting GC allocs every frame under "RenderPipelineManager.DoRenderLoop_Internal() in the editor. I'm wondering if it's normal or not.

 

any news on light weight lensflares?

 

Still waiting on the shadows fix, does anyone know something about it or know how to fix it. For people who maybe dont know the shadows only render from world position 0,0,0 so I can move with camera further away and shadows will stop rendering.

 

JUST what I was blabbering about... Done by hacking lighting.glsl in the shader library of the LWRP package.

 

Now for baked light maps....

 

[LWRP Mixed lighting on direction light doesnt work properly]

Today I was recreating how the game lighting should be done, I am currently working on MMORPG project, and I want to run it on any pc and maybe somewhere in the future even on other devices. Thats why I am using LWRP, then I though having baked lighting would be a lot faster so I changed the Direction Light to baked but no shadows were casted on the dynamic objects and ofcourse player. Then changed to Mixed lighting becaus I knew from using it in my old projects that it works just fine, after changing to mixed things got weird, first of all is that dynamic objects dont receive shadows from static objects, second of all the shadows from dynamic object are casted over the baked shadows. Tried experimenting with Lighting Setting but nothing changed.

The question here is if its only my bug or its something known for sometime that I didnt saw in posts etc. and if its fixable or when It will be fixed, plus adding image in old RP and LWRP. Thanks


(Old Rendering Pipeline)


(LWRP)

 

I bet light probes could help with that.

 

Now WHAT shader's used for baked lighting?

 

Couldn't do THIS either

In Unity's Shader graph as well...

 

I had something similar and disabled shadow cascades in the LWRP asset. That worked for my 2.5D game where i could set the shadow depth to the visible range without any aliasing - obviously it's not a solution for true 3D games.
Glad I'm not the only one with this problem.

 

Anyone got any alternatives for lensflare? Taken that Unity wants to get rid of flares.

 

Regarding scripting, I'm curious as to why so many settings in LightweightPipelineAsset are read-only at runtime. It's nice that we can set up a few preset assets and swap between them, but the lack of flexibility and fine grain control is frustrating.

It would be nice to be able to tweak shadowmap resolution and other performance-critical settings at will, especially while testing, to (e.g.) check impact on different mobile devices. Or to have a few low/medium/high presets but still allow users to tweak certain individual settings as many PC games do.

Alternately, a way to build a LightweightPipelineAsset with non-default settings entirely in code would work. I don't see any way to do that right now?

 

@Tim-C any update on hololens support for 2018.2? Please remove it from list of supported platforms if your latest release will crash on any built out project, as it is not right to claim it is a viable build target.

 

I see on GitHub that a bunch of "Keep-Variants" fields have been added but either aren't exposed or aren't present in the version compatible with 2018.2. A mutable subclass where those are enforced might be a solution - my hope is to have at least a bit more flexibility for performance profiling before settling on per-device presets.

 

Got an alternative thanks to Unity's particle system.... Now if I could put THAT onto another layer as if overlay... And perhaps an image effect as an alternative.

 

No because any build, even a cube will reproduce this. No need for a bug report, no project can run it. Have tried at home, at work, multiple pcs, OS etc. Have tried existing projects and fresh ones.

Currently you just cannot build out for hololens using 2018.2 and the LWRP, so instead of trying to follow a bug just make a blank project with these, deploy to hololens and hey presto you will see the crash!

I would file a bug with full attached project but really given that we have tested this extensively we are very sure you will not need one to come across this.

 

I found a bug report here. Experiencing the same issue.

https://issuetracker.unity3d.com/is...weight-rp-on-uwp-platform-trigger-an-exeption

 

Glad I am not alone!

EDIT: updated the issue with editor versions

 

Do I properly understand that something like having motion vectors would be impossible by design?

 

Don't draw opaque and alpha test in the same queue.

 

Hi everyone! How many realtime light sources can i get working on lwrp on android? Currently on pc i can have working 8 light sources, however when i switch platform to android, only one light source remains working. Using Unity 2018.2.5, lwpr 3.0.

 

Is anyone managing to use this with Android VR? If I tick 'Virtual Reality Supported', I just get a black screen as described in this thread https://forum.unity.com/threads/def...ys-black-screen-when-built-to-android.539587/

Not sure if this is a Unity or pipeline issue.