Search Unity

  1. Unity 2020.1 has been released.
    Dismiss Notice
  2. Good news ✨ We have more Unite Now videos available for you to watch on-demand! Come check them out and ask our experts any questions!
    Dismiss Notice

Join us for #SRPLife Week!

Discussion in 'General Graphics' started by jbooth, Jun 18, 2020.

  1. jbooth

    jbooth

    Joined:
    Jan 6, 2014
    Posts:
    4,337
    Over the last few years, Unity has introduced the Scriptable Render Pipeline (SRP) system, along with several render pipelines (LWRP/URP, HDRP). These new render pipelines have created significant issues for Unity users and publishers on the asset store. A few with examples are listed below:

    • Shaders must be rewritten from the ground up for each pipeline. There is no upgrade path from Standard to an SRP, and shaders written for one SRP (URP) won't work for another(HDRP).
    • No upgrade path for shaders between versions of the SRP. URP 7.1.8 shaders are not compatible with URP 7.2.1 shaders, yet are both for Unity 2019.3.
    • Rendering code must be re-written for each pipeline. The CustomPass system for URP and HDRP are completely different, yet do the same thing.
    • Code is often broken or different for no reason on different pipelines. Camera.backgroundColor is used in URP/Standard, but in HDRP it's stored in a different property on a custom component and aliased in the editor to look like the camera component is being used.
    • No documentation for shaders. This means countless hours reverse engineering the shading system. And when things change, there is no documentation on what has changed.
    • New versions not sync'd to Unity releases. URP 7.1.8 and URP 7.2.1 shaders are incompatible, and both for Unity 2019.3. Users are forced to upgrade depending on which patch version of Unity 2019.3 they are using, making it impossible to support.
    • Assets written for multiple pipelines cannot "just work" when installed. If you have even the simplest material, users will need to manually upgrade your project to work in SRPs.

    Since SRPs were conceived, we have been asking Unity to address these types of issues, and this has fallen on deaf ears. Even after several years, we have no official response to any of these issues, or even confirmation that Unity see's them as actual issues worth solving. I have also personally received the feedback from several Unity employee's that "Only you care about this stuff", which I know is not the case.

    As such, we invite you to join us in changing your profile picture from to the following image to raise awareness of these issues, and show Unity that more than one person would like to see them addressed.

     
    Last edited: Jun 29, 2020
    R0man, space928, Cynicat and 73 others like this.
  2. olli_vrcoaster

    olli_vrcoaster

    Joined:
    Sep 1, 2017
    Posts:
    24
    I generally like the idea that Unity reinvents itself to keep up with new technologies and to optimize their pipeline from the ground up. And i really hope that some day (IN THE NEAR FUTURE) universal renderpipeline will be my new daily workhorse.
    But for now i have to agree with you, there is too much half-finished stuff going on at the same time. These days everything seams so "agile" that it actually feels like chaos.
    HDRP sometimes feels like an impulsive response to Unreal's AAA trailers and the stuff we really love and prefer unity for is slow and unconsistent in developement.
    When i first heard about SRP i thought it meant a seamless transition from LWRP, over BIRP to HDRP ... but it's actually 3 independent engines now, that you can modify in their own ways!?
    And get this damn package manager tidied up... I can't believe something so essential like the renderpipeline is sitting right between a "google AR ios plugin" and an in-app "purchasing system"
     
    Cynicat, Tanner555, joshcamas and 3 others like this.
  3. knxrb

    knxrb

    Joined:
    Dec 16, 2018
    Posts:
    12
    I agree with everything said here, hopefully they realise it's a bigger issue that is experienced by more than just a few people. Just because not everyone speaks up about the issues on the forums, doesn't mean they don't have to go through the same problems.
     
    Last edited: Jun 18, 2020
  4. edwar496

    edwar496

    Joined:
    Jun 28, 2016
    Posts:
    15
    Done. I agree 100%. As excited as I am for all the SRP content, my only option has been to completely avoid it until it's finished.
     
  5. recon0303

    recon0303

    Joined:
    Apr 20, 2014
    Posts:
    1,634
    Ya I agree , I use many other engines over the years (Still do ) when I first seen the new rendering, I knew it would be a mess.....I hate to say this, but its been what Unity continues to do, forget about those actually wanting to release stuff...and others who have... but we won't move to the new rendering, until its actually usable....stable... So I would agree with the OP and Oilli
     
    NathanielAH likes this.
  6. olli_vrcoaster

    olli_vrcoaster

    Joined:
    Sep 1, 2017
    Posts:
    24
    Well i waited for like ~2 years? before i even got into SRP and it's still not production ready imo
     
    natereesedev and NathanielAH like this.
  7. gecko

    gecko

    Joined:
    Aug 10, 2006
    Posts:
    2,093
    That is really infuriating. I don't comment on those threads because I am not a shader programmer and have nothing substantive to contribute -- but the benefits of what you're arguing for are indisputable. And plenty other people do comment on those threads in agreement with you. Truly, what the hell has happened to Unity?
     
    recon0303, Prodigga, OCASM and 6 others like this.
  8. bfoddy

    bfoddy

    Joined:
    Mar 27, 2012
    Posts:
    37
    Living the #SRPLife over here too. The documentation is extremely weak.
     
    NathanielAH likes this.
  9. Kirsche

    Kirsche

    Joined:
    Apr 14, 2015
    Posts:
    46
    Well, there would be a lot more still here if they had a fraction of your good will and patience.
     
    Prodigga and NathanielAH like this.
  10. fherbst

    fherbst

    Joined:
    Jun 24, 2012
    Posts:
    647
    While I don't agree that Unity is deaf to these issues (as you well know @jbooth some people are painfully aware), I think in general Unity needs to at least acknowledge them publicly (not through individuals) and lay out a path forward.

    Here's some more points.

    - Lost functionality. Things that emerged from 10+ years of graphics development at Unity are suddenly gone. Getting them back means fighting with QA, nagging every Unity person you can find, and insisting that these missing is a bug, not a "feature request you should discuss in the forum".
    Examples include GPU Mesh Particles (1000x speed regression), 360° Stereo Rendering (omitting an entire industry)
    - Not enough Testing in the Graphics repo. I had to personally create and PR unit tests and entire test categories for the URP where I got told "well, we can't test any combination, can we" for very common usecases (URP + ShaderGraph + VR). This goes hand in hand with the practice of pushing knowingly broken code to master and "fixing it in subsequent PRs" which almost always lead to regressions.
    - Not enough dogfooding. Since URP/HDRP/ShaderGraph are separate packages, they are maintained by separate teams without much communication in the past. This leads to finger pointing ("that's not our fault") and curious cases of URP devs never having used SG, SG devs never having used URP, XR devs not touching Unity (only C++ backend) and so forth. I'm a strong believer that time spent "in the system" is important for everyone and ultimately avoids many errors and saves time.

    I do believe the SRPs are the right way forward, and originally were a good idea. Deciding to develop them without a common system architect across graphics features was a bad one.
     
    R0man, Joe-Censored, OCASM and 14 others like this.
  11. valarus

    valarus

    Joined:
    Apr 7, 2019
    Posts:
    190
    I like your ideas jbooth. I would also like unified workflow for URP and HDRP, one engine instead of 2 different ones.

    I've made this scheme as suggestion how to unify SRP in one modular engine with inspiration of Houdini.
    For example, one could create terrain instance running with foliage system and could switch between URP or HDRP for render.

    Workflow and graphical interface would be the same for both SRP (shader graph UI , custom processes UI,..) only will they run in background differently.



    I've also would like to SRP would become of a single instance engine, instead of installation per project base.
    https://forum.unity.com/threads/single-hdrp-engine-instance-feature.914717/
     
  12. Rowlan

    Rowlan

    Joined:
    Aug 4, 2016
    Posts:
    1,394
    I get the shivers when upgrading from one minor Unity version to the next. Let alone upgrading SRP minor versions. The Horror! The avatar describes best what I get to see. And the nightmare and huge waste of time that follows ahead.

    For HDRP I've been thinking for quite some time now that there hasn't been any architecture concept. At all.
     
    Ruslank100 and NathanielAH like this.
  13. hawken

    hawken

    Joined:
    Aug 22, 2013
    Posts:
    539
    I was very impressed with the LWRP Shader Graph system and invested a lot of time in it, only to have almost all of my efforts trashed by the next version that came out.

    Even the samples from Unity’s own blog didn’t work from version to version.

    This in turn made me avoid the entire system forever. If anything, it shouldn’t have been shown or released until it actually worked properly.
     
    Last edited: Jun 20, 2020
  14. customphase

    customphase

    Joined:
    Aug 19, 2012
    Posts:
    197
    We've been using HDRP for our project, and it was mostly fine so far. However i do have a couple of gripes with it:

    1) The custom pass feature. Its great to have, but why the hell are you exposing only 6(!) injection points? Look at how its handled in the standard pipeline https://docs.unity3d.com/ScriptReference/Rendering.CameraEvent.html. Why not expose injection points for each rendering step like that? It literally takes 2 lines of code for each injection point, and it doesnt introduce any performance impact, so whats the matter? Why do we have to embed the package and modify the code manually just to add injection points that we need?

    2) Locking most of the code/classes behind access modifiers. I understand that some code isnt designed to be accessed from outside, but some things are absolutely necessary to have access to. For example we use modified version of the HDRP/Lit shader, so we need a modified Editor GUI class as well. But can we inherit from the default LitGUI class that HDRP/Lit shader uses to write our own modification? Nope. And we need the custom editor GUI not just for the quality of life, unity uses shader editors for essential functionality, like setting keywords/stencil values, so we cant just ignore it (which is another problem IMO, editors shouldnt have anything to do with that in this case, it should be controlled with some project-wide controller). Ok, we can write our own shader GUI without inheriting i guess. So we need to do our own stencil setup as well. Ok, let me get the stencil values from the StencilUsage class. Oops, its also inaccessible due to its protection level. Great. That also means that in any custom coded shader we have to manually hardcode stencil values and change them manually with each HDRP upgrade where they decide to change up stencil values. Amazing.

    Another example is rendering objects in custom passes. Unity has an example custom pass, which uses this line:
    PerObjectData renderConfig = hdCamera.frameSettings.IsEnabled(FrameSettingsField.Shadowmask) ? HDUtils.k_RendererConfigurationBakedLightingWithShadowMask : HDUtils.k_RendererConfigurationBakedLighting;

    Try replicating that in your own custom pass, and you'll get a compilation error, HDUtils.k_RendererConfigurationBakedLightingWithShadowMask and HDUtils.k_RendererConfigurationBakedLighting are just not accessible due to their protection levels. Why? Whats the point of doing that?
     
    Last edited: Jun 19, 2020
    Joe-Censored, Lyje, OCASM and 5 others like this.
  15. marcatore

    marcatore

    Joined:
    May 22, 2015
    Posts:
    158
    I don't have experienced yet the transition from a legacy project to the new SRP (Urp or HDRP) so I shouldn't express my opinion but I have faith on experienced devs and what described here is very very far from what I'd like to face when the transition will be unpostponedable.
    So, please Unity devs, try to face these issues and give us the best workflow user-friendly tools possible.
     
    Ruslank100 likes this.
  16. tirarex

    tirarex

    Joined:
    Feb 19, 2015
    Posts:
    9
    You are just bad developers and do not know how to work with SRP!
    Just a couple of mouse clicks and my 4k render has 222 fps! At the same time, it is possible to achieve maximum optimization, 0 draw 0 vert 0 tris!
    If you turn off the shadows, then the frame time will become -1ms and my computer will fly to Mars.
    This is only possible with SRP !!!
    Graz Unity, you are the best!

    Just kidding, SRP is terrible, URP works with a bunch of bugs, there are no shadows, post processing slows down, the shader graph constantly crashes, the build works differently from the editor. This is just hell to develop :(
    photo_2020-05-29_20-51-22.jpg
     
    NathanielAH, Ruslank100 and hawken like this.
  17. BattleAngelAlita

    BattleAngelAlita

    Joined:
    Nov 20, 2016
    Posts:
    214
    SRP is excellent. Its just URP are bad... HDRP is fine
     
  18. ledbetterman

    ledbetterman

    Joined:
    May 5, 2015
    Posts:
    80
    I'm working on a game that I'm tempted to switch to URP. The benefit of performance, access to shader graph and vfx graph... sounds great! But, every time I think I'm ready to commit, I run down the features I wanna use and remember why I havent.

    Light cookies? Nope.
    AO? Nope.
    Decals? Nope.

    Not to mention the amount of store assets that don't support URP. Many visual effect assets like NGSS and Aura 2. It's too much of a gamble of what your locked into, especially as a solo indie dev who relies on asset packages like these to make games that would otherwise be too complex for one person to finish.

    That said, credit to the teams working hard at maturing this tech. I think it has great promise, it just needs to benefit from more cross-team communication and candid acknowledgement of what needs to be shored up to be 'production ready'.

    Thanks for raising awareness on this issue. I hope SRP stabilizes in the next year; I'd really like to use it.
     
    Last edited: Jun 20, 2020
  19. Rich_A

    Rich_A

    Joined:
    Nov 22, 2016
    Posts:
    281
  20. SecondCobra

    SecondCobra

    Joined:
    Jan 25, 2017
    Posts:
    24
    Had so many problems with URP breaking on version change. Also trying to get into DOTS is a nightmare. Little solid documentation, major differences between HRDP and URP - that has to indicate a design issue!
     
    Ruslank100 and NathanielAH like this.
  21. Crayz

    Crayz

    Joined:
    Mar 17, 2014
    Posts:
    145
    I switched back to the built-in rendering pipeline and felt relief. Everything was consolidated, right there, all built-in, nicely integrated, easy to work with.

    Prioritize compatibility or instead of sweeping existing systems under the rug, upgrade them?
     
  22. BattleAngelAlita

    BattleAngelAlita

    Joined:
    Nov 20, 2016
    Posts:
    214
    @jbooth
    Rename topic to "URP/HDRP Life". Don't blame whole SRP-api just because of 2 unity's in-house realizations are bad.
     
  23. Rastapastor

    Rastapastor

    Joined:
    Jan 12, 2013
    Posts:
    135
    I mean it is pretty scary that the ENGINE devs themself fail to use their OWN ENGINE feature :), like there is a proverb 'the shoemaker’s children are ill-shod'

    As a hobbyist i don't really care that much if something is stable or not, it only frustrates me that some of the assets i like to use are not up to date or break with every version release and have to wait some time for the devs to fix them. So that is my only gripe with current state of the SRP, but considering working with Unity is some ppl livelyhood, i can imagine the frustration of constant overcoming the issues and head bumping, not necessarily because of their fault. I wish Unity took this stuff seriously and address the complaints and issues with SRP

    I think someone has raised a good idea how they should approach it. Admit it was a mistake, remove SRP and other big 'preview' stuff from current Unity. Release Unity LTS and focus on Unity 2.0 with all those features not beeing constrained by current architecture :), but i guess that will never happen.
     
    NathanielAH likes this.
  24. BattleAngelAlita

    BattleAngelAlita

    Joined:
    Nov 20, 2016
    Posts:
    214
    Unity's OWN terrain system are bad. And jbooth making buck from this.
     
    Ruslank100 likes this.
  25. jbooth

    jbooth

    Joined:
    Jan 6, 2014
    Posts:
    4,337
    the fundamental issue is with SRP, because it does not provide the proper abstraction layers to make common rendering tasks compatible across pipelines, or even between versions of the same pipeline. The layers built on top can not be more stable as the foundation they are built on.
     
    Last edited: Jun 20, 2020
  26. Flow-Fire-Games

    Flow-Fire-Games

    Joined:
    Jun 11, 2015
    Posts:
    232
  27. GuitarBro

    GuitarBro

    Joined:
    Oct 9, 2014
    Posts:
    102
    Couldn't have put it better myself. Hence why I am still using the Standard RP as my daily driver.
     
  28. hawken

    hawken

    Joined:
    Aug 22, 2013
    Posts:
    539
    Totally forgot about this. No support for decals at all in LWRP
     
    ledbetterman and NathanielAH like this.
  29. DeathRace26

    DeathRace26

    Joined:
    May 26, 2019
    Posts:
    71
    I also wonder when ST 8 will finally get its support. Are we still going to have to dream about working GPU Instancing with shadergraph?
     
    Ruslank100, NathanielAH and Rowlan like this.
  30. Raul_MadGoat

    Raul_MadGoat

    Joined:
    Jan 10, 2015
    Posts:
    327
    In with this as well!

    Huge pain in the a** supporting graphics assets across all render pipelines when nothing is consistent between them and the existent API seems to break or change every few versions.
     
    Ruslank100 and NathanielAH like this.
  31. NathanielAH

    NathanielAH

    Joined:
    Jul 22, 2013
    Posts:
    38
    I completely agree. They are abandoning Built In renderer, without SRP (URP & HDRP) being fully ready. It leaves all of us caught in limbo. There are amazing assets that won’t upgrade to SRP until at least 2020.4 LTS due to current SRP standing. I want SRP to work; it makes sense. But the approach has been ham fisted, community deaf, and just all around ignorant.

    As an indie dev. I have thousands ($$$) poured into this engine which makes it tough to say, but Unreal looks better every day that SRP continues to suck and Built In is abandonware. Just saying.

    -N.
     
  32. Fedora_Dev

    Fedora_Dev

    Joined:
    Oct 28, 2016
    Posts:
    25
    I hated how far behind Unity is with the times. They spend so much time diversifying that they just aren't good at any one thing. There are open source engines that are catching up to unity right now.

    I've sunk 9 years of my life into learning this engine and the honest truth is there have been nearly no real improvements since unity 5. They continue to fall further behind. Unreal is releasing an incredibly powerful tool that already dwarfs the srp in a year. How long will it take unity to catch up?

    Unity needs to invest time into producing full featured AAA games on their own engine so they actually have an idea of how terrible it is to produce games with their game engine.
     
    R0man, Ruslank100, Cynicat and 5 others like this.
  33. Crayz

    Crayz

    Joined:
    Mar 17, 2014
    Posts:
    145
    They really should do that.
     
  34. hawken

    hawken

    Joined:
    Aug 22, 2013
    Posts:
    539
    Unity do actually work with AAA (and all other) developers on shipping games, they have a very good idea of how the engine is used in production.

    URP has growing pains like all new features, replacing the core renderer of Unity is no small feat. There is some push back from the XR community that this was recommended as the way forward with essential features missing*. Perhaps in this area URP could have been tested more before being recommended as a solution for VR and AR.

    (* features missing: shadows over transparency, shadow fading at distance, shadow resolution blending, ambient occlusion post processing, etc.)

    Objection is mute for the most part as standard renderer is still available and will be for a long time. It does all the things but performance might be a little less than URP.
     
  35. jjxtra

    jjxtra

    Joined:
    Aug 30, 2013
    Posts:
    1,190
    The standard renderer had better be available for the next decade at least, that would be a catastrophe to remove.

    I dropped URP for all assets I tried to support it with and have no plans to support it unless something amazing happens.

    I do hope Unity figures this out. I never ran into a case where the standard pipeline fell short and only URP could give me a feature I wanted. HDRP may be a different story but I've never played with it.
     
    Jingle-Fett likes this.
  36. jbooth

    jbooth

    Joined:
    Jan 6, 2014
    Posts:
    4,337
    except that they are letting it rot, adding new features that are SRP only, or breaking them in standard or not properly supporting them (terrain instancing doesn’t work with surface shader tessellation. Surface shader bugs are no longer fixed). Essentially standard will continue to crumble from lack of support, as they only care about SRP now.
     
    Cynicat, tatoforever, hawken and 2 others like this.
  37. jjxtra

    jjxtra

    Joined:
    Aug 30, 2013
    Posts:
    1,190
    I wonder if a refactor of standard pipeline would have been a good intermediate step instead of SRP. This is all hindsight and probably doesn't matter, but it may have been interesting to try and remove deficiencies from standard pipeline first as a baby step...
     
    Ruslank100 likes this.
  38. jbooth

    jbooth

    Joined:
    Jan 6, 2014
    Posts:
    4,337
    There was nothing preventing the development of SRP as a refactor of the standard pipeline - though it's obviously a lot nicer to start fresh and build something new and exciting along with the SRP.

    In fact, when I was at Disruptor Beam we had a custom SRP that worked with surface shaders - it simply setup the same constants/passnames/etc and everything continued to work as normal. This allowed us to develop with existing shaders and asset store stuff until we were far enough along to put in our own lighting model, etc..

    In my mind, the idea workflow would have been to make the render pipeline scriptable and replace needed functionality, such as Grab Pass, Graphics.Blit, etc, with the new functionality as optional. Basically, introduce things like CustomPass as an optimization and remove the old techniques over time. This would mean there would be a single way to insert a custom pass, instead of each render pipeline providing their own versions. Sure, perhaps the enumeration of where to insert a pass would be different, but right now there is no similarities between the two pipelines.

    I'd have introduced a replacement for surface shaders that cleans up the old system, but does the cross compilation in a C# system, such that each SRP can take what the user has written, parse it, and decide what code to generate from it. The Shader Graph would have written to this format, such that there is a common abstraction layer that takes user-written shaders and converts them into SRP specific shaders, which doesn't care if that data comes from a graph, a text file, or any other system that might generate that data. Then when you decide to spin off your own SRP, or extend it via some asset store tool, you can modify the code gen to add whatever passes you want - and shaders made in the graph or a surface shader like format just work for the most part. Yes, if you decided to make the dreams renderer in Unity, you'd likely not have them be compatible, but in the case of HDRP/URP the inputs to the lighting equation are similar enough to abstract. And I suspect most renderers for the next 10 years will be the same.
     
  39. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    6,890
    Outside of Hearthstone, which big budget AAA game has been released with Unity?
     
  40. GuitarBro

    GuitarBro

    Joined:
    Oct 9, 2014
    Posts:
    102
    What saddens me most is that HDRP actually has some genuinely desirable features that are difficult to code manually (or find a github repo someone else made lol) but is still not suitable for production use yet.
    You could make the argument that GTFO or Escape from Tarkov fit the bill. But hardly anything on the scale of Fortnite or Unreal Tournament.
     
  41. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    6,890
    They don't really though, both of those are made from indies. Maybe Recore? (the game famously plagued with performance problems?)

    There aren't really any AAA games made in Unity. There doesn't exist the equivalent of Unreal's Final Fantasy VII: Remake for Unity. It simply doesn't. At best it's "good looking indie games" (which are not AAA) or "technically AAA, but it concerns games built with their 4th tier teams, usually for mobile, and with indie sized budgets" (which again are not AAA, although I'm looking forward to someone arguing how Lara Croft GO is the equivalent of Gears of War 5).

    Whether that matters at all for indies is a different matter. My opinion is that it doesn't.

    But let's be clear, if Unity is saying they are talking to AAA that use Unity to ship AAA games, what they mean is that they are talking to themselves in an empty room.

    (and I'll bow out of this thread now, since I'm getting off topic)
     
  42. Treiger

    Treiger

    Joined:
    Mar 20, 2013
    Posts:
    19
    Thanks for pushing for this Jason.
     
  43. ROBYER1

    ROBYER1

    Joined:
    Oct 9, 2015
    Posts:
    865
    I feel this strongly, have had so many setbacks on VR/AR projects when trying to use URP for supposed performance gains. After a good year and 120 bug reports to Unity, most of my VR and AR issues have been fixed.
     
  44. hawken

    hawken

    Joined:
    Aug 22, 2013
    Posts:
    539
    In production on current and new projects, I only use standard and Amplify Shader Editor in LTS versions of Unity. TBH had mostly forgotten about URP existence myself. See some great things from time to time happening, but watch from very far away, I just don't have the patience (or time) anymore.
     
    KokkuHub and GuitarBro like this.
  45. corjn

    corjn

    Joined:
    Feb 6, 2014
    Posts:
    144
    I want to add the fact that HDRP does not support custom lightning and it never will. This is such a terrible design decision. I made a water shader recently with Built-In and I ended up with a more realistic result using custom lightning, because it gives much more control.
    HDRP is like the bad part of Unreal Engine shading workflow. It's monolithic. If you want to make something a little bit different than usual, you basically have change the code of the pipeline.

    I made a post about it : https://forum.unity.com/threads/support-for-custom-lightning-in-hdrp.793416/

    This is Unity's answer : "it is not possible do to custom lighting with HDRP by design"
    So, you really need high fidelity graphics + custom lightning ? Well, bad for you, it seems it's never going to happen.
     
    Last edited: Jun 27, 2020
  46. laurentlavigne

    laurentlavigne

    Joined:
    Aug 16, 2012
    Posts:
    3,148
    I was shocked to find out that built-in deferred is much faster than URP.
    Could someone create AND MAINTAIN a thread that lists all that's broken or regressions from built-in to SRP? Or a google doc, that'll help a lot.
     
  47. Coroknight

    Coroknight

    Joined:
    Jul 10, 2012
    Posts:
    21
    Unfortunately this is very common Unity behavior. I fear that Unity is actually too reliant on feedback and they use it as a weapon to cut corners and narrow the scope of their projects way too far. That way they can keep pumping out new features to attract customers and when anyone complains they can just say "well we listened to customer feedback and this is what they asked for."

    Listening to feedback is good, having a tight scope is good. But, just like everything else in life, taking a good thing too far turns it into a bad thing. Customers shouldn't be expected to list every requirement of a system before you build it. At some point you have to ask yourself "what are reasonable expectations for this system?" Custom lighting seems like an obvious blindspot for a game engine.

    Another example is UI Toolkit. They aren't even trying to reach feature parity before shoveling out version 1.0. The list goes on and on.
     
    R0man, Jingle-Fett, OCASM and 3 others like this.
  48. customphase

    customphase

    Joined:
    Aug 19, 2012
    Posts:
    197
    Unless youre talking about shader graph specifically, HDRP does support custom lighting. It doesnt support custom deferred lighting, but in forward and with custom coded shaders you can do whatever you want. We do custom per-vertex lighting this way in our project for particles for example.
     
    Last edited: Jun 23, 2020
    MothDoctor likes this.
  49. corjn

    corjn

    Joined:
    Feb 6, 2014
    Posts:
    144
    No it does not. Read the thread I made about it. If it was the case, then amplify would have already supported it. You can't access the lights data (shadows for example) generated by the HDRP, because everything is made and merged into one big loop.

    It is still possible to do it, but then you would have to rewrite a custom light process all by yourself, like make your own custom shadow masks. You would have basically 2 lightning processes for only one rendering. Very bad for performances.

    With built-in or URP, what's good about them is that you can acess light data that are created by the pipeline, and then use them in your shaders. You don't have to re create the same data twice.

    "We do custom per-vertex lighting "
    You probably don't use the light data generated by the HDRP. That's the meaning of "custom lightning". What you do within HDRP is unlit, unlit by the HDRP lightning data.
     
    Last edited: Jun 23, 2020
    Ruslank100, AlanMattano and OCASM like this.
  50. customphase

    customphase

    Joined:
    Aug 19, 2012
    Posts:
    197
    Ok, let me rephrase. It doesnt officially support custom lighting, but you can hook up all the necessary standard includes and get all the lighting data you want. It just might change in the future, which might break your shaders, which shouldnt be hard to fix anyway. Again, we've made lots of custom lit shaders in HDRP for our project. Just look at the ShaderPassForward.hlsl and LighLoop.hlsl code, and try to replicate that.
     
unityunity