What renderer to use ? URP vs Built-In + Some DOTS discussion

Hello,

I'm just starting Unity, but have 3D background with shaders/opengl and heavy C++.
I need to create artistic style (I mean not exactly PBR) fully dynamic scenes with multiple volumetric lights and particle effects.
And I need this to work on mobiles & desktops. Beta version is expecting within 3 month with production in 2020.
From first sight I understood, that I have to go with URP(LWRP) and probably VFX graph, but this comparison shows for me, that URP is not yet completed and then I found a lot of complains in this forum about features/quality/bugs of URP. From another side Built-In pipeline lacks VFX, will be deprecated (no development, no small bug fixes, just critical) and less efficient for mobiles.
Also documentation, blog posts and changelogs sometimes contradicts each other.
So I completely messed with direction to go and need advice from persons who have experience with both pipelines: which one is better suited for my project?

Thanks.

 

If you're just starting out, you'll likely find yourself relying on existing resources, the vast majority of which is going to be largely based on the built-in pipeline still. It's by no means a "bad" pipeline and it has been used on projects that match a similar scope to yours.

Remember, you can always learn URP, HDRP, and the entire pipeline system later if you find one fits your needs better.

 

I agree with this. This is the main reason why I've not switched to any of the SRPs yet.

For example, you mentioned that you want to use volumetric lights but neither the built-in rendered nor the URP have this feature included. For the built-in renderer, though, you'll be able to find multiple paid and free volumetric light implementations on the asset store, github, etc. I don't know about URP, on the other hand. It's so new that people haven't really developed many add-ons for it yet..

 

My opinion which I will not discuss:

Universal. Get stuck? ask forum. Why SRP?

• faster
• active feature development
• supports DOTS
• VFX graph
• Shader graph

Universal is also simpler, you likely don't need all the learning tutorials built-in required, and even allows you to visually do render passes and other stuff within the editor.

Sure, built-in has a lot of old crap floating about but it's exactly that: old crap. It's also rapidly falling behind, and so are all the assets that support it. Those individuals and amateurs (and most of them are amateurs) won't be fixing your sky and water problems forever.

Unity is solving those problems actively and ongoing with SRP.

 

I'd like to believe this, but honestly URP (formerly known as LWRP) still has show stopping bugs, and I'm not sure I would recommend new developers go down that route.

Sure, on a brand new, simple project, everything likely works with the new pipelines. But, most projects are not simple. My current project is a cross-platform AR project and it's a struggle to use URP along with ARFoundation. Eight months ago this blog announcement touted LWRP support. Everything's even better when ARFoundation added image tracking, which my project required. Then (not sure when it happened), ARFoundation + LWRP no longer worked together. Last week, with ARFoundation 3.0.0, it finally sort of works again (excepting an IL2CPP Android build).

Developing AR is not simple, the build/test iteration is painful and becomes more so when a project needs to be rebuilt time and again because of changes/updates to the plug-in and the renderer. Assuming this new user adds anything extra, like AR or an asset store product, they are likely going to run into frustrations.

I do agree, and appreciate what Unity is doing with SRP. The only reason I was willing to suffer through the pain of AR + LWRP is that the performance and quality is noticeably better than the built-in renderer. My hope is that the past year was a transitional year though, and in 6 months everything will settle down and 'just work' again. My fear is that 'transitioning' becomes the new normal and with each project you have to do a ton of research to figure out the correct combination of packages to make a stable project.

 

I see, but your situation is specific to AR if I'm not mistaken. So if that's the case then anyone not on AR, who are beginning a new title should compare built-in to SRP and factor in if they need graphs/future proofing.

The Universal renderer is *significantly* simpler and cleaner than the built-in renderer so it's not going to have that much of a long dev time.

 

Yes, my complicating factor is AR. The OP mentions the project will use VFX and I would assume Post Processing as well. Add in a potential need for camera stacking as the UI is built out and suddenly you have a complex set of interactions and compatibilities.

The VFX graph is more performant and superior to built-in features, but we lose camera stacking (a standard practice for years). Maybe that's OK for the project, but for a new developer the standard built-in route is going to feel more stable and predictable in features.

OTOH, if they go built-in and then decide they really need Post Processing, I cannot even recall how that works in the built-in pipeline or where to import it (Package Manager or Asset Store?).

 

Package Manager.

 

I would personally recommend using the URP because you are just starting Unity and you could jump right into DOTS, rather than use the "classical" method.

From personal tests I have done URP appears faster by default for a wide range of scene types and when you combine it with DOTS performance is uber quick. This might also be beneficial for a save/load system as decoupling the data makes it easier to manage, and has the benefit of being quicker when loading scenes.

My vote is for URP if you want maximum performance on mobile. DOTS is just on another level. ECS + job system + burst compiler on URP will give you much better results in terms of performance.

https://unity.com/dots

 

But DOTS is not a general purpose solution. It doesn't replace the "classical" method, it operates alongside it to provide improved support for specific types of use case.

Plus, if you're just starting then learning the basics first rather than jumping right into specialised systems is probably a good idea. Walk before you run.

That said, I think I agree that URP is probably a good idea for new projects. Hopefully I can provide an experience backed opinion on that in a few weeks. The transition period where URP is becoming the new standard will probably be a bit bumpy for new users, but why learn the old one if you know you'll have to change again later?

 

You make it sound like every project is a fit for DOTS, which ofcourse is not the case. It in no way replaces classical unity development, it is something that can be leveraged for some projects depending on viability

 

We would need to see a screenshot of what you are trying to do.

In general, you should use built-in. Why? Because it's the most stable platform and almost every Unity mobile game was built using it and they perform just fine. There are no real performance concerns if you do basic optimisations. All store assets work, too.

URP is them trying to recreate Built-in in a more modern way, but it's basically still LWRP right now.

If you need VFX graph then you will need to use URP or HDRP. If you need volumetric lights then how are you doing that on mobile devices? You can get them in built-in with an asset, or you can fake volumetrics using various techniques (depending on what you are trying to do).

 

Thank you very much for your advises.
I got a look from different perspectives.
And by the way I tested a little URP. Looks better from fps, manageability point of view. VFX somehow works. Post processing doesn't work for me. Probably not yet implemented. Shader graph is not so bad to work with. And custom node is a winner.
So I will try to go with URP and write custom shaders if necessary. In worst case I will adjust design to URP (and my possibilities.

 

It is implemented but it's accessed differently than the built in renderer.

 

Really ? Any clue where it's written how to use ? I didn't find any special package except Post Processing 2.1.7

 

You guys think upgrading to newer version is worthwhile for a basic desktop/console project that largely uses unlit, handpaint shaders?

Perhaps the shader graph is bonus for non-coder, but what if we already got third party solution like amplify? Any other reasons to upgrade beyond improved realistic lighting?

 

I'm not aware of any documentation. I just created a blank project and in the sample scene was a "Post-process Volume" with the "Post Process Volume" component attached to it with Bloom, Color Grading, and Vignette by default. I was under the impression it was in an odd location like with HDRP but it appears I was off there.

Spoiler: Screenshot

 

It literally replaces the classical way of unity development... that's why the old way is being called "classic". This isn't an opinion - it's been clearly stated in DOTS documentation and videos about how its the "new" way to program fully intended to replace the old method of using gameobjects and monobehaviour. It's likely they will not remove the classic style but it's akin to walking vs driving. Driving is objectively quicker... Sure, you can walk 10 miles but if you drive it will be much quicker and less stressful.

it might not be a full replacement yet because they're still working on it but it's been stated multiple times that DOTS is going to be the way forward.

"We’re rebuilding the core foundation of Unity with the high-performance multithreaded Data-Oriented Technology Stack."

They are rebuilding Unity's core foundation to work with DOTS. I'm not sure how you see this as not being a direct replacement to the classic way of programming.

 

They changed how post-processing works but the documentation is a bit lacking. You basically add two components to the camera (PostProcessVolume and PostProcessLayer).

on the camera in question add the PostProcessVolume and PostProcessLayer components. Set the post process layer to a custom layer "Post Processing Layer" for performance reasons. You also need to create a post processing behaviour profile and drop it in the slot in the post processing volume's profile slot.

 

Care to provide a link to this documentation? Because I haven't found anything resembling proper docs for DOTS.

 

Well there isn't "official documentation" for DOTS yet. I picked the wrong wording but it's easier than "stated in a collection of videos released by Unity, the information available in devblogs, and other various videos or code snippets including github which act as documentation insofar as they provide examples of classic vs DOTS and related systems". But DOTS documentation could refer to anything (videos, articles, blogs) from Unity that talk about DOTS and ECS vs classic, of which there are quite a few.

This is something I've noticed quite far back.

https://blogs.unity3d.com/2019/03/08/on-dots-entity-component-system/


Game Objects aren’t going anywhere. People have successfully shipped amazing games on it for over a decade. That foundation isn’t going anywhere.

What will change is that you will over time see our energy to make improvements tilt from going exclusively into the game object world, towards the ECS world.

https://github.com/Unity-Technologies/EntityComponentSystemSamples

The Entity Component System offers a better approach to game design that allows you to concentrate on the actual problems you are solving: the data and behavior that make up your game. It leverages the C# Job System and Burst Compiler enabling you to take full advantage of today's multicore processors. Moving from object-oriented to data-oriented design makes it easier for you to reuse the code and easier for others to understand and work on it.

To me this is a clear indication Unity is moving towards DOTS and away from the classic style of development whilst still maintaining support for those who don't want to move to DOTS.

 

As the topic has veered into DOTS land (and it should because SRP is the only real way to take advantage of DOTS for rendering) I might as well mention visual scripting is DOTS too. I mean what we're looking at is what Unity's been calling "Unity 2" in some internal circles. It's basically a complete rewrite from the DOTS up and built-in isn't a part of that. So yeah it's fine to use either but to make the most of it you'll want DOTS backbone.

Really the question is if your game will look 10x better because you could put 10x more on screen vs if you want to rely on asset store.

 

With a beta delivery date within 3 months, I'd probably go with the legacy pipeline at this time.

 

DOTS based rendering isn't anything to write home about right now. It's just missing too much, and unless they all the sudden decide to pick up the pace on it, it's going to be a long while before that changes. We have been using DOTS since simple jobs first came out, 99% of our own stuff is all in DOTS. And it's rendering is remarkable in that it's the only part of DOTS we don't use.

 

I disagree but it's a personal opinion. The Megacity demo is something that couldn't be done with the classic method. (and I don't call it classic to be mean-spirited, it's just the term I've heard used by people like Mike Geig in videos when talking about DOTS/ECS vs GameObjects/Mono

 

I don't agree that they couldn't have made Megacity without Unity DOTS. Unity loves to show off demos with extremely high numbers of entities moving around in them but as impressive as these demos are the reality is it wasn't the first time we saw that accomplished in Unity.

We had entity component system frameworks before Unity DOTS.

https://github.com/sschmid/Entitas-CSharp

We had the ability to draw meshes with higher performance than using a GameObject.

https://unity3d.com/unity/whats-new/unity-5.4.0
https://docs.unity3d.com/ScriptReference/Graphics.DrawMeshInstanced.html

We just didn't have the ease of use we have now with Unity DOTS, and would have had to use more smoke and mirrors too.

 

I guess it depends on the standard for implementation. I don't think you could implement it in the standard way and get the same performance. I know ECS and instancing has been available for a while but things like the burst compiler haven't (at least it's still preview)

https://blogs.unity3d.com/2019/02/26/on-dots-c-c/

"We’ve built a code generator/compiler called Burst. It’s been available since Unity 2018.1 as a preview package. We have a lot of work ahead, but we’re already happy with it today."

"All users benefit as the parts of their frame time that are spent running engine code (usually 90%+) get faster. "

and most importantly...

"By writing Unity’s runtime code in HPC#, the engine and the game are written in the same language...... where nothing is stopping users from writing a better particle system, physics system or renderer than we write."

That's personally some of the reasons I think it will be able to produce scenes that can't be done with the conventional method. Whether those things are useful to hobbyists or even non-professionals is questionable. Not sure I can see myself writing my own physics or particle systems any time soon if it's not 100% necessary.

 

Thank you, it's really works!

 

It absolutely could have been done without DOTS. Excluding stuff that wasn't even released yet like the audio. This isn't a matter of opinion. This is stuff we have code and data for, and some of us have actually been using it and know exactly how well it performs and what it can and can't do.

 

I'm not trying to say it would be absolutely impossible to get it running using the standard method but it's obviously faster and better performance using DOTS...You could get megacity to run on a potato but just with a poor framerate, stuttering, etc. That's what the whole Megacity was designed to showcase afaik. In the longer videos they talk about how they tried to push it to the maximum and how ECS and DOTS was the reason they were getting such a stable framerate with so many objects.

I've looked before but haven't been able to find a video reproducing the Megacity using the standard vs dots method because i was curious about how they compare so if you have a link I would be curious to see the performance they get.

 

I've edited the original title of the thread to include some DOTS discussion as its actually quite relevant to picking a renderer.

Some random extra thoughts:

• You end up saving a TON of ram with the DOTS stuff. Streaming is cake, and takes very little time to load a world, or snapshot or stream meshes etc with DOTS.
• Stuff is less dynamic without DOTS. You just fake it, sure, but it is faking it and you come up against some pretty hard limits to how dynamic or changing something can be. It also extends dev times as tricks do cost you in R&D. Throw it at the world, let it take care of it.
• SRP. This is the biggie. You don't batch by material any more. You batch by shader. This is a huge deal. It means all your LODs and the hundred thousand objects remain interactive speeds. Can you do all this without SRP and without DOTS? Yes but forget anything being dynamic and you will take longer to make it.

Full disclosure through I'm on HDRP. I'm not moving. I really like this engine. It's stupidly fast in the right hands. It's getting even faster. As soon as DOTS is mature enough (I mean proper editor conversion) then I'm migrating to it ASAP for a full DOTS main project.

The performance gains are way too good from personal experience but I am of course wary of stability, of support and workflows. These things are what I, and everyone waits for.

The SRP though, IMHO is very much ready if you're not doing AR and you can prepare your rendering for DOTS improvements without coding in ECS. Behind the scenes, the Unity engine is being optimised with SRP in mind. So for me there is no reason to contemplate builtin for any new projects and it's why I recommend SRP.

The time a new project will be finished - any serious one - will be a year off from now. Thus, for any studio it's a decent safe bet if the SRP of today works for you.

 

Just to add some discussion, i saw that some people talked about AR, so i just want to discuss about VR, especially for the Oculus Quest. Should i use build-in render (classic render) or URP ?

I tried build-in render and it works quite well. But the "future" seems to be the SRP (URP in VR mobile case).
Any opinion ?

 

@hippocoder, @Anaxis_Studio
Hi, I would really like to use URP with DOTS, but unfortunately currently both of URP(SRP Batcher) and DOTS are not working correctly.
How do you think about it?

https://forum.unity.com/threads/are-unity-subscenes-and-lwrp-compatible.717422/#post-5184914
https://forum.unity.com/threads/batchrenderergroup-doesnt-render-ambient-color-on-urp.786242/

 

Did some basic tests in 2020.1 today and URP with Post Processing resulted in worse performance than built-in with v2 stack on mobile. (25fps vs 35fps).
The funny thing is 2018.4 with v2 stack had 45 fps, and 2018.4 with v1 stack had closer to 60 fps, which is ridiculous.
I'll do more research tomorrow and post better structured results.

 

I believe that, given that I've read that the new URP stack includes such features as "hardcoded-16-pyramid-texture-bloom" amongst others. And the PPv2 stack itself isn't exactly light either, with up to 1ms/frame on the CPU wasted on bad for loops iterating over volume settings that don't exist.

To the topic, if you want to play around, use the new stuff. By the time you (possibly) get serious, there's a slim chance that it might be production-ready enough to ship a game. Until then, if you are serious, you'll know that all the scriptable render pipelines, DOTs, etc, is about as production-ready as most new Unity features

 

I have a thread on this I just speant about 500 dolalrs on assets for this topic unity fails to cover properly to become even more of an issue than it was while I was sitting there taking two or three days before making every purchase thinking it through appearing to be able to use vfx without having to upgrade to hdrp and use its horrendous way of dealing with materials. As well as seeming to want to force ecs if you want to release a multiplayer game so youre now forced into scripting the rendering as well as learning ecs and changing the code to hinder releases instead of helping people release stalling hindering and just being an obstacle instead of the every asset that is produced helping you build your game were going to help you build your game half of us probably being unity coders leaving out functions to get self profit from coding it on the asset store up to millions of dollars per asset while unity hinders, stalls, prevents you from releasing it.


So while looking at all this bullshit on new render pipelines I make decisions to not use hdrp because it is a complete failure with materials and height maps, see that I wont be using hdrp and appear to not need it for vfx graph, and then decide to make a bunch of purchases that liekly cannot be used to even release my game with just going to be throwing all that money in the garbage period cant be used just there to buy it and throw your money in the F***in trash.. and get no response on the forum bringing up the topics just F***ing screwed by people who refuse to admit mistakes etc like the rest of america in specific and the world in general.


I am able to load in vfx graph into I guess im using built in legacy or standard pipeline. This parts confusing, and doing so and seeing it work made me decide to use no scriptable pipeline and buy some assets that do not work for scriptable pipelines.

Because I thought this was universal that got moved and named lightweight while hdrp was the new addition however its been three years looking into unity. Theres focus on these two with not much mention of what we were using and that sounds like universal.

Can I use shadergraph or vfx and it works in my built package because vfx graph appears to be working in the editor.

I dont want to use hdrp (due to material change) or lwrp really I'd rather use the built in renderer and be able to release the game how people were releasing them without extra stuff that appears to try to make things more complex for releasing a game online while giving off an appearance of being effective and performance as a reasoning, while having some needed additions like vfx graph, I started to learn game design and now its like I have to learn something entirely new just rebuilt the engine from scratch to release a game is how it feels everything you knew is now worthless.

I want to use legacy shader and be able to use that pbr workflow using just the standard shader (my height maps come out horrible in hdrp I wasnt going to go here but I do have screenshots saved and hdrp has been complete and total garbage for me and I dont want to use it but I want vfx graph --most important feature that the game requires above all assets I just paid for maybe even worth a game in hdrp with the most horrendous looking materials on the pyramids possible due to heightmaps going on a degenerate path evidentally -- and shader graph which is lesser important and then will look into its materials later and see if theres some kind of reasoning to force a full switch which I dont see happening (for things like fish I already know its types like see through a leaf or hand, or color around the outside to sheen onto fish, and transulcence I looked into it quite a bit was going to use it....) and I dont want to change to using different sets of textures when I can create these standard pbrs with a workflow I like and they are somewhat simple to do and effective) to create my game, I dont like using hdrp materials atm and many of the assets I just bought do not support scriptable pipelines.


So now im looking at amplify shader since I dont know if I can release with shadergraph anymore or even use vfx graph which is in the project and appears to be functional.

I cant tell if documentation is just outdated or not.

To be honest with you this engine is kind of a mess right now, a thought stemming from the asset store situation, easy to regret purchases and wont get a refund if you cant use them, as a matter of fact if you need a refund and cant use it for either your project or just for what you wanted as seemingly advertised you might see that person promoted into a unity coder and the asset goes into unity officially still not accomplishing what you paid for.. for kind of being bad/shady business, although the software has its other uses. Then what you wanted is in the asset store (digger vs polysculpt and now a really good free sculpting tool 3d artists should look at its amazing with unity instead of zbrush maneuvering for a less headache workflow I have a rating there youll know if youre on the right one)... its on the asset store yet you arent going to buy it since it dont support hdrp and guess what you see that you can import vfx and it appears to work and unity might be outdated in their documentation however you probably wont be able to use this in your game either even after paying for it.

You need to focus on spending money on assets to not build your game and spend money in the asset store forever evidentally.

 

Here's my post with more details: https://forum.unity.com/threads/per...ions-of-unity-post-processing-and-srp.786944/
I'd be very grateful if someone can point out to me what I did wrong with my test and why I get such a bad performance.

The problem that I see is not only with URP but with PP Stack v2, which initially is so much worse than v1. Also, Unity 2020.1 itself is slower than 2018.4. When all these performance issues accumulate, I can't get a basic primitive scene to work at 60 fps. I mean, what are my options here?

 

No, it's not like that at all.

 

You think you know but how many people that work for microsoft do you personally know and know everything theyve done in their lives to other people behind closed doors, youre speaking without knowing. Which you kind of should of just let it be how it was without a two cents addition.

Without defending what you dont really know.

 

You're comparing your issues with a game engine to human trafficking. That is so outlandish as to be laughable.

 

Please try to avoid going so far off-topic. And I'd like to remind you that we want to foster an open and healthy discussion within the community - but we won't tolerate disrespectful behaviour towards other members. Thanks!

 

I'm starting a new project atm and struggling with this question. The game is low poly, similar to something like Astroneer (in terms of 'lighting' and low-pol). So I'm thinking URP is over the top for my project?

 

Astroneer can be done in any pipeline. Your decision should be based on what features/performance you need, and what platforms you need to support.

 

IMO the SRPs are not production ready at all, unless your game somehow maps exactly on the feature set used by Unity's demos.

URP is lacking a lot of features, every time someone bothers to benchmark it against built-in it comes out slower, and if you use HDRP you lock yourself out of Switch, mobile, or running at 60fps on PS4 and Xbox One.

With built-in you can at least buy your way into nice graphics on the asset store (remember: Adam and The Heretic were made before SRPs), while with the SRPs as soon as you need anything that can't be done with shader graphs you'll find zero documentation and a plethora of obsolete tutorials due to the ever changing architecture, which severely hinders the creation of SRP-compatible assets.

 

It's considerably faster here for me but perhaps we are doing very different things. If you think URP is slower than built-in do file a bug report as Unity considers this an actual bug.

 

The Heretic exists specifically to show off the HDRP. That you don't even know this suggests to me that the rest of your post is made up of statements solely from you rather than from any actual sources.

https://unity3d.com/the-heretic

 

My mistake. It was indeed made using HDRP, but it was heavily customized back then and they recently rewrote it to function on stock.

My sources are the countless threads in the SRP forums with egregious bug and bad performance reports. I have yet to see proof of URP running faster the built-in, specially on mobile, "if it runs slower it is a bug" be damned.

 

Assume much? The "customized" parts are part of VFX and you can just go right ahead and do that in the VFX graph. This can all be done in Unity. There's no special locked-behind-closed doors stuff. What's happening here is you've decided you know and somehow that's not correct.

 

There was a github fork specifically for the Heretic, but I'll stop here. Seems all my complaints are invalidated by that one mistake then.

 

By everything you said, actually. You even went as far as to hand-wave vaguely at other beginner's assumptions about SRP rather than bringing forth your own or a case number.

I'm going to keep on here because stuff like that is harmful to all devs, not just you. All incorrect information is harmful to development.