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

I always hated that idiom: What doesn't kill you can cripple you for life, too.

 

No. I've given feedback, been phoned directly by Unity and had confcalls with them based on the feedback - and still nothing happened.

However I've also submitted circa 50-60 bug-reports to Unity, and seen about 30 of them get fixed rapidly in new Unity releases.

I've reported 30+ things via forums. Of those, 5 I was told "I won't work on it unless you submit a bug report, because I'm not allowed to" (or variations on that), and the ones I submitted as bug reports: at least 4 got fixed if I remember correctly.

2 of them were rejected as "Unity only accepts this via forums", and I had to reply "your own staff on the forums already told me to file this as a bug report", and eventually the QA team stopped rejecting them and allowed their colleagues to work on them.

Submitting bug reports: works.
Everything else: haahahahahahaha no.

Great for you that you're going to talk to teams who are currently playing with ProductBoard. When someone can point to a few big things, or a few dozen mall things, that got fixed *because* of a report via ProductBoard -- then we'll pay attention.

Until then: no-one should be using Product Board, Unity aren't using it internally.

 

Or, more likely, we're posting here because this is the official place to post if you want anything. It is much lower success rate than bug-reports, but it's official.

 

@a436t4ataf I can understand how one would feel that way about the new roadmap / productboard. Historically the Unity forums certainly have more staying power than any other newfangled thing Unity has tried, like Unity Connect (RIP.) My intention for posting roadmap links in this thread is for anyone that may not be aware of the official Unity Platform Roadmap launch and I have suggested to try the also official (since March 2021) feedback feature on the roadmap as it relates to SRP and "Surface" Shader API items that were added only 3 weeks ago, as it relevant to this "What's next for SRP" thread
https://unity.com/roadmap/unity-platform/rendering-visual-effects

I'm hopeful about the roadmap feedback being able to make a difference. But i'm not here to debate the platform roadmap's effectiveness or long term staying power. I have no idea how it's going to pan out, and we all have different kinds of feedback to share that might be better suited to particular methods. Do whatever works for you.

 

Man, the Unity devs in charge told us to do so. If that's not official, idk what could be!
I understand your frustration. Like, I REALLY do. I feel it myself. But it's not that much of an effort to simply write down your suggestions and concerns there as much as you do here.
Will it make a difference? I don't know. If it doesn't, we all know what to do: find some other engine that fits us instead.
Amazon just open sourced Lumberyard under the Apache license by the way.

 

Bureaucracy

 

We've all been asking for "shader replacement" for 3+ years now. Here SRP v11 beta is available now ali says that they don't give a sit about adding new functionality to SRP-API as long as URP/HDRP teams can do features without api changes. Of course *RP developers can do workarounds like LightMode Tag or ShaderLOD. Shader replacement is feature not for developers, it's for users of *RP, so don't think we got that functionality in near future.

 

First : In unity 2021.2 DrawRenderers can recorde by cmdBuffer, but it also is unified framework, did any plan separable them like DrawTerrain or DrawTree.

Last : Any plan for performance? DrawRenderers has many I/O overhead(memory copy) and it doesn't have cache mean evryframe it will re generate draw call data, and GraphicsJob just have llittle speed up. So I rebuild all primitive pipeline except skined renderer for research.

Custom MeshPipeline I got 15X! CPU performance up for MeshRenderer. for example 8010 Renderer(10 is dynamic), 4 Mesh, 3Material.


Custom MeshRenderer VS Unity MeshRenderer :



And Scale View :

 

And FrameDebug it can see because dynamic instance just have 3(Mat) * 4(Mesh) = 12 DC.

 

Yes, sure, we should put our comments and feedback to a place where it's not visible to anyone and we can't get any feedback back or comment.

I said somewhere else that I sometimes like going on the balcony and screaming my Unity frustrations into the void. It seems it's slightly more effective than writing on the product board.

 

Sad thing is, Unity is still the most usable and productive engine for a lot of developers despite all the flaws that it has deep down. I still think that it's great for gameplay programmers as it offers little to no foundation for a game, so you can code it yourself to your complete liking (unlike as with UE4, where it suddenly weighs down the entire basis for a game on your shoulders), not to mention that coding in C# is mostly a joy. And I think that, as a concept, SRP is a really good API, the extensibility is absolutely great.

That being said, I'm not thrilled about not having access to deeper parts of Unity and having it be overly restrictive. I'm disappointed that I can't do multithreaded code with a lot of UnityObjects because the engine is "unsafe" (because no engine is truly safe) and that it assumes that most people doing this aren't skilled enough for it. I'm sad that I have no access to the C# and C++ parts of the engine and as a result can't optimize them to my project's needs. Instead, UT offers to buy the license to Unity's source.

I remember Aras saying "we'd open source all of Unity today if we thought we could get away with it and still be in business tomorrow" in the related blog post, and I can only conclude that Unity being closed source and getting revenue from that license is a big part of income. Is your model even the right one if it really is the case? At that point, I would only hope that Unity would reconsider their business model and just go the Unreal way with royalties as an alternative, but providing the source code.

Personally, these were some of my issues with the engine that I wanted to pour into this thread, in hope that it'll help them snap. By no means do I consider Unity bad, I can think of numerous issues with other engines that I've used. I'm not overly experienced in professional game development yet, but I get the picture that the entire industry is filled with this dread over tools. If it is, then I will bite the bullet, eat the paint and enjoy the ride to its fullest till the end of time. Again though, sad that things had to turn out this way with Unity... The moment I'll go full-time to Unreal, I'm sure that I'll be furious over many of its quirks the same way, too.

I'll be on a lookout for this thread, bound to be as interesting as with that one 2019.3 release thread

 

https://twitter.com/SebAaltonen/status/1407661348197175299

There are major performance gains URP could have but doesn't - you can perhaps look into this technique, however the author is on holiday for a month so you will need to work it out (or ask in this forum).

 

I try it, BatchRendererGroup just a package for DrawMeshInstance, also did't have cache will evryframe re generated dc data, and if same instance to more it will separate to multi dc. and Batch just have one submesh control mean seam mesh renderer just because have 2 submesh it will be culling twice.

 

This right there

People complaining is part of the business model, it's a dark pattern, because it create a need to be filled, they can't be efficient else they loose the draw to their premium.

Basically you get a preview with base functionality and obvious fix just right of the way, but far off enough that you get invested enough in the project with sunk cost fallacy, that's the macro transaction, same idea than microtransactions, give you a problem for free and a solution for a price. And if you want to stay competitive you'll pay.

 

Well, the LightMode tag worked, though I had to use it in conjunction with Use Passes. They could've saved me a lot of time if their documentation for shader replacement had an RP addendum to explain how to perform this workaround.

 

Hey guys, you've had a head of steam but I'm going to have to draw the line at any form of what might be perceived as insulting toward any Unity staff. Please note any further replies will have to be in the context of Scriptable Render Pipelines. Thank you.

 

Asset developers, why don't you just collectively abandon the older versions of URP/HDRP/Editors?

I know that the asset store forces support for certain versions, and that a % of the market is on older versions, but its possible for some of devs to upgrade their editor versions for less effort than you are exhausting on this huge level of extended support.

If that doesn't work, collect your efforts and make a 3rd-party Asset store?

 

I usually do it after I make sure I announce it a few months before it happening. But lately, the adoption rate for newer unity versions is super slow so I still try to keep the assets up to date for those users as well.

On a survey I did on my discord channel, about 25% are still on srp 7x, so quite a big number.

But indeed, while probably most devs would like to move to newer unity versions, there are many potential buyers. I saw many devs unhappy that the minimum required version for new submissions is 2019.4 and about 20% are still on 2018 ( but those don t buy as much)

 

A lot of us refuse outright to support SRP

 

Do you mean SRP as the underlying system or specifically URP and HDRP? if so, why?

(I'm struggling to get the most convenience out of URP so I'm considering rolling my own SRP and just taking control so your experiences are interesting to me)

 

Specifically URP and HDRP. Mainly because the store is hard to support already because too much of the user base are complete beginners who don't realise they are beginners and too trigger happy to 1* for any stupid reason.

Add the mess of SRP on top of that where things break and change constantly. No thanks.
Add no documentation on top of it. No thanks.
Add missing features compared to built in and needing to explain why you can't do X. No thanks.
Add trying to support not only multiple Unity versions, but also multiple URP version and multiple HDRP versions. Really, no thanks!

 

Do we think that it might make sense to try to build a community led SRP pipeline that's designed how we want it with proper extensibility features? In theory, the SRP API may give us enough to completely bypass Unity's mess and create a widely adopted "standard" pipeline.

In reality this is probably a huge amount of work and not practical for various reasons, although we could start by forking one of the existing pipelines. This is mostly just frustration talking.

 

It's been said a number of times that there's not enough 'dogfooding' in the development of the current URP and HDRP pipelines. For those who are new to the term, it originates from a dog food maker who advertised how fit his product was by 'eating his own dog food'. It meant that this fellow had skin in the game, that he had to suffer the repercussions of his product if there were flaws in it.

I'm not naive enough to imagine a utopian ideal for a monolithic, top-down-led community effort, because a leader singleton will never be able to account for all individual differences of members in a community.

I can see some good things and some bad things with the current SRP.

First of all, I would say that the current SRP is about 95% good. 95% might be good enough if you were in an academic environment, but in a theoretical chocolate-cake factory that was retooled from a broken-glass making factory, releasing chocolate cakes that are 95% chocolate cake and 5% glass splinters would be an enormous disaster.

Trying to release a game with a pipeline that is 95% good is like running a marathon with a rock in your shoe.

If I discover a bug, I have to issue a bug report rather than using the forums, which means that only unity devs see this issue, and, if they get permission to work on it, the bug might be fixed, but the person who discovered the bug will have to sit there, dead in the water (if it's a very critical one), awaiting the next release, not knowing if the bug has been addressed, hoping that the bug might be fixed while the bills pile up.

With the forums, it's much easier to provide more context(screenshots and links to recorded video) and get more heads on the issue for stopgap workarounds.

And usually, even before I issue a bug report or a forum post, I perform a lot of testing on my end to see if I screwed up somewhere, pummel the search engine and manuals, and start digging into the pipeline code when the documentation proves inadequate, and, if it turns out that there is a shortcoming of the pipeline, I may duplicate code from the package cache and start editing it, resulting in a solution that is temporary until the next time they issue an update that may break my solution.

And it's only after I have exhausted all possibility of solutions on my own end that I will look to the forums or issue a bug report, or go to the discord where my query will be ignored and scrolled offscreen while in a murderous mental state.

 

The term 'production-ready' should be one that only your users get to use.

If you haven't had to suffer the use of your own tools, then you aren't a user, and you don't get to say 'production-ready'.

When people who use tools labeled as 'production-ready' discover otherwise, the term will lose all meaning and trust.

If you want to make this pipeline get fixed faster, then there needs to be a better way for people to contribute fixes where the work doesn't just get siloed in a blog somewhere only to gradually become forgotten or obsoleted over time.

The "shouting into a black hole" experience of reporting bugs also has to be replaced with one where:

A) More than hollow reassurances are offered (these will build costly mistrust)

B) There's some form of triage to separate between people who are improperly using the software (possibly because they didn't read documentation, or because there was inadequate documentation) and actual shortcomings of the software -- you may want a WIKI structure for your documentation so that when I discover how a thing is actually supposed to work I don't just keep it to myself.

C) Members of the community can provide assistance and be recognized for it. (My dopaminergic cycles must be satisfied so my brain's reward systems will release opiates and encourage me to continue this behaviour.)

D) If a fix has been created, then there is a route for it to find its way into a future build.

 

Unity does dogfood some of their stuff, but apparently they never come back for seconds. Take a look at the Asset Store Originals that were updated as recently as late last year:



People seem to love these:



Also, if you look at the descriptions you can see some nice intro text:



If these assets contained custom hand written shaders then I could maybe understand this, but as far as I can see they're just meshes, textures, materials, and scene settings, so there's no reason for them to not be compatible with newer versions of Unity.

What are the SRP teams even doing randomly throwing in breaking changes that have no auto upgrade path available? That shouldn't be allowed.

I think 2019 LTS, 2020 LTS, and 2021 should receive updates that make it so all of these assets can be imported without modification, without errors, and without magenta materials.

It's embarrassing that asset developers have to spend so much time and jump through so many hoops to make everything work in as many versions as possible, meanwhile Unity just throws whatever on the store and forgets about it.

What amazes me most about this SRP debacle is that literally nobody was asking for this. Unity of their own volition decided to mess with the most important aspect of their engine and completely bungled it up in so many ways, and yet to fix this we must band together and make some grassroots effort hoping someone over the castle walls hears us? The asymmetry here makes no sense. Surely someone high up in the graphics department had to greenlight such a massive architectural change after much discussion from other graphics developers right? If so, why can't these same forces come together again to fix this now. Does nobody in these departments use Unity at all? Or maybe atomicjoe's right and the management has changed too much.

Anyway, as long as the Asset Store still has lots of customers and my products sell, I'll just suck it up and deal with whatever. I already posted my thoughts to one of the SRP cards, maybe I could do more, but unless proven otherwise it just seems like a pointless gesture by Unity that merely acts pressure release valve that won't result in much. Conversely, I do know the impact spending time on my assets can have on my income, so my time is much better spent there.

 

That's "escalation of commitment" for you!
I'm pretty sure SRPs are the pet project of the CTO and he doesn't want to back off, even if the world is crumbling around him, since that would require for him to admit he screwed up.
There is no other explanation possible.
Also there is the fallacy of the sunk cost: they have spent so many time, money and resources on this that IT HAS to work, otherwise all of that would have been for nothing.

Plenty of companies go out of business because of this selfish human behavior.

 

According to the following talk (first 3 minutes), Unity Technologies created Scriptable Render Pipeline because it was too hard to create and support vastly different visual styles and games with a single render pipeline only. For game developers as well as Unity Technologies.

Spoiler: Scriptable Rendering Pipeline - Unity at Capsaicin 2017

 

Holy **** the irony of this is killing me

 

It's not rocket surgery!

 

When we say unity doesn't dogfood it's own stuff, we don't mean they aren't using their stuff internally, but mostly the team have decoupled responsibility. You have alpha team that do whatever they want, then beta team that do what they can with what alpha team released, to show it in a good light. The red flag is whenever the beta team release something, thet still has to fix stuff from the alpha team with premium access to unity core, like adding occlusion probe and fixing the source code.

Unity has a structural problem that dilute responsibility of problem. It won't be solved by commitment and listening.

 

It's not just the company's resources that have been invested into SRPs, but also that of every developer and asset dev who has spent time trying to make SRPs work within their game.

From what I can tell, the SRPs are 95% functional, but that last 5% (which is going to take 20x of the work to get it to 95%) is gonna require fine-tuning, and the fine-tuning is gonna have to come from us.

Why must it come from us? Because we're the only ones who have to ship games with it. We have the skin in the game. A number of people have mentioned Unity's internal bureaucracy has crippled their ability to solve outstanding issues in a timely fashion. I'm not alone in my criticism of their leadership.

I think that real leadership comes from being first. You go first, and lead the way for others to follow. Unity has gone first by making the URP and HDRP pipelines, and, much of my reverse-engineering study has shown me how the foundation works (and some of what doesn't.) There's some skilled systems developers among us. We're going to have to take what they've started and finish it for them because they're good at getting things started, but we're the ones who make things ship.

So we have a laundry list of problems, and they have to be triaged so that the right person can see it and do something about it. Most problems I see on the forum that go unanswered are problems that I can't solve myself because the person reporting them shows a couple of screenshots, does not explain HOW those screenshots were generated, does not explain if those glitchy objects are mesh renderers, does not show their shader graphs, does not show frame debugger stepthroughs, does not show screenshots of their pipeline, pipeline assets, etc.

It is very hard to separate how many of those issues on the forum are the result of improper setup vs. a flaw in the SRP system. And I know from experience that it's very easy to screw this stuff up because I'm always in a hurry, and the documentation is spotty, and I rely on internet searches, blogs, docs, videos, reverse-engineered source, and some of what I learn is outdated! Some of the practices I've learned from the BIRP are outdated, too!

So I think if we're going to get through this mess, we have to sort ourselves out, first and foremost, because that part is the part we have the most control over. There are people among us who aren't using the software properly, sometimes because their knowledge is outdated, sometimes because they haven't learned the ropes, sometimes because the documentation is spotty, and these people are best served by getting them the knowledge they need. The manuals and the documentation REALLY needs to be reliable so these people can help themselves.

From that, we can finally begin to get reverse-engineers to track down the actual problems within the SRP systems. I'm curious to know how many people really understand how an SRP does what it does, understands what command buffers are, understands the differences between static and dynamic batching, etc.

 

All institutions dilute responsibility. But they do concentrate efforts and resources as well.

I think they're good for large, bulk work, but it's really the job of individuals to perform fine-tuning, just because we're the only ones who can.

The steamroller has taken us this far, but we can't make it move *exactly* 3.7 mm to the right.

So let's put them to shame by fixing it for them.

 

If that is the case, money flows the wrong way between Unity and its userbase.

 

We already did, check the asset store.
Unfortunately, unity customers can only do so much for them. SRP took it to a whole new level.

 

I'm a very very good customer of the asset store. I'm still using Unity personal, yet I've recently spent thousands on the asset store to solve problems with Unity. I don't have a problem with paying people on the Asset store to solve problems for me no matter where those problems came from. It looks like one day we'll be seeing new SRPs on the Asset store. Unity will take its cut and I guess this will be their business model, going forwards.

Now, whether this was their game plan or not is entirely up to speculation but in the end, I have a game I need to ship and there's no way it would be possible without Unity and it's asset store.

 

Or so you'd think, but I really think that if all the money and time spent towards working around Unity's shortcomings were spent elsewhere, a lot more things would be possible without Unity.

 

That's true of a lot of things but it's not something any single one of us can control and the longer we sit around hoping that somebody else will fix it, the more stuff sits undone. Everyone thinks that the problem sitting right in front of them is the last problem they'll ever have to solve and then after that it will be smooth sailing and parties from there on out, but the truth is there's another wall just waiting for you to slam into after you break through this one.

The difference between someone who ships and someone who doesn't is that the person who ships is the one who keeps breaking through until the last wall is broken.

 

The one who ships is the one that doesn't use Unity. Because the one that uses Unity is too busy solving the problems Unity creates, instead of making his game, and Unity keeps creating more problem than it solves.

 

I dunno, I've been playing Subnautica 2 when I get off work and that's been made in Unity.

Look, there's no shortage of people here out for blood who can't wait to see someone's head on a stick in front of the Unity offices as a warning to others, and we'd all have to get in line, and I will be vigorously trying to elbow my way to the front.

But you know, after all the blood sacrifices and the payments in pounds of flesh, we still gotta get our jobs done and get paid, and you can either go to another engine or pick up the source code they gave us and take a whack at it. I managed to make the best of a bad situation and by and large most of the problems are because the documentation just really sucks and the SRP is an unfamiliar beast.

If you have actual technical BUGS to point out, then do exactly that. Find out where in the source it's gone wrong and maybe one of us people can do something productive about it. Trying to wring out productivity from people you've declared are incompetent is like trying to get blood from a stone. It's a waste of time.

 

The onus to make Unity better is on Unity, not on the community.

If I report bugs, best case scenario I get a fix 6 months later in a version I can't use for another 6 months. Worst case scenario QA can't reproduce my issue and I lose a bit more sanity.

Reporting bugs to Unity does not benefit me, and I will not do that for them for free, and neither should anyone else.

 

Whilst I've contributed my frustration to this thread, I agree with @moatdd that some people here are unhealthily out for blood. At the end of the day, if Unity isn't a good product anymore, the thing to do is to explore the market. Games do get shipped in Unity, so saying that it can't be done is clearly melodramatic.

SRP is sufficiently hackable that an individual or a team can achieve almost anything they can dream of with it given the resources. Where it fails spectacularly is in supporting the ecosystem - third party pipeline modifications cannot be seamlessly dropped in side by side, so expertise and time is required to deviate from what works out of the box, and the out of the box features are lacking. "Pick up the source code they gave us and take a whack at it" doesn't work to fix these ecosystem and plugin issues, although @jbooth is making a valiant effort.

 

You do that. I'll be using the built-in render pipeline in the meantime, which is more powerful, more compatible, faster and has great documentation.
Seriously, there is nothing you can do even on HDRP that you can't do on the built-in pipeline using either custom or asset store add-ons.

The last videos I checked comparing URP and BIRP performance were the last nail in the coffin for me.
Whatever problems they tried to fix with the new render pipelines, they clearly failed to deliver.
Scriptable Render Pipelines was something I was REAAAALLY hyped for, as a technical artist myself. But the new render pipelines have completely screwed the Unity ecosystem without giving anything in return.
Those are not "growing pains" as they like to call them, this is outright CANCER.

They should just completely scrap URP and HDRP, convert the built-in render pipeline AS IT IS to C# using the SRP API to keep ALL current compatibility and benefiting the users with deep custom modifications if they wish so.
Then update Surface Shaders to make it compatible with any custom SRP by open sourcing the shader parser and translator in plain C# so everybody can fine tune, adapt and expand it to his liking.

Instead of replacing a well established system, EXPAND IT!
Implement the HDRP features as ADD-ONS to the central built-in render pipeline as an optional package that requires DX12 hardware and DONE.

There! I fixed the SRP debacle for them!
Do you really think no one at Unity thought about this?
I bet they did but the guy in charge said: "Naaaah, let's do it MY way instead. Screw compatibility."

 

Sadly, I have to agree with this. I have reported lots of bugs to Unity in my time and got a lot of varied results from the QA (as expected in general, always some great people and some not so great).

However, too often once the issue has been found and once it finally permeates through to dev its dismissed. That I'm getting sick of. Too often classed as "as designed" or requires a significant rework to fix, so we will close it instead... really?

This is the perfect example:
https://issuetracker.unity3d.com/is...s-eulerangles-if-its-y-rotation-is-close-to-0

I pointed out shadows in a scene with a floor, a cube and a slowly spinning directional light cause bad/erratic flickering. This is pretty huge since it means there are problems in any Unity game trying to simulate a day and night cycle.

2 years later and this is still not fixed.

Its not like they can even offer an alternative like saying to use Global Illumination because its still classed as depreciated for BIRP. In fact this is the bug that started me hating SRP because the first response from Unity was very telling. It was basically "we are too busy with URP, so we wont fix this". When it was pointed out that this was not an acceptable response they then changed it to "Postponed" which just means dead in this instance.

So basically all open world games with a sun aren't as important as URP... really?

 

Indeed! WTF Unity!

 

That is the essence of why I find it hard to believe much anymore from them. I am desperately trying to Not " disparage " any single or group of Unity employees. Something like this is simply " Truth " to me, trying to say this applies only to SRP is really hard to keep this thread solely on this topic, when in fact SRP ends up being tied to other Unity problems, the engine as a whole has to be taken into account. For me trying to think of SRP in a vacuum, is practically impossible because one thing relies an another. The question becomes is this an isolated problem ? just confined to SRP ? IF* that were the case, then everything else about the engine would all be hunky dory ....

How can the asset store fix problems / bugs/ features in the engine in order to ship a game ? YES to be sure games get shipped and it gets done. But assets you bought at one time to fix " a problem ", become obsolete as the engines changes.. so if you can do write offs and or are making so much money from your game that it does not matter to you then great .. What about reputation tho ? The only other thought about using " assets " to fix problems .. is the to many cooks idea again.. 4 - 6 almost same assets to fix a general problem, then how many times does that asset interfere with another asset and cause even more problems.

Call me stupid here, I don't care, because I don't know how to code, and do not know what is possible and what is not... but some one mentioned a screen shot and how hard it is to get a sense of the problems, of what could be causing it. ( with the understanding that the probability of user error, is high ( but why would that be ? ) )

Would it be so hard for Unity to write a utility that will only make screen shots while the editor is running ( or a utility for builds ) ... that what this utility would do, at the instant the screen shot button is pushed, would be to output a log file, with everything that is happening at that instant ? obviously would include, PC windows version , unity version, ram,etc .. nothing like personal data, just the common stuff to every computer, that unity uses .. " graphics card etc..
Hope that makes sense.. one coffee down, three to go

 

Everyone is kind of unhappy with SRP but not messaging what specifically they want in order to fix SRP.

I'll go first: I'm probably always going to be unhappy with shadergraph. It's taken years and still requires me to edit source code to get what I want.

Therefore I've given up on it and want surface shaders but with control over the final pixel rgb so I can do grading at a shader level instead of using post fx and do whatever stylised things I want.~

I can do exactly this with unlit, but it's unlit, so...


Just don't forget we want to modify the final pixel RGB after lighting. That's just so important to have that control.

 

One of my freelance 3D artists renders his work in Unreal Engine :-/ (even though we're working on a Unity project)
So I took UE5 for a spin over the weekend with some test assets from my current project.


https://cdn.discordapp.com/attachme.../864113758410637332/Unity_2021_URP_vs_UE5.png
Top Unreal, Bottom Unity.


For an FPS, Unreal wins, easily
The lighting looks great out of the box. I can achieve the above without really any UE experience and a couple of hours playing around with the post processing and lighting.

But Unity still has the edge for performance (200fps vs 60fps in this test scene) - this is the major factor for Switch
And I think its easier to get a consistent visual result with Unity (even if the lighting is unrealistic) especially for stylised or topdown games

However, the quality of the 3D assets seems to matter less for Unreal, since the engine does so much of the heavy visual lifting
Having megascans and visual scripting is another potential major advantage which I've not tested.

I used to think that Unity had the edge for small projects and teams, but now I think even that if you are designing games with visuals as the focus, Unreal lets you produce content faster.

I'm also seeing slightly more Unreal C++ programmers becoming available, at lower rates, so that edge is softening as well.

 

I'll go second. Too many things require a source edit of the pipeline. In fact, customising the pipeline source is the whole point of SRPs. This is a broken design for a few reasons.

• Maintaining a pipeline fork against upstream changes is an unreasonable burden.
• Shipping a plugin that needs to make a tiny modification to a pipeline requires shipping and maintaining that whole pipeline.
• Multiple pipeline modifications cannot sit side by side in a project, so 3rd party addons cannot be mixed. This breaks the entire ecosystem.

The solution to this is to have enough extensibility points in the standard API that pipeline modifications are not needed. BIRP was not perfect in this regard, but the

CommandBuffer

plugin opportunities were significantly better there than what we have in the SRPs.

 

I've been looking at Unreal recently too. The things they provide out of the box seem fmuch better than Unity's and I'm very tempted, but the lack of good support for some types of lower level customisation scares me. For example I was looking this morning and I don't think that compute shaders are officially supported, although some people have managed to get them working. They get around this by letting you recompile the entire engine so that you can do anything you want, but this is a major burden. I use an engine so that I can trust that low level platform interaction was written by somebody who knows what they're doing, and that doesn't work if I have to patch it in myself.

I'm very tempted to switch but it's a hard decision and I'm going to have a look at some other engines too.

 

From the top of my head, might not be accurate:
- Surface shaders
- Blackbox shader graph, not extensible
- Everything internal, it's hard to even change a post-processing value
- If you want to get the camera background color? guess where you can find it. Camera.backgaroungColor is not the one if you are on HDRP
- probably more than 50% of the assets supporting URP, will not work in your URP version
- SRP versions are tied to the unity version, so there is no way to use URP 10 in 2020.1
- Or a unified workflow between them
- Different naming conventions between shaders, different mask maps, etc
- In HDRP Ao is in post-processing, in URP it is a render feature
- Render Features, both have it, but they are different
- Camera stacking in URP, Compositor in HDRP
- Render features vs Render graph
- Different light values, I get HDRP is physically based, what about having URP behave the same, not sure
- Different implementation between BIRP, URP, HDRP so it is hard to learn any of them properly (if it is the case)
- Exposed SRP Batcher in URP, hidden in HDRP, why?
- unity_ObjectToWorld, aa no that is not working with instanced in HDRP, use UNITY_MATRIX_M instead or whatever
- keywords, built-in shader properties, stencils - undocumented, you never know what to use. Different naming in URP of course
- poor documentation, you will need to dig a lot to see what is going on, and then forget everything because you are now on another SRP
- 5 years in the making and still full of issues!
- Claiming that they are production-ready, hmm

Ideally, Unity would have ONE SRP with tons of customization, HDRP is in that direction. Might be harder to do, but any game engine on earth has one rendering pipeline (the ones I know).

I don't develop games for a few years now, so I don't really care about what features are added or what is not working, but this inconsistency between them bothers me a lot. And what bothers me the most is that every time one of my users reports an issue, I need to ask: platform, what unity version, what SRP, what SRP version, forward, deferred, frame settings, post-processing, etc?... instead of just asking for the platform, forward or deferred, maybe post-processing enabled?

So who the hell has time to test all these variations, not even unity themselves... so now instead of spending time to create some better products, we have less time to test, N times more work to do, N times more support to offer, N times more time spent to learn new stuff and dig, and dig. Sorry I need to go, I have some issues in URP 7.4.3, some flickering, but it works in BIRP and URP 7.5 and the shader code looks correct, so why it is not working?