Feedback Wanted: Lightweight Render Pipeline

I recently had a go at testing a project I'm working on (early development stages) in the 2018 beta and using the LWRP. I wanted to share a bit of feedback and a couple of things I noticed.

The project is targeting mobile, it's 2D using mostly Sprites and some custom rendering with Graphics.DrawMesh, DrawMeshInstanced and CommandBuffers. No lights, No shadows and mostly transparent shaders.

Moving things over was really quick and painless, and I can see a performance improvement on device. I had to rewrite some custom fragment shaders, which was easy enough by looking at the source shaders in the repo, but it'd be great to see an overview on what's different/what needs to be added in the final documentation.

Dynamic Batches
It looks like dynamic batching doesn't work with LWRP, is this by design? Below are some screen grabs from the frame debugger showing the built-in render vs LWRP (both in 2018.1b13) you can see with the built-in renderer there are 2 dynamic batches and there's about a 10 draw call difference.



Garbage Allocation
The LWRP seems to be allocating around 1.3KB of memory per frame in the editor, on device (iOS) it's much less at 160B but still per frame? (Coming from Array.Sort() and CommandBufferPool.Get()).

 

I've being testing the LWRP on 2018.1.0b13 and I don't see any notorious difference between the standard and lightweight pipelines while running the editor, however on my Android device I'm experiencing a performance degradation. With the standard pipeline I'm getting 30 FPS as shown in the image below:



When I switched to the Lightweight rendering pipeline I expected to get at least a small but noticeable gain in the frame rate, however at least according to the profiler I'm getting a severe performance lose, less than 15 FPS as you can see in the image below:



One fact worth noting is that everything seems to take a lot longer, not only the rendering, so it makes me think there's some scale error on the profiler's graph, maybe?. On the device itself the LWPR seems a little slower, not as much as half the speed as it's shown on the profiler, however it does feel slower.

I thought I was doing something wrong, so I disabled all the post-processing effects and created a brand new lightweight profile, assigned it the graphic's params and repeated the test, but I'm still getting the same results.

 

I'd like to know why shadow strength is ignored in mobile.
and Is there any plan to enable it in the render pipeline settings?

 

@phil_lira do you have geometric specular AA in LWRP? or any specular AA? mostly asking for VR here

 

The receive shadows on renderer is not work in LWRP.

 

Thank you for a reply. It's good idea to change the behavior in the next version.

BTW, Where should I define SHADER_HINT_NICE_QUALITY? It seems to be used in Screen Space Shadow Shader. But it's hidden from my project.

 

I found a uGUI disappearing issue on iOS in specific condition and reported the issue.

See:
https://github.com/Unity-Technologies/ScriptableRenderPipeline/issues/1161

 

hi,

It seems occlusion culling is not working with LWRP, can someone confirm?

thank you.

 

Hi @Tim-C ,
This issue is really a showstopper in my mobile project.
It relies on postprocess that needs a depth texture (depth of field). In 2017.x I found no way to avoid a depth-prepass, and extensive search on internet confirmed it (https://gist.github.com/aras-p/5e3aa6f81c543ca74e3ae296c72ffcaf) ... but I'd be very happy to be wrong !
We're moving to Unity 2018.1 with SRP LW because it's the only solution I got to fix this problem, as having a depth-prepass on mobile is impossible if we want to keep a good framerate with a nice visual quality.
This works and I'm very happy with it ! but dynamic shadows (even if one single object cast shadows) add the prepass back on the entire scene,nullifying our efforts.

I understand this'll officially come in 2018.2, however it's a long way to go and we can't iterate on our game without dynamic shadows for 3-4 months. Is there any way we could have access to this sooner ? (e.g as a PR that's not yet merged into the master or something). I don't mind if it requires heavy tweaks to the LW SRP code on our side (as an example, I'd be able to totally remove screenspace shadows to reduce the shader variances); anything will help us because the only other possibility is for me to code the non-screenspace shadows myself.

Hope you understand, thanks !

 

Hi!
Dynamic Batch is not working for me too. Render-pipelines.lightweigh 1.1.2 and Last 2018.1 Beta
Bye!

 

Concern #1: Is LWRP going to support substance Materials?

Concern #2: LWRP is a bit on the too low side visually for VR and HDRP is too much for VR so... with the introduction of this uncomfortable split, towards a less flexible pipeline, (no, having two separate rendering pipelines is not flexibility, it's specialization) Unity is kind of delivering the VR scene to Unreal. There are no large studios that I know of doing VR with Unity and there are no indie VR studios that have the luxury to have an engineer who would be specialized in SRP. So... chances are the small teams doing VR with Unity will feel locked into choices they do not want, thus considering a different solution. Unreal and other engines in the meantime are supporting a unified pipeline. That definitely does not sound good for Unity. I know this was meant to help Unity's visuals shine, but the solution chosen (especially when the Unity standard rendering pipeline becomes deprecated and chances are it will sooner or later) is really bad in my opinion.


My suggestion is spend time and effort to bolster the existing pipeline and improve the lighting solution. SRP is great for large studios, and large games, but it will probably rub your current user base (which is not large studios with large games) in the wrong way with unwanted issues.

Don't try to become Unreal in the place of Unreal. People chose Unity over Unreal for different reasons while they have the option at any time to chose any other engine they see fit for their project and team.

 

Substance have already said they will maintain their own plugin. Yes it will, but its an SRP so if it didnt the community could add support (same way amplify has a substance sample node).

 

After the last updates, I wouldn't hold my breath... looks like someone really dropped the ball with planning. Very disappointing. We will not be using 2018.x for our next projects. At least that is very much certain. Maybe 2019 when the technology has matured.

 

Do you mean substance or unity? Because unity 2018 is in beta, and substance designer 2018 and painter 2018 are amazing in my opinion. What is the problem you have had with it?

As for the plugin, that doesnt have actual substance in engine support yet and will come with 2018.

Either way, message them on their forums if you own a sub or license as they always are great at getting back and helping.

Example: painter 2018 was crashing when it first came out, they fixed it within a week for users on tablets like we are, despite it originally being outside their hardware scope.

 

This post has brought my attention and I think there’s a point of concern here. As an asset publisher that cares about VR compatibility we are looking very shortly after the response on the new pipelines.

One of the values for Unity is democratising game and VR development so I think the ultimate goal is to provide a flexible pipeline for any user - however ease of use or learning curve has always been a strength of Unity. Everyone I’m consulting is against the current “strategy” of bringing two pipelines with the added capability of letting users to customise their own pipeline in a proprietary form.

Many publishers expect Unity will ultimately provide an abstraction layers so even if the underline pipeline is different, the asset and application layer would be mostly agnostic (in the way surface shaders can provide different features based on certain pragmas).

Now, I understand that the current split between LWRP and HDRP can be tricky in VR and high-end mobile... more when a project development spans several months and years and the technology evolves quite fast..

This is not an easy take for sure - systems so complex and the sheer amount of creative options you can throw in, forces some hard split at some point. I personally have witnessed the difficulties to bring different VR rendering modes on different devices : Single Pass Stereo on Android for instance is still on preview and faces many issues with image effects. For instance, image effects that work with Multi Pass, Single Pass and Instanced Mode on desktop might not work out of the box on Android which in sum demonstrate that Unity is reaching the limit of the engine complexity.

I welcome some decisions like LTS releases and the split between LWRP and HDRP engines although an abstraction layer to reduce development complexity is a must or the users will simply switch to a more efficient engine in terms of development.

 

Personally I like the strategy and I'm a single developer, but I suppose I do have certain luxuries.

Regarding abstraction I suppose I'd be interested in more detail as to what areas exactly. I can imagine it working out ok in some ways in terms of helping people feel less trapped by an earlier pipeline choice they made in a project. But I'm thinking more about conversion than abstraction. And a lot of peoples complaints have been about specific features Unity dont think belong in lightweight pipeline being omitted, and abstraction doesnt solve that unless it happens to involve getting these features back into lightweight by the backdoor. And I'm really not sure I want to see that backdoor unlocked because that implies Unity dedicating resources to writing some systems for non-compute capable platforms that they've decided to only write in the modern compute way for HD pipeline. Or at least, I'd rather such things be approached and argued on a feature by feature basis rather than under some broad wish that the entire pipeline split be hidden by abstraction.

I dont mean to sound negative, just not quite understanding what would actually be gained by abstraction, as the form I keep imagining it in severely compromises some of the purpose of going down a flexible, scriptable pipeline route in the first place.

I do care what asset developers think of all this change as I use many product from the store and would like to develop some myself. It's hard for me to comment much on this aspect though because I am not privy to any conversations about it in forums that are dedicated to asset store publishers, since I am not one yet. There are all manner of areas which I can imagine are painful for asset store developers. I also think there are some very interesting opportunities with this pipeline stuff, including people providing their own customised pipelines. Yes that could turn into a messy nightmare in some ways but its another thing to consider when talking about the options small development teams will have in future, and what abstraction may or may not be feasible. There are certainly more possibilities than just 'chose one of the 2 unity scriptable pipelines' or 'develop your own if you are big enough'.

 

And honestly I think I could probably talk forever in abstract terms about this sort of thing. Which is another reason I hope people dont mind if I end up saying 'please be much more specific' a lot.

For example the idea that LW is a bit too low visually, that can be a true statement but still not give me much of a clue as to what features specifically are missing from LW that lead to this situation. And an example of what sort of device you would hope to run such a feature on, but for which the HD pipeline is unsuitable.

Anyway, I dont expect my relative optimism that any problematic gaps that are shown to exist will be filled over time, one way or another, if not by unity then by others if there is a real demand, to cause everyone else to just sit back and go 'oh well thats ok then, no worries'. Theres loads of concerns that seem valid to raise, but I do think some of them are more concerning because its early days for the pipeline stuff, and over time some concerns will be addressed and the benefits will be clearer.

If this doesnt happen and it all goes pear-shaped then you can tell me how wrong I am! But I suppose I feel this way because I'm in the opposite camp, I was far more likely to stop using Unity if they had stuck to their traditional non-scriptable pipeline and been too afraid to tackle legacy quagmires in radical ways.

 

Hi @elbows

The abstraction layer I commented above is for shaders - after a potential conversion, ideally we should be able to continue working on an unified “Surface Shader” syntax (or a master shader library) so the engine could solve the links to the underline pipeline (at least the default LW/HD and also legacy whenever possible) - this way we don’t need to fork our packages to support all of them.

It makes sense to have some art packages optimised for each pipeline but in the case of systems or heavy scripting packages that’s not ideal in terms of maintenance.

Also, including materials/shaders for different pipelines in the same package adds more house-keeping work to the user - eg. what will happen in a build if an user keeps materials and shaders for different pipelines coming from the same package (will it fail to build or finish with lot of warning/errors or maybe a lot of junk code and shader variants that never will be used will end in the app?)

 

Regarding shader variants, any comment on revamping the multi_compile implementation so we can define several groups of allowed combinations?

For instace, say I have:

Code (CSharp):

1. #pragma multi_compile feature1 feature2 ... feature8
2. #pragma multi_compile option1 option2

And I know feature3-5 will never work with option1.

Would be great if I could add something like:

Code (CSharp):

1. #pragma exclude_variants feature3 feature4 feature5
2. #pragma exclude_variants option1

Which will produce a set of combinations to be subtracted from the above. Something like that could also group exclusion sets.

 

Last week, I created a collection of high customizable unlit shaders designed for Lightweight Render Pipeline. It's useful for VFX and particles and GPU Instancing / GPU Instancing Particles friendly.

Link is here:
https://github.com/beinteractive/LWRPShaders

 

We do VR visualization of CAD models, and from what I have read so far, the HDRP doesn't support VR (and is deferred only?) and the LWRP only supports a single shadow caster?

This essentially means that we're "stuck" with the old pipeline for the forseeable future until someone creates (and maintains) a VR pipeline that's somewhere in the middle.

 

Don't get me wrong, I love the new features. They are amazing. The way they are delivered is bad to say the least.

To begin with, it will increase the cost and complexity of production, having to work on two different projects since you can't run LWRP and HDRP simultaneously. For those working on multiplatform projects, that want to take advantage of the new features, there is now a need for at least two versions of each and every material. One for LWRP and one for HDRP. Not to mention the need for a technician who will have to write a new custom version SRP because LWRP simply does not cut it for high end VR projects.

On top of that, the decision to drop Substance integration, a solution that could help streamline the creation of materials, makes things even worse. Integration with Substance was one of the key features that lead to the adoption of Unity in our case.

Not sure how the importance and value of Substance came into discussion. That is not what we are discussing.

2018 does not support it yet, AND based on an official response, even when 2018.1 is officially launched, Allegorithmic is going to launch an early beta with limited functionality and no support for mobile. Probably not VR either.

Considering that according to official posts in December 2017, Allegorithmic was already working on a plugin, and that, surprisingly, there still is no such plugin in sight, I do not expect Substance materials to be fully supported before 2018.3 which is very very late for anyone wanting to start a project today. This is very inconvenient to say the least, and even catastrophic for those, who may be depending on a pipeline with this technology. Very bad planning and prioritization of features. Suspiciously bad. Especially if we consider that the majority of Unity houses are publishing primarily on the more "modern" platforms such as Mobile, VR and AR.

Exactly. Those in VR/AR development, one of the most prominent use cases of Unity's efficiency is actually left hung to dry. That's how bad the new dual pipeline strategy is. I am sorry to say so, but whoever had this idea is going to cost Unity at least some thousands of seats, and push people to Unreal which will now become the only premium game engine that actually does offer a unified pipeline. ​

 

From that? I assumed you meant substance, as you said substance.

As for that, we got around it by writing our own shaders. If your making a VR/AR project and you don't have a tech artist or someone that can write shaders for VR, then you really need to hire one ultimately because relying on in-progress massive changes to support your in progress projects is a very bad idea and will in the end likely mean you have to push back your release date.

 

Not really. But since this change was made, and since shader graph ONLY supports the new pipelines, we are forced to hire someone for that purpose, and increase out running costs if we want to use the new graphics options. The idea behind SRP, was to offer high end visuals and stop people yammering about the graphics advantage of Unreal. The new features clearly achieve that. Ultimately though this comes with the "gift" of increased costs (minimum 40K a year). Not to mention the increased effort in man days for the dual materials which eliminates Unity's flexibility advantage. This will make us appear costlier to our clients. That's how bad the new dual pipeline strategy is.

In which case and depending on the volume of projects, we may prefer to move exclusively to Unreal engine (we currently use both) which offers a unified pipeline and thus, a lower cost approach. That's perfectly fine with us. I just can't see how this is beneficial to Unity. It is already upsetting plenty of teams.

 

Everyone has to keep in mind this is all still work in progress. It wasn't recommended to jump ship from the current pipeline as yet for the new ones

Lightweight Render Pipeline is the closest Pipeline to being finished and will support VR/AR. It's meant to be multiplatform and performant. (Reason why It doesn't have the advanced features in HDRP)

LWRP Blog Post - More info here



HDRP is still experimental/early in development and will support VR in the future. (Again its still work in progress/preview)

HDRP Blog Post - A lot of information here


HDRP will work on most projects as long as you know the platform and what graphics API you are aiming for. Once you know this most of your problems with running two versions of your project for each Render Pipeline won't matter.

For instance, HDRP supports/will support Vulcan. Vulcan API is more open/inclusive API than then others DX12 etc. So with that in mind if you Use HDRP you could reach pretty much any PC (and I say PC because it's the most varied platform) with hardware that can handle compute shaders. HDRP won't be stuck in "Max Graphics mode", it's still scalable as you would expect. You can create lower feature versions of the pipeline to run on the weaker end of the spectrum.
You can even lock it to Forward or Deferred Rendering based on what you need.

The goal of each Render Pipeline isn't to switch between each of them. You have to know what you want to support and choose the Pipeline that best fits. In order to do that you have to know what each of them does and will be able to do in the future, as well as the platforms you want to support

 

Same error here on a blank project where all I've done is try to install it via the Package Manager.

 

In which case, I would not promote it as such in GDC or my blogs only to slap the fine print to people when they notice that it's still not production ready. That is kind of misleading. I would keep it in semi-stealth, and let only those who want to experiment and provide feedback use it.

i.e. you do not say, 2018.1 is awesome with great features like shader graph… which btw, does not support your current pipeline... but only one out of two not production ready experimental pipelines, which you should not use but look how amazing they are! we are only using them for marketing purposes at this point, use them at your own risk. oh and we also broke your current Substance pipeline in advance. Don't worry. The new SRP is there. Oops!

 

I understand how it might come across like that for those who get the beta builds as a new Unity version

but you have to keep in mind beta builds are here for people to test things and provide feedback before release.

With the release of 2018.1 you will be able to use the Lightweight Pipeline in production and HDRP will still be preview.

Unity is both making new tech and revamping the engine, so moving forward there's no reason to try and support the current pipeline if they want to get rid of it. Old tech will be removed (example the old Rendering Pipeline) but it won't just be removed and replaced with the new pipelines in a release. So when 2018.1 is released with the new tech, people will have a chance to try it before changing even if its only preview. They will see and work out how to fit things into their pipeline/workflow moving forward while still being able to use what they know. (They wont be forced into using them so this is why there will be preview tech available in some builds or rather packages)

 

If you are using 2018b13,you can modify two code to remove depth pass and use normal shadow mapping:
1. set screenSpace to false, in LightweightPipeline.cs
m_ShadowSettings.screenSpace = false; // SystemInfo.graphicsDeviceType != GraphicsDeviceType.OpenGLES2;

2. define SHADOWS_SCREEN to 0 in shadows.hlsl
#ifdef SHADER_API_GLES
#define SHADOWS_SCREEN 0
#else
#define SHADOWS_SCREEN 0
#endif

 

Unity 2018.2.0b1
Render-pipelines.lightweight Version 1.1.4

Default shaders not compiling, no error shown in console

 

I've been doing some investigations and it looks like Soft Particles may not be working correctly in Lightweight. I have not been able to get fading based on the _CameraDepthTexture to function properly. Is this something anyone else has experienced?

Attached are some images of the very simple reproduction case. This was Unity 2018.1b13 with the latest from the 2018.1 branch on GitHub (Package version 1.1.5-preview).

 

Do you have Soft Particles enabled on the Lightweight Asset?

 

Yes, they are.

 

Confirming the same behaviour here. Of note is that the legacy soft particles do still fade correctly.

 

Do anybody know, why LT not use Universal Reversed ZBuffer like HD?

 

This is still happening with 2018.1.0b13 and

"com.unity.render-pipelines.core": "1.1.5-preview",
"com.unity.render-pipelines.lightweight": "1.1.5-preview",
"com.unity.shadergraph": "1.1.4-preview"

 

not exactly sure what triggered it, but I was messing with ShaderGraph

and I think just by using Lightweight Render Pipeline,
Iam not able to click on a Material's Shader dropdown to select any shader
i click the dropdown and nothing happens
2018.2.0b1

 

Anyway to get replacement shaders working in the lightweight render pipeline?

From the general render pipeline thread someone mentioned you need to use
DrawRendererSettings.SetOverrideMaterial

But I can't think of any easy way of inject this into the lightweight pipeline

Is there plans to support replacement shaders at some point in future? If not I'm going to have to sadly revert back to the old system.

 

So, I've ported one of my UAS projects over to the LW render pipeline. The UAS requires the following to ship an asset:

1. A demo scene
2. No errors are thrown in the console when the asset is installed.

However, it doesn't look like this is possible. If someone does not have the LW pipeline active and installs the asset, then the shaders will throw an error as they cannot find the needed include files, and I can't just ship the code which generates the shaders, because I need to ship a demo with the package.

Is there a "#define _USINGLWPIPELINE" that would allow me to #if around this and prevent the errors when the user doesn't have the LW pipeline installed?

 

You could create some sort of binding, Dictionary or other that maps a Camera to a Material, then at the point of rendering the Camera, pay the hash lookup and if it passes do the DrawRendererSettings.SetOverrideMaterial?