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?
@jbooth_1
Rename topic to “URP/HDRP Life”. Don’t blame whole SRP-api just because of 2 unity’s in-house realizations are bad.
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.
Unity’s OWN terrain system are bad. And jbooth making buck from this.
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.
+1
Couldn’t have put it better myself. Hence why I am still using the Standard RP as my daily driver.
Totally forgot about this. No support for decals at all in LWRP
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?
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.
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.
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.
They really should do that.
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.
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.
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.
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…
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.
Outside of Hearthstone, which big budget AAA game has been released with Unity?
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.