Search Unity

  1. Unity 2019.1 is now released.
    Dismiss Notice

Feedback Wanted: Lightweight Render Pipeline

Discussion in 'Graphics Experimental Previews' started by Tim-C, Feb 19, 2018.

Thread Status:
Not open for further replies.
  1. Luke_161

    Luke_161

    Joined:
    Mar 3, 2015
    Posts:
    11
    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.

    frameDifference.png

    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()).

    Screen Shot 2018-04-04 at 10.28.30.png
     
    AcidArrow and GameDevCouple_I like this.
  2. georgeq

    georgeq

    Joined:
    Mar 5, 2014
    Posts:
    452
    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:

    performsrp.png

    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:

    performlwrp.png

    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.
     
    whogas, soleron and Jes28 like this.
  3. beinteractive

    beinteractive

    Joined:
    Apr 10, 2014
    Posts:
    21
    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?
     
  4. phil_lira

    phil_lira

    Unity Technologies

    Joined:
    Dec 17, 2014
    Posts:
    365
    @Luke_161 we have some fixes in flight for the garbage collection. I'll double check it now. I'll also check Dynamic Batching.

    @georgeq Can you share your project? I'd be very interested into looking at that. You can open a fogbugz case if you prefer.
     
    Jes28 and Luke_161 like this.
  5. phil_lira

    phil_lira

    Unity Technologies

    Joined:
    Dec 17, 2014
    Posts:
    365
    @beinteractive That was a bad decision on my part to disable shadow strength in mobile. It's going back in the next version of LWRP. Meanwhile you can define in the shader the following: `#define SHADER_HINT_NICE_QUALITY 1`.

    Our goal is to expose in the pipeline asset tiers of shader quality, and then we scale the pipe shading on these tiers. However we can only do that in 18.2 because that requires some additional keywords that only then we will be able to strip.
     
  6. Reanimate_L

    Reanimate_L

    Joined:
    Oct 10, 2009
    Posts:
    2,350
    @phil_lira do you have geometric specular AA in LWRP? or any specular AA? mostly asking for VR here
     
    soleron likes this.
  7. watsonsong

    watsonsong

    Joined:
    May 13, 2015
    Posts:
    360
    The receive shadows on renderer is not work in LWRP.


     
  8. beinteractive

    beinteractive

    Joined:
    Apr 10, 2014
    Posts:
    21
    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.
     
  9. beinteractive

    beinteractive

    Joined:
    Apr 10, 2014
    Posts:
    21
    phil_lira likes this.
  10. JUBA-C4

    JUBA-C4

    Joined:
    Aug 16, 2014
    Posts:
    12
    hi,

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

    thank you.
     
  11. ph_

    ph_

    Joined:
    Sep 5, 2013
    Posts:
    64
    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 !
     
    Last edited: Apr 10, 2018
  12. phil_lira

    phil_lira

    Unity Technologies

    Joined:
    Dec 17, 2014
    Posts:
    365
    You define it to 1 in any .shader file.
     
  13. phil_lira

    phil_lira

    Unity Technologies

    Joined:
    Dec 17, 2014
    Posts:
    365
    @watsonsong Thanks. I can reproduce it here. I'll take a look at it.
     
  14. phil_lira

    phil_lira

    Unity Technologies

    Joined:
    Dec 17, 2014
    Posts:
    365
    There's an issue with 2018.1 that the occlusion culling visualization is not working with SRP. most likely it will be available with a patch to 2018.1
     
    JUBA-C4 likes this.
  15. phil_lira

    phil_lira

    Unity Technologies

    Joined:
    Dec 17, 2014
    Posts:
    365
    I can help you with that. In GLES2 we force single cascade hard shadows until we can get the keyword stripping. If you want it's very easy to force the same for other platforms as well. You can use this branch. (very experimental though). You need to make two changes:
    1) Open LightweightShadowPass.cs and in BuildSettings method set supportsScreenSpaceShadows to false;
    2) Open Shadows.hlsl and define SHADOWS_SCREEN to 0

    The easiest way to embed the SRP from source in your project is through package manager. You can download/clone the SRP repo to any place in your computer and point the package manifest.json file (located in your project Packages folder) to the repository local path. This is the file I use in my computer. You can just update the path to point to the correct location in yours.

    Please note that if you have both PostFX and MSAA enabled you'll still get a Depth prepass. The reason is that we can't resolve multisample depth without Texture2DMS and not all platforms support that. We are currently working to get Texture2DMS support. (GLES 3.1 and above).
     
  16. CogumeloSoft

    CogumeloSoft

    Joined:
    Dec 28, 2012
    Posts:
    55
    Hi!
    Dynamic Batch is not working for me too. Render-pipelines.lightweigh 1.1.2 and Last 2018.1 Beta
    Bye!
     
  17. soleron

    soleron

    Joined:
    Apr 21, 2013
    Posts:
    87
    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.
     
    Last edited: Apr 11, 2018
    eobet likes this.
  18. GameDevCouple_I

    GameDevCouple_I

    Joined:
    Oct 5, 2013
    Posts:
    1,524
    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).
     
  19. soleron

    soleron

    Joined:
    Apr 21, 2013
    Posts:
    87
    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.
     
  20. GameDevCouple_I

    GameDevCouple_I

    Joined:
    Oct 5, 2013
    Posts:
    1,524
    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.
     
  21. Thrawn75

    Thrawn75

    Joined:
    Nov 16, 2014
    Posts:
    2,138
    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.
     
    Last edited: Apr 12, 2018
    eobet likes this.
  22. elbows

    elbows

    Joined:
    Nov 28, 2009
    Posts:
    2,169
    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'.
     
    sand_lantern likes this.
  23. elbows

    elbows

    Joined:
    Nov 28, 2009
    Posts:
    2,169
    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.
     
    Last edited: Apr 12, 2018
  24. Thrawn75

    Thrawn75

    Joined:
    Nov 16, 2014
    Posts:
    2,138
    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?)
     
    Last edited: Apr 12, 2018
  25. Thrawn75

    Thrawn75

    Joined:
    Nov 16, 2014
    Posts:
    2,138
    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.
     
  26. beinteractive

    beinteractive

    Joined:
    Apr 10, 2014
    Posts:
    21
    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
     
  27. ekergraphics

    ekergraphics

    Joined:
    Feb 22, 2017
    Posts:
    257
    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.
     
  28. soleron

    soleron

    Joined:
    Apr 21, 2013
    Posts:
    87
    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.
     
    Last edited: Apr 13, 2018
  29. GameDevCouple_I

    GameDevCouple_I

    Joined:
    Oct 5, 2013
    Posts:
    1,524
    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.
     
  30. soleron

    soleron

    Joined:
    Apr 21, 2013
    Posts:
    87
    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.
     
  31. Grimreaper358

    Grimreaper358

    Joined:
    Apr 8, 2013
    Posts:
    472
    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
    upload_2018-4-13_9-38-8.png


    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
    upload_2018-4-13_9-31-37.png

    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
     
    GameDevCouple_I likes this.
  32. jumach

    jumach

    Joined:
    Apr 14, 2018
    Posts:
    4
    Same error here on a blank project where all I've done is try to install it via the Package Manager.
     
  33. soleron

    soleron

    Joined:
    Apr 21, 2013
    Posts:
    87

    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. :p oh and we also broke your current Substance pipeline in advance. Don't worry. The new SRP is there. Oops!
     
    sand_lantern likes this.
  34. Grimreaper358

    Grimreaper358

    Joined:
    Apr 8, 2013
    Posts:
    472
    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)
     
    GameDevCouple_I likes this.
  35. rainini

    rainini

    Joined:
    Nov 26, 2015
    Posts:
    3
    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
     
    GameDevCouple_I likes this.
  36. nikescar

    nikescar

    Joined:
    Nov 16, 2011
    Posts:
    94
    Unity 2018.2.0b1
    Render-pipelines.lightweight Version 1.1.4

    Default shaders not compiling, no error shown in console
     
    Last edited: Apr 23, 2018
  37. equalsequals

    equalsequals

    Joined:
    Sep 27, 2010
    Posts:
    103
    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).

     
  38. Andy-Touch

    Andy-Touch

    A Moon Shaped Bool Unity Technologies

    Joined:
    May 5, 2014
    Posts:
    1,005
    Do you have Soft Particles enabled on the Lightweight Asset?
     
  39. equalsequals

    equalsequals

    Joined:
    Sep 27, 2010
    Posts:
    103
    Yes, they are.
     
  40. Karearea

    Karearea

    Joined:
    Sep 3, 2012
    Posts:
    310
    Confirming the same behaviour here. Of note is that the legacy soft particles do still fade correctly.
     
    equalsequals likes this.
  41. Jes28

    Jes28

    Joined:
    Sep 3, 2012
    Posts:
    346
    Do anybody know, why LT not use Universal Reversed ZBuffer like HD?
     
  42. Giles-Coope

    Giles-Coope

    Joined:
    Jan 5, 2015
    Posts:
    47
    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"
     
  43. Deleted User

    Deleted User

    Guest

    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
     
    Last edited by a moderator: Apr 27, 2018
  44. tertle

    tertle

    Joined:
    Jan 25, 2011
    Posts:
    1,247
    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.
     
    Last edited: Apr 27, 2018
  45. JasonBooth

    JasonBooth

    Joined:
    Jan 27, 2014
    Posts:
    127
    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?
     
  46. equalsequals

    equalsequals

    Joined:
    Sep 27, 2010
    Posts:
    103
    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?
     
  47. phil_lira

    phil_lira

    Unity Technologies

    Joined:
    Dec 17, 2014
    Posts:
    365
    Hey,

    I'm looking into your feedback and I want to work on the major pain points/concerns you have regarding LWRP.
    I'd like to share with you a preliminary roadmap for LWRP for 2018 TECH stream and some major feedback points we are addressing. Be aware that this is a preliminary roadmap and it might change later.

    As many of you noticed there's a feature gap between HD and LW pipes that we are not covering atm. LWRP is growing to close some of that gap. That means that by 2018 LTS we target a LW forward renderer that has almost feature parity with Unity and has some enhancements in terms of workflow, shading and performance. For 2019 TECH stream we'll continue working on LWRP with a focus on high end mobile. I'll discuss 2019 plans when we come closer to it.

    Also, I want LW to be easily extensible, which is not true atm. We'll refactor the pipeline to make it more modular so you can plugin your own passes or even customize your own renderer. I'm sorry that both C# and Shader API have been drastically changing. We plan to stabilize it by 18.2 release. Then docs with somewhat the final C# and Shader API will be done.

    We are also looking into some AO options for LWRP.

    Here's some preliminary goals for 2018 TECH stream:

    2018.2 - LWRP improved performance and enhanced shadow capabilities
    In this release we'll aim to:
    - Support to multiple realtime shadow casting lights
    - Pipeline refactor to make it modular and easily extensible.
    - Shader and C# API stabilization.
    - Shader and memory footprint optimizations
    - Improvements to mobile tile utilization
    - Shadow pass optimizations.
    - MS depth resolve to avoid depth prepass in some cases.
    - GrabPass alternative. One will be able to request the camera color texture after opaque rendering.
    - Docs for the Shader Library and C# API

    2018.3 - (Somewhat) Feature Parity with Unity Builtin Pipeline.
    In this release we'll aim to:
    - Support to missing probe features. LPPV, Occlusion Probes, Reflection probe blending, box projection.
    - Support to Baked and Shadow mask mixed modes.
    - Explicit controls over shader quality.
    - Support to point shadow casting lights.
    - Physically based light attenuation
    - Pipeline feature and platform stabilization
    - This is the last release that might have breaking API changes. From this point on api will be backward compatible.
     
    Gametyme, Pawige, soleron and 4 others like this.
  48. phil_lira

    phil_lira

    Unity Technologies

    Joined:
    Dec 17, 2014
    Posts:
    365
    The Standard LW shader was developed to be have an upgradable path from Builtin Standard. Therefore it should work.

    LWRP can help VR devs in two fronts here:
    1) Rendering capabilities are being extended while maintaing performance.
    2) LWRP will be refactored to make it very easy to extend for your own project needs.
     
  49. phil_lira

    phil_lira

    Unity Technologies

    Joined:
    Dec 17, 2014
    Posts:
    365
    Multiple shadow casting lights are coming to LWRP in 2018.2. However the majority of lighting features that are still missing are coming in 2018.3.
     
    ekergraphics likes this.
  50. phil_lira

    phil_lira

    Unity Technologies

    Joined:
    Dec 17, 2014
    Posts:
    365
    We've added a C# variant stripping capability in 18.2. Here's an example of the LWRP shader preprocessor: https://github.com/Unity-Technologi...ghtPipeline/LWRP/Editor/ShaderPreprocessor.cs
     
    Thrawn75 likes this.
Thread Status:
Not open for further replies.