Because with URP you cannot achieve a high level of graphical fidelity because of missing features? Our approach is to make stuff as good looking as possible on the respective platform.
urp is just a starting point, is better to modify it than switch it to another.
1 Like
That’s not the point of the discussion. And it doesn’t matter where you start, converting between different SRPs is currently difficult.
And the main point of the whole idea which is discussed here is to have ONE project / code base with either ONE highly configurable render pipeline or multiple switchable pipelines in co-existance. So basically a scalable solution.
1 Like
URP and HDRP are just starting template, why are you going to switch your project between starting templates? Stick with one and modify it is the right way of using srp. I can’t imagine how horrible the renderer will be if unity doesn’t work on the merging carefully. And cannot imagine how many fallbacks need to write if I want to use multiple render loop. I admit it’s nice to have the same API on both render pipeline, but don’t assume that switching render loops is just as simple as changing the value of a drop-down menu. And don’t assume that everything in HDRP right now will work in what they called “simple render loop”, there are still a lot needs to do. I’m most worried about they will mess up lots of things like unreal did in mobile renderer, for example, a lot of unnecessary things inside the buffers to achieve unified result.
Not sure if you understand what I am saying. I don’t want to switch, I want to use both pipelines for different platforms, and we cannot afford to build ray tracing / SSS / other stuff into URP ourselves, nor do we want to maintain a branch of URP.
Actually we are using both for different platforms right now, but this has to be two different projects / branches because it’s not feasible to have both in one Unity project for now. This is one of the things Unity wants to achieve with the new architecture.
The point where I am with you is that I too see a high risk of failure here. E.g. a new scalable render pipeline which is not good/fast enough for mobile anymore and still lacking advanced rendering features of HDRP. That’s why I am more in favor of the co-existance approach (including unification wherever possible, e.g. RenderGraph API, Screen Space effects / Post Processing, …)
well the script is here
Example: local float end// float data.model end)
im not sure. but okay input graphs.
planning a game development cycle is done by professional studios that have people dedicated to this task. those studios also have the capability to write their own pipeline to match what their game functionality needs to do.
for the rest of game developers, the majority of which we are part off, we basically start messing around with no planning, make it look as amazing as we can, try to export to some platform, it doesn’t work because we have added 1 billion polygons and 500 different Ik rigs. Try to convert, is a mess because assets use custom shaders, who knows how to write those for a new platform? Each step, trying to cut your way in the amazon jungle using a rusted machete, hoping to arrive to Chile from Brazil.
Unity could split the user base in the average dev joe that imports bunch of stuff in the engine and the exporting and assetts authoring is done behind scenes automatically. In godot they have this “export to platform” menu, that doesn’t convert you project like in unity. You just click on what platform you want to export and it does this. Unity could do something like this and then if you really want to get deep inside and start configuring stuff and optimize everything yourself you can do it. There are some parts where this logic is applied in unity so is nothing revolutionary.
But is difficult to say if this is a good idea or not. Dumb down the software while also have a complex system available? Can this work?
I would very much prefer to see a single rendering pipeline with a selection of renderer features (as the pipelines already have today) that one can optionally add as needed in order to scale all the way from simple to complex. If we don’t need some stuff, then we don’t add renderer features for it. You guys have already built this kind of scalability into URP - why isn’t HDRP just “urp with lots of extra stuff turned on”?
The split between separate pipelines has been disastrous for publishing and consuming 3rd party assets. Some things work in only one or the other or in neither, etc. A single, unified pipeline that can be infinitely scaled according to needs sounds way cleaner and better for everyone.
6 Likes
The excuse for HDRP separation from URP was mostly about HDRP using compute shaders, so I can see that if they are everywhere there is little need for 2 pipelines… So depends on mobile I guess.
But customisation is so limited - you have to mod the URP package to change lighting - this must be a priority. Not all games are super realistic in style but at least in HDRP this has been a big focus, even in URP the major change in lighting calculations made it realism focused.
Isn’t block shaders just like nodes with custom scripting elements? Like you could still author a shader in Shaderlab.
That and GPU differences.
There’s a reason so few water and sky assets work on mobile, it seems it’s not just compute compatibility.
this is reflected in the naming for the unified pipelines being focused on GPU type.
2 Likes
Generic solution can never beat specialized solution. It’s a trade-off Unity has to do as a generic game engine.
My guess is that, Unified RP will not be quite as fast and lean as URP. It probably can offer the full capabilities of HDRP but with some caveat and limitations that has not been there before. just something in between… I hope they make it worth it. And I hope I’m proven wrong 
How exactly will the unifying be done?
Does it mean that URP and HDRP will be deprecated in the future?
1 Like
It will be roughly URP and HDRP under the hood but seamlessly usable.
Multiple??
Interesting. It’s the first time I see something like this mentioned.
The whole idea of the SRP is to allow users to do exactly that. Switch features and options on and off to fully customize your rendering for ultimate, specialized optimization.
Built In was very limited in that respect. But to be replaced with a dual system was a mistake.
The new system should have the options of URP and HDRP under one hood. And that is what the unified approach will try to fix in two years’ time.
It is too late for all those users that Unity lost to Unreal. And sadly, it is going to lose more when the unified approach comes because after so many years, people who have spent years to master one approach do not like starting from scratch. And at that point it is like opening a window of choice for them.
Either learn a new thing in Unity from scratch or learn a new thing in a different engine from scratch. And that is where, if one is not satisfied, (especially after so many years of blunders) will more easily consider switching.
And in that sense, it is best they base the unified approach on HDRP instead of URP it is definitely more complete, and I suspect more people were using HDRP than URP all these years, but I may be wrong.
1 Like
Most small developer projects yes.
But prestigious big studio projects that are multiplatform would greatly benefit from that. Even if you save 20-30% production time it is a significant boost.
Tbf current HDRP suck ass. If unified will fix its core problems i am ok with it
It sounds like every rendering function will need to be implemented three times with compute shader base, fragment shader base and fragment shader without structBuffer. And every renderGraph will be designed with parallelism and vertical on tile in mind. It is difficult.
But I long awaited the unified material, light assets workflow for SRP. Unified asset with multi SRP is best for me…