Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Official Post-processing and URP - The plan

Discussion in 'Universal Render Pipeline' started by Chman, Dec 17, 2019.

  1. Chman

    Chman

    Unity Technologies

    Joined:
    Feb 6, 2010
    Posts:
    721
    While working on Universal Render Pipeline for 2019.3 we developed an integrated post-processing stack that is better coupled with the pipeline. This allowed us to deliver several performance improvements in the pipeline. The new stack also supports new effects like Camera Motion Blur and the Volume Framework.

    Earlier this year we decided to drop support for PPv2 in URP in favor of this new integrated post-processing stack. However, the new stack is currently missing a very important feature for users: custom post-processing.

    Over the past months we have received several pieces feedback about this decision. Lack of custom post-processing is perceived as a regression from PPv2. Major concerns were also raised about the timeline of the PPv2 deprecation in URP and the lack of support for all custom post-processing effect written for that stack.

    Based on this feedback, we decided to add support to PPv2 in URP as a fallback mode in 2019.4 LTS. This way developers will have a choice to still keep using PPv2 for the next 2 years in LTS and we will remove support for PPv2 in UPR in 2020.1 instead.

    If you have PPv2 package installed, there will be an option to select PPv2 stack from the pipeline asset. It works the same way as it used to work in LWRP and with the same limitations (no support for Ambient Occlusion, Temporal Anti-aliasing and Motion Blur).
     
  2. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    6,586
    Is custom post processing something you're going to add to the integrated post processing stack in urp? If so, any eta?
     
    Cynicat, Ruslank100, zhuchun and 4 others like this.
  3. BattleAngelAlita

    BattleAngelAlita

    Joined:
    Nov 20, 2016
    Posts:
    400
    How about to extract PostProcessPass to scriptable object asset, and allow to override it with what post processing you want?
     
    Peter77 likes this.
  4. doarp

    doarp

    Joined:
    Sep 24, 2019
    Posts:
    147
    I’m only using Unity a couple of months but it seems that this kind of decisions (deprecating PPv2) without consulting the game developers are more frequent then reasonably acceptable.
    Every deprecation should be first discussed openly with the devs, pros and cons properly weighted and given ample time for us to prepare for any expected breaking change.
    PPv2 works on 2019.2.
    Doesn’t work on 2019.3.
    will work on 2019.4.
    will not work in 2020.1.
    This is just a joke.

    will there be custom PP in URP builtin PP in 2019.4?
     
  5. seffles

    seffles

    Joined:
    Oct 2, 2013
    Posts:
    32
    Why wait until 2019.4 LTS? Wasn't the point of moving to packages so that you could ship upgrades to things like URP without having to wait for major releases?
     
    Immu, Ruslank100, cxode and 1 other person like this.
  6. Admin_Friend_Factory

    Admin_Friend_Factory

    Joined:
    Oct 23, 2018
    Posts:
    41
    We just moved our full development away from PPV2 to URP PP in 2019.3. So the most important thing to get is the URP Custom Post Processing added to the Unity 2019.4 LTS release, at latest. We have done all he migration and the development in preparation for URP so will be in waste if no URP Custom Post Processing is supported for 2019.4 LTS. PPV2 in 2019.4 LTS is not really what we need. And all the Asset Store developer are in need of getting the Custom Post Processing for URP in 2019.4 LTS to be able to support crucial functions. Custom Post Processing is mandatory for almost every game development and I doubt any game developer will launch any game with URP if they will be pushed to 2020.1 (simply to risky to not be on a LTS release now with URP). @Chman can you please confirm the strategy? Thanks
     
  7. xCyborg

    xCyborg

    Joined:
    Oct 4, 2010
    Posts:
    632
    I love the integrated post-processing stack, it's much better, I hope you aim for feature parity with HDRP, oviously not quality parity, but at least having the same effects.
     
  8. Lars-Steenhoff

    Lars-Steenhoff

    Joined:
    Aug 7, 2007
    Posts:
    3,513
    Thanks for leaving v2 in there, until v3 has feature parity

    Still unclear to me:

    1: Is custom post processing still going to work in v3 and and when

    2: A way to transfer settings from v2 to v3 ( close enough )

    And by adding it to 2019 URP I think you should keep it in 2020 too, so people can choose what to use, and still have time for the v3 custom effects to be developed
     
    Admin_Friend_Factory and seffles like this.
  9. Lars-Steenhoff

    Lars-Steenhoff

    Joined:
    Aug 7, 2007
    Posts:
    3,513
    Very good points
     
    Admin_Friend_Factory likes this.
  10. equalsequals

    equalsequals

    Joined:
    Sep 27, 2010
    Posts:
    154
    I'm curious as to if Unity has observed a regression in PPV2 with URP in XR sometime after 2019.1? In LWRP 4.x (2018.3/4) Single-Pass Stereo was supported in PPV2 but now it appears to be hard-coded to fall back to a Multi-Pass, resulting in a performance hit. I'd be happy to elaborate if anyone would like.
     
    laurentlavigne likes this.
  11. Devil_Inside

    Devil_Inside

    Joined:
    Nov 19, 2012
    Posts:
    1,117
    What about performance (Case 1202538)?
     
  12. Elvar_Orn

    Elvar_Orn

    Unity Technologies

    Joined:
    Dec 9, 2019
    Posts:
    159
    Hey everyone,
    As I'm quite new to the URP team I've had to ask around to get details and I hope I can answer some of the main questions you've put here.

    When we decided to move to integrated post processing we were following the model that was used by HDRP. Their solution seems to be getting fantastic feedback and we wanted to follow in a similar direction. Having a deeply integrated post stack allows for better hardware level performance as we can make more assumptions and tightly integrate the post with the universal pipeline. Looking at the performance of V2 vs the integrated it is clear that V3 is the winner here. Unfortunately changing the post this late in the process with no clear upgrade path from v2 to integrated has left a number of users in a bad place. Integrated is still lacking some features that are in V2 and didn't have a clear upgrade pathway.

    We realize that this puts a number of people in a bad place and want to address this before 19.3 is officially released and this is feedback we have heard and have actioned on during the Beta period. We are committed to not removing PPv2 until integrated meets the needs that you currently have. We also want to ensure that there is a window where both integrated and v2 are supported so that you can migrate your projects in a better timescale.

    To be clear PPV2 will work on URP 19.3 with the package we are producing, and we will be adding custom post to the integrated stack ASAP.

    It will come, no hard ETA but it will land as soon as we can make it happen.

    We will be looking closely at seeing if we can do some tooling to help with this

    Is there bug ID for this?

    Looking at the bug history this is being processed it seems to happen only on some devices and our QA is trying to narrow this down. It's being investigated :)


    Once again, we really value your feedback here. It's the reason we are adding PPv2 back in for a period so that we can better serve your projects and not desert you with tech you can't use. We really need your feedback on these issues and want to ensure you can make the best games and projects you can. Please stay vocal about URP it's really important to us to make it awesome.

    Cheers,
    Elvar
     
    Last edited: Dec 21, 2019
  13. xCyborg

    xCyborg

    Joined:
    Oct 4, 2010
    Posts:
    632
    @ElvarOrnUnnthorsson Will the URP post stack provide an effects master node for support with Shader Graph?
    Will you take feedback while developing custom effects? on Github maybe.
     
    Peter77 likes this.
  14. Elvar_Orn

    Elvar_Orn

    Unity Technologies

    Joined:
    Dec 9, 2019
    Posts:
    159
    When we get to developing the post fx master nodes we will happily take feedback :)

    How exactly we'll do that I'm not sure (forum/github/...) but I've just added a task to myself to figure that out with the ShaderGraph & PP teams once we're underway...
     
    JesOb, Peter77 and Lars-Steenhoff like this.
  15. Lars-Steenhoff

    Lars-Steenhoff

    Joined:
    Aug 7, 2007
    Posts:
    3,513
    @ElvarOrnUnnthorsson
    Thanks for the answers

    I was planning to skip 2019 and go straight to 2020.1 as there are important things in 2020 that I need. ( Like this: #244 larger than 4GB files on 64bit)

    Currently on 2018 and default renderpipeline.

    I have many custom post effects for v2 and would love it If they still can be used in URP 2020.

    Until there is custom post effects for 2020 and some time had passed for asset store creators to upgrade to v3 custom effect I think its a miss not to have it in 2020

    And this pushes me go back to default render pipeline again. because at least it's not changing.

    I'm not a programmer so I won't write any post effects myself and therefore rely on asset store or GitHub.

    Nice action to let me control v2 post effects with playmaker.
    Post Processing Stack V2 - Playmaker Actions

    Massive list of custom post effects for v2
    SC Post Effects Pack

    SCPE_Social.jpg

    I would miss out on all these effects when I'm only able to use only v3 in 2020:
     
    Last edited: Dec 20, 2019
  16. Admin_Friend_Factory

    Admin_Friend_Factory

    Joined:
    Oct 23, 2018
    Posts:
    41
    //To be clear PPV2 will work on URP 19.3 with the package we are producing, and we will be adding custom post to the integrated stack ASAP.

    Hi, can you confirm that the integrated URP PP with custom post processing will be ported to 2019.4 LTS, this is super critical question for us for our launch? Thanks
     
    Lars-Steenhoff likes this.
  17. Elvar_Orn

    Elvar_Orn

    Unity Technologies

    Joined:
    Dec 9, 2019
    Posts:
    159
    I shall find out (Placed it at the top of my todo list) but now the Holidays are coming so I don't expect to be able to give you an answer until January. I hope that's okay.
     
    Last edited: Dec 21, 2019
  18. Lars-Steenhoff

    Lars-Steenhoff

    Joined:
    Aug 7, 2007
    Posts:
    3,513
    Have a great holiday!
     
    Elvar_Orn and Peter77 like this.
  19. markefus

    markefus

    Joined:
    Nov 2, 2014
    Posts:
    22
    Hey! I would definitely appreciate an answer on custom URP PP as well when you're back from the holiday.

    I feel like this should be a priority feature. URP is extremely lacking, potentially not usable for some, without it.
    From what I've gathered, currently the only solution for custom PP is to do a custom render pass?

    Have a good New Year though!
     
  20. StaggartCreations

    StaggartCreations

    Joined:
    Feb 18, 2015
    Posts:
    2,227
    Lars-Steenhoff likes this.
  21. TextusGames

    TextusGames

    Joined:
    Dec 8, 2016
    Posts:
    429
    Last edited: Jan 5, 2020
    cxode likes this.
  22. Shudrum

    Shudrum

    Joined:
    Apr 3, 2011
    Posts:
    63
    Lars-Steenhoff likes this.
  23. Elvar_Orn

    Elvar_Orn

    Unity Technologies

    Joined:
    Dec 9, 2019
    Posts:
    159
    I've now been able to contact the relevant people and confirm that yes, The plan is to port URP PP with Custom Processing to 2019.4 LTS
     
    Ruslank100, cxode, RogDolos and 3 others like this.
  24. optimise

    optimise

    Joined:
    Jan 22, 2014
    Posts:
    2,113
    How about camera stacking?
     
  25. Lars-Steenhoff

    Lars-Steenhoff

    Joined:
    Aug 7, 2007
    Posts:
    3,513
    So to make it clear, please correct the if I'm wrong:

    • PPV2 will be supported in 2019.3 URP and 2019.4 URP ( with custom post effects )
    • PPV2 will be deprecated in 2020 URP
    • Custom post effects for PPV3 URP will come in 2019.4 and upwards.

    When is URP PP with Custom Processing coming to 2020?
    Will you keep PPV2 with Custom Processing as an option in 2020 ?
     
    Peter77 likes this.
  26. Elvar_Orn

    Elvar_Orn

    Unity Technologies

    Joined:
    Dec 9, 2019
    Posts:
    159
    Yes, so the plan is like this...

    Post Process Plan
    • 2019.3 => PPv2 will be supported.
    • 2019.4 => PPv2 will be supported. PPv3 gets Custom Post Effects support.
    • 2020.1 => PPv2 will be deprecated.

    Camera Stacking plan
    To release it in URP 7.2 and the target for that is this month.
     
  27. liiir1985

    liiir1985

    Joined:
    Jul 30, 2014
    Posts:
    147
    It seems the current camera stacking implementation would apply post processing after rendering the last camera in the stack, this would ruin the whole ui with Bloom and such. This isn't acceptable for UI set for "screen space Camera". The main reason why most people need camera stacking, is to overlay UI, which cannot be applied with Post processing.(UI SFX needs particle effects and also other 3d elements, which makes the overlay mode of ugui unusable) I hope you can address this issue with the final release of the Camera stacking, otherwise it's still useless for most of us
     
    JesOb likes this.
  28. phil_lira

    phil_lira

    Unity Technologies

    Joined:
    Dec 17, 2014
    Posts:
    584
    Camera stacking is expected to land in 7.2.0 package as well (end of January)
     
    optimise and Lars-Steenhoff like this.
  29. phil_lira

    phil_lira

    Unity Technologies

    Joined:
    Dec 17, 2014
    Posts:
    584
    If the last camera in the stack renders UI, then post will be applied before UI. The current implementation should handle most scenarios and we tested it with several UI setups including Screen Space Camera.

    We have plans to support post-processing being applied individually per-camera but this is not going to make in the first version of camera stacking.
     
    syscrusher, Onigiri, JesOb and 2 others like this.
  30. Admin_Friend_Factory

    Admin_Friend_Factory

    Joined:
    Oct 23, 2018
    Posts:
    41
    Hi Elvar!

    That's great news and thank you for following up promptly on this urgent issue.

    Bartek
     
    Elvar_Orn likes this.
  31. liiir1985

    liiir1985

    Joined:
    Jul 30, 2014
    Posts:
    147
    Hmmm, I just pulled the camera-stacking branch of URP on github, and tested it with PPSv2 compatible mode, the post processing is applied after rendering UI, so this is a problem with PPSv2 and got solved in the integrated post processing of URP?
     
  32. spryx

    spryx

    Joined:
    Jul 23, 2013
    Posts:
    557
    URP PP is a forked version of the one in HDRP. "PPv3" is entirely different from PPv2.
     
  33. phil_lira

    phil_lira

    Unity Technologies

    Joined:
    Dec 17, 2014
    Posts:
    584
    Unless you have merged the PPv2 integration and Camera Stacking branches yourself I don't know how you are testing these. They are not ready. Camera Stacking branch landed today on master. We are now opening a backport PR to start the process to test PPv2 integration with Camera Stacking. :)
     
    Lars-Steenhoff likes this.
  34. liiir1985

    liiir1985

    Joined:
    Jul 30, 2014
    Posts:
    147
    Yes, I merged them by myself to replace my selfmade camera stacking+ppsv2 solution and then found out the post processing is applied after rendering UI, and my buttons and icons are glowing like laterns.

    And btw, it seems it's not the problem of ppsv2, I tested with integrated PP, and the UIs are still rendered before PP. And I didn't see any related code regarding this issue in the camera-stacking branch(the branch got deleted recently, but I think I have the latest version)
     
    Last edited: Jan 10, 2020
  35. Andre_Mcgrail

    Andre_Mcgrail

    Unity Technologies

    Joined:
    Dec 9, 2016
    Posts:
    244
    If you are using Camera space or World space UI then this is expected as it is rendered 'In Shot' so post will affect any objects rendered by that camera, for UI to not be affected by PP you need to use Overlay UI mode, this is slapped on the screen after the cameras have finished what they are rendering(including post).

    If this is not the case then you are hitting a bug, then it should be reported for us to look into
     
  36. liiir1985

    liiir1985

    Joined:
    Jul 30, 2014
    Posts:
    147
    It's like what you described, but what I'm trying to say is, this will make 80% of the use case for camera stacking unusable. Because the main reason why most of us want camera stacking is for using Camera Space UI, which is the only possible way of adding UI SFXs(with particles). Applying PP on UI is unacceptable since I don't want glowing buttons or icons or UI SFXs, and all my UI will be rendered way much darker than it should be in linear color space(texture srgb filtering + PP Blit, gamma correction is done twice).
    I think this issue should be addressed before you guys release the camera stacking ferature to the public. Otherwise you'll get even more frustrated users, because it's still an useless feature for most of them.
    PS. Don't get me wrong, I'm a big fan of SRPs, and I love using LWRP/URP, and I already fixed this one on my personal branch by adding an extra stack for overlays after the PP, but not everyone out there has the ability to modify the render pipeline
     
    Last edited: Jan 10, 2020
    bluescrn, Korindian, Ferazel and 5 others like this.
  37. andybak

    andybak

    Joined:
    Jan 14, 2017
    Posts:
    563
    This is also going to be problemmatic for VR where you largely use World space for UI.
     
  38. Andre_Mcgrail

    Andre_Mcgrail

    Unity Technologies

    Joined:
    Dec 9, 2016
    Posts:
    244
    Unfortunately without a very expensive compositing system this gets very tricky, for now I would suggest rendering your UI to an additional camera with a render texture and comp that overtop.

    To explain why we haven't gone down the route yet is because of UX, workflow and performance. Because if we think about the perfect usage we would be able to have any objects rendered without post if we chose, the tricky thing here is when we get into either interleaved objects(those required to render between other objects in terms of summit order) and the other situation of occluded objects(those that should appear 'in' the scene where they will disappear behind things).
    Both are near impossible without using a compositing approach(much like you would see in something like Nuke or after effects) something where we have multiple buffers of the layers in which need to comp together, each post processing effect would need to not only preserve alpha but also depth(and once we have deferred we are talking potentially about multiple buffers per object). Anyone who has done depth of field or motion in post using Nuke or similar will understand this is not only very tricky to get looking good but it definitely doesn't work at 60fps.
    Our options are very limited when looking at this, right now the UI system, when not rendered as Overlay type is thrown in with the transparent objects, this is because the UI system has not been moved over to SRP fully(in terms of API and control of rendering on the C# side) meaning this work would need to be done first for us to have full control over it and start to look into ways to make the existing Camera and World options play nicely with SRP, but this is only a small part of the work. Next we have the issue of telling what to do post on vs what not to, there are two ways to look at this, we simply render any non-post objects after rendering post, or we use bits in the stencil buffer to mask the post-processing.
    At this point we start to get close to a system that could work, but if we did the latter with stencil there will be artefacts surrounding all the pixels that neighbour the one affected by post and the ones that are not, even the most advanced film post-processing plugins and tools have trouble managing this and really is only solved by rendering DOF/Motion blur in camera(only really possible if doing path/raytracing) or using deep rendering(in realtime this would be a filtrate nightmare). Rendering any objects you want to not have post affecting at the end gets us the closest, but then what about occlusion with a frame that has 10 pixel horizontal camera blur, do we spend a heap of extra processing and memory to make sure we have both a blurred depth buffer and alpha channel? or do we ignore them and simply have a very discontinuous image at the end.

    The UI system needs to be able to render normal objects in it without having to be set to Camera or World modes as rendering a 3d object or particles should just work and this is something that needs to be addressed sooner than later, for now to achieve that the best thing seems to be using a render texture, throwing all your UI into that using a separate camera, and then use that render texture in a fullscreen RawImage that is being rendered in an Overlay canvas, no ideal but it will give you the effect you would want if needing objects and particles in UI not being affected by post.
    As for VR, the majority of post processing effects should not be used anyway, the idea behind most post is that it's trying to simulate a camera lens, where in VR you are not wanting to give that illusion but you are wanting to make it feel as if you are there, seeing it through a human eye, which you are already looking through, thinks like motion blur/dof/bloom should really not be used, and things like vignette/colour-grading/tone-mapping are things that won't effect world space UI to a degree that you need to pay for the cost of a system that would separate them.

    We are releasing the camera stacking now as it will solve a heap of workflows in a nicer way than what we would have otherwise, and the workflow is something that will work fine once we start looking into options for separating out things like post-processing masking.

    Also please let us know if you have seen any real-world examples of this, as I have not seen UI(classic UI not 3d objects as I know we are still lacking with that one) that is in world space that is not affected by post. Most games tend to use an overlay based approach like ours and simple track objects in world space. I know DOOM 2016 did some separate post on theirs and then comped it on top afterwards, but this is still essentially overlay, or close to the trick I described above by using a separate camera and render texture.

    Here is an example of UI tracking working to simulate what might be done in World canvas setup:
    trackingUI.gif

    I have got to the point were I would like to be able to use a 3D object for the mini-map, so this work needs to be done at some point as it would be hugely useful to be able to do and many games do it, but it's not on our list right now as we are still working on getting feature parity with builtin, I mean we still don't have point light shadows, shadow masks, reflection probe blending, deferred rendering, the list goes on, so right now we are looking more at stability, performance and feature parity, once these are ticked off we want to look at making URP really be able to do some cool stuff that a new cutting edge rendering system should be able to do.
     
  39. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    11,594
    Completely lost you here. Do you mean in cases where you want to have multiple cameras render multiple world 3d objects that are then composited properly?

    But in any case, the answer to almost all "do we do this thing that may be a bit expensive, but that some people may want" is : make it an option. Isn't that the whole point of SRP? To have more options and more customization?
     
  40. Andre_Mcgrail

    Andre_Mcgrail

    Unity Technologies

    Joined:
    Dec 9, 2016
    Posts:
    244
    Say you are making an RTS, and you have depth of field, each unit you want a world space circle under it rendered when it's selected, but this you don't want to have being affected by the depth of field. Here we would have to blur parts of the unit over the terrain its sitting on but then for the selection circle to look like it's really 'there' in world space we normally just do a simple check against the depth buffer, so see if it's in front or behind, but now that would be a harsh edge not a soft out of focus edge.

    And this is the point of SRP, the customisable part is there, right now you could go in and start to write your own fully layer based compositing renderer in SRP to handle situations like this, hell you could probably make a killing on the asset store, but as for an out-of-the-box situation that still works on all the platforms we support and need to run well on it takes a lot longer than a studio making the feature work just for their needs, and this is the biggest selling point for SRP, is that you can dive in an tune it to what you need it to be without paying us for source code access or waiting for us to make a button in the inspector to do it.
    That does not mean we are going to be lazy and not make that button to do it, we just have a lot more bases to cover when it comes to implementing something, and due to our small team size we need to prioritise based on needs, and that means being something that can replace builtin completely one day so we can focus on SRP rather than being so divided between rendering solutions.
     
  41. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    11,594
    Gotcha. This makes sense and I understand what the problem is.

    Although this case would be a problem for the built-in renderer as well, right? Most people are complaining about the lack of camera stacking in Unity because there are certain things we used to be able to do (and were encouraged by Unity's tutorials and manuals) that are now really hard/impossible.
     
    Lars-Steenhoff likes this.
  42. JesOb

    JesOb

    Joined:
    Sep 3, 2012
    Posts:
    1,096
    We really in our simple fps game just get rid of Overlay UI because there is so many bugs in it and inabilities to do simple things like 3D object or to be in front/behind scene objects lack of correct text rendering that just disappear on iOS and TMPro team just dont want to do something with it. The say it is by Design. Incorrect work in split screen, inability to rotate UI because there is no perspective projection...

    SO with all this we just end up using only WorldCameraRelative UI that dont have any bugs in it that overlay has.
    The only thing we need is able to move all aur objects to render after post and thats all.

    Just Add ability to render something after post processing all visual artifacts that can appear is our responsibility to use feature correctly. Please Dont create magically working features, dont create feature that magically make everything looks good in price of performance. Make simple things (like render objects after PostProcessing or any other step) and afterwards make complicated ones on top of it.
     
    Last edited: Jan 13, 2020
  43. andybak

    andybak

    Joined:
    Jan 14, 2017
    Posts:
    563
    Leaving aside the original question (for which I understand the tradeoffs you have to make) can you *please* stop making proscriptive statements like this that presuppose a huge number of aesthetic considerations which should be down to us?

    There are many situations where bloom works really well in VR. Depth of field is trickier but still not completely off the table.

    We're not all aiming for photo-realism and I'm concerned that if this point of view is endemic within Unity it will affect the choices you end up offering us.

    (As an example I offer the simplification of fog in HDRP to be only the "physically real" exponential type. Really limiting for those of us who actually wanted non-realistic fog or were using fog to create other effects).
     
  44. TJHeuvel-net

    TJHeuvel-net

    Joined:
    Jul 31, 2012
    Posts:
    837
    I do hope when this is added we can not only make custom effects, but also a whole custom stack. With the PPv2 we can only make a single effect, and combining all your effects into one draw call/stack is not really supported.
     
    BattleAngelAlita likes this.
  45. liiir1985

    liiir1985

    Joined:
    Jul 30, 2014
    Posts:
    147
    I fully understand and agree with your decision made to this. It makes sense, I'm talking about this issue isn't because what you did is wrong. The perfect solution would be allow the ui system to render 3d objects or particles without an extra camera, like you said. But it's not something that can be solved in the near future. In the meanwhile we need alternatives, It's just simply the fact that what we are doing is now completely impossible to achieve with the current implementation, which will drive the user away. You'll need ui paricles, even as simple as you just want to notify the user a skill is ready(with a fancy particle which is sparking when skill is ready for use, it would be a great regression if you fallback the solution to a series of animation sprites). If you really tried to implement the camera space ui with extra camera with RT, you'll then notice it's just impossible. Anything with alpha blend is scewed if you render the thing on to a RT(the color is blended with black or what ever color the rt is cleared for, and the result is just incorrect)
    What I'm talking about isn't some rare use case, but rather something that is needed nearly in everyday's development.
    Every project with not that simple UI as a Tech demo will encounter this problem. For most of the mobile developers, this issue is even more critlcal than PBR or performance at all, because it's impossible for now to make the project with URP's default implementation. If you let the user choose between URP and UI particles with builtin pipeline, they will choose UI particles with builtin pipeline without doubt. Most console/pc game tend to use more simple UIs, because they want the user to focus on the content they made. But for mobile games, UI tend to be much more complex, with many particles. Some mobile games are even made of mostly by UIs and it's really very important to have UI particles.
     
    Last edited: Jan 14, 2020
    goncalo-vasconcelos likes this.
  46. phil_lira

    phil_lira

    Unity Technologies

    Joined:
    Dec 17, 2014
    Posts:
    584
    You can now disable Post-processing and inject your own solution for post-processing with ScriptableRenderPasses. That means you have to handle final post/blit pass correctly do do sRGB color correction when necessary and apply AA.
     
    TJHeuvel-net likes this.
  47. phil_lira

    phil_lira

    Unity Technologies

    Joined:
    Dec 17, 2014
    Posts:
    584
    @liiir1985 can you file a bug and report your case then send me a DM with the case ID. I'll look into your setup.
     
  48. Giometric

    Giometric

    Joined:
    Dec 20, 2011
    Posts:
    170
    FWIW, this exact determination was made at my job just last Friday. We considered URP to start a new project with, but knowing we weren't going to be able to do particles in the UI completely outweighed any potential benefits.

    Edit: That said, I agree with @Andre_Mcgrail that the ideal solution (for our particular case) is to be able to render 3d objects properly in the UI in the first place, though I understand that's probably further out.
     
  49. phil_lira

    phil_lira

    Unity Technologies

    Joined:
    Dec 17, 2014
    Posts:
    584
    To make this a little bit more productive and less confusing. Can someone summarize in bullet points what you can achieve in built-in pipeline that you cannot with URP and the new camera stacking system?

    There are big improvements to SRP and the stacking solution coming but I'm failing to understand what with the new camera stacking you are missing to achieve.
     
    TextusGames likes this.
  50. Giometric

    Giometric

    Joined:
    Dec 20, 2011
    Posts:
    170
    To be a bit more clear, the camera stacking feature as described should do what we needed once it's in. That is, it would allow us to have a separate UI camera rendering a "Screen Space - Camera"-mode UI, which is what we used with the Built-In renderer so that we could render meshes and particles in the UI for various FX / celebration moments / etc. The lack of separation for the purposes of post-processing likely wouldn't be a problem for us, since we probably won't use any Post FX at all (maybe Bloom? Not sure how that would behave with UI objects, but it might not have been an issue).

    For us, the fact that camera stacking isn't in there right now is really the biggest factor - I know it's intended to land in a package update soon, but we are on 2019.1, not 2019.3 (which, I would also point out, is still in beta). We could try starting from 2019.3 (or more likely 2019.2), but our expected time table for this project is very short (less than a year), so we're starting this project from an existing codebase. This means there's shared tech and various third-party stuff that needs to be upgraded as well. Because of all this, we may or may not upgrade Unity during development, but we wanted to avoid counting on doing that, in case there are issues we can't get around quickly.

    There's also, of course, the possibility that we do all of that and then it turns out the initial camera stacking implementation still doesn't fit what we need; again, I consider that unlikely given the description of what it will do, but it's still a risk. To be totally fair, from our end it's largely a situation of "we have what we need with the built-in renderer, the handful of things we want from URP aren't enough to justify upending our setup".