Search Unity

  1. 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

Unity What is next for us at Unity with Scriptable Render Pipelines

Discussion in 'General Graphics' started by mirrormask, Jul 2, 2020.

  1. protopop

    protopop

    Joined:
    May 19, 2009
    Posts:
    1,402
    I think that was the strength of the built in render pipeline. It really scaled well and I think for many developers we need a single project file we can build out from to multiple targets. I am legitimately curious what advantages the switch to SRP has. Was there something about the render pipeline that was not good? What's better in SRP?
     
  2. iamarugin

    iamarugin

    Joined:
    Dec 17, 2014
    Posts:
    521
    Please do not merge graphics packages back into core Unity, make the package manager better (only show compatible versions).
     
  3. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    5,206
    It's well explained in this rather short talk:
     
    protopop likes this.
  4. landonth

    landonth

    Joined:
    Dec 3, 2018
    Posts:
    44
    I see a lot of concern and possible misconception about this. Maybe we need some clarification from Unity on this?
    From what I understand, the only thing that's changing about this is that the verified SRPs with be pre-installed and it won't be so easy for someone to mess up their project in 2 clicks by upgrading to a non-verified URP or HDRP version and then flaming Unity because it doesn't work out of the box. but it'll still completely possible for devs and teams that really need that flexibility and know what they are getting into.
    It's a "fool-proofing" measure to give us the best of both worlds:

    - A surefire way to get up and running with a verified SRP package and dependencies that isn't so fragile for those new to Unity or those that don't care about modularity.
    - Those that need deep package modularity will still be able to do everything they need, with a few superficial hoops you have to jump through to prove you truly "know what you are doing." e.g. copy and pasting a git repo link into Unity package manager in order to use some experimental/alpha branch of an SRP package or there being further warnings and disclaimers that "this is unverified / untested / will break things."

    If some one at Unity can confirm or clarify this interpretation, that would be much appreciated.
     
  5. protopop

    protopop

    Joined:
    May 19, 2009
    Posts:
    1,402
    Thank you - that was concise and explains a lot about the SRP strengths and weaknesses.

    One issue is that it looks like SRPs have different versions quite frequently and new versions can break project assets? With built in render pipeline I'm using the same assets I used with unity 5 and even unity 4 in some cases. I'm not sure what will happen is we have a URP 2020, URP 2021 etc that potentially break projects. I'm not trying to knock SRP I'm just seeing a lot of version numbers for every package lately and there seems to be an exponential number of dependencies that seems like it is tricky to manage.
     
    Peter77 likes this.
  6. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    5,206
    I assume the main reason why there are many compatibility issues at the moment is because SRP is new. Once SRP matured and it's clear what is needed, I would think they can iterate on the C# side without changing the native core. So far, I believe a lot of these issues come from the need to change or extend the unity core for SRP to work.
     
  7. transat

    transat

    Joined:
    May 5, 2018
    Posts:
    772
    I just recently stumbled on this thread. It’s so easy to miss out on important communication like this! I appreciate pretty much everything that was stated in the OP. And Like many I also express some degree of scepticism about these new promises and am wary of the suggested timeframes. Hopefully some of this makes it in the 2020 stream.

    As for the issue of tying the SRP to the the editor... it makes sense but only because every new version of the SRP seems to demand the latest version of the editor anyway, due to stuff often not being backported.

    Otherwise... it would make more sense, in an ideal world, if SRPs were independent enough to automatically work across editor versions. In other words; the opposite of what we have now. So ideally I should be able to use URP 10, 11, 13 with Unity 2020.1. For this to work Unity would need to have the opposite approach: taking stuff out of the core editor and moving it to the SRP (to reduce dependencies).

    As a bonus the editor would get slimmer. Slimmer still if the Package Manager were moved out of the editor and into the Hub.

    But this is all wishful thinking and possibly too tricky to pull off. So as it stands, the current solution to tie the SRP to the editor might be the easier option to relieve some pressure on devs and the graphics team. It doesn’t really look like that dramatic a move, and some tooling can probably be designed to speed up the workflow for some of the developers who are adversely affected by the change.

    PS - looking forward to surface shaders 2.0. I like where this is heading and what @jbooth has suggested so far.
     
    goncalo-vasconcelos likes this.
  8. nasos_333

    nasos_333

    Joined:
    Feb 13, 2013
    Posts:
    8,631
    I think is supposed be more flexible to control its features, but that seems to make it both more complex to use and less performant with same feature set as standard.

    So far seems like not a replacement for standard in the slightest, i see standard is far superior after all my urp work.
     
    Jingle-Fett and knxrb like this.
  9. wlad_s

    wlad_s

    Joined:
    Feb 18, 2011
    Posts:
    127
    I'm really more interested in future of built-In pipeline, not future of URP/HDRP since they are really not that usable. They seem usable for studios that have direct support from Unity or experts (although @Acegikmo herself is having problems with new SRPs and we all know she's a super-shader-expert! Not to mention @jbooth , another expert who's struggling).

    For us indies, Built-In is still far far superior and easier to use. You can achieve so much alone and with the help of Asset Store. That's why I'm still using Built-In and I'd like to know more about its future. Like will it be supported for next-gen consoles? Even asking on dev forums or asking a console manufacturer directly doesn't yield any answer about a simple "will Built-In be supported on next gen yes or no?" question. How am I supposed to plan release platforms and talk to potential partners if such a basic info is kept super-secret? I have to register for next-gen access and get dev-hardware only to find out my game will never work and that I never needed access and hardware in the first place?

    So, is there a thread about the future of Built-In? If not, please make one, I think it's far more important for current developments than dreams about the glorious and uncertain future. It will take years and years for Asset Store devs to catch-up to SRPs once they are really finished and documented and that's when real parity to built-in will be achieved. I bet it will be 5 years minimum until something like this exists for SRPs. For HDRP there's not even an ocean solution that looks better than Built-In.

    We can have something cause an economic crash tomorrow and all those SRP dreams will evaporate, while Built-In works now as it is and provides livelihood for devs (although Unity is letting it rot, like instanced terrain + tessellation is broken and no one seems to care). Please let us know what's going to happen to our currently mature tools and when.
     
    Last edited: Sep 3, 2020
  10. iamarugin

    iamarugin

    Joined:
    Dec 17, 2014
    Posts:
    521
    URP/HDRP is pretty much usable if the developer have a little bit more knowledge than just "download a bunch of assets from Asset Store and slap them together into a new «game» and sell it for $2.99 on Steam".

    There are several problems with RPs right now. There is no API like surface shaders in builtin, so we currently have no layer of abstraction for hand-written shaders without using Shader Graph. Shader Graph itself is far far behind from something like Amplify Shader Editor. No realtime GI at all. And there is almost none documentation (at least in HDRP).

    But the potential is so huge. Finally, we have the tools, to achieve graphics fidelity and perfomance, comparable with other engines. I hope UT will concentrate their efforts on SRPs and solve remaining issues and will not spend their time on builtin.

    P.S. Ocean solution for HDRP: https://assetstore.unity.com/packages/tools/particles-effects/crest-ocean-system-hdrp-164158
     
  11. wlad_s

    wlad_s

    Joined:
    Feb 18, 2011
    Posts:
    127
    What you said there is very condescending. If you want to make something special and stay true to your artistic vision, you really need help either by hiring professionals or finding help through the Asset Store. I have customized almost every Asset Store package I bought, for example I've made that FogVolume3 use vdb volume files which took me about a week, but making a volumetric clouds system like that from the ground up would take many months.

    Look, I know I'm not an expert. I'm just an artist who wants to continue making games. I did very well with Builtin so far. A game on PS4, Switch, Steam, iOS, featured multiple times in categories like "Games are Art" and featured in Humble Indie Bundle, so it's not like I'm just slapping assets together. I'm just saying that given the current state of SRPs, people like me can't make games with them as they used to.

    Even money doesn't help. Like, who do you hire to help you out when even experts such as Acegikmo and jbooth are struggling? The author of FogVolume3 doesn't even want to hear about SRPs, despite the budget I offered.

    I'm not here to bash Unity or SRPs but give feedback from a real-life indie developer. Of course it's great to move forward and develop new things, but info about the plans for the old tools should be provided.


    HDRP Crest Ocean, wow, seems like it's really done! My bad, last time I checked, it lagged well behind BuiltIn and URP versions.
     
    protopop and OCASM like this.
  12. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    5,206
    Do not confuse problems raised by asset store publishers with your own, as many of the SRP issues they point out do apply to AS publishers only.

    For example, one major problem AS publishers complain about is that they have to do 3 times more work than before, to support HDRP/URP and builtin. Your game will not target more than one pipeline, thus that's not a problem you run into.
     
    Nephasto and JoNax97 like this.
  13. jbooth

    jbooth

    Joined:
    Jan 6, 2014
    Posts:
    4,424
    Actually there are games in development shipping mobile on URP and desktop on HDRP.
     
  14. transat

    transat

    Joined:
    May 5, 2018
    Posts:
    772
    If it were easy for them to maintain assets across pipelines then it would also be easy for users to switch from one pipeline to another. And if it's too difficult for the asset devs to continue their work then users will have fewer options on the store. So their cause is our cause. :)
     
    protopop and De-Panther like this.
  15. perholmes

    perholmes

    Joined:
    Dec 29, 2017
    Posts:
    62
    Unity has stated that they will support a unified shader model so that you can deploy to URP/HDRP from the same project with the same shaders, and URP will degrade as needed when a feature is only available in HDRP.
     
  16. jbooth

    jbooth

    Joined:
    Jan 6, 2014
    Posts:
    4,424
    Unfortunately they haven't shared the details and gotchas- and talk of this has only been via shader graph so far. Right now, even something as simple as getting the background color of a camera is different between URP and HDRP.
     
    goncalo-vasconcelos and OCASM like this.
  17. perholmes

    perholmes

    Joined:
    Dec 29, 2017
    Posts:
    62
    I agree, we shouldn't plan as though all our problems will go away in 2021.1. But I appreciate seeing that they're recognizing the fragmentation. The inability to support URP and HDRP from the same project actually drove us to Unreal for a while. We'll live with URP for the time being, and it sounds like maybe we can target both in a couple of years.
     
  18. wlad_s

    wlad_s

    Joined:
    Feb 18, 2011
    Posts:
    127
    I actually have no problems with development in Unity because I'm using Built-In :D I'm wearing this #SRPLife badge out of solidarity with asset developers.


    What bugs me now is that I've heard rumors that Built-In won't be supported on next gen, which would really be a shame. Asking on relevant channels yields either "ask someone else" or a "please wait" response :confused: I also don't get how come it seems like I'm the only one with this problem. Am I really the only last dinosaur who still develops in Built-In? :D Oh well, back to working and hoping.
     
    Last edited: Sep 7, 2020
    protopop likes this.
  19. perholmes

    perholmes

    Joined:
    Dec 29, 2017
    Posts:
    62
    We completely assumed that the Built-In pipeline was semi-deprecated and would eventually go away. They do say that all new feature development goes into the SRPs. We got the message that in the future only SRPs will exist.
     
  20. KokkuHub

    KokkuHub

    Joined:
    Feb 15, 2018
    Posts:
    445
    If built-in doesn't work on PS5 and XBSX a lot of people will be seriously pissed, me and some of our clients included, but considering how out of tune Unity is with the actual needs of developers it wouldn't surprise me. They routinely ask "have you tried <latest Unity beta version> to see if it solves your problem in <actual version your project uses>?" with zero regards to the perils and resources involved in updating large-ish projects across Unity versions, for example, so I fully expect them to tell people to "just re-create all your custom shaders in shader graph" and call it a day.
     
    Ruslank100, OCASM and wlad_s like this.
  21. neoshaman

    neoshaman

    Joined:
    Feb 11, 2011
    Posts:
    5,569
    BTW I always wanted to rant about their visual tech demo, which are basically just using unity as a viewer for baked data generated outside of unity with expensive tech and high skills that doesn't translate into a workable workflow, with unique implementation that need code access to the engine and that will never be released or implemented. BY that logic I could compile stuff and have them play into blitz3D and say you can do that in blitz3D which is obsolete DirectX7 and yet I can probably emulate most unity demo by just feeding data on the fly. I mean most of the interesting part of heretic demo is not useful in anyway.

    Props to their fontaine bleu demo for the whole photogrammetry workflows at least (boo about their grid occlusion system).

    So the problem of srp is really in a deepset mentality problem in how to tackle the practical problem of making games, visual in specific here.
     
  22. landonth

    landonth

    Joined:
    Dec 3, 2018
    Posts:
    44
    This is a valid criticism of cinematic demos in real-time engines --but it isn't unique to Unity (e.g. the UE5 reveal demo was made in the same fashion.) While interesting, it's a stretch to say it's on the topic of the Scriptable Render Pipeline roadmap here. There are teams dedicated to making these demos, completely separate from the team at Unity working on Scriptable Render Pipelines.

    I do welcome you to start a new thread if you'd like to offer feedback on what the Unity Demo team has been up to, and the impressions cinematic demos can leave that often overshadow interactive and workflow demos, etc. It's a worthwhile discussion. :)
     
  23. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    7,137
    I do not understand how it not being unique weakens the criticism. (and if it doesn't, why did you bring it up?).
    Not really, or did you miss the last line?
    Here. Every time Unity needs to actually do something, Unity themselves create custom solutions, because their out of the box solutions simply won't do.

    Similarly SRPs are great in theory, but in practice they have many problems, as we have seen. SRP issues are a symptom of a larger problem with Unity where a lot of their solutions sound great in theory, but in practice they have so many holes and impracticalities they may end up causing more problems than they solve -> Exemplified by how many times we see Unity themselves tell us "we didn't use that, because it's slow" "we changed that for this project, because this way it's better" "we created a whole new feature, since our built in features didn't cover this" etc.
    Hey @neoshaman , you have landonth's permission to start a new thread, aren't you glad?

    If I want to open a thread, what form do I need to submit to you so I can get permission?
     
    Kennth likes this.
  24. neoshaman

    neoshaman

    Joined:
    Feb 11, 2011
    Posts:
    5,569
    Completely disagree, unreal demo show something close to a real common use case, actually talk about real dev pain point, with many elements present in old build of unreal but better, done with asset they made available for free, and article that show the breakdown of some effects. The whole synopsis they use is to walk you through concern you may have -> here is a scene, it's detailed, the engine can handle it, here is a character, it move around so we manage interactivity, the lighting is real time GI, so you don't have spend time baking, the engine can import data directly, we handle the complexity for you, cutting the worflow to single step, and you don't have to author all data, we provide this quality to you with quixel, here is refresh of old system (particle, sound, etc...).

    Unity have cloth tearing, scene morphing, facial animation, wrinkle map, per character shadowmap, occlusion volume... all are either custom stuff we will never see, or expensive animation made on expensive tools with unity only reading an alembic, then say, hey guys look at what unity can do, this is HDRP, except it's not the highlighted stuff are done without the engine. In the end the demo is useless and non salvageable. Then they wrote an article that make you realize everything is done with external tools and then the artist geek on his own creative process that has nothing to do with a proper workflow. Basically unity demo don't answer problem face by the process of game development, which is why people have been salty about them since unity 5.

    how it's relevant to SRP? the point is that they keep solving the wrong problem or provide the wrong implementation, SRP was great when it was only HDRP and LWRP, because they were specialized pipeline for narrow goal (solving realism performance) then they took away flexibility and closed interoperability, they took away graphic artistic control on lighting and technical implementation of many shader for a photorealistic SVBRDF model where lighting is either bad (non pbr) or good (pbr) and where material are only fancy coating on objects. The SRP problem exist in a continuity, that is, they don't make "games", and whatever tutorial game demo really don't matter because it's not to scale and are aiming low hanging fruits.

    Contrast with when old unity implemented Tetrahedral lightprobe and surface shader, it was a reflection born from mixing with pain points that were recurring on the forum, realizing that light was hard and everyone was hacking around, so they provided more control on light with the concept of surface, it was organically grown. SRP kinda start like that, but then they became increasingly closed with rash decision (like depreciating Built in, tossing surface with the bathwater) being made and limited communication. They were in a mode where they knew what was best for us and that we would soon realized how foolish we were, literally talking down to proven experts who solved problem dev were facing.

    There is just a straight continuity of new unity to the current discussion about SRP.
     
  25. CarpeFunSoftware

    CarpeFunSoftware

    Joined:
    May 7, 2015
    Posts:
    34
    Meh. I guess I'm too "new" to fully comment, and Unity has much history, but if you're going to have Scriptable Render Pipelines, I don't see a reason to have "rendering paths" within a pipeline. Seems like legacy thinking. Maybe it's because transparents use a forward path within deferred anyway so have both?

    But if I want something different, no problem! "Just" add a new pipeline. The pipeline has characteristics of XYZ, and that's how it works.

    But for now, we can have SRP - Forward, SRP - Deferred, HRDP - deferred, etc.
    Why get all "of two minds" within one pipeline when the whole idea is plug-and-play pipelines? Hell, I should be able to pick from a documented Smörgåsbord of basic pipelines, and customize it from there. For any given pipeline, here's the passes that are called in this order, documented, or created by the custom-pipeline authors.

    And if I want to write that ray-traced pipeline (neither forward nor deferred) for that spiffy space-alien provided card that supports 500 lights and ray traced everything at 1000 fps, I should be able to. Knowing full well that I have to A) Allocate render textures and decide how they're set up, B) call shaders with render passes for this pipeline, with the passes called at the proper stages. I suppose I should be able to use Unity's existing shader library (like for shadows for example, if not ray traced) IF IF IF I conform to certain requirements (use RT3 for this, RT2 for that, pack data this way...), but if not then I don't have to.

    What I need is the abstraction model for SRP's and the documentation. I'm still checking into the github doco, but more overall documentation and abstraction would be nice.

    One thing I don't expect is Forward SRP to also be Deferred SRP. Why? Sounds inefficient to me. Sure, the standards for the assets should be the same, so they can "move", and some shader "blocks" can be the same. But other "blocks" (passes) would be pipeline specific. By definition.

    I guess I'm a "rebel". I want assets to be reasonably transportable between "stock" pipelines, so you should try and keep texture usage standards where practical. But if not practical, screw it. Give me well documented efficient (and different) pipelines that aren't Frankenstein "try and make everyone happy" milquetoast amalgamations. Teach everyone what the differences are and let them pick one, and the assets will probably (but not necessarily) be different. Particularly the shaders.

    Pick a pipeline. I get that producing assets across pipelines is a problem, but it's a problem chopping up a Chevy and fitting it to a Ford too. I mean, different pipelines are different, and that's mostly a good thing in terms of features. But they're different pipelines because they're fundamentally different.

    But I'd love to have it all documented, so I can go from there. In code, in a text editor.

    2 cents and lots of love to all, thanks for the great engine.
     
  26. jbooth

    jbooth

    Joined:
    Jan 6, 2014
    Posts:
    4,424
    Well then you wouldn't be able to have transparency in your game (at least without using dithering or depth peeling or some other hack). Deferred Rendering only works for opaque objects, so most engines have to mix several of these concepts to rasterize a scene. There are actually a ton of different possible rendering pipelines that could be made, and each have different tradeoff's around lighting complexity, memory, fill rate, hardware, etc. But fundamentally they are all primarily driven by issues to do with lighting. At some point, these will all be unified under a single concept like path or raytracing, but we are still a ways off from that.
     
    xVergilx, protopop and landonth like this.
  27. CarpeFunSoftware

    CarpeFunSoftware

    Joined:
    May 7, 2015
    Posts:
    34
    I mentioned that in the first paragraph, the deferred pipeline would still call a transparent-object-specific pass.

    But there's other issues too. As many as you could invent.

    The main point is the abstraction model. And documentation.
     
  28. Aviryx

    Aviryx

    Joined:
    May 30, 2020
    Posts:
    97
    I've been through the process of building a scriptable render pipeline from scratch a few times and here are the main issues I have encountered:

    1) There is a huge lack of structured documentation regarding scriptable render pipelines. Technically, the information is available if you search hard enough (well... most of it) but it's either under UnityEngine.Rendering in the documentation (and lacking relevant implementation notes) or it's just a vague "check out this repo on github or look at what we did with the URP/HDRP." and is such a headache to navigate.

    A perfect example.... how do I render the skybox? Oh cool here is the docs about it:

    https://docs.unity3d.com/2020.1/Doc...ering.ScriptableRenderContext.DrawSkybox.html

    `context.DrawSkybox(camera)`
    `context.Submit()`

    But there is no mention that you need to setup camera properties before rendering the skybox or you get weird results (or some other method is required). You need to go digging into the documentation (this being under the ScriptableRenderContext class)

    https://docs.unity3d.com/ScriptRefe...tableRenderContext.SetupCameraProperties.html

    In fact.... I don't even know if that is true as the example linked by Unity does not setup camera properties anywhere.

    https://github.com/phi-lira/CustomSRP/blob/master/Runtime/CustomRenderPipeline.cs

    So why is the skybox incorrectly rendered without setting up camera properties in my case? I have no idea.

    2) Please consider providing better shader support/documentation.... I know ShaderGraph is probably easier to maintain overall but the lack of docs about custom shaders is so frustrating. I shouldn't have to frankenstein code together. Info is scattered about it. For example, a "base" example for a lit shader.

    https://gist.github.com/phi-lira/225cd7c5e8545be602dca4eb5ed111ba

    3) Documentation Chains

    The docs for SRP stuff seems to be scattered everywhere. Like a not-so-fun easter egg hunt.

    "Ok i used the docs to make a skeleton pipeline, what next? Scheduling and executing render commands."

    https://docs.unity3d.com/Manual/srp-using-scriptable-render-context.html

    "Make direct API calls to the Scriptable Render Context..... ok can do."

    https://docs.unity3d.com/ScriptReference/Rendering.ScriptableRenderContext.DrawRenderers.html

    "Hmmm... ok well it gives an example but it's super basic. How do I specify something such as dictating an order for opaque or transparent objects when sorting? There is nothing about it in the documentation afaik. I need to render opaque first, then skybox, then transparent geometry... so how do I do it?"

    3 hours later....

    "A random obscure post on the internet told me there is something called Sorting Settings... ok I'll google 'Unity Sorting Settings' "

    https://docs.unity3d.com/ScriptReference/Rendering.SortingSettings.html


    "uh... ok not really sure how to do this. oh "criteria" what kind of sorting to do while rendering. I'll click that".

    https://docs.unity3d.com/ScriptReference/Rendering.SortingSettings-criteria.html

    "um ok not too helpful but it provides more references so guess I'll look at each one"

    https://docs.unity3d.com/ScriptReference/Rendering.SortingCriteria.None.html

    "ok not useful. Next link"

    https://docs.unity3d.com/ScriptReference/Rendering.SortingCriteria.html

    "Ah ok now we're getting somewhere. The properties list at the bottom has the answer!"

    https://docs.unity3d.com/ScriptReference/Rendering.SortingCriteria.CommonOpaque.html

    "ok now just have to figure out how to use it" (lol Unity you made me spend hours getting to this point and you're not going to give me a basic implementation? I like puzzles but please.... help me out).

    30 minutes later...

    `SortingSettings sortingSettings = new SortingSettings(camera) { criteria = SortingCriteria.CommonOpaque };`

    4) Trying to build a production-ready pipeline is such a monumental task (good luck finding more than 3 or 4 examples on the internet) that I don't blame people if they avoid doing it. I think improved documentation under the "SRP" section of the docs should be something Unity seriously considers as it makes working with custom pipelines a nightmare.
     
    Last edited: Sep 10, 2020
  29. forestrf

    forestrf

    Joined:
    Aug 28, 2010
    Posts:
    100
    Does the "Backed Lightmaps" mode in the Scene View work with SRP? Because I'm unable to make it work. That mode and many others. And there's no documentation for doing it or examples I can found anywhere that work.
     
  30. Aviryx

    Aviryx

    Joined:
    May 30, 2020
    Posts:
    97
    Yeah but I'm not sure if there is a "clean" way of doing it.

    https://github.com/Unity-Technologi...elines.core/ShaderLibrary/EntityLighting.hlsl

    You can use that to retrieve light data so you can sample the light map but might run into weird "how am I supposed to do this?" cases where it will take hours of googling to find a result. For example, checking to see if a lightmap is compressed or not.

    Or like sampling light probes... you have to pass that data to the GPU per object (https://docs.unity3d.com/ScriptReference/Rendering.PerObjectData.LightProbe.html)

    Oh look no example.. just a barebones description. "Setup per-object light probe SH data." lol so helpful.

    And that is without taking into account how to actually use that information. For example UnityPerDraw data has a bunch of float4 vectors that represent different light colours (red, green, blue) and then you have to sample this... and do XYZ, then some other obscure thing (oh and the probe data has to be provided as an array of coefficients).

    Unfortunately to get something like that working is a painful experience (imo) and there is not much I can help with in terms of "here is a bunch of code" but I wish you luck. It's certainly possible - whether you're willing to risk your sanity in order to implement it though is the question.
     
  31. landonth

    landonth

    Joined:
    Dec 3, 2018
    Posts:
    44
    @neoshaman I have replied to your points about tech demos on a new thread:
    https://forum.unity.com/threads/uni...s-to-practical-workflows.968562/#post-6303699

    My reply to your points on SRP:

    I wouldn't say SRP has ever been "great" :). But I see what you're saying, the design intentions shifted a bit. Custom lighting and NPR Non-Photo-Realistic rendering is definitely a pain point for developers that need a streamlined solution. Instead of keeping LWRP highly focused on being lightweight only, and focusing on improving the experience of writing a custom SRP (for those of us that would rather take that route.) it seems now Unity is focusing first on making Stylized / NPR lighting and materials more feasible in URP to be as scalable and extendable like Built-in RP in many ways, whereas HDRP is still purely focused on Photorealistic / PBR. While I personally would rather have a improved custom SRP workflow / tools sooner than later, and like you, I was aligned with LWRP's original focus / intent... I can see why the majority of people just want URP to be more like the Built-in RP. The community's feedback on LWRP not being scalable was very loud and clear --so that's where the focus is right now: making URP scalable and extendable.

    I overall agree with this criticism, that some damage has already been done with this misunderstanding of the community's needs, and now only after the mass of negative feedback, execs / product managers at Unity finally realized they need to shift direction. Hindsight is always 2020, as they say.

    A few clarifications to note:
    1. (Assuming you meant "deprecating" not "depreciating," common misspelling) Built-in RP is not deprecated nor are there plans for it to be deprecated. People have certainly spread rumors about this, but there has be no announcement of this I'm aware of but please correct me with your source if you have some new information. My personal prediction is this would / could only happen several years from now and only after URP has completely superseded Built-in RP's features in virtually every way. Built-in RP isn't getting much in terms of new features, sure, because it's an aging pipeline that wasn't a solid foundation to build next gen features on top of. But lack of new feature updates is not what deprecation means. Deprecation means telling devs they should not use a feature at all, or announcing end of support of a component / feature, and may also imply complete removal in the future. Instead Unity has been clear some projects should definitely still use Built-In RP as they provide feature comparison tables to URP and HDRP to help determine what choice to make, as neither Included SRP supersedes Built-In RP in all features:
    https://docs.unity3d.com/Packages/c...l/universalrp-builtin-feature-comparison.html
    https://docs.unity3d.com/Packages/c...definition@8.2/manual/Feature-Comparison.html
    2. Surface Shaders and lack of a complete Shader API are a big missing that should have had much more focus from the beginning, so your criticism is on point here. However, putting the past in the past, this was just addressed by Unity developers in the original post on this thread as something they are now working on. Take this commitment how you will --this is the official word in any case.

     
    Last edited: Sep 12, 2020
  32. KokkuHub

    KokkuHub

    Joined:
    Feb 15, 2018
    Posts:
    445
    The concern right now is if built-in will continue working on PS5 and Xbox SX. Nobody can get a straight answer from Unity staff on this. It's still not even clear if the current LTS releases will work or if we'll be forced to upgrade to 2020. This is the first new console Gen after the change to TECH/LTS system, so there's no past precedent to how they will proceed (current Gen consoles came out all during the Unity 5 cycle).
     
    knxrb, landonth and OCASM like this.
  33. BattleAngelAlita

    BattleAngelAlita

    Joined:
    Nov 20, 2016
    Posts:
    246
    @Aviryx
    Disagree, SRP api is quite simple and straightforward. Of course, it's lack of some features, but still nice. Maybe my experience is such different because i started learning SRP api from LWRP 0.1.28. In that times LWRP was very simple, light, and friendly to read code.

    Most debug views don't work in SRP, but you easily can recreate it bu yourself. For URP you can use "URP Debug Views" plugin.
     
  34. Aviryx

    Aviryx

    Joined:
    May 30, 2020
    Posts:
    97
    I disagree. There are basic features/documentation missing and, after almost 2 years of the SRP being available, it's annoying and makes life more difficult. Maybe we have different experiences? I'm talking about putting together a production-ready custom pipeline to be used for a commercial game.

    having to hunt through pages of documentation, search github, and spend hours looking through google results is not simple or straight forward - especially when Unity should be providing that information. After 2 years Unity are still telling people (in the docs) to go look at an example pipeline made by a Unity employee in his spare time which is ludicrous.

    They just tell you to go to github for a barebones example (that doesn't really explain anything either) and good luck replicating the shader library or supporting custom lit shaders.

    Their example of "how to build a custom RP" amounts to:

    1) create the basic pipeline asset and instance
    2) lol good luck... there is a repo on github though so maybe go check that out?

    For example, the skybox render situation. Nowhere does it tell you about having to setup the view-projection matrix before you render the skybox. Absolutely nowhere. The first time I created a SRP I spend days... literal days, trying to figure out why.

    Can you tell me why the view-projection matrix needs to be setup before you render the skybox? Because, if not, then it perfectly shows what I am talking about in terms of poor documentation from Unity.

    https://docs.unity3d.com/2020.1/Doc...30.774757725.1600458631-1591492147.1599730990

    https://docs.unity3d.com/ScriptRefe...30.774757725.1600458631-1591492147.1599730990

    Look at the documentation for both the skybox and camera setup info... there is basically nothing there in terms of explanations or "hey you might want to know this...."

    Why does Unity still not have even a basic example of creating a pipeline? Not even one with a skybox lol... they literally say 1) create a pipeline asset 2) create a pipeline instance 3) go look at github for examples or see the HDRP/URP pipeline. That is nowhere near enough information. It's not good enough to say you can technically figure it out after spending hours looking through document chains and github.

    It's possible to put together an SRP but it's certainly nowhere near simple or straight forward if you are looking to create a production-ready pipeline on par with the URP or HDRP.

    Imagine trying to write an operating system and someone is like "oh just go look through the source code for linux and you will figure it out". That is what Unity does in terms of "oh you want to implement this complex feature? durr just look at the source code for the HDRP and see how we did it".

    If they want more people to start using SRP then I still argue they need a huge change/update to the docs.

    I have a toaster with a manual containing more information than Unity provides for their SRP solution.

    Why can't they provide a thorough tutorial like this?

    https://catlikecoding.com/unity/tutorials/scriptable-render-pipeline/

    I mean I would even settle for a link at the bottom of the SRP docs. Would be more useful than what they have now.

    (here is an unofficial example of implementing a custom render pipeline)

    It's not like graphics programming is the easiest thing anyway so why make it so much harder for anyone to really make use of the SRP (both studios and asset creators).
     
    Last edited: Sep 19, 2020
  35. KokkuHub

    KokkuHub

    Joined:
    Feb 15, 2018
    Posts:
    445
    Besides the lack of documentation, there are a few implementation decisions that limit SRPs.

    The first is culling, which is an opaque process hidden away inside Unity's black box. It enforces rigid paradigms on how render lists are to be produced and consumed for both view and shadow rendering. For example, the concept of shadow cascades is baked into the API. Any shadowing pipeline that slightly deviates from the hard-coded use case needs to fall back into workarounds using multiple cameras, which are still not enough for producing render lists that don't fit the usual frustum culling scenarios.

    For example, you'll have a hard time making a custom SRP leverage single pass rendering to multiple shadow cascades or single pass cube map rendering, which could be used to greatly reduce draw calls on some GPUs like the Nvidia Maxwell used on the Nintendo Switch.

    Second problem is shader generation. Or lack of thereof. There's a missing opportunity to modernize the shader pipeline through some sort of scriptable shader generation API, but instead we got another monolithic template injector in the form of Shader Graph which is hard-coded to work with Unity's own SRPs because of it's underlying design.

    Any render pipeline is intimately intertwined with all shaders used during scene rendering, it shouldn't be something that is manually configured on each individual shader/material. If my pipeline implements a different kind of shadowing projection, or needs an additional render target with extra information to be produced during normal rendering, it should be possible to process all shaders to add this functionality to them in a programmatic way.
     
    Last edited: Sep 19, 2020
  36. Aviryx

    Aviryx

    Joined:
    May 30, 2020
    Posts:
    97
    Exactly.

    Pushing Shader Graph as the "main" solution for URP/HDRP (and authoring shaders in general with the SRP) is really annoying and comes off as more of a convenience for Unity (in terms of maintainability) rather than something for users.

    Sure, if you don't want to write shaders (or don't know how) then Shader Graph is really cool... but it should not be at the detriment of those who still want to write custom shaders (especially within a custom pipeline).

    I don't think it's acceptable to expect me to either:

    - keep a close eye on Unity's github repo for their graphics and subsequent core render pipeline code/shader library in order to figure out "how do I do this" or "what did Unity change this time that caused my shaders to break"

    - generate a basic lit shader with shader graph and then spend however long pouring through borderline-unreadable code in order to pull certain information about how to work with Unity's lighting.

    Again, I point to the fact that the only thing we really have is a template made by a unity employee (an unofficial example)

    https://gist.github.com/phi-lira/225cd7c5e8545be602dca4eb5ed111ba

    and, after 2 years, it's disappointing that Unity don't seem to offer the kind of support you would expect if you want to create custom SRPs for commercial games.

    It's so complicated that you might as well stick to URP/HDRP unless you're developing for mobile... then it might be worth the headache of a custom pipeline which is a shame because the SRP is really powerful.
     
  37. neoshaman

    neoshaman

    Joined:
    Feb 11, 2011
    Posts:
    5,569
    PREACH

    I stop looking at the custom srp as soon as I hit that point, teh disapointment was real, you are telling you have the culling list, and you won't let me peak what's inside?
     
  38. forestrf

    forestrf

    Joined:
    Aug 28, 2010
    Posts:
    100
  39. sand_lantern

    sand_lantern

    Joined:
    Sep 15, 2017
    Posts:
    157
    To add to this, a few months ago I decided I wanted to get my hands dirty learning how to write shader code as a custom post process for the HDRP. Turns out the only way to know how to do this is to already know how to do it, because there was next to no documentation. What documentation there was, much of it was out dated. I get that the HDRP stuff has been a bit of a moving target, but that doesn't give Unity free pass to pretend like it doesn't exist.

    And I should clarify that this was among the simplest of shaders. I just wanted to make a simple Z-depth based "fog" because the built in fog didn't work for our scene. It took me at least a week to even get anything to happen because of how many secret gotcha's there were in the workflow.
     
    Egad_McDad, Aviryx and landonth like this.
  40. Aviryx

    Aviryx

    Joined:
    May 30, 2020
    Posts:
    97
    Exactly. It was much worse before core RP 7.1 if you can believe that. When you were able to figure out how to do something Unity would update their core tech and it broke everything. It's better now (not had anything broken or weird happen) but I'm getting sick of spending 7 hours to achieve what should be doable in 20 minutes.

    There is no excuse - even if HDRP is a moving target. AFAIK the HDRP and URP both use Unity's core render pipeline.

    https://github.com/Unity-Technologies/Graphics/tree/master/com.unity.render-pipelines.core

    So even if the HDRP and URP get updated daily - anybody trying to use the underlying technology shouldn't be effected by this constant change, yet we are because Unity expects us to pour through their raw code to figure out how to do something.

    Yep. Even creating something basic like a lit shader can be incredibly difficult... I mean ffs they don't even bother explaining basic stuff like:

    - rendering a skybox
    - rendering unlit opaque objects
    - rendering unlit transparent objects (and the subsequent sorting that needs to be done)

    and when they do have "documentation" it is the most basic of explanations that gives no description and no examples.

    https://docs.unity3d.com/ScriptReference/Rendering.SortingSettings-ctor.html

    Look at this laziness... documentation page for the sorting settings constructor that doesn't give an example! What absolute madness is this?

    "oh" you think, "Well maybe they just put an example of how to do it on one of the other 20 pages of documentation that relate to sorting settings, right?"

    https://docs.unity3d.com/ScriptReference/Rendering.SortingCriteria.CommonOpaque.html

    Nope. Lol.

    Code (CSharp):
    1. SortingSettings sortingSettings = new SortingSettings(camera) { criteria = SortingCriteria.CommonOpaque };
    There you go Unity. Just made that documentation page 1000 times more useful.

    This is what annoys me. I can put up with a lot of other stuff (I clearly love Unity as I've been using it for 8+ years) but can someone at Unity please suggest sorting out the terrible (lazy) documentation for this stuff? or even give us an answer about if you plan to change it at all.

    Why bother having a documentation page that has basically no description, no example, and no relevant links. Might as well just write "lol gtfo" instead of giving me the most basic syntax as they are both just as helpful.

    I've spent approximately the last 5 months building a custom (from scratch) render pipeline for a commercial game with a few other people.

    Would I do it again? NOPE. In fact, I think I might had PTSD (Pipeline Traumatic Scripting Disorder) after the nightmare I have experienced.

    I really don't understand. Unity, you want people to use the SRP tech, right? That's why we're moving away from the built-in pipeline. So why are you not giving us the tools (ie - documentation) we need to make high-quality games with a custom pipeline?

    Is this what we can expect to see with ECS? (which is also poorly documented but is more forgivable as it's not something I expect to see as 'standard' for another few years).

    Why is there a basic "how to make a ping pong game with ECS" tutorial but not a "how to make a really basic render pipeline?"

    At this point I don't see myself jumping ship (I don't know C++ so don't want to use Unreal and CryEngine is (imo) a clunky, unitiuitive engine to work with... even if they do have C# support).

    However, this will not last forever. There is no doubt other engines will come out (or maybe Unreal/CryEngine will appeal more to me in the future) so Unity really need to consider who they are trying to attract.

    You can't have them all Unity! Even though I know you want everybody and anybody to be able to just pick-up and use Unity. One (or more) groups suffer. By making everything more "casual/easy to use or pickup" you sacrifice stuff like detailed documentation for your SRP tech.... no doubt because "nowhere near as many people will create their own SRP from scratch" - but you still built the tech so you must want people to use it, right?

    The studio I work for is not big enough and certainly does not have enough cash to build our own engine so we're kind of stuck with whatever Unity provides. 99% of the time it's great but there has been very little change in terms of Unity's priorities. I mean it's been what? 2 years since SRP has been available. Yet the documentation looks like it's for experimental tech that is still in preview.

    lol anyone might think Unity literally employs one person (phil lira) to do their SRP stuff. (Even the URP boat attack demo was actually made solely by the same guy, right?)

    I get that most of your attention goes into onboarding/basic tutorials etc. That's fine... but please don't forget about those users who really want to make the most of the SRP tech. SRP + ECS could be amazing but I'm really worried that it's going to be a nightmare to use for the first few years.
     
    Last edited: Sep 23, 2020
  41. BattleAngelAlita

    BattleAngelAlita

    Joined:
    Nov 20, 2016
    Posts:
    246
    I was in developing of game from 0 to OBT with my custom SRP. And that was huge! And i definitely do it again. Guys i know who writes their own pipelines - are all happy too.
     
  42. Aviryx

    Aviryx

    Joined:
    May 30, 2020
    Posts:
    97
    We are trying to build something that is close in parity to HDRP except where we require custom solutions that are more efficient for what we need or something that we "prefer" when compared to a HDRP feature.

    I would be interested in knowing how much trouble you have developing custom pipelines (if any) because there is not a ton of support and a lot of stuff is "unity-specific" so you can't just implement standard graphics programming solutions (for example, working with Unity lighting).

    Do you not run into any issues? and if not, where are you finding this Unity-specific information about implementing certain rendering techniques? (supporting multiple directional lights, shadow maps, etc)

    I would also be interested in knowing if the pipeline(s) you have written were used for commercial games that have been released, and if so, what game(s)?

    I'm specifically talking about a production-ready pipeline for commercial games (PC/PS4/XBOX).

    Also, considering you're a graphics programmer, I would be interested in your view on the current SRP support (documentation) and if you think the current level of documentation is adequate, or do you find yourself relying on outside information to implement unity-specific features?

    Here is an example. Shadows have been difficult to get working "correctly". There are still artifacts/aliasing by the feet even though the rest of the shadow appears to be fine.

    Small things like this are where Unity's documentation falls short. I have to look at Unity's graphics repo on github and try to figure out what they did etc and it's just not fun. It takes a long time and doesn't always work.

    This is without considering applying TAA/MSAA/FXAA (which would fix the aliasing around the player). Also notice the subtle difference in colours. I think Unity achieve this by applying tonal mapping but I'm really not sure (hence why better documentation would really help).

    We actually fixed this problem (this is just a test image from months ago) by using post-processing colour grading and applying MSAA. But I would like to know (from Unity) how to handle cases like this rather than going in blind.

    123.png

    Yet the result is still slightly different (the colour difference is subtle but the result we achieved is less "yellow" than Unity's HDRP). It's possible to do but it's made overtly difficult by the lack of proper documentation imo.

    234.png

    Here is another example where something was more difficult to implement than it should have been due to a lack of documentation (anti-aliasing problems and weird shadow results).

    89.png
     
    Last edited: Sep 24, 2020
  43. BattleAngelAlita

    BattleAngelAlita

    Joined:
    Nov 20, 2016
    Posts:
    246
    Here the game:

    You can say it's just a mobile, but still. Game was closed after 3 week of OBT, but its differently not my fault.

    I start learning SRP-api from very early stage, in late 5.6 or 2017 version of unity. And i learn it by nature method - look at unity early lwrp/hdrp code and try doing something similar. There was 2.5 times we thinking of dropping custom rendering and go back to standard: 1 - 2017 doesn't support shadowmasks, fortunately in 2018 masks support was added. 2 - in 2019 cycle unity decide to remove "Blit Type" setting for all custom SRP's. This cause to everything to become dark on old android+linear lighting. Fortunately i can find hacky solution to force proper blit type. You can check this bug here: Very high contrast and saturation on android build (LWRP). 2.5 - There was some specific order of execution culling to support drawing world space canvas.

    About documentation - It's quite okey-ish. Not good, not terrible. HDRP/URP documentation is much-much worse(basically doesn't exist)
    About support - What do you mean? On the forum unity guys sometimes answers, mostly not.

    Do not understand what do you mean. Just grab all lights, proсes them whatewer you like, and then pass to shader. What a problem?

    And about different from HDRP and your pipe - this is totally not a unity business to document algorithms specific stuff. HDRP use one tonemapper, i use other, you use third. I use 3 different shadow mapping techniques in my pipe, some guys(and i too in new pipe) don't use SRP prowided "DrawShadows" command at all.
     
    Last edited: Sep 27, 2020
    Aviryx likes this.
  44. Aviryx

    Aviryx

    Joined:
    May 30, 2020
    Posts:
    97

    Nice. My problem is grabbing the lights in the first place if you didn't know how to do it. They are unity-specific naming conventions that you need to know and are slightly different to OpenGL graphic calls.

    Whilst I partially agree Unity has no business documenting the underlying algorithms I still think the docs could be improved. Although maybe it could be me as you clearly don't seem to have any major issues.

    However, for me, this process has been painful and taken much longer than it would have if Unity provided some documentation.

    "Just a mobile game" I think mobile games can still be complex and it looks great. It's a shame that it didn't work out for you.
     
    Egad_McDad and sand_lantern like this.
  45. BattleAngelAlita

    BattleAngelAlita

    Joined:
    Nov 20, 2016
    Posts:
    246
    cullingResults.visibleLights return array of all visible lights. Then you can do with this lights what you want. I separate all lights in 3 arrays - point, spot and directional. Sort spots and points by distance, directionals by intensity. Then pass to shader main directional light with most intensity, secondary directional light as fill light(simplify, just n.l calculation), 32 point lights and 32 spot lights.
     
  46. Aviryx

    Aviryx

    Joined:
    May 30, 2020
    Posts:
    97
    The problem is that is an over-simplification of the issue.

    1) The documentation regarding all of this is sparse and "bare minimum"
    2) You completely failed to mention that If you sort or otherwise modify the VisibleLight list then an index remap is required so it's not as simple as just "return array of all visible lights". (Again, this sort of stuff is not well documented in terms of implementation.)

    3) Nothing you have said addresses the myriad of issues I listed previously.

    4) Show me anywhere in the documentation about setting up the view-projection matrix before rendering the skybox (because that documentation for that doesn't exist).

    https://docs.unity3d.com/2020.1/Doc...ering.ScriptableRenderContext.DrawSkybox.html

    context.DrawSkybox(camera)
    context.Submit()

    But there is no mention that you need to setup camera properties before rendering the skybox or you get weird results (or some other method is required). You need to go digging into the documentation (this being under the ScriptableRenderContext class)


    5) Show me where I can find an example of how to implement sorting of common opaque objects. (It doesn't exist!) The only thing is Unity's bare minimum doc page that isn't helpful.

    https://docs.unity3d.com/ScriptReference/Rendering.SortingCriteria.CommonOpaque.html

    Nowhere do they have something like this as an example:

    SortingSettings sortingSettings = new SortingSettings(camera) { criteria = SortingCriteria.CommonOpaque };

    These are fundamental issues with working with the SRP. There are a lot of things either poorly documented, not documented at all, or the information is old.

    I'm not saying it's impossible to work with SRP - just more difficult than it should be 2-3 years into development.

    You appear to agree that the documentation is not good enough too - that is my main complaint. I am tired of having to hunt for info around the internet.

    Surely you would also benefit from improved documentation too? That is all I want from unity. Some better docs on a solution that has been around for 2+ years.
     
    Last edited: Sep 30, 2020
  47. BattleAngelAlita

    BattleAngelAlita

    Joined:
    Nov 20, 2016
    Posts:
    246
    You need a documentation on how to process, copy, sort and pass simple array?:eek:
     
  48. sand_lantern

    sand_lantern

    Joined:
    Sep 15, 2017
    Posts:
    157
    If you could read rather than just trying to show how smart you are, you would have understood it isn't simply processing the array, but understanding what needs done after the processing in order for the graphics to also know what you did.

    It seems like you're hell bent on feeling superior and not even having a reasonable discussion.

    @Aviryx I would suggest moving on from this conversation because it's clear that Battle Angle isn't conversing in good faith and only trying to troll.
     
  49. forestrf

    forestrf

    Joined:
    Aug 28, 2010
    Posts:
    100
    You need documentation?:eek:
    Not everybody knows what you know, has the time to reverse engineer, read others code and analyze how some black box areas work.
    I'm using my own SRP for Genokids. I'm happy with it and what allows me to do. I also lost a lot of time researching what the devs that made the SRP already know but didn't write anywhere.
    Because I hope we can agree SRP is not simple and straightforward with it's many details and corner cases.
     
    Aviryx and sand_lantern like this.
  50. Aviryx

    Aviryx

    Joined:
    May 30, 2020
    Posts:
    97

    lol you either don't understand my point or you are being purposely obtuse. The SRP is clearly in need of a major documentation overhaul.



    Also, I like that you conveniently only replied to one of my points. I will re-iterate, just in case you missed them.

    My whole point is the documentation needs to be better and, in some cases, it doesn't exist at all. How you can be so condescending when we both apparently agree on the core issue (documentation is lacking) is amazing.

    And, for the record, no I don't need documentation just to get the culling results for lights... that was not my point.

    My point was that you left out a ton of information regarding the issue for convenience - suggesting you "just get a list of visible lights" but we both know it's not that simple in every case.

    For example, swapping two light positions in an array and then swapping the indicies in the index before calling cullingResults.SetLightIndexMap (but I am just a lowly peasent who had to learn this information from various places on the internet rather than in the docs so what do I know?)

    The entire issue is that whilst Unity provides examples for a myriad of other things they have seemingly left the SRP in it's most basic state.

    Why not condescendingly ask me if I need documentation (including coded examples and image references) on how to rotate a cube... because Unity thinks it's worth having an example in the docs.

    https://docs.unity3d.com/ScriptReference/Transform.Rotate.html

    Just think about that for a moment.... Unity decided it was worth having a coded example of rotating a cube, but apparently they don't think it's worth giving basic SRP examples/tutorials?

    Yet you seem content to look down on us mere mortals who *scoff* might need documentation for things as complex as.... oh, I don't know. Writing a custom render pipeline for a game engine?

    In any case if you are not going to have an honest discussion than my attempts to convey anything about my experience to you will just be ignored.

    However, I think you should reconsider you position on what you deem to be "unnecessary docs". Surely your own life would be made easier with better documentation?

    And, if so, I don't see what we are disagreeing about.
     
    Last edited: Oct 1, 2020
    neoshaman, OCASM, De-Panther and 3 others like this.
unityunity