Question Adoption Rate for URP/HDRP of projects

It would be great to get some hard stats on how many people are using each render pipeline. Last we heard was about 50% BiRP, 15% HDRP, 35% URP. Any update?

 

It's my statistic (1 year) for the water asset for each pipeline (full price only, without sales)

Spoiler: Image

HDRP ~40%, URP ~31%, Built-in ~28%

 

My numbers for render adapters map more closely to unity's stated numbers from months ago, about 2.5:1 URP vs HDRP, with most people still on built in.

The type of asset can massively bias things, so that's why I'd like some official numbers.

 

A stat like this would only make sense for completed, published games (or about-to-launch), and it would also need a "bucket" for custom RPs. That could be insightful.

Knowing what people are tinkering with, or using for incomplete/unreleased projects isn't helpful and I don't see how Unity would definitively know that (even deep-analytics can't distinguish hobby or student projects).

Asset coverage doesn't help much, as plenty of assets can be easily changed from one RP to another (all models, many non-ShaderGraph shaders).

 

For an asset creator POV, wouldn't it be more useful to poll asset-store customers specifically? If people were say, avoiding URP because of lack of key asset support (for instance), then that wouldn't show up in project/usage numbers.

 

No, any poll I do will cover a very tiny percent of unity users, biased towards my own crowd. This is evident as Kripto and I have very different numbers from our user bases. Unity has hard stats on how many projects are started in each pipeline and have given them in the past. They have pretty extensive analytics about editor usage too..

 

These feel like cherry picked numbers. What is the total adoption rate?

E.G if 2021 LTS is 80% of the sample then the 50% SRPs number in 2022 is almost meaningless.

 

Was this in reply to me or just a side note/addition to your first comment?

With how quick this reply was I'm guessing its unrelated

 

Some numbers from the vegetation engine / atmospheric height fog, mainly open-world type games, top-down, etc
344 votes on February 2023: 19% BiRP, 47% URP, 34% HDRP

BIRP and HDRP are slightly lower compared to June 2022

 

So essentially all the new graphics features in HDRP are targeting 6.25% of the market in 2022.2, and 3.75% of the market in 2021. And at 100% SRP uptake, would peak at about 12.5% of the market if the ratio stays consistent.

 

So would you like them to drop HDRP in favour of 1 pipeline?

 

I would see this changing with coexistence becoming a thing.

For me I would have easily chosen HDRP for my project, but being locked out of Mobile and WebGL made that option impossible.

But if it was reasonable to switch from URP to HDRP and back even with some added work, I would gladly use HDRP as well for my PC releases.

 

You're making a lot of assumptions about what co-existence means, and how easy such a task is. For instance, FBX is a "universal file format" - but internally its just 3 file formats in one file (3dsMax, Maya, Motion Builder). It's quite possible that co-existence means "You can have an HDRP and URP project in the same project, but all materials, shaders, scenes, lights, cameras, etc have to be different for each". So full porting and all the work, without switching between projects. And twice the build times.

I agree though that if it ever becomes easy to run a project in both pipleines we would see higher uptick of HDRP- and those ratio's may change over time for many other reasons as well, so I'm not arguing that these are fixed numbers.

My point is, that based on the current numbers, most of this new graphics tech is being spent on a tiny number of Unity projects. The new water and sky systems look very nice, but very few projects can use them. So to most unity users, those features don't exist. This strengthens the perception that Unity is not moving forward in graphics, because for most users, it's really not - or at least not fast.

Also, as a publisher, HDRP support is not worth my time (it's the hardest to support, and accounts for a tiny percent of the target market - though my ratio is closer to 3:1 than 8:1, but perhaps asset buyers are more likely to run HDRP than non-asset buyers, etc).

I mean it would seem more reasonable to break up compatibility along hardware lines and performance levels than via an arbitrary 2 pipeline split. For instance, in BiRP you had multiple rendering paths available that you could enable/disable (legacy, forward, deferred), which had associated passes generated in the shaders automatically via surface shaders. A modern, scriptable version of this abstraction was another choice, and would have prevented drift between other pipeline features (like Camera background color being different on different SRPs, like WTF). But it's pretty clear Unity is choosing to double down on the SRP split instead.

 

Based on responses today thats not the case, shadergraph supports one shader for multiple pipelines, and blockshaders seems to have the same intent.

The separate scene workflow might provide some challenges but it's clear the goal is to make it as seamless as possible and more so over time.

Question - What's the status of Coexistence? And the impact on features? - Unity Forum

For me it's a promising solution to the problem so far. I'm no stranger to making an effort to make things work on so many platforms as it is, as currently my project works on PC and mobile (and WebGL sometimes), while aiming for as high a visual fidelity as i can manage.

It just needs to be manageable.

 

Still seems a lot like FBX to me - doable, certainly, but not anywhere close to ideal as it puts most of the work on the end user. And engine should solve problems, not create them. And I suspect Unity will loose focus on it long before getting to a smooth workflow. If we consider next steps, it would be having both components on, say, a camera or light instead of having separate scenes, and making things like the light mapper SRP aware so it can store data for each render pipeline separately. To do this right, it slowly leaks out into all kinds of systems across Unity, not just rendering, because these were written like different platforms, not separate rendering paths.

Combine that with DOTS which has a lot of this kind of clunky workflow issues (converters, hybrid game objects, etc) and you're looking at a very non-ideal experience for authoring with lots of loose ends and hoops to jump through. Then add asset bundles, where you are basically self managing the build across two build systems, and now two pipelines, etc, etc. To me, these solutions are all "non-scaling", as they add multipliers to the users work - and rather than solving developer problems, they are creating new ones.

I'd say the ideal case for co-existence is one we already have- switching between forward and deferred rendering. This is quite easy in URP/BiRP and has no ramifications to the end user, despite these requiring fundamentally different shader authoring paths, lighting systems, etc. I don't expect URP/HDRP to get anywhere near that, but a single scalable pipeline would get much closer than what they are likely to achieve, because it would have started with the premise that they are the same instead of being two completely separate platforms.

 

That's why I said "asset-store customers", not "your customers". I inferred that you are trying to assess how much support to provide for each RP, both to cover existing customers, and potentially new/future ones. A Store-wide poll could get to that, without biasing it either towards only a single asset-creator's base, OR the entire ecosystem of projects in-production, which includes non-Store users.

 

Just observation on my part, but the business-models & concerns are critically different between asset-creator and Unity as a whole. The HDRP & custom-RP users, for instance, may represent a low-adoption rate in terms of number of users/projects, or may be over-represented for certain types of assets (realistic vs stylized, terrain tools, etc). But they may well be a significant % of professional, revenue-bearing projects.

Seems like asset creators need to know what % of asset-buyers in their category (models, shaders, terrain, tools, etc) use which RP for support & product-release-cycle purposes. But that info != what Unity likely uses to determine its own support/development resource-allocation.

 

Adoption rate only part of the story; how many still working in Builtin from way back?

 

The pipelines and considerations for rendering are so different I don't consider this that easy.

There's a lot to consider how the rendering features of HDRP affect the image. To me it's far more drastic than the changes from forward to deffered. That is more of a shader issue, but HDRP to URP is a lighting, post processing, amoung other issues.

And if I break it down more a URP scene made for mobile might have entirely different structure than a HDRP scene made for PC. More dynamic lights, things like square lights, more dynamic objects. Things I might not even want loaded in a URP scene things beyond just what LOD can manage.

Then due to those changes the lighting in cinematics may change, exposures need to be configured differently.

ATM for my game I just effectively make a mobile game with a highfidelity coating, but if I switched to HDRP and treated that as a PC only scene structure I'd consider things very differently. Sure you could do this all in one scene, but that may require even more management than a split scene setup. Cause I do quite a bit even with URP alone.

The sort of things I've done to a scene just for raytracing considerations is a lot.

I'm not against the multi scene idea, I just hope the solution becomes more seamless over time. Things like instanced scenes kind of like prefabs may help and such.

 

I think you're only kinda proving my point here - in that running in two SRPs is never going to be simple or as easy as people would like it to be, and that the work required is not being solved by the engine, but rather put on developers instead, increasing complexity in a massive way. It's a shoehorned fix as opposed to an elegant solution to scalability across platforms.

I've worked on projects that shipped on mobile through high end PC before, and generally you work on the best looking version and port down to the lower end platforms. In most cases you're able to do this by subtracting the expensive features, modifying LODs, texture sizes, etc, and the work (while significant) is manageable. And we've seen this done for years in Unity as well.

But working across multiple pipelines adds many new layers of complexity, which IMO are primarily a side effect of the render pipelines being built separately. Had a unified system been built where various models of rendering could be customized, I think having separate scenes would be a last resort kind of case instead of the first option. Features like camera relative rendering, custom passes, etc, would have been done in one way instead of multiple ways. The camera would just be a camera, a light a light, post processing would have been post processing. In each case with various options being disabled or too expensive for certain tiers of performance/platforms. Instead they are being treated as if they are fundamentally different things - but a chromatic adoration post processing shader is not different because it's in HDRP vs URP- these are arbitrary platforms created by unity, not mapped to particular hardware.

I think the primary job of a game engine is to make things not only possible, but easy and scalable. And many of Unity's latest systems feel bolted on to the engine, without enough regard for how much time and complexity they require of developers. Features like SRPs, DOTs with its various hybrid modes and converters, Asset Bundles, which are basically an external build system the developer has to manage, all increase the complexity cost of a project massively, and in some cases providing little benefit to the developer. Most people can't tell the difference between URP and BiRP by looking at a screenshot or by looking at the frame rate.

I think the long term effects of this arbitrary split is that users will request just about every feature from HDRP to run in URP. Why not? It's running on the same hardware, why can't it have water, or volumetric clouds? Camera relative rendering, etc, etc. Unity might take this to mean those features need mobile equivalents, but fundamentally they are right in asking for this - That PC hardware running URP can do all of those things, and very little about HDRP cannot be ported to URP.

But anyway, this is way off topic now- I am happy to have some official numbers from unity.

 

Yes I'm aware of that scaling down process, and often the result is quite ugly and barely performs lol. We've seen the rough ports of Unreal games to switch, and how bad plenty unreal mobile games can perform even on the newest devices

Yeah CA isn't fundamentally different but things like SSR, SSAO, and some other effects certainly can be.

For me I almost canceled my games mobile version before trying URP, it's not like I didn't have to make many considerations and adjustments still. But it was in a much much better state and still is. To me I'm unconvinced a single pipeline is ideal.

And a little workflow to take full advantage to both mobile and PC is worth it for me. It goes beyond the pipeline but also how unity works in general, managing lighting and assets and such.

 

I think the main point you are missing here is that it isn't a 'little' workflow. In simpler projects, sure. In any project that has more specific needs (which is any project trying to push the boundaries a little) then it becomes a nightmare of reinventing the wheel when you really shouldn't have to.

 

I think that's more a fault of the Unreal engine, which has never catered to low end devices as long as it's been around. I've worked on other engines which manage that scale a ton better (even Unity handles it way better than Unreal).

 

My favorite example is that I have to know which render pipeline I'm in and use #ifdef's around those pipelines to set the background color on the camera.

 

Oh i agree it depends on the project. But to me it's like managing a good prefab or scriptable object structure early on to avoid a ton of work later as things scale up.

Here managing a good scene structure can prevent this from being a big problem. But if you're already deep in I can see it being a huge issue.

Keep in mind tho this is just a stepping stone, not the final workflow.

I would think having separate scenes would mean you have to do that less, generally.

 

Not if you want to set something via code. In this case:

- Camera has a Color backgroundColor field.
- In HDRP, camera still has a backgroundColor field, but it's not used.
- In HDRP, when you change the backgroundColor field in the editor, it's under the camera component. But secretly in changes a color property in an HDRP only component added to the camera.

So these things being loaded from different scenes makes no difference here. You still have to:

Code (CSharp):

1. #if _HDRP
2.     cam.GetComponent<HDRPAddativeCameraData>().backgroundColor = color;
3. #else
4.     cam.backgroundColor = color;
5. #endif
6.  

Internally they are both type Color too, so it's totally bonkers..

And don't forget, you now have to manage having the right object pointers for everything in two scenes instead of one. God forbid someone rename, retag, or not set a reference in both.

But anyway, stopgap and all, I still think the end result will be people pushing URP to be the "one true" scalable renderer across pipelines and HDRP being the PC/Console only pipeline.

 

That is very interesting, is about what i see in users of my systems, around 20% ask for URP beta version comparing to my overall sales. And a negligible amount HDRP.

Also have seen many users try the URP and go back to BiRP after see that is not yet anywhere near ready for serious use, for multiple reasons.