That’s not a plan, it’s a habit.
4 Likes
At this point I have to assume they have it written down on a whiteboard somewhere.
4 Likes
In terms of features, I agree, URP could have some brighter features, after all, only its big brother is gaining interesting features (HDRP). Still, I don’t think HDRP is just for ArchiVix, it’s useful for any game. but not for all platforms, and that’s where the URP comes in. (A lot of people forget, but the idea behind the URP is to be compatible with ANY PLATFORM, not any graphic)
And thinking from a graphical point of view, I think of the URP as something scalable from basic to intermediate-advanced. As for HDRP, it’s only good for modern consoles and PCs. (Of course, you could have better graphics in URP or some of the brilliant features of HDRP, but that takes away from the idea that it’s scalable to all hardware, you can release a mobile game that runs on PS5 and WEBGL, and it just works, but still, it would be nice to have some brilliant features in it)
Also, I’m waiting for the DOTS renderer to integrate with the SRP, the performance gain of the SRPs with it should be much more interesting, and remove the CPU performance problem already mentioned here before.
1 Like
We have 3 pipelines and each of them has at least one breaking issue.
Built-in is in maintenance mode.
URP is meh features wise.
HDRP doesn’t support enough platforms.
Unity is the only engine AFAIK with this issue. Other engine that will not be named is able to scale from mobile to PS5 high end, while also having more feature-pizzaz than HDRP
3 Likes
Thing is that’s already been changed. It started to change when LWRP was changed to URP. URP will soon have Forward+ and that means compute shaders to figure out tiled lighting, and at this point we cut out half the mobiles in the world and ES2.0 devices. That’s a change that has to be accepted. It’s also a purely optional one the user can configure.
But wait, there is more. HDRP also broke the rules like this by splitting what HDRP could support with similar rationale and intention: HDRP originally did not support DXR and Raytracing, something that the majority of HDRP devices still don’t have hardware support for.
So URP and HDRP both have quite high device fragmentation. That’s something you can’t avoid and should engineer for and accept from day one. Unity tried to avoid it and failed to do so. Because if they kept avoiding it, they’d bleed customers to other engines.
So both pipelines are already polluted with hardware feature fragmentation. This should not be feared but welcomed or we have an URP that’s too slow and a HDRP that’s too slow. Keeping things all one hardware capability feature set is the death of any modern engine.
There is absolutely no reason why URP can’t have high end features that remain optional, after all that’s exactly what happened with HDRP, and purely optional to enable.
I understand Unity’s engineers shaking their heads at this post, but it’s purely a post about customer rationale, not the challenges of keeping that software healthy, or even the shader permutation hell that they’d burn in.
2 Likes
When I first read about the “scriptable rendering pipeline” concept, I expected something highly modular. Like a menu for every target build with a bunch of checkboxes describing features like transparent surfaces, unlimited lights, DXR etc. For mobile you’d obviously disable many of those entirely and for desktops you’d toggle the features through a graphics-settings menu at runtime.
Then in your code and when designing materials, you’d have to provide fallbacks for when certain features are unticked and the pipeline automatically uses the fallbacks when needed, otherwise providing maximum features.
That would be the dream of usability in terms of scalability and not require to decide for a specific pipeline…
Too bad that appears not to be possible.
It’s in this threat that made me look up that the Unreal Engine actually supports mobile? Always thought they were higher-end machines only. How did they manage the scalability without multiple pipelines?
2 Likes
Extremely poorly.
Guess there is no silverbullet for this kind of problem then…
Garena free fire has some word for you
It’s in a south park episode:
- announce random feature
- ???
- PROFIT!!
But source license. At this point nothing matters, and all conversations become moot. What matters to us as indies is how much work will Unity do for us?
It’s simple.
Unity should have made HDRP into URP instead of making LWRP into URP.
If they did that then we could have had the two ends of the spectrum Unity users really wanted:
-
A super lightweight render pipeline that is built to put your game on glorified spuds. (LWRP)
-
A mid-range to high-end pipeline that is built to scale from Switch-grade hardware to PS5-grade hardware. (URP)
Boom.
Everyone is happy except for maybe some fringe arch-viz and cinema Unity users.
To those people: “Go to Unreal or use Blender.”
drops mic
4 Likes
Nah, I think the solution is for URP to develop faster and get more exciting features sooner.
To do that I suggest they drop support for low to mid end hardware, say mobiles and up to a Switch / Oculus Quest and then we can finally have two pipelines that cover the same exact hardware.
And 2 is obviously better than one.
Soon after Unity does that, Epic, driven by envy, will modify nanite so that every triangle on screen is rendered with a different render pipeline.
It will be the birth of the meta-render-pipeline-pipeline and we will have Unity to thank for it, even though Unity will not make its own equivalent for 30 more decades until they finally give up and buy one from the asset store (that they then continue to sell).
2 Likes
For free!
You, sir, are brilliant.
Mark it on your calendar, people:
01 / 30 / 2022 at 3:12PM (USA - MST)
@AcidArrow suggests that*:*
“[Unity should] drop support for low to mid end hardware, say mobiles and up to a Switch / Oculus Quest and then we can finally have two pipelines that cover the exact same hardware range.”
I believe that this is a prophecy that in the end times Unity will have two pipelines that cover the exact same range of hardware and will have zero interoperability between them.
I further prophesy that there will be a great war between the people on each side.
I call this event: Render-Pipeline-mageddon.
2 Likes
Not quite. URP would still be left without raytracing. In fact let’s be honest. High-Definition means raytracing. Then it all makes sense. The concept of using HDRP and not raytracing is just a fallback at this point.
You would choose HDRP if your fidelity target absolutely benefits from raytracing. Only then, does URP make sense.
2 Likes
Definitely agree with this, particularly with Blender’s Eevee rendering engine these days.
Speaking of which, that’s open source right? I wonder if some crazy bugger could implement Eevee into Unity. That would be hilarious to see.
Yes.
Can’t be done, because Blender is GPL. GPL and proprietary do not mix.
To be more specific, it is not possible to make Eevee a part of unity. You can make Unity talk to blender, though.
2 Likes
Stupid law getting in the way of stuff that could be both hilarious and awesome at the same time.
On topic however, I kinda understand the point of what URP ended up being. If the initial intent was going to be a render pipeline for lower end devices (aka LWRP), that’s quite the smorgasbord of various and somewhat wildly different devices to account for, which, I imagine, would eventually and naturally permutate into a render pipeline focusing on universal compatibility.
I haven’t used HDRP, but from what I’ve seen poking around in the manual, it seems a lot more complicated than URP. Personally I don’t mind having a simpler set of tools, though in the future I hope to learn how to code them myself.
I’m using HDRP for a while now, it is not that scary after you have the properly set up scene.
Especially the exposure and light.
So exposure (automatic) min = -2.5 max = 13
Physically Based Sky Ambient dynamic.
Directional light (affect physically based sky) 100k lux.
But what was problematic was that it is so hard to make scene smoothly darker, still don’t know how to do it properly. I need it for smoothly changing scene from lighter to darker (basement cave etc).
In daylight your other lights like point lights are not going to be be visible, and if you force them to be visible by making them super bright, they will “expolde” with brightness in a dark scene.
That’s kinda the whole point of GPL. To make it unusable with proprietary engines.
1 Like