Well but this is a matter of editor-tooling, not compatibility. Nothing to do with OpenPBR.
I can perfectly see the case of a current graph being upgraded to ShaderGraph2. likely 99% of the node API will be upgradable.
I can see some things that could break, like availability of the depth buffer, or stencil. Or custom rendering / sampling of lights. But this are very specific features that would always have an alternative approach if changed.
Some frag inputs might be packed differently. Or some texture-packing techniques might need to change their approach to conform. But again these are trivial to adjust, and we are talking years of margin.
Well i was worried that you were gonna mention some OpenPBR fundamental breaking difference. Dont think there is one.
Fair point about the 100%, though the points i mentioned (depth, stencil, custom) i did only because they’ve had a history of being troublesome. But don`t really expect them to change if no major URP/HDRP pipeline changes have been announced
This is great news and I’m personally glad that the Unified Renderer is returning. I have advanced character shaders and I would have hated making two versions of the same shaders for two different pipelines (unfortunately, Subsurface Scattering and diffusion only works with hdrp).
Also I hope for Unity 7, things like custom lighting is supported for HDRP and we need the ability to use Amplify shaders in the FX graph… That is one of the few things that drives me insane about Unity.
Open PBR as a standard is likely intended to make sure the two pipelines look similar besides rendering features.
It’s a standard to base the scalability on, not much else. There’s inevitable changes as things like physical light units come to the URP side of the renderer.
EDIT: That said just because of platform differences which is what the selection of pipelines will be based on, i don’t expect all things to be compatible between them.
In my experience URP is much more performant with less effort required optimizing. A BIRP optimized project may not perform as well on URP, but a URP scene runs much better than it would if simply moved to BIRP.
Regardless, there’s not much feature wise on URP you can’t easily get. And the rest can be dealt with if people demand it. Being forced to move on will help move things forward faster.
I do want to point out keeping some expectations in check, while you may not be choosing platforms under the hood you’re still seemingly choosing loops for specific hardware (or graphics settings). I would be surprised if you didn’t need to bake in considerations between these in your shaders. Or if some features only work on the high-definition loop.
I don’t know. I haven’t used Unity in the last two years and I’m hoping to get back up to speed on all of it. The last time I worked in the engine, I had shaders specifically designed for HDRP assets, such as characters.
From what I remember, in order to even get Transmission and Subsurface Scattering to work with URP, you had to take it in the shader. With HDRP, you just turn it on and it worked… mostly.
And I don’t know if RT works with URP, but I know it does with HDRP. I will have to wait and see
You have more faith than I and two years isn’t really that long. I’m afraid I have experienced way too many instances of Unity being dumb and only being caught out by developers who put in considerable time and effort to track down ‘weird’ issues, sometimes on a simple whim that something is wrong!
Two instances that spring to mind would be;
The insane use of InstanceID as a sorting parameter for static batching that was present in Unity 2019 to 2023! However the replacement (sorting by axis) is only marginally better ( but appreciated thanks to the Unity developer for doing that ) in general terms and for specific use-cases could be worse. Far worse than that was they removed the method call to initiate the static batching from Managed to Internal code, preventing some of the better developer solutions from even working!
The incredibly poor code for updating Post-Processing volumes in PPS2, that had huge negative effects on performance, but was not caught until developers dug into the code.
We can already see problems just with the announcement, where initially I and I suspect many/most other developers assumed that it was a true Unified Renderer, like how the BiRP could be considered a unified renderer, but what wee are actually getting is a unified or at least exchangeable data system to allow ‘seemless’ switching between URP & HDRP.
These are very different systems that massively affect ones perception of this new feature once its understood. Granted it might just be the best way forward that we could expect into this decade long debacle, but it doesn’t mean we have to be happy with it.
Finally I think this is probably a good reason why I hate to see the BiRP removed in a future version. For me I see the BiRP as a way to keep unity ‘honest’ in its claims for URP. It provides a means to illustrate and test potential failings in URP/HDRP performance which could not be easily shown in any other way.
For example if a developer updates an old project from BiRP and it lacks the performance of URP, even after implementing changes and best practises for URP then clearly URP is under-performing in some way and needs to be addressed.
On a personal level, I feel like URP or HDRP have become even more of a blackbox than BiRP, which is ironic since I believe most of the code is public. The fact that performance was an ongoing issue for so long and potentially still is, along with the lack of feature parity or ease to replicate features, illustrate this issue.
I used no post-processing at all.
In regards to using a top-down scene, I feel that might be a poor representation since by definition its quite a contrived use-case that likely avoids many potential performance issues for rendering ( ignoring post-processing)
However I must strenuously point out, that my work in this case was not really to profile differences between BiRP and URP, it was instead to examine methods to improve performance in the ‘worse scene test case’ via static batching, mesh-combining, GPU instancing etc. One of those aspects was to try the new SRP Batcher to compare to those older methods. Later the testbed moved into testing more efficient methods of static batching after it was discovered that for years Unity’s static batching was no better than random!
As such while I did spend time and effort to ensure the BiRP and URP render settings matched, I would still like to return to the project and doing some additional due diligence before being 100% happy with my test results. I think off-hand one area that might be an issue is the large number of shadow casting point lights used in the scene and how the different render paths might be affected.
All that said I was super impressed by the staggering performance boost switching to URP Forward Renderer gave the project! The new SRP batcher alone turned 20 fps into 65 fps! This made the deferred rendering in URP result so much more dis-heartening as it DROPPED from 90 fps to 65 fps! These results showed the same relative gains/losses when the scene was switched to static batching and this was tested in both editor and a build.
So its not simply a case of me claiming deferred is slower in URP, its a little more naunced than that, though it is part of the claim. My concern is that where URP forward provides significant gains, URP deferred provides considerable loses. That I feel is a strange situation.
Edit1:
There is clearly one worrying aspect about these results, as all 3 rendering paths for URP provide the same framerate. I’m positive I double checked that the rendering path was switched and went through the overlay annoying duplication of various URP setting references, however it is still a bit too much of a coincidence for me to be happy about.
Edit2:
Oh I remember why my work on this project stalled - due to its nature and wanting to gather as much accurate profiling as possible, I went down a rabbit hole of writing various tools for profiling in builds, custom build scripts to re-use the same scene multiple times but enable/disable different optimizations ( e.g. no static batching, static batching, Material GPU Instancing or not etc), plus adding support for a custom static batching method ( see posts in the thread above by Error-md1).
As is often the case, one rabbit-hole, led to another, then another and so worked stalled. Hopefully I can return to it soon as the original purpose of how to best optimize complex scenes is an interesting one that goes far beyond the basic ‘meshcombine’ or static batching, or even the new GPU Resident stuff.
I don’t think we have enough information yet to know what they’ve done here do we? Last I heard myself it was a fork that’s combining them both and the switching is similar to graphics tiers but you can swap out the entire loop.
I’m very glad to see BiRP go myself; while I’m not building games that have encountered performance problems others seem to run into, I love the gains you can get over BiRP because you can actually turn off most of the features and slim it down to.
Most of the issues I have with it are UX problems that stem from it being a package, and this should go a long way to making that better.
To me this issue is largely irrelevant, since the way URP is performant is very different than BIRP.
I’ve said this before but while you can bring a BIRP optimized scene to URP and it might outperform it, you cannot do the reverse. A URP performant scene isn’t performant in BIRP. And the more features are different the less comparable they become.
But the main issue, is much like when Blender got rid of it’s old internal renderer for Cycles and Eevee, cutting the fat helps move things on. You want faster better progress on these pipelines keeping built in around is just dead weight that keeps getting broken as people complain. This is evident even in 2022.
Yeah, well I think this is why I felt the communication from Unity was, as to be expected, poor. Though in their defensive I guess my statement that you quoted is also poor, as it wasn’t meant to diminish the ‘Unified Rendering Solution’ and certainly not to preclude what you’ve stated about swapping RenderLoops. I guess in my defense, what I stated was the most basic lowest level implementation details that are required in order to implement RenderLoops ( which can I just say I hate that name with a passion! )
The problem I see here though is the granularity and options these RenderLoops apply. Watching the video again this swapping is performed in an inspector named ‘HD Render Pipeline Asset’, which strongly suggests to me that the Unified Rendering is still split between URP & HDRP, but within those you can further and maybe now easily toggle on features. That in itself is great, but doesn’t really resolve the issue that many of us have wanted with a single rendering system as you still have to decide up front which to go with, albeit now with the ‘ability’ to maybe swap between them relatively easily due to the shared data structures and Scalable Lit Shader ( begs the question what about writing other shaders for this system! )
This is interesting, can you give any examples of where you get gains over BiRP because you can turn off a feature as to me nothing springs to mind that BiRP has that can’t be tweaked or disabled vs SRP.
As fior the UX, yes, a thousand times. I cannot express the frustration I had recently when actually using URP for the first time in how dumb the settings were spread out, the duplicate reference in QualitySettings which I eventually surmised was simply a ‘default’ fall back setting to use.
Which is my issue, URP should NOT be less performant than BiRP.
There is no good reason for a like-to-like comparisons coming from BiRP ( the other direction is mute ) should be slower in URP. I mean just look at my results in my above post, where while URP Forward is massively outperforming BiRP Forward by 225%, for Deferred it is massively under-performing by 30%!
Granted maybe the URP shaders are slightly more complex or some other non-obvious additional work is being done in URP, but and this cannot be stressed enough, if the visual end result on screen between URP and BiRP is exactly the same, that level of 30% loss of performance is damning and needs to be addressed.
They have a roadmap thread that’s clearly coming (see Unite 2024 RoadmapUnified Rendering (will become available at a later point)).
The video they showed is pre-alpha, and names of things can’t be read into as indicative of what’s actually in the release. It should hopefully all be clarified in the roadmap thread.
As for what you can disable… I haven’t used built-in for roughly 7 years. The way I felt when working with BiRP was that everything was hard-coded and disabling something involved early exits and stripping, but with SRPs disabling something means the stage is never added and its dependencies are removed. Although it annoyed me to have to re-write stuff to move to Render Graph, it’s only improved on that front.
Also, probably worth mentioning that they’ve mentioned they’ll be releasing Deferred+ in 6.1, which should alleviate any concerns you have with Deferred performance in URP.
I dont’s believe it is, I don’t think like for like comparisons tell the whole story.
In my case because of the way I need to develop my game, optimizations for BIRP would add significant difficulty in development. I would have had to cancel my mobile version cause it simply wouldn’t have been viable.
But since URP is much easier to get performant than BIRP I could continue my mobile version, which is why I’ve been using URP for the last 3+ years.
I think that 30% loss is probably not using the advantages of URP and focusing on that. Things that make development smoother not just performance good.
I think we are talking at cross-purposes here. If my statement that like-to-like deferred performance is 30% less in URP then that presents a baseline that most likely effects everything. The fact that you can use URP features in some such way to gain over BiRP is great, but the likelyhood is you are still leaving up to 30% performance on the table that has never been addressed.
Think of it this way, you invest time in URP features to improve performance of your project by 20%, yet if what I have found is true and Unity could fix it, then by default it is likely that your project could have been 20-30% faster to start with!
Furthermore I guess I haven’t been explicit enough about these tests. These were initially designed to compare between batching systems and strategies. As such the test project had zero additional features, no post-processing, no lightmapping, or baked GI ( might not even had realtimeGI). Minimal use of fancy shaders ( something like 95% standard shaders or whatever the more optimized Lit-shader is called, though this is another aspect I want to dig into to double check in the future ), no optimization beyond batching, so no occlusion etc.
In short this was a test of many gameObjects using relatively low polygon counts, many shared meshes, 90% or more shared materials, but with large number of realtime lights and shadows. I feel this is about as basic a rendering setup as possible that represents typical complexity of geometry and gameobjects in a scene, but with large numbers of realtime lights where deferred rendering should shine. As such it does not make any sense for URP deferred to be at such a low performance.
This is also why if the visual result is the same between URP and BiRP then the performance issue is important! I’m not claiming that URP can’t look better, just the whole point of these tests where to have them look the same for a like-to-like test, yet performance for the same visual result is worse than BIRP.
Thanks I hadn’t seen that thread, i’ll keep on eye on it.
Sorry I thought it was obvious, but the ‘HD Render Pipeline Asset’ is the standard settings asset of HDRP, so it seems clear to me that RenderLoops are a sub-section of the individual SRP being used. Maybe it will be changed and certainly if true it does make it puzzling as to how they will offer switching between SRP’s if RenderLoops are part of that - guess we will have to wait and see.
Hmm, well that doesn’t really help as offhand I can’t think of anything that would need to be explicitly disabled in BiRP that can’t be. That is not to say there isn’t, just all the obvious things like number of pixels lights, per pixel lighting, shadows etc can all be easily tweaked or disabled. That is obviously not true for something like its PostProcessingStack and there might well be new features in URP that one would wish to disable.
I really don’t get why people are have such a hard time grasping what i’m stating about performance degradation in URP ( outside the fact that I still wish to double check and perform more testing ). While improvements are welcomed and it will be interesting to see what Deferred+ offers, if the underlying architecture or some other aspect of URP is artificially handicapping the performance of deferred by potentially 30% that is a problem. If Deferred+ gives 20% more performance over Deferred thats great, but if you lost 30% to start with you are still performing worse overall.
However I feel like i’m having to place far too much emphasis now on the specific performance degradation values rather than my initial point that there might be a degradation issue in general that URP needs to solve and how that can be illustrated by comparing like-to-like with BiRP, hence why I would rather see BiRP stick around for a few versions more. So I wont bang on about this further, especially not until I can confirm my initial findings.
Eh, I think we all follow, there’s just nothing we can reply with that relates directly to your issue. Personally I’d love to test the difference myself to profile it and see where the discrepancy you saw was coming from. If it’s something that could be thrown up on a repo I’d love to test it out. Or if there’s a good description of the scene that would be easy to replicate in an hour or so.
I gave a thumbs up, but it felt wrong not actually replying.
I too would love for others to verify (or refute and improve) my results and will certainly look to publishing what I can, but as its based on Synty assets so that might be difficult. Mind you the ‘Dungeon Pack’ i’m using is in the current Humble Bundle so maybe there is a good chance you or others might have it
However i’ll also be looking to see if it can be replicated without using bought assets. I had a great deal of fun messing with iProcessScene at runtime and for builds while exploring the project, for example you can easily replace every gameobject mesh with a cube mesh without actually affecting the saved scene. This was kind of a cool way to see a scene represented. Point is if the issue is not based purely on the assets in some way, then maybe a repro could be produced without those assets.
