Tbf, both tessellation (Water) and raymarched volumetrics (Clouds) are pretty expensive, sometimes even more performance heavy than raytracing.
Don’t see much point in not using HDRP at this point…
I can only speak for UE cause i work with it’s rendering module. And is not half of it’s features. All it’s features works on mobile (if the hardware has proper compute support and drivers). But if the hardware fails to support them, it will disable them and use fallback rendering features on mobile. That’s the real culprit, mobile driver support. And for that same reason some features are disabled (that you can enable btw if you mod the sources, at your own risk). The same could be said about HDRP, it doesn’t work on mobile for the same exact reasons. Lack of proper driver/ graphics API support.
The way you can see UE rendering pipeline, is like this: Imagine HDRP and URP merged together, but using the same fundational systems (eg, they also have implemented Render Dependency Graph and works very similarly to the one Unity implemented), where it has a predefined settings per platforms. So you can have the same game, with the same lights, materials etc setup with high end graphics on consoles but for mobile or nintendo switch it can be setup with a clustered forward renderer. You can switch pipelines and preview them in editor with 2 clicks and this is the beauty of one pipeline.
Even when writing RenderGraph code, you don’t need to care about where it’s going to run as Gbuffer has the same exact layout for all renderers (which btw is just deferred and clustered forward). Data is mapped from CPP graphs struct → HLSL the same exact way, even when targetting a toaster. Now try that with HDRP + URP, gud luck! 
While Unity folks are now trying to unify pipelines to fix fragmentation, UE folks are way ahead doing nanite/lumen optimizations for mobile or trying the next big graphic thing for high end.
Lastly, I don’t want to look like im bashing the work Unity graphics folks are doing. I do recognize they are doing the necessary to improve and unifying pipelines and that’s a great step forward. I still use Unity on my personal project so im also very interested in having an unified workflow that scales top to bottom and I truly wish them the very best to achieve that.
9 Likes
If you meant people forking URP versions and adding missing features. I know a couple of them. jk hehe
I have yet to get up to speed with Unity RenderGraph implementation, but the one made by Epic, is great. They actually rewrote their deferred/forward renderers with RDG. Proof of concept! :V
Those assets are regularly not compatible with mobile as people tend to do them, hence why. It’s a challenge clearly. It’s not that URP will never get it, but clearly it’s easier to make it just for PC first. It’s not just that it’s a clear line it’s also the burden of optimizing and compatibility is shifted.
It’s that you might build a game around a feature, then suddenly find out it doesn’t work in build. And possibly, even if it doesn’t work in build you’ll likely still have those shaders in the build.
When water and sky comes to URP I know it will work on everything (assuming the device is not entirely shit). There isn’t a setting or toggle to make it work in build it will just work.
I mean it’s not just raytracing, it’s also stuff like mesh shaders, or other tech. There’s many things it took a long time to reach mobile that’s not just performance related, even seemingly basic stuff like compute shaders is still flakey.
Plenty of things that would be bad to build a game around, and then find out it won’t work on mobile at all. IMO these things should be created with platform intent from the start.
I’m not sure that’s always the case, for example as far I’m aware the water system doesn’t work on mobile at least the UE5 version. There’s no real fall-back solution, nor a guide for making it work on mobile if it does work or is intended to work.
But lighting wise yes that’s true.
But based on some switch releases it doesn’t seem “that” seamless even if it works lol. But maybe that just shows lack of intent from the beginning from the devs in those cases.
The problem with the water system on mobile it the same as with HDRP, it has many compute based components such as the physics and the fluids simulation. But they are working on a fallback solution for mobile.
This is a top priority for us, I expect we get this done soon.
9 Likes
To me, this is the next big step forward for HDRP/URP unification.
3 Likes
Thanks for this (the OP post I mean). This subject particularly resonates with me because I have been working on high end projects but a major chunk of my income comes from sales on Nintendo Switch. Often I build in URP with add ons and tricks to try and pull off more high end effects (for example the limited number of cubemaps per object, I make all of my reflection probes change priority based on their distance from the camera, lots of little smoke and mirrors tricks to work around limitations) but it’d be really nice to be able to make full use of HDRP and then create a URP ‘port’ afterwards without having to redo everything.
Unlike a lot of the commenters here I believe the two separate pipelines to be a good thing. It’s nice to be working on something knowing everything in it will be fully compatible with Switch, mobile VR etc., it’s nice having that choice. I’ve worked in Unreal and it is very cool, but you have to compromise a lot for Switch or mobile and be very careful building for those platforms, whereas with URP you can really push it because of its optimisation.
So really, more… shall we say… Unity… between the two pipelines would be a really nice thing to have, and I appreciate all these updates making the porting process easier.
1 Like
This is so ironic considering that you haven’t even worked in HDRP.
I have not worked on 10 pipelines, but I am sure that 10 pipelines is good thing. 
I don’t understand how it happened that Unity created three different pipelines and turned from a simple engine into a monster with three different documentations, APIs, shaders, GUI, etc.
And people developing for the simplest platforms are happy about this. The more difficult and worse, the better?
Mobile game developers are glad that they have been allocated a small sandbox (URP). But they are still in a huge landfill, to which a lot of garbage is constantly being added.
1 Like
Your first paragraph contradicts your second one. You want high end features from HDRP but you are OK with two separate pipelines? That’s exactly why HDRP can’t be easily ported to URP, cause they are very different. Just take a look at the amount of different ways you can create renderpasses in both pipelines.
You know why this thread exist right? Unity folks are trying to fix the fragmentation issues within rendering pipelines. 
That’s right, in 22LTS, we basically have 4 different types of render passes (urp internal, urp custom: ScriptableRenderPass, hdrp internal=RenderGraph, hdrp custom: CustomPass). To unify the render pipeline implementation and the extensibility, we’ve adopted RenderGraph in URP internally and in the URP extension API. So in U6 we go from 4 to 2. And the next step is to adopt RenderGraph in the HDRP extensibility API to get to a single render pass definition.
4 Likes
It’s interesting to see the discussion here, we’ve had hundreds of these over the years. The big challenge is to find that sweetspot of fragmentation versus unification, to not have a lowest common denominator solution, while standardizing the workflows and features as much as possible. The SRP vision started from a very relevant and good place. But due to specific circumstances the fragmentation went beyond what brings value. I wrote a brief post mortem here . Some of this fragmentation reduces your user experience, and it’s also very costly for us. Some however brings value, which is what is described in this thread as well.
2 Likes
I’ve surprisingly never read this, but much of whats there is where I thought you guys were going/ or were thinking. Just based on general behavior.
1 Like
A pipeline for low end is very different from high end indeed. We’ve started to use the term Render Loop internally for the set of render passes that combine the core renderer and features for a specific platform. Such a render loop can have very different frame resources and data, ie the render textures that are generated to build the frame. Which impacts the injection points that we can or should expose to extend the render loop. If we want to get the most out of a platform/devices, there are going to be differences here.
That’s the key thing indeed. Even if we have different Render Loops, everything around that should look and feel the same, same extension APIs (but not necessarily all same injection points), same light data, same workflows, etc. But not necessarily have all features on every Render Loop.
1 Like
100%… makes sense
@AljoshaD ,
I get it, it’s not an easy task to have HDRP and URP under the same renderloop since they are very different (in part due to how far away both pipelines diverged and specialized). But to an user stand point, it should indeed feel the same (ie creating custom render passes or setting up light/materials).
This is the wonderful experience UE allows end users to have, whenever you are targeting Nintendo Switch or PS5, one one light, one material, one way to write render passes, the engine take care of the rest.
Ultimately, you must find a way to make shaders authored with SG work when changing pipelines. For example, URP Lit, will become the default Lit under HDRP. If moving from HDRP to URP and the shader was using a shading model not available in URP, then the master node input pins will grey out (it will discard anything that is not supported, only take into account supported/available shading model inputs).
Some of those suggestions might already be solved (or are being solved), pardon me if that’s the case, im kinda out of touch a bit with Unity rendering stuff since i started working with UE last year.
But again, we do appreciate all the hard work you guys are putting to reduce fragmentation and to bring unification of pipelines.
2 Likes
It’s like that since version 2021 or so when they introduced shader graph targets
What I meant is that a shader must be authored once, not twice. We have many nodes that aren’t compatible/usable when switching pipelines, others that behave very differently. This is an other side effect of multiple pipelines/fragmentation. Hence, why I suggested “ultimately”, since we are far from it.
that was interesting to read…
sorry, can you explain why you have that idea/suggestion? i don’t understand, sounds pointless (english is not my main lenguage, so maybe is that XD)
Ideally, not having to add additional setups or nodes/conditions when authoring shaders, they should work under all pipelines. Same for lights/materials, not having to tweak lights or materials when swapping pipelines/platforms.
But I’m not speaking for current state of unification of pipelines. It’s my vision of the ideal workflow for the future given existing constrain (keep two pipelines under the hood). Even if we keep two render loops and two pipelines, they should feel as one for the user. One shader, one light, one material, etc. The engine should swap shading models/render features depending on what pipeline is active.
1 Like