Official What is next for us at Unity with Scriptable Render Pipelines

A single renderer makes the most sense. I used to agree with the idea of URP, but years later, I don't.

Games like Dragon Raja (UE4) and Genshin Impact (Unity built-in) are what mobile games look like at this point. So what renderer do I use for a mobile game that will also release on PC? Or a PC game that will also be released on mobile? HDRP cannot do either, and URP cannot meet people's expectations of modern PC graphics. Built-in is also past the point of being able to look like a modern PC game (non-physical lighting/materials, no volumetrics, etc).

URP replacing Built-in is a strange concept, because built-in was never meant to be a lesser renderer. By choosing URP, you're mentally accepting that you don't want top-end graphics. That's not what you were accepting when using built-in in 2017 - you were using the best visuals Unity currently offered, and could easily scale down to mobile.

URP can someday replace Built-in from technical point of view, but not the use case, therefore, it's not a replacement. And that's only because built-in has been abandoned. Built-in would be far ahead of URP if they had continued to update it with better lighting/volumetrics, etc.

Built-in was never meant to be a lesser renderer. It was meant to have the latest tech that it was possible to support. Until URP commits to that, it will never be a capable replacement, and remember it will take them years starting from this point. For example, Auto-exposure is only still "planned".

I'm curious as to why anyone would use URP over Built-in. Is performance meaningfully better? Or because there was no Shader Graph (at that time) or VFX Graph? Or maybe you're a technical artist that needed some access to the render pipeline to achieve something that was impossible?

On another note, Unity also need to focus on the quality of their tools. Probuilder/Bolt integrations and feature sets are poor and the terrain upgrade was some kind of april fools joke. UE4/5's modelling tool plugin is the kind of quality we need.

 

There were fundamental technical limit to builtin which is why they abandon it. First lighting is a huge issue and expensive in builtin (one pass per light) which destroy fillrates, srp were made to avoid that.

 

Valve already fixed that and even made the source code available freely on the store back when SteamVR was first released.
Unity only had to implement the solution internally, but they didn't.
They have the means but not the will.

 

But does it work on 70+ platform?

 

Isn't that why we have deferred rendering? It's nice that URP can render multiple light in one pass, but seems like there are some margins until weaker device can take advantage of said feature compared to the built in. Like when you don't actually need to have more than one or two lights in the scene, then it's actually defeating the purpose where URP seems most likely running slower.

Agree, URP and other Scriptable Pipelines should be optional, not everyone has the skill/time/will to play around with those. It's nice to have those so people with extra time and enough knowledge could play around with them, but for those who want to focus on the game itself, BiRP should be just fine.

 

URP is perfectly capable of high end graphics, it's just that it's not quite there out of the box. It might not be top end like HDRP but if you're targeting mobile that's likely not viable anyway. For me I have visual pairity (better really) with built in with the exception of NGSS. And much better performance on mobile personally. Even using it isn't much different than built in. But I had to buy some assets to do so just to get some effects unity hasn't provided yet.

We're pretty much near feature pairity with built in at this point so there's no real issue. Just some additional performance improvements needed, which will likely come now the stuff is there.

And then maybe we'll start seeing new stuff soon, and things like HDR display support again.

I imagine BiRP will be fully obsolete in a couple years.

 

For me personally it's significantly faster, took my game from barely 20fps to 60fps. But that's because I couldn't optimize the way BiRP needs you to, minimize materials and objects.

SRP batcher alone is worth it to not have to need that optimization. And makes development smoother not having to worry about it.

My parsonal experience with vulkan on mobile is awful, it would crash if the game reached above 1gb if ram.

 

Also applies to Vulkan. The thing about these things is... if someone is on an ancient non-bug-fixed version they will believe passionately it will always be like that. It's how humans are, mostly.

 

Is there some version issue? For me the issue has existed since 2019 and I'm on 2021.2 now. I thought I was just an optimization issue until someone suggested vulkan might be the problem.

 

Yes, but built-in stopped getting meaningful updates in ~2017, so URP is only matching the graphics quality of 2017. I would say the last decent updates to built-in were motion vectors and temporal AA. So I wouldn't say it's "perfectly capable of high end graphics". It comes down to opinion, but for me, "high end graphics" is the rendering quality that modern games release with or a step below. It's more than a few steps below. Without HDRP-type lighting/shading (I don't know what it's doing technically) you can't achieve that, unless you're game is stylized or non-first-person so it doesn't matter. At least it does have inverse square light falloff.

 

I think you can just fine, much like with BiRP for years half the problem with that "unity game look" is people not knowing how to use it. Or being unwilling to make custom stuff with like amplify shader. At least compared to games like Judgement, Halo Infinite, and plenty of other modern games. It's not bleeding edge but thats also not the point.

And ofcourse you wouldn't get HDRP type lighting/shading on mobile, but thats the point right? if you want to jump between the two that much i understand, HDRP is very different from BiRP and URP. But I don't understand why someone would complain HDRP doesn't work on mobile when even URP can be a challenge depending.

The most I expect to come from HDRP is features like DLSS, more post process effects (Native TAA, SSR, Auto Exposure solutions instead of asset store need), and hell maybe even raytracing cause why not and maybe that won't screw mobile madly .

 

A game engine should be providing most of that for you. I don't think we should be creating a custom renderer to get a character to show behind a building, even if they have an easy way to do it.

But Unreal Engine 4/5 scale to mobile, so I don't see the problem with Unity just having an HDRP that can scale down. For me, it should replace URP so we can have one pipeline again. When targeting mobile you should be able to disable whatever won't work.

And mobile is constantly evolving. Every 6 months you can get a faster phone for the same price you paid 6 months ago.

 

I don't exactly see why it should, it should provide core function and tools to make what you need, rendering methods for games are vast. Unity doesn't need to make a template for every possible rendering style/method. For example one thing I like over UE4 is access to lighting data in the shader.

Even a character seen behind a building has a lot of nuance behind it.

I can't think of anything i would consider HDRP quality on other platforms that was ported to mobile. URP quality sure, but not HDRP quality. And even the UE4 games that exist on mobile don't really perform that well in my experience which is currently a Note 10+.

And it's not just disabling what won't work, I'm pretty sure the foundational structure has a lot to do with it too. The needs of the architecture are different not just the processing power. There's a bunch in HDRP like even light source types that I'm pretty sure just aren't feasible for mobile at all.

 

It would've been a lot simpler to make BIRP slightly modular.
Eg: Expose all rendering passes (so we can remove/change them at will), add a simple API to inject rendering passes or just let us do it manually with command buffers. This would've avoided all together the 3 pipeline fragmentation or the lets recreate BIRP features in SRP through 7 years...

 

Let's not forget CRP in the discussion though, the expensive but liberating solution

 

That's exactly why they started the SRP, because the monolithic structure of BiRP didn't allow that, they had to rewrite from scratch.

 

Unity's goal is to sunset Built-In and replace it with an eventual feature-complete URP. As that's an inevitable step what we should do is support URP - but highlight what would really make it work for us. At some point Built-In will be causing more problems for Unity as it won't get new features.

Customers will want it to work on a new console's features or support a new GPU feature and - huh - it won't. That's going to happen. Anything that's technically a feature is not going to go to Built-In is it?

Shadergraph support was only for the eventual migration to URP/HDRP.

 

Build in works for ps5 I think?

And BIRB is more than just the renderer, for example unity tree creator trees are not supported on URP so if your game uses them you are stuck.

 

Yeah they really need to work on that, it's still a perfectly fine tool that literally just needs a shader made for it. And the shader already exists cause Lux Render made one. Just tree creator keeps swapping to the default for some damn reason.

I assume that asset is old and no one knows how it works anymore. But at least change the default shader...

Like it should be very very very simple.

 

Yeah I mean new features based on the hardware or platform. For example DLSS or raytracing on a PS5. Spacewarp on URP and so on. Basically, Built-In is a complete liability, and all Unity needs to do is really pump some performance into URP.

Then everyone is happy.

 

The reason they started the SRP is to allow people easily create custom renderers because no one has access to BIRP render passes. Also to offload some of the C++ rendering tasks to the C# side. Where BIRP is entirely C++ side, SRP rendering passes are defined in C#.
I still believe, they should've pushed for exposing BIRP passes and allow people to create new ones using command buffers while they try to re-create BIRP feature set in URP. How long since LWRP/URP is trying to be feature set? Six-seven years now? And what is the result? Similar performance at worse with less features, new bugs and regressions, 3 render pipelines, forcing everyone write shaders with grapths...
I would call that very monolithic design indeed.

 

Considering how long it took to get URP to get parity I feel like focusing on exposing BIRP wouldn't have yielded better results. It would have just extended URP development and HDRP development. And I probably would have canceled the android version of my game as simply not viable.

BiRP is probably great for what it is cause they stopped touching it, I imagine if they tried messing with it we'd have a similar scenario to current URP with less potential benefits in the long term. If they figure out some of the current issues plaguing performance in some cases it's clear URP will be an ideal replacement.

URP only JUST reach parity, imo it's not surprising there's room for improvement.

 

I've worked with OpenGL renderers in the past and exposing render passes is a lot easier than re-creating entire render pipelines from scratch. Sure, BIRP is legacy code, compiling C++ takes ages, you have to exit the editor, re-open it, etc and prob no body want to touch it. I get it but today they still have to maintain it on new platforms and consoles because the majority of users still on BIRP for obvious reasons.
Unity devs argue that SRP is modern, but I don't see anything modern in URP, other than the SRP Batcher. URP still trying to catch up feature parity with BIRP today and performance is questionable.

Few huge benefits to expose all BIRP render passes:
- Allows users to develop new render passes (or replace the BIRP ones)
- In the backend, Unity could've developed the SRP Batcher to be compatible with BIRP
- The most important one, avoid fragmenting the Asset Store and Unity art pipeline ecosystem

This would've allow people to customize the pipeline (thus maintaining compatibility with current assets) while Unity cook some secret sauce behind the curtains (like Epic Games did with Nanite and Lumen). Most of the effort now is put to re-create BIRP features and hope to be at least equally fast so people might jump in. But that's the issue, if there's no incentive to jump in, no one will do it. You have to see crazy amount of performance speed to justify the move from BIRP to URP. And is not there, is actually worse than before.

Lastly, keep in mind that BIRP still being used today to publish very big mobile games (Genshin Impact, Call of Duty mobile, etc) and before that there was many others games made for mobile on BIRP, big and small. I also published games with real-time lighting and shadows to mobile and it was purely BIRP based, in 2015. You can check the videos in my signature. That game was running smoothly on iPhone4S devices back in the day.

Thing is, 6-7 years later, are we in a better position than before SRP? I don't think so. Maybe in the future when Unity is fully optimized on DOTS, when the new HybridRenderer is fully integrated and running behind GOs, when everyone dropped BIRP, when there's no trace of BIRP in the Asset Store, etc. Perhaps, it will make more sense. Not today.

 

You can do raytracing with built-in, you just have to write all the shaders yourself. Someone even made an asset for it: https://assetstore.unity.com/packag...rp-forward-deferred-urp-vr-spi-support-184088


You are also forgetting about tons of long-lived mobile games which are forced to upgrade to newer Unity versions to continue working at all on new versions of iOS and Android. Migrating a mature built-in project to URP is a hellish nightmare bordering a full rewrite. All surfaces shaders become unusable, several features have no direct URP equivalent (grabpass, replacement shaders, several graphics injection points, material property blocks, of the top of my head) and may never have due to architectural differences/limitations. Even light behaves quite differently and requires environment artists to relight every scene.

There are also features which are implemented in the Unity C++ side which are deeply woven into built-in doing things like looking up shaders and passes by name or setting magic shader properties, which are still MIA in SRPs and may never make it, like terrain billboard details and tree creator. If your game relies on those you'll have a hard time moving to URP.

So Unity is sitting on a time bomb with this whole "built-in will be removed" situation. Maybe they expect everyone who's still operating a mobile game using built-in by 2024 to have the money to spend a man-year or more rewriting all their graphics stack and do over all their scenes lighting, or purchase the Unity source code so they can make whatever version that works for them compatible with Apple's and Google's latest whims.

 

Well that'd be a problem of Unity's own making, I think. On one hand Unity wants to replace Built-In long term but on the other they can't. What this does mean though is even if Built-In sticks around for yeas, it will still be the worst choice for devs beginning a game today.

All it will mean is more work to support any latest thing. And I think, that's not why we use Unity.

They definitely have source licenses and can build anything they want and support anything they want, so they're not good examples of why to keep built-in around. I know Genshin already modified the source for that.

 

I think Unity should stop wasting their time trying to make a "smooth upgrade path" from BiRP to URP.

It's pretty obvious any REAL game is never going to have a smooth upgrade. So why are they building Shader Graph for Built-in, hmm? Furthermore, why on earth would a game want to upgrade to URP other than for the not-always-true promise of better performance than BiRP?

Maybe Raytracing support, a good RT GI, and A.I. Upsampling would entice people to use URP — the "modern" pipeline?
Wait, what? It doesn't have those things?

Okay. Well maybe "better performance" will be enough to make users happy?
Hmm? It doesn't have that either?

What about a giant roll-eyes emoji? Does it at least come with that?

Nope.

 

God knows. Hope nobody sees me as a fanboy here because I'm not being a fanboy, just realistic. I don't see the logical path where Unity goes back to Built-In.

I think really, the turning point will come with features that most regular developers don't have the budget or experience or staff to implement new features. That's what pushes people to SRP.

I think URP is basically getting ready for some really big hitters. Hybrid rendering and Forward+ don't sound like small potatoes to me.

This will mean Built-In kind of still will be faster for the very low end (LWRP is dead, after all) and URP will end up running a lot faster and looking a lot better. At least I suspect a well-made F+ and hybrid renderer to feed it will result in that.

 

This is way too much work and way too messy to make a vert frag shader work properly in URP though.

And it's not even upgrading an existing project that worries me. Losing the ability to write simple vert / frag shaders quickly and easily is a big hit for me, and not even the "new surface shaders" or whatever can fill this gap.

Maybe with Hybrid and Forward+ they can get performance up there (in... 2 years at least?), I don't know, it still seems totally unexciting to me.

As we've summed up in this thread, the only modern and exciting parts of URP are the SRP batcher and the Visual FX graph. Everything else is just repackaged 20+ year old tech that people just think is new, because they've been using Unity for too long and don't know any better.

 

But most vert frag shaders should just work in URP without the fluff. Try making an unlit shader. That's vert/frag historically. Built-In and SRP can have those shaders work on both and they're tiny.

It's all the lighting and everything else that's hard to change. Unity mentioned they're doing some kind of blocks thing where you determine what each block or stage will do. Time will tell. I don't know if I will be in the old people's home first or not though.

 

They work easily if you don’t want the SRP batcher to work with them, at which point you will have terrible performance. If you want them to work with the SRP batcher, then watch the video.

 

Well, there's few reasons why they would need Unity sources. You can speed up BIRP by doing couple of changes. First is to having access to how framebuffers are setup, when exactly they are cleared, how they are binded, to have more control how to set them up, keep them alive and resolve depth maybe after forward pass. Or feed all light/shadows data to the forward base pass to make it a single-pass multi-light forward renderer. Implement a proper depth pre-pass in the forward renderer (usefull to fight overdraw in large open worlds), etc. These changes are way faster (even if you had to dig C++ BIRP renderer sources) than writing entire render pipelines from scratch or even adopt a new render pipeline.
That is, a blind guess, maybe they needed sources for something more or something else.
What about Rust from Facepunch? Another large open world game made with Unity BIRP. They adopted HDRP then went back to BIRP a year later because performance issues.
My point is simple, if both HDRP and URP aren't ready for real production (slow, lack of features, buggy, etc) they shouldn't advertise it or push people to use it and keep improving/supporting BIRP in parallel. Because this makes the transition to SRP slow and painful and worse of all, extend the fragmentation period a lot longer which is bad for absolute everybody, including Unity itself.

 

Thing is HDRP was really quite fast in the early versions. I was able to get 4k running (with it's older shadows and old upscale) on an imac (with bootcamp) and equivalent PC from 2014 at 60fps. So the cheat was upscaling, sure,. but everything else was running pretty fast. Both computers had haswell 4770 CPUs which have only 4 cores. Seems that since, then it's got progressively slower to the point devs have to switch away from it again.

That's probably the problem facepunch had. The Unity Factor. They keep slowing stuff down over time. I know this is for sure for my own situation since my own (old) game no longer has run at that framerate ever since.

Then enlighten got removed and I gave up, moved to URP, hoping it would be better. I think one possible factor is that Unity changed the purpose of HDRP and URP as time went by.

 

I dunno, I've seen pretty opposite of that on my end. HDPR has constantly gotten faster and would be interesting to know which HDRP version they used on Rust because last few versions have had some major perf improvements (so it's also possible they simply dropped HDRP too soon). But if just having a raw performance as major reason to swap from built-in to HDRP... that's not going to end well.

I don't even know why people are so obsessed with these performance comparisons alone, there's a lot more into the rendering than just raw performance. Also would want to note that newer rendering architectures have always added more overhead, making the thing run worse especially on weaker hardware. There's nothing new here except I guess if you are a seasoned Unity developer, you've been so used to built-in renderer staying architecturally same for past decade so any change is going to be viewed as negative.

If you look around and see what has pretty much happened on every other game engine's renderers when they've upgraded them is the same: it pretty much always perform "worse" than the previous iteration, especially when you insist running it on ancient toasters. But the thing here is that even with the added overhead in renderers, our hardware has also evolved in past decade, being more capable on running more complicated things. If the renderers didn't evolve at all in past decade, we all would be just looking at CS level rendering and be amazed by 300 fps in each game and everyone would be happy since well... we got nice performance still.

 

100% sure HDRP is much slower for me, than it used to be. Perhaps their focus changed toward movies and future tech? I think so. It will barely run on PS4 these days while before it was acceptable.

Render graphs, changed shadow code, etc. DXR and so forth. I have no idea how you possibly figure it's faster - because you can't even access the old shadow code now.

 

Because performance is what drives innovation in art direction and design.
When you add new rendering techniques that implies new overheads the trade off is always scaling. You won't run on older hardware but exploit new hardware better. For example, UE5 with nanite and lumen. Won't work (or perform poor) on old hardware but on recent hardware will put billions of triangles on the screen with dynamic global illumination and frametimes will remain stable.
With Unity is just regression over regression without anything scaling, mostly slowing down on each major version. For example, both URP and BIRP in 2021.2 runs slower than URP and BIRP in 2019. I ported URP 7.7 to 2021.2 and it was also slower.

[EDIT] Bonus: shader compilation (any kind of shader) is also 5-10x slower in 2021.2.

 

Well, the current UE5 renderer supports UE4 version plus the new nanite and lumens stuff. You get to pick instead of them just going "OK guys, here's the future now F*** the past". Now I can't do this and support modern hw at all. Because to do that I'd need something like 2017-18. And the problem with that version is that it's fast but filled with bugs, which were fixed but the goal posts of perf also moved.

Sometimes games take 5 years to make. That's the same engine in UE5 but quite a bit different in Unity. I'm going to just have to agree with tato on most things.

It's just indicative of how Unity runs things.

 

Waiting for Unity to implement some new feature that our W.I.P game need is the biggest mistake we can make.
I did this in the past multiple times and every time got punched really badly in the face. But I've learned from these mistakes.
The important thing to keep in mind if you work with Unity is to design your game around features that are stable and work. Forget about "performance by default" or "we will make this run fast" or "once Unity runs fully on DOTS we will have free unicorns".
Unity will have to deliver sooner or later, or they will get crushed by competition. But im not counting on any promise anymore.

 

Now I'm genuinely concerned about that because I'm on 2020 LTS and was planning to upgrade to 2021 when it would hit LTS.
Should we stay on 2020 LTS instead??
Unity, WHAT THE HELL??!!

-EDIT: I use BIRP

 

I started a new project with latest Unity 2021.2 recently. The project doesn't contain much at this point, just URP and a bunch of custom scripts to prototype some gameplay.

However, the 2021 editor is crashing a lot for me when changing C# code and switching back and forth between Unity and Visual Studio. Before you upgrade, I recommend to give it a test-run for a while to figure out whether 2021 is actually usable for you. I already regret that I didn't start the project with Unity 2019.4.

 

Wow... thank you very much for the advise!
I can't believe Unity keeps getting WORSE the more money they have!

 

I had started a project with 2021.2 in November to try out some things with .NET standard 2.1 and Visual Studio 2022, and had no crashes.

 

The big big problem of URP is that it had started as LWRP, which has a very distinct st of priority and executed them well, seems like management seeing the result of a tight design started to want to replace BIRP without understading teh reality of the situation, LWRP wasn't design to be flexible, it was design to do one style very well, turning that into somethig UNIVERSAL is going to the opposite direction of that philosophy, hence why the pain.

Unity causes this, because they didn't understandf how gameS are made, which is also reflected in teh absolutly inflexible design of early shadergraph, so their priority for these stuff shifted over time BECAUSE they were forced to have a reality check. BUT that's why they can't execute well on that premise, they are retrofitting new philosophy (flexibility) on something that wasn't design for.

When BiRP was main and Unity's SRP were optional, the messaging was quite clear, there was no confusion. Birp was the "Mario", can do everything but excel at none, then if you wanted something more specialised you looked at the USRP like you shop for asset, and eventually the promise was teh code would be clear enough you could extend then or learn from them to do a Custom SRP.

Some manager thought it was probably smarter than the smarties and sharper than the sharpies when they mandted to turn LWRP a specialised SRP into the URP. Destroying the appeal of the "Mario".

 

I wouldn't say that, Unity has many years of experience in engine development and also helped studios directly with game development. I would rather say the problem is that Unity know too many approaches how to make a Game, and somehow want to cover everything.

 

Oh hell no. Unity is sorely missing experience actually building games or it wouldn't be in this mess its in now. Things like Mono not being inlined really show this because in magical fairly land where you are making a basic game this is fine. But apply this to a full blown AAA game and that cost is unacceptable, needing things like IL2CPP or DOTS to fix it. If Unity had been battle tested with a full blown AAA game from the start I suspect it would have been designed Very differently.

They fail to deliver the foundations all too consistently and rely on the asset store to plug the gaps. Take 'Next Gen Soft Shadows' and 'Text Mesh Pro' as examples. The shadows in Unity suck, so hard. The tech is ancient and has so many issues that it required HDRP to start to fix them (and its still in a sorry state). As a result NGSS has consistently sold, 2 full versions, for years because it can offer clear improvements that Unity does not. Text rendering was Horrible when it first landed and why TMP was such an essential tool because it was such a drastic jump in quality.

If Unity had done their job right in the first place, there wouldn't be space for drastic jumps in quality and they wouldn't need to have bought the developer to integrate TMP into the engine.

 

That was the status from back then, when Unity was developed as an engine for IPhone games and AAA didn't have the goal, not the status Unity is in today. Even if Unity knows how to create games today, it is not easy to redesign the engine.
The experience of developing your own games does not necessarily mean that you automatically become a better engine developer, rather the engine would develop in a direction that is tailored to their games.

 

Even for 'back then', the decisions Unity made where bad all around. There is no excuse for how poor quality that first pass of UI was and almost Every game has UI in it.

Of course it does.......... if you don't develop games with your tools you're not seeing how its used in the real world. What you are saying is like writing code and committing it straight to production without any testing. You cannot anticipate with 100% accuracy how things will work in real scenarios, there is always something you didn't consider and the ONLY way to verify if something is working is to see it in action.

This is why there is a whole industry called Quality Assurance and its vital to any software project.

Exactly..... this is a self defeating statement because what you are inadvertently saying is that Unity needs to develop a wide variety of games in order to gauge everyones needs properly because if they just developed one game the engine would most reflect that games needs the most.

Since they dont develop a single game...........here we are on a forum complaining about how bad their tech is.

 

You only need the feedback, you can also get that through other sources. The developers who develop the engine are not necessarily as those who create the games. That would be the same as saying that a company that makes excavators doesn't know how to make excavators because they do not do civil engineering themselves. (I know that's a stupid comparison )

The forum only represents a minority of all users, and negative feedback is more likely to be posted than positive feedback, so the forum is not necessarily the best source for this statement. There are people who constantly complain about how bad the tech is and you can't make games with it, while others are silent and make successful games with Unity.

 

I'm going to make this my last post with you since you clearly don't want to admit you are wrong and would prefer to think everything is all roses with Unity atm.

How long is this thread? How many threads have you spotted like this one? How much feedback do you think Unity has on this subject? How much impact has that had in preventing these problems......clearly not enough.

The other thing that developing games yourself does it actually put your skin in the game. Its easy to dismiss or not even read feedback like these threads but when you have to actually deal with the issues day to day you are much more likely to do something about it.

Well yes, that is exactly what I am saying. You can make an excavator that picks up more than any other in the world and marketing will say its thus the best one in the world. A manager reads its the best so they buy it, but give it to the guys who use it day to day and they find its arm moves too slowly so its now 2* slower to get anything done. They would have known and spotted that flaw right away.

The company who actually uses the excavator would know this and be able to make a better product without needing to do market research and make mistakes along the way to get to the same quality.

The issue is that Unity is in this phase of throwing crap out there they think will help but is in fact terrible. So they have to gather feedback and makes changes until its working. This process is painful and taking forever. If they made games themselves, they could cut out a lot of this pain by going through it themselves instead of having us go through the pain for them.

Yes there are people who make games like Flappy Bird that does absolutely nothing to push the boundaries of tech and makes a ton of money. That doesn't mean we are all trying to make games like Flappy Bird, some of us are trying to make games that look modern and these are the people that are complaining.

This statement also shows your lack of understanding on the subject since its not that we can't make games with Unity but instead that we have to fight with Unity to make higher quality games. An engine is supposed to save us time and make our lives easier, Unity is not ticking that box as well as it used to.

 

Don't get me wrong, I just think that many people are often unfair to Unity. This quickly puts me in the defender position.

Companies that use the excavator would not even be able to build an excavator, let alone build a better product. But they're really good at using it. If there is a problem with the excavator, feedback is given to the manufacturer and they are responsible for improving their product.
When the manufacturer gets feedback from thousands of users, from all sorts of different use cases, that builds up a much greater knowledge as an single own civil engineering company. Only a newcomer to the manufacturer would benefit greatly if they had their own civil engineering company.

I was thinking more of games like Genshin Impact.

 

Agreed. Unity not making games themselves is one of their biggest problems. They think that having people embedded into dev teams and getting feedback is enough. The problem that comes from not making their own games is that their priorities become completely random. If they had a game releasing in a year there would be more features and improvements that mattered.

For example NGSS has screenspace shadows that can optionally only display in the distance, which lets you reduce your main shadow distance, whereas in HDRP it will apply everywhere. I could be wrong, but this was true the last time I checked.