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

Here is my archive of old LWRP sources, from version 0.1 to 5. I learn SRP-api looking at this sources(and old hdrp too).

>setting up the view-projection matrix before rendering the skybox
Obviously you need to setup view, projection and other matrices to draw anything. I assume, you setup your own matrices, with your own naming. If that - DrawSkybox() is just a sugar that says to unity "draw sphere with skybox material", so you need to provide matrices with unity names.

>how to implement sorting of common opaque objects
If you ask about manual object sorting - it's impossible at now.

 

Thank you. I will take a look and see what I can learn.

Although you are correct about "Obviously you need to setup view, projection and other matrices to draw anything." the problem is I was not aware of that when I first started learning graphics programming/SRP.

I look at it like this....

I'm not a rocket scientist so if I tried to build a rocket I have no doubt it would fail. However, if NASA specifically came out and said "Hey, guys! We've got this really cool tech that allows you to build your own rockets" I would expect NASA to provide a ton of documentation about their solution.

I might never become a rocket scientist/engineer working for NASA or SpaceX.... but at least with the documentation I can build and launch miniature model rockets from my garden.

It's frustrating that Unity has provided such a cool option but decided to not explain it very well - resulting in a painful experience (imo) when trying to build a SRP.

 

I have a conspiracy theory: yes, SRP-api are open, but unity want to monopolize rendering teсh, and want to all to be stick to HDRP/URP. Because of that we have a limited documentation, lack of some crucial features, Shader/VGX graph exclusivity. My company decide to drop development of a custom SRP and stick to HDRP. Say hello to a new term - "HDRP-jail"

 

Same thing with VS Bolt, they bought it, killed Bolt 2 ... put bolt 1 tutorials behind a pay wall ( now free bc Covid )
and am making it interrelate with " higher " Visual scripting nodes. I hope but won't be surprised they make
Bolt hard to understand for new people/ people;e with low math skills/ coding experience.

 

My theory is SRP started out with good intentions. Unity genuinely wanted to give people more power and impact on the final product without requiring costly source code licenses to peek under the hood.

However, after they built the LWRP (and subsequently changed it to URP) and the HDRP, I think they realized the monumental task they inadvertently took on - maintaining three separate and complex render pipelines (in addition to everything else they do).

This has caused a mix of apathy (the challenge of writing and maintaining high-quality documentation is too great) and I think Unity don't believe the SRP will be used by the majority of developers so... why bother putting in the substantial effort to maintain docs etc?

https://github.com/UnityTechnologies/ScriptableRenderPipeline


Unity Scriptable Render Pipeline
The Scriptable Render Pipeline (SRP) is a new Unity feature in active development. SRP has been designed to give artists and developers the tools they need to create modern, high-fidelity graphics in Unity. Including a built-in Lightweight Render Pipeline for use on all platforms, and a High Definition Render Pipeline (HDRP) for use on compute shader compatible platforms. These features are available in Unity 2018.1+.

We are committed to an open and transparent development process, and as such you are welcome to take a look around if you are really curious.

Detailed documentation is being added here: Wiki

https://github.com/Unity-Technologies/ScriptableRenderPipeline/wiki (404 Error)

(and btw if you think.. oh that's because they mispelled it and used a hyphon.... https://github.com/UnityTechnologies/ScriptableRenderPipeline/wiki returns 404 too)

Oh Unity....

"This feature is currently in preview. Some features may change or be removed before we move to a full release."

So SRP is still in preview? But HDRP and URP are built on SRP??

Correct me if I am wrong but doesn't Unity claim URP (and HDRP?) to be "production-ready". How are they production-ready when they use tech that is still in preview?

Has the repo not been updated?

Will our hero Spiderman make it out alive? Find out next week!

(on a separate note this also makes me worried about how well ECS will be documented on release)

 

It's well explained in this rather short talk:

It's sad that writing a custom SRP seems to be such a big undertaking.

I'm not sure if having these monolithic hard-coded URP and HDRP renderers is better than their monolithic hard-coded built-in pipeline.

It sounds great in theory, but they still don't seem to be able to put out fixes quick(er) without having to change the core (so they bound URP/HDRP to the editor bundle again), they still don't seem to be able to fix something in the pipeline without breaking something else and they still don't seem to be able to make it faster than built-in. What are the benefits for me if this is considered production ready?

I'm also skeptical when it comes to writing a custom render pipeline. If it takes a bunch of high class rendering engineers half a decade to deliver a half finished product, how realistic is it to other groups of developers.

Good documentation was always a weak point of Unity in my opinion. But they caught up with at least the core API's. However, it feels like 99% of their packages, so basically everything that is relatively new, have bad to useless to even non-existent documentation.

 

This talk was made by Aras. But unfortunately he is no longer work on graphics. I thing this is one of major reasons on what happening now with SRP.

 

There isn't a straightforward method to upgrade HDRP 7 project in HDRP10. Opening such project clears out HDRP asset and Unity thinks HDRP pipeline is not present.

I would like that HDRP 10 moving forward would offer core support that SRP projects(v10+) can be opened in future Unity versions.

 

IMO the goal should be to have ONE Unity (currently Unity is everything but united). Otherwise it's horrible wasting of resources, loosing synergy and insane fragmentation of asset store. One Unity, one assets, one verified way to do things.

And secondly: to make Unity really usable for creators there must be available standard set of usual 3D features like decals, projectors, water system, weather, state-of-the terrain terrain etc. available out of the box like in Unreal. It is untenable to require creators to buy or write their own shaders for as basic features as water or decals. Look e.g. how feature-complete Unreal is.

 

Overall I agree with this sentiment as it largely aligns with the scope of my projects --Unreal has Unity beat for many high end out of the box use cases. But it's also foolhardy to not mention or have concern for the difficulty and additional effort / resources it takes for developer to scale down Unreal Engine for an optimized mobile platform with high compatibility (not just the high end mobile devices that came out yesterday.) Unreal has made major progress in this area and laid a foundation for low end mobile and 2D, but still has a long way to go in making these workflows easier and accessible, as it is not their primary focus. Smaller devs without the resources might even say building and optimizing Unreal for their mobile and/or 2D project versus Unity's solutions is untenable, a horrible wasting of resources. Both of these engines have more and more overlap as time goes on but they still have their niche use cases that they are best suited for "out of the box." This also factors in availability of community resources and the focus of products of the unity asset store & unreal marketplace. So, while you are spot-on in regards to your use case (i presume 3D projects with mid to high end targets that call for state-of-the art features,) when looking at the big picture of every possible use case and project scope, it's a subjective comparison.

 

I many time thinking about some alternative, unified, scalable, feature rich render pipe. Some GRP(Good Rendering Pipeline). But problem is the same that with URP/HDRP - fragmentation, rage of asset store creators, fear of developers to switch to unfamiliar workflow.

 

I really want Unity to help us port some of the built-in pipeline shader feature to SRP.

I don't need Unity team write more code, I just want some of the built-in pipeline shader parameters to be fully documented. The rest we can handle just fine.

I have put down some thoughts here:

https://forum.unity.com/threads/how-do-you-reverse-engineer-built-in-shader-parameters.993950/

 

What SRP should achieve is to create a default workflow with bigger hierarchy than graphical pipelines.

For example, in built-in you can reach solution with second camera as depth pass, in HDRP 10 you would use camera compositor, in URP custom pass but different than in HDRP.

If you use second camera or depth pass, you need to choose the pipeline from the start. I think game logic using second camera shouldn't depend on the pipeline.

Default workflow should also allow you to, for example, create terrain, grass, ... without choosing graphical pipeline.
So imagine this default workflow as workbench. A many iterations. When project is near end than you choose graphical pipeline you need to achieve artist's point of view.

Developers should have freedom to create as further as possible without disrupting the workflow.

 

I've tried reading through this entire thread and everything else I've come across regarding SRP over the years and it's still not clear to me what the end goal is with having 2 render pipelines? To me this approach is the polar opposite of what Unity was about when I started using it and as far as I understand it's also a different approach from every other engine out there? So what is the end goal here?

Will URP be faster than it's possible to be ever be with something like Unreal, Unigine, Lumberyard, Godot or GameMaker for mobile? Or will HDRP be able to give me better graphics on PC than any other engine? One of these has to be true, right? If neither of these are true then what is the point?

I also honestly don't understand the whole technological divide between the 2 pipelines. What are GPU-compute-capable, high-end platforms? Isn't having your game on as many platforms as possible the norm these days? I mean Fortnite is on every platform. And it feels like it was designed for whatever platform you play it on. How would you replicate that in Unity? Is that URP or HDRP? How far up will URP scale and how far down will HDRP scale?

The way I see it having 2 render pipelines will always bring with it huge drawbacks no matter how many of these promised features are implemented, so what possible benefit is big enough to warrant these huge drawbacks?

 

I hear you and I wish the ecosystem of platforms here was easier to target with one super scalable RP. It's a bit if a mess right now with a major industry wide rift with graphics hardware and APIs in a major transition right now. Moore's law is dead, too, which amplifies the difficulty and importance of optimization.

To benefit is performance (and workflow) optimization "out of the box" for a wider range of use cases that anything else on the market. Unity's is competing with several engines that all have their own niche.

URP targets on what Godot and Mobile frameworks focus on and are optimized for. (2D, simpler 3D Mostly non-gpu compute capable targets, but is being extended to scale up to a middle ground, high end mobile and non photorealistic games.)

HDRP targets what Unreal and Cryengine is focused on and optimized for. The latest, state of the art features, largely photorealistic, almost entirely focused on high end compute capable platforms only. (sure Unreal can run on higher end mobile now but good luck with optimizing that to run on low or even mid range devices, if you aren't Epic games or some other large studio that can just write their own custom render pipeline optimized for a flagship game.)

Unity is competing globally on an incredibly broad spectrum that no other engine is, and in more industries far beyond videogames than any other engine as well.

If they tried to fit in all in one render pipeline, they'd have to make major compromises in performance, compatibility, scalability. e.g. if you didn't use compute shaders or any new API features you would have better compatibility but you'd have much worse performance on gpu compute capable platforms. That is the major problems they were having with Built-in RP, as well as lack of extensibility devs were asking for.

Granted, someday eventually all platforms will have "compute capable" GPUs and then we may be able to have a more fully scalable render pipeline for all, though at that point who knows how advances in raytracing and neural rendering will have shifted the high end targets.

I hope that helps paint the bigger picture here.

 

Thanks, that makes some sense, but I'm still curious how you'd make these choices as a developer. And what would these choices even consist of? Would you have to test every feature in the different pipelines and benchmark them against your target platforms to guesstimate what you can get away with and what features you'll end up needing? How much faster is rendering 10 cubes in URP compared to HDRP? What if it's 10 cubes and 20 spheres? Is it faster to render 500 cubes in HDRP? Do my shadows need to be that good? Is lower quality depth of field acceptable? Do I completely sacrifice higher end features to also allow lower end devices to run my game? Do I need URP to reach 60 fps or could I use HDRP and still reach 60 fps?

Spelunky 2 recently launched with a DirectX 11 minimum requirement and a lot of players were pissed they couldn't play the sequel when they've been able to play the first game just fine. I also think Fortnite introduced that requirement a while back. Would that be the equivalent of choosing HDRP over URP for example? Do I screw over some players to give cooler features to the rest?

What if ray tracing becomes expected in mobile games in the coming years? Currently that's a HDRP feature. Would HDRP become the go to for mobile development as well or would URP also get ray tracing at that point? And would they have the same implementations of ray tracing or different ones? And so on...

I guess I'll just have to wait and see for myself when/if these pipelines ever become production ready, but I can't help but fear what this will mean for Unity and the Unity community. I remember how awful it was for me as a beginner when Unity was using both Unityscript and C# (and Boo, I guess, but luckily nobody used that, otherwise I would have been in a world of trouble ) because I never knew which language an asset, tutorial or code snippet would use, and I could end up buying assets or tutorials that were borderline unusable for me, but compared to this that's kind of a trivial problem to have, at least based on how I fear this could end up. And of course a big fear is that development will just work differently between the pipelines. So that you find yourself in a situation where think you know Unity by heart, but in reality you only know 1 pipeline and when you switch to the other one you need to learn a lot of stuff again because lighting works differently or post processing works differently and not just in the editor, but how you interact with these systems through scripting etc., and then you realize authoring assets is different so that assets you find outside of Unity that are marked as being "Unity ready" are in fact only ready for 1 particular pipeline etc. Although that's one thing I hope they're working towards fixing based on the information in this thread. Currently I think just the fact that I have to export textures differently from Photoshop to use them in HDRP is a completely pain in the ass and frustrating enough on it's own that I'm staying away from HDRP, completely ignoring everything else about the pipelines that I can't stand at the moment.

And if the goal with HDRP is to compete with Unreal and similar engines then I feel that's just doomed to fail anyway. All you can do is hope to catch up to where they were many years ago. Looking at Unreal 5 I'd venture you'd need an entire editor built around that type of streaming technology just to be able to work with such assets inside the editor and if Unity were to support that for HDRP then HDRP is suddenly it's own editor rather than just a rendering pipeline. But these are areas I know very little of and in general I hate learning things I already know so maybe I'm overly skeptical and fearful of changes happening to Unity.

Avoiding fracturing the community would be my number one priority in all this, but the approach so far has been as bad as it could possibly have been in that regard. The Unity community, and by that I mean everything everywhere (github, youtube, reddit, twitter etc. etc.), has is by far my favorite thing about using Unity. I'm able to find everything I need somewhere and up until the last few years all of it has been for the same "version" of Unity, but lately more and more things are becoming URP only or HDRP only.

 

Unreal targets mobiles just fine, they were able to target them fine even back in the iPhone 3GS days.

Why should I care about this when considering "Is Unity the right engine for the things I want to do"?

If I go to a restaurant to eat Italian food, and the Italian food is bad, what am I to do with the information, "Well, the restaurant is a broad spectrum restaurant, it even tries to make food for horses, and also offers many cuisines from all over the world, you can't really expect them to be able to boil pasta properly."?

It doesn't.

 

LWRP was originally an example pipeline, a guide to creating your own custom pipeline. HDRP has been the internal pipeline for beautiful commercial cinematics. But after a while, marketing guys decided to sell this pipes as a new feature.

In the end we stuck in lose-lose situation. Developers force to choose pipe based on insufficient data, asset store guys have troubles with supporting of multiple versions of asset, URP is slow for mobiles, HDRP is slow for PC/Consoles.
Most of developers is decline to making custom pipeline, cause they believe in mythical "unity support". Yea, after AO, point light shadows, hiding any quality settings in HDRP, developing new features for latest alpha versions of unity, and refuse to port crucial features to old versions.

 

Actually, Unreal does have multiple "pipelines":

• Mobile forward
• Desktop forward
• Deferred
  
• Ray-tracing

The thing is that those are (mostly) abstracted away from developers: your materials don't all turn into pink when you switch between them and you can make a single project that targets multiple pipelines.

One problem with SRP is that it is missing a crucial component for renderer abstraction: robust shader generation. Yes, there is shader graph, but it's insufficient: it's hard-coded for Unity's own pipelines, is missing a lot of features, and the team behind it goes out of their way to make it as hard to extend as possible.

(Yes, this is another rant at the lack of an SRP equivalent of surface shaders.)

 

This is the same for the Visual Bolt " Conversation " if you can call it that. Multiple versions of VS for different types of data , that, could work better for the different versions of Render pipeline Versions/ideas ? Front End/Back End ? , if i read things right. In any case it makes my head spin just trying to get what and how these can fit together. I mean this is sposs to be easy ? But like a last post of mine, I missed a typo on my IQ as 100 , should have been 140 ( and it does not matter to me and never has ) Plus i have no math and hate the idea of learning scripting .. that alone if you think about it.. a high level scripting, that is easy to explain and powerful to not slow down projects, Is with grasp ( imho ) if people set their minds to it.

Personally if it is possible, there must be like a set of DLL's, base coding, etc that run the main editor ? So i see this ( in part ) as feature creep as Quote " LWRP was originally an example pipeline, a guide to creating your own custom pipeline. HDRP has been the internal pipeline for beautiful commercial cinematics. But after a while, marketing guys decided to sell this pipes as a new feature. " as an example. So on to this, add all the pipelines for render engine and everything else, to my way of thinking is to me, No wonder there are bugs and it seems as another person said " 2 steps forward 1 step back " and it kind of feels like a house of cards that adding one more thing might collapse it, and become un-manageable.

I have zero experience in coding and no idea how internal structures work.

So i do not know if this idea can work, or is just stupid to start off with... but it seems to me that maybe an idea could be to split the render engines into different Unity"s ? Like say you could decide what your project will be.. example HDRP ..
so you would start Unity and pick HDRP , then in theory the " base coding of Unity engine " would be the same? So that say stuff like Lighting and what ever is needed specifically HDRP will be included. That way ( if it's possible ) in my mind, since there will be less conflicts ( cards, lol ) to deal with , there should be less bugs ? IDK if that makes sense, or I am explaining it right ? ( it also seems to me if it is possible, then having the Unity Visual scripting every one wants ( Bolt 2 ? ) Then after that is done, hopefully there could be some kind of conversion to another render platform type for a different set of hardware. I just got out of hospital ( not covid related ) but am having to do a decrease on some med's that are very powerful, plus restrictions on fluid and food intake and a couple of others ,, salt .. Anyways , I hope I can get my point across and this all makes some kind of sense.

 

HDR10+ output support for PC and premium mobile phones, when? It's 2020.

 

Hey so uh am I missing something or did this never happen? There was a TON of great feedback and criticism and concerns in the early part of this thread, and basically none of it seems to have been addressed...

 

No, they've been completely silent since posting this. I fully expect that the solution to "compatibility" between the pipelines is going to be like the FBX format, where they just stuff the full complexity of both pipelines into one shader file and call it a day, rather than actually abstracting them correctly, and still forcing everyone to use the shader graph if you want any chance of compatibility between unity versions.

 

Damn, this was July? Would like to add my voice to get the official word on what might have been taken away from this discussion too - @Tim-C can you give us an official update?

 

They really love doing this, don't they? Make big promises, go radio silent, and then out of nowhere release something mediocre and unstable (aka Unity's "stable" designation) that doesn't cover important use cases. At this point, I'm just going to stick to the built-in render pipeline until (or if) this blows over or competitors like Godot catch up.

 

@Treiger they are literally executing the plan already though, some of the things have already happened like shipping SRPs along with Unity editor etc

 

That's nice and all, but the main issue I care about is cross-compatibility, which still hasn't been addressed. I understand it takes time, so I'm not complaining about them taking too long, but more on the fact that we haven't gotten any updates on how they're tackling it after all the feedback here. Communication matters, especially when the community is frustrated by the lack of quality in recent years.

There needs to be a proper abstraction layer for the two pipelines and shader graph shouldn't be hardcoded for the two pipelines. It would nice to know if they were doing exactly that, instead of trying to guess if they're going to get it right this time.

 

You didn't notice the SG change on SRP 9.x+ ? You can now author shaders using same shader graph that target multiple targets. For example you can now write a single SG that works on all URP, HDRP and VFX Graph. I'd assume you could expand it even further to custom SRPs.

 

Because they hardcoded SG to work with both pipelines. Yeah, this gives us cross-compatibility with SG, but writing a shader by hand to support both pipelines is still a pain because there isn't proper abstraction ("Shared asset and API interface for both render pipelines" section in the original post), which means you have to manually deal with the kinks of each pipeline to achieve cross-compatibility. I understand it takes a long time, but it wouldn't hurt to communicate how exactly things are going and how they're approaching it.

Not sure about the extending SG part, people have said it's hard to extend but I haven't personally tried it yet.

 

Well they haven't actually done anything on it yet, if they ever will. If you browse the repository history you can get a pretty good idea of what they are working on (mostly new features). I had a meeting with them months ago and there were lots of excuses of why a shader abstraction was hard ("We might change languages from HLSL", "Mesh Shaders"), but none of these reasons made a ton of sense to me. They are already coding an abstraction layer, they just hard coded it to only work with the shader graph - which effectively just writes a vertex/fragment function and sets up some structure- nothing that can't be done with a text parser as well. They also promised to get me some plans in a month or so, but that never materialized either. So while I think they are going to make it easier to work across pipelines, I think it is very unlikely they are going to make it easier if your not using the shader graph. They are, at least, documenting some of the changes they make to the shaders now.

As for extending the SG, it's still requires hacking the assemblies or modifying source to create a simple node. This makes the SG a dead end, IMO, unlike Amplify which allows you to extend it however you'd like and has much more robust support overall. Unity seems to be suffering from the mythical man month here..

 

It's easier with the items. Everyone knows that without items you can't move! In some matters, such as items, it is impossible to hide how important it is to us. I used to try to play without items, but it is very important that our game is colorful. Any self-respecting player will say that items are one of the most important items in the game.
Even my dad, who has been playing games for years, always told me that you need items.

https://odealo.com/games/path-of-exile/items

 

Unity Research posted a survey today asking for thoughts and opinions on Shader Graph. If folks here wants to make their voices heard this might be a good way to do it.

https://old.reddit.com/r/Unity3D/comments/kfr2d9/unity_research_share_your_thoughts_on_shader_graph/

 

Whats the end goal for the piplines? Unification or will they continue to be separate? Its insane how switching pipelines turns all my textures pink but in unreal its damn near seamless. I want to like Unity but I find it disheartening that it seems like they don't care about about a unified Unity like unity_8GpP3O6xy9RefA said above.

 

Unity never intended to have Unity between their renderers, otherwise they would have thought about how to bring them into Unity in Unity in the first place.

 

having 2 teams working on the 2 different official new rps in 2 different cities does not sound ideal to me.
just going through the folder structure of urp and hdrp you will see that they are completely different and this is not caused by design but just by personal decision.
and having 2 different teams with completely different experiences in game dev does not sound optimal either.
i can fully understand that urp does not support spot light shadows right now as they are evil. but i can not understand why urp does no support spot or point light cookies instead: these are 20 years old techniques to work around all issues you get when using point lights.
it just looks as if someone hasn't done his or her homework.

regarding unification of material descriptions i have never been a fan of unity - starting with the good old standard shader. there have been some improvements over the time but texture packing still is way from being ideal i think.
and no standard smoothness prefiltering still - after all the years!

 

Another horrible play by Unity...

 

As @Tim-C hasn't been active since November but I see @mirrormask is around - please can we get some communication going again, your initial post brought a lot of hope for increased transparency and it would be a shame for that to have been the last of it. If there is more coming but it will take some time to arrive, please at least just let us know that's the case. Even bad news is better than no news.

 

Thanks for posting that and bringing it more attention.

Sadly its a bit useless as its not going to capture many of the users like myself who've steered clear of the new Unity pieplines and ShaderGraph, precisely due to the problems discussed in this thread. The very first question "Which version of ShaderGraph do you use", I answered truthfully 'none' and that was it, survey over, 'thanks for your participation'! Sure that might give Unity a data point, but it doesn't allow the survey to determine WHY I don't use it.

Obviously I could try and take the survey again ( assuming its not tracking my PC ) and choose a different answer, but after a decade of using Unity and hitting these sort of issues more and more i'm no longer inclined to waste more of my time, when they have all the information they need from this post, the forums and other avenues.

Just to be clear, most of my issues with Unity have stemmed from poor decision making, deprecation of new yet often incomplete features for a newer incomplete feature. The majority of my work revolves around very short duration client projects with absolute hard deadlines of 4-12 weeks tops and simply doesn't permit time to learn completely new systems from scratch, especially if those new systems are feature incomplete, incompatible or a constant moving target.

Normally i'd bite the bullet and invest my own personal time to learn and incorporate these new features, but at present I just don't see the point. Examples of which are Unity's SRP, Enlighten deprecation/removal and having just been investigating VR I see the same problems there -steamVR no longer being supported, but the official XR plugin replacement not supporting native steamVR controller input - yet another mess that has existed for almost a year at this point. Oh and addressables when combined with TextMeshPro, where adding a UI element to a group will result in the full duplication of all TMPro assets in the bundle as they derive from a resource folder.

 

Just chime in to say this is mostly the same for larger projects: either we avoid the incomplete features or we roll our own, in very few case do our engineer/tech artist built upon incomplete solutions.

 

Also a word on the shader graph survey: on our project we are using 2019 LTS and we know any new shader graph features just won't help us, that make us very unlikely to give detailed feedbacks because we know our version is locked at 7.x; and the survey almost assume people will just follow Unity team onto 2020 to solve their issues.

 

Same here...started the survey with a truthful first answer, because i only occasionally look into ShaderGraph, but would not consider myself a "user" because I am again and again reassured, that sticking with ASE is the more stable choice. Couldn't give more proper feedback on the details, because the survey creator did obviously not care for that...

I felt strongly dishearted since months by the way Unity communicates and lives up to the strong words they brought up during the roadmap streams and all that.
Management decision making is still....peculiar...to put it nicely. Not just with the SRPs, that by now don't make any real sense anymore, because you just can't really go "outside the box" without loosing access to Unitys own tools (because VFX graph, shader graph, etc. are hard-locked to URP/HDRP)

Same stuff goes on with the whole XR development.You get half-developed solutions with questionable base-designs like XR Interaction toolkit, that was in hibernation for almost a year and now has one of the most ambition-lacking roadmaps, I have ever seen...
I'm not starting with the constant run-arounds with the whole XR plugin-stuff...

Sorry for the rant...but the current git-repo move just was the drop that brought me to vent that...

 

Surveys are almost universally devoid of value. They usually consist of a mixture of leading questions with assumptions baked in and overly broad questions where the possible answers veer between meaningless or inaccurate.

I think people use surveys because other people use surveys and they can't think of a better approach.

I too abandoned the this survey halfway through because I was having to make up answer after answer or pick an option that didn't fit.

 

URP and HDRP should be merged. One should be able to select (if it is not intelligent enough to get it by the platform one deploys to) what the minimum and maximum specs/features one goes for in current deploy platform are and then it should automagically do the right thing in the bg to make things work with intelligent scaling/fallback options as far as possible and then for the rest one should be able to toggle something like quality settings to turn specific things on/off on different hardware if something is totally not supported on specific hardware and no fallback available (it should then let one know in nice way so one can do something about it)
One has to plan the implementation a good bit more than my rough brainstormed gist of course, like whether all shaders could scale all that way down or up with automatically generated fallback/upscale versions or one as user adds multiple shaders for different spec ranges in a material or however one does it, how one toggles post processing and adjusts it for different spec capabilities etc where there is no automatic behind the scenes scaling etc but yeah, it is not acceptable to have a shader look pink when switching to a different RP and in general one should not have to switch an RP, there should be a single unified new RP and next to that old builtin existing until that new one is really fully all around satisfyingly acceptable replacement.
There should be a single post processing stack which does the correct thing in the bg to look as close as possible to what the user set for one quality/spec range level and then he could set settings for a higher/lower spec range level (so then it would do the urp/hdrp version stuff automatically in the bg)

Some may have thought having a URP/HDRP splitup fully seperate RPs could be a good idea at the beginning, but sorry, how long has it been? How much longer does the Unity userbase have to endure this nonsense which is so obviously not working out and with every month it goes on it makes things worse?
(and i mean sure not easy to manage a single RP which scales from all the way down to all the way up, but i think time also told us and you that managing so many separate RPs is even more problematic than that on way more ends)

Also, if some still don't get it: One of the very main reasons A LOT of the users are using an engine like Unity is because it allows to deploy a project to multiple platforms from a single project source and ideally make the most of the capabilities of the hardware and capabilities on each. So the idea of scaling all the way down on weaksauce hardware but also being able to use the latest high end bells and whistles on the highest end hardware with the same project base.
That one does not have to have multiple projects or deal with a giant manual transition of changing all materials/shaders/post processing/lighting etc manually by hand when wanting to go from something that was made for phones or switch initially to using the latest kickass graphics card/api features for highend pc/console (or the other way round)

With the separate render pipelines you are completely killing all that expected and needed wide platform and specs range support.
(Yeah, i know, marketing would say URP is intended to become the thing that scales most or could be used on the biggest (low specs) range of devices blabla, but then marketing has not listened to me and the others, we want Unity in Unity which means it should allow scaling from all the way down to all the way up with a single RP and single assets/shaders/post processing stack etc base) (while still also being able to use the most kickass features on the higher end ones which scale down where possible and get disabled where not)

One could still keep the functionality around for people to make their own render pipelines etc besides the (then) one new (unified) RP it ships with (besides builtin), but like others said, that is to most users a nonsensical offering anyway because a) too complex or too time intensive and b) not viable really for many things since a lot of unity systems are at best halfway usable working with builtin or hdrp or urp, as soon as one deals with an own RP then one can't use many of the unity systems with that properly anyway, so what's the point then.

It is not even just >cross platform deploy from one project base which can nicely scale from all the way down to highest possible level up (using the highest end graphics features in it, too on spec ranges which support it)< being made difficult to impossible by having those not cross compatible separate render pipelines for different spec targets, it is also most other aspects that were good about unity eco system being actively demolished constantly by this separate new RPs approach.

Like for example a huge strength of Unity was asset store and huge pool of community learning and general resources.
State now?
Total chaos where lots of things are not cross compatible anymore.
One basically has to check with every resource, learning content and asset/shader/post processing effect and what not all in which puzzle combination it is usable or not and likely redo all again from scratch.
(And lots of stuff created by the community over many years is not usable at all anymore of course with any of the new RPs etc etc).

Sorry, but come on Unity Tech, please wake up before it is too late, we need the Unity in Unity again.

In the long run it should be clear to everyone that those pipelines should be combined to one (as specs of the lower end devices increase each year, too), but i hope Unity does not take those years to come to that conclusion and does it in this new year already so the Unity users can leave behind this huge fragmented nonsense time.
(and your UT dev base that painful juggle of all those separate RPs and all things not fitting together and in each version different things missing and to reimplement etc etc)

(Also: I could say similar things about the whole dots approach, Unity should intelligently use dots/data oriented design etc etc) in the bg in all the systems as applicable/needed to get higher performance there, not expect most or even just half of the users to jump on board with changing their whole coding style or dealing with multiple and dealing with multiple versions of all unity systems and features each fragmented, feature incomplete and broken in different ways..
but yeah, that's a whole other can of worms and my comment is long enough already)

And only semi related:
Like others have pointed out the (meanwhile only semi) new XR plugin setup is still in sad state, so like many others i use the old builtin plugin setup way still (until if ever the new XR plugin setup becomes a proper reliable enough alternative) and then i see a new feature like Phase Sync for Oculus Quest and instead of it being exposed as a public bool toggle in OVRManager inspector on the script (or toggleable with a single one line call to OVRManager or similar), it is only exposed in the Oculus Android Plugin in XR Plugin usage setup.
Why?!?
I know, and i said, only semi related, but just another example for how you have so many un un-unified all incomplete in different ways versions of systems and features now on so many ends and then with such nonsense on top for some things even force users to use the new thing while it is incomplete and even buggy in major ways.
Sad Panda-
(So on that one @you and also @Oculus please expose the toggling phase sync flag in OVRManager inspector or somewhere else and also in general api call script usage way asap to also be usable when not using the incomplete xr plugin management way but rather still the still way more trustable old plugin way and oculus integration with that, thanks =) )

 

I actually really like that URP and HDRP are split. They're completely and fundamentally very different render pipelines. HDRP is absolutely not suitable for Mobile-VR -- and there's no way it ever will be (heavy use of deferred shading, full screen effects, etc).

Similarly, because of the platform compatibility and reach of URP, it is *really hard* to ever make URP on par with Unreal/AAA graphics. Just look how long it took URP to reach parity with the old renderer. HDRP succeeds because they largely only have to target consoles and PC. It needs that freedom to move quickly and chase higher standards.

If you've ever taken a look at the code underlying each RP, you'll understand why you can't just merge them -- they're really different. URP will never be as visually stunning as HDRP, and HDRP will never be as performant on mobile GPUs.

 

The problem is that hdrp is not performant as great as unreal. I spawned one same model of car in array and the fps difference is just cruel. i can spawn to hundreds of instances in unreal with no use of gpu instancing, however with unity i get like 30 fps. And that is QUITE a difference......

 

I can't verify if any of what you say is true or not apart from the fact that URP and HDRP are indeed very different, which I don't view as a pro at all, in fact I view it as the one of the biggest issues with Unity at the moment. All I can do is compare how it is now to how it was before URP and HDRP and how products I have experience with from other engines behave.

PUBG runs (well) on everything from mobile to a high-end computer. Fortnite runs well on everything from a mobile to a high-end computer. Both made with Unreal. How would you do that in Unity? URP or HDRP? And if you choose one or the other, why even have the other one? And would your choice then be to about sacrificing lower end performance for high-end graphics or sacrificing high-end graphics for lower end performance? Why? That seems ass-backwards. Apple iterated on their phone hardware until it was fast enough to be put into desktop computers and sooner or later they'll surely unify their operating system across devices as well. I feel like even thinking about mobile, desktop or consoles as separate devices at this point is starting you off on the wrong foot. You should be able to make your game once and then be able to make the choice of which devices to support at your own leisure, ideally with fully automatic tools to handle the scaling between devices. Having to make an upfront decision of what devices you think you'll want to support feels to me like the opposite of what Unity used to be about or where the technology is heading.

And on another note is it even somewhat realistic to think that Unity will be able to keep up with Unreal or AAA in terms of graphics? I feel like it isn't. I feel like staying relevant in terms of the latest tech involves so much more than just trying to get a vertical slice of latest tech barely up and running in some preview package in your engine. If Unity ever catches up to Unreal Engine 4 then Unreal Engine 5 will be out. And unlike Unity they will have the tooling required or expected to work with AAA content as well.

HDRP feels to me like an experiment gone too far, but all of this feels like an experiment gone too far to be honest. Unity feels like 3 different engines at this point and it's negatively affecting everything that made Unity great in the first place. Well, that and the fact that Unity feels like dozens of separate teams working on their own thing with zero communication or strategy between them on how to actually unify it all in the end. The "It just works" slogan feels like a parody by this point. There are multiple ways to do input, there are multiple ways to do animation, there are multiple ways to do UI, there are multiple ways to do rendering, there are no... multiple ways to do networking, there are multiple ways to do particles. And similar for all of them is that one way involves using an old system that's barely been touched for years and another involves a preview package. And to top it all off DOTS looms in the darkness like some unknown threat of a completely new, untested architecture that will replace everything that's come before it? Or something? Even thinking about DOTS makes me frustrated.

I at least feel Unity is extremely frustrating to work with and relate to at this point. I've not touched the new SRP's because the feel volatile and they still don't support the things I take for granted and thus the rendering tech I have access to has remained more or less stagnant since Unity 5.x. And with regards to everything else I have no idea what to put my money on except that I know for certain that all of the stuff that's actually included with the version of Unity that I'm using is going to be replaced by something at some point because Unity makes that part clear on every possible occasion. They just aren't very clear about what's going to be replacing it.

Look at the games made with Unity. I'm willing to bet every single one of the select few well known graphically impressive games made with Unity have source code access to the engine. And yet those games don't come close to the number of sales that some of the "janky" looking Unity games have. Games people play because they're just fun games to play. Games that were made in Unity because Unity is (was) easy to get into and iterate in and thus wacky people came up with wacky game ideas.

And I'm still waiting for that promised blog post about the removal of several repositories from Github which I'm hoping will give us some idea of what Unity's plans are going forward.

Lol, it's hard to write anything about this without it turning into a rant. Not really directed at your comment in any way.

 

All of these tend to share something in common—they are all monolithic replacements for their existing counterparts.

There is nothing necessarily wrong with this approach, as it allows users to continue working with the deprecated systems without worrying about breaking changes, and allows a complete re-architecture. However, it comes with a few drawbacks:

• Users now need to migrate to new systems, rather than adapting to breaking changes as they come in. This can make migration a huge task (learn the new system, move all their assets/code), rather than a series of small tasks with each version upgrade.
• The userbase of each new system starts at zero. Users are the ones that drive features, find bugs, and most importantly battle test tools.
• The feature set of each new system starts at zero. 100% feature parity isn't always required, but since it starts at zero it can be unclear what the eventual full feature set will look like for the system, and when a timeline for when it will be implemented.
• The userbase for a discipline/problem becomes fragmented, so now assets on the asset store, forum replies, Unity answers responses, reddit posts are all fragmented (and since the new features are optional, you can't just filter by Unity version!).

...so there's a lot of risk that users won't migrate, resulting in feature sets that are not complete or battle tested. Systems might also just never reach a point where they are production ready.

I think the Input System is a really good case study here. We can see an initial post about improving the input system happened in May 2014, while preview-0.1.2 was released April 2019 (not sure if there were other releases in between). I think the end result is a pretty great package, and I'd never criticize the team for delivering late—software is inherently unpredictable. But there are well tested ways to mitigate risks and I'd be interested if Unity has done any post mortems on the subject, since it's sort of been a trend for a bit.

 

Just to be clear, Unreal Engine also has two fully separate render pipelines: Mobile Forward and Deferred.

They just do a better job at building their asset tooling to support both. That said, their asset tooling is much less flexible - it takes 6 blog posts and many separate engine source code changes in UE4 to make a simple toon shader. So they sacrifice flexibility for ease-of-use, to make all this easier to swallow.

So the big issue, in Unity, is that both render pipelines aren't asset-compatible. It's rather hard (although getting easier) to make a material or asset that works for both.

 

That is one of the biggest issues, yes, but it is not the case that it would be all fine and dandy if that would be solved while they are still separate render pipelines with separate packages etc etc.

TwiiK's message summarized my thoughts perfectly, so i won't reiterate them way lengthy again now.

But in summary it is already the biggest fail that they are separate to begin with and that leads to a huge amount of other major issues on pretty much every end.
You say they are separate because so different that they would be hard/impossible to combine.
Like Twiik i share the same view: that is a major design failure then.
Sorry, all the platforms are growing closer together and getting more powerful (and new options are also becoming more popular over time like streaming games where client hardware is less important to begin with), it is a huge fail to make something which only works on some spec ranges or is only optimized for low end and can't enable highest end bling etc, and that way split up your whole community (as if there would not already be enough splitting and incompatibility points with each of the other multiple systems for pretty much every aspect)

All those issues all coming from the separate render pipelines with separate packages etc setup, ranging from making the whole editor not friendly to start with, making it a cumbersome decision with every project which Unity version/RP etc to go with (usually to then always get annoyed by different things not implemented or buggy in each), assets and libraries oneself and the community build up over a decade not working as it should in different ways in each etc etc and no proper solution in sight for fixing this mess as long as one goes in with "separate by design and it's gonna stay that way"

Yes, we know Unreal and other engines have different rendering options, too (like in Unity in older versions one could easily select between forward and deferred path or sure, now also things like regular old lighting paths or raytracing for this or that feature etc in different engines), the issue is that it all is separate in Unity instead of feeling like one unified engine where let's say i could choose different quality levels for lighting/reflections/ post processing or whatever and then the higher end versions would only work on higher end hardware (and could use a different rendering path or whatever internally) but it would all feel like one engine with one interface where it gracefully switches/scales and auto adapts for those different specs, not that one has to install different separate things which each have different degrees of different features implemented or not in different semi buggy ways which are on top incompatible to the degree of one having to redo everything.

If things would be made asset compatible but it still be separate render pipelines/packages etc, one still has all the many downsides like things only working in one and not the other or features still developed only for one and not the other because those teams are doing all separately and independently seemingly never anyone considering much wether this is a unified single game engine to the user or just a hodge podge of choose your patchwork puzzle pieces.
Most people want one completed usable reliable completed puzzle which feels as a whole as engine they can use in one way for everything, not broken incomplete puzzle pieces of five puzzle boxes thrown together and be told try to combine them to one thing or pick your poison of which not implemented parts in each you can better live with (of which half you can only discover in the middle of production).

 

Yeah, that's what I meant when I said asset compatible. A shared interface for both pipelines, so they feel like a single pipeline, even if there's different paths under the hood.

I understand that lots of people want this, but I don't want this. Part of the reason Unreal is a terrible engine is because it really limits the types of games you can make. Toon shading? Out of luck. Modify the underlying shaders? Nope.

Unity is kind of a mess for small projects that Just Want Everything to Work, but the flexibility is absolutely unmatched. I would really hate to see it turn into Unreal.

So there's this inherent tradeoff between flexibility and simplicity. Unity is (slowly) attempting to do both, which is really challenging, but I fully respect the goal.