Official Universal RP Status

I'm on 2020.1.0a22 (latest available on the Hub) but it's still 7.2.0 and not 8.0.0, and I have to unfold the "all version" dropdown to see it. The icon doesn't show that it's available, nor the update button.

Is it normal ?

 

Thank you, Multi-Pass is now rendering in both eyes but the camera jitter is still there. The jitter was not there when only one eye was rendering (Left Eye-MultiPass with URP 7.1.8). Unfortunately the multi-pass and multi-view are both jittering. (Unity 2019.3.0f6)

 

Sure, I had already reported issue with 7.1.8 two weeks ago. The same issue continues with 7.2.

 

Looking forward to trying out 7.2.0.

I notice that the linked project roadmap seems very out of date - camera stacking is "roughly six months" away, the roadmap doesn't look that much different to how it looked last year. Might be nice to get an update for that, so we know what's coming next!

 

Do Unity 2019.3 - 4LTS will get updates of URP or development and support for 2019.3 stopped now and only small bug fixes will arrive?

In other worlds. Do URP package will support older(LTS) Unity Versions like all asset store packages do?

 

Multipass renders in both eyes now, but both multivew and multipass are both thousands of OpenGL errors per frame "nobody can dev, let alone release using this" kind of broken. There isn't even a fallback to a version that works. It's this or back to Built-in. Is there an ETA for these issues or a priority queue? Would be nice for this to work before new features get added that can't be used until the fundamental issues are resolved.

 

Could you get volumetrics in URP?

 

In https://docs.unity3d.com/Packages/c...l/universalrp-builtin-feature-comparison.html comparison table, it says in research and I guess it'll probably come with 2020 LTS.

 

Are you facing the same jitter in Multi-Pass as well now that you were facing in Multi-view?

 

Thanks for clarify

Since you actually make separate version of package for each Unity Version I suggest to use Unity versions in packages to clearly indicate this.

e.g.
URP 6.5.2 -> 2019_2.5.2 -> 19_2.5.2 -> 192.5.2
URP 7.1.8 -> 2019_3.1.8 -> 19_3.1.8 -> 193.1.8
URP 8.0.5 -> 2020_1.0.5 -> 20_1.0.5 -> 201.0.5

 

Yep. At some point Multipass was buttery smooth, but only in one eye, and now it's jittery.

Queue James Franco: Fixed, but brokeeeen, but fixed! But still broken!

 

same here!

 

It is just that the camera is rendering too many objects at once which is why the jitter is caused. If you keep very few objects infront then the jitter won't be there. Unfortunately there is no solution for this.

 

Do you know when 1.2.0 is going to be made available as a package? Where can we pull 1.2.0 master to test?

 

In 2019.3.1f1 I cannot install 7.2 with the package manager.



I tried pressing the "refresh" button at the bottom, 7.1.8 is still the latest version detected. I also tried editing manifest.json to 7.2.0, but got an error.

 

Upgrade your project to 2019.3.0f6 (the latest version)

 

If your scenes use MSAA and Depth buffer you out of luck and you dont want to upgrade to 7.2
https://forum.unity.com/threads/android-urp-7-2-0-no-rendering-display-on-some-devices.827754/

 

2019.3.1 is the latest version, try installing 7.2.1

 

What difference is it making? Have they fixed the problem with Oculus XR?

 

Thank you very much! Editing manifest.json to 7.2.1 worked

 

It is causing by Render Pipeline's MSAA (4x). If you disable it, the jitter will disappear. But disabling it also makes objects have jaggery effect.

 

Is getting SpriteRenderer and CanvasRenderer to work with SRP Batcher anywhere on the roadmap?
I notice that it breaks SRP Batching due to MaterialPropertyBlock being used for rendering of sprite data.

 

Does that mean, if we have new features on URP, we'll not have them in 2019 LTS like SRP 8.x features?

 

Does that mean 2D Lighting will not be fully featured in 2019 LTS? :/

 

Any news regarding deferred rendering? Will it be compatible with 2020.1 or we have to wait for 2020.2?

 

Re: roadmap...


I'm sorry if it sounds negative but we would like you to finish your jobs with shadergraph etc before adding more and more features. Currently, there is so much missing from it and it is rather un-optimised.

I mean I see all these dazzling new intentions on that roadmap but not a single word on helping developers achieve better work with what you already half-finished.

I hate, hate being negative. I would only talk like this as a last resort. If this where shadergraph ends up, as it is today in latest 2019.3/2020.1 then I have to say it's simply nowhere near finished.

You're basically providing URP for speed then removing that speed again with current state of SG.

You prevent people from being able to dive deeper because things change a lot, that's fine. But you also don't give them a way to achieve things. Authors like @jbooth are left with no place to go. If you did optimise SG enough, and give just a wee bit more access in SG, then it would be acceptable as a compromise to dump a lot more custom nodes in. Currently that's just not possible. There's no per-vertex-calculation access for speed. There's no access to a vast array of things that are easily grabbed via vert/frag shader, states, tess, culling etc...

This is the future of Untiy's built-in replacement, and it will require using URP basically with vert/frag shaders for performance instead of URP shaders.

Where are the SG improvements on the roadmap?

You want us to use URP but force us not to.

 

Good to know thanks
Please consider adding shader code preview and implicit control for nodes like put computation inside VertexShader or Pixel shader and other optimization techniques so we dont need to rewrite all SG shaders by hand for optimizations.

 

Thanks, I spoke to Tim and have also gathered some intel from regular devs (crusty pros ofc) and am willing to feed back. These are really simple oversights really that can go a long way if addressed.

Thanks for listening

 

I just love that you say URP is production ready, but the documentation for shaders is scheduled from 6-12 months from now and we're forced to learn all that stuff by digging through your code every release for any practical production issues.

And opening the node graph API so you can write actual shader nodes for the graph isn't on there, meaning you plan to keep your SG basically closed to anyone wishing to practically extend it (as opposed to fork it), nor are you planning to provide any abstraction layer fro writing practical shaders that don't require upgrade hell on every single release you make.

 

My feedback for Unity is basically working with this, as it doesn't look near term for surface shaders. HDRP and URP are really far apart but graphs actually work fairly well with both right now assuming your template master node has decent ports.

So I'm just hoping really we can get dirty with function nodes that operate per-vertex so we can at least make everything almost as fast as our vert/frag stuff (assuming bandwidth isn't the issue). While this doesn't work how you would like, it would greatly improve performance if you were ALU bound (I am, surprisingly), and it's compatible with the existing lit / unlit templates.

Given vert/frag with function nodes -> master, the perf and ease of dev cannot really be much different from if you were using surface shaders. What are we missing?

Going to call upon the rendering gods to chip in as well as I do respect my betters @bgolus don't hide

 

Quite a lot, actually

• want to feed data from a compute shader into a shader? Nope.
• Want to do custom instancing code? Nope.
• Want to extend the shader graph with your own nodes with options for the user to select? Nope.
• Want to add tessellation? Nope.
• Want to do a geometry shader (ok, bad idea, but) ? Nope.
• Want to decode stuff in the vertex shader and pass to the pixel shader for use? Nope.
• Want to generate shader code based on use selectable options? Nope.
• Want to write multipass shaders? Nope.
• Want to write custom shaders for systems other than traditional materials, like terrain, post processing, etc? Nope.
• Want to write shaders that run in all 3 pipelines? Nope.
• Want to understand and optimize the code in a maintainable way? Nope. What the shader graph outputs is what you get, period.
• Want to do custom lighting functions? Nope

And this is just off the top of my head.

 

@erikabar @phil_lira

I don't fully understand this, please bear with me if I ask the obvious.

This isn't meant to put URP in a bad light, I just want to make sure I really understand it. It's an important topic to me, because we're at the beginning of a new project and need to choose what tech to use.

Features that are currently missing in URP, compared to built-in renderer, such as Point Light Shadows (1, 2) for example, do not get implemented for Unity 2019.3/.4 LTS.

Important question: Therefore URP won't have feature parity with built-in renderer for the entire Unity 2019.4 life cycle?

 

I see yeah. I'm using only URP and the game is for all platforms. By being able to do a lot of calculations in vertex I can solve all my problems. I don't need any options or most of what you need because I don't have customers to support so I really don't have your level of difficulty or needs.

I do custom lighting, and optimize in a maintainable way just fine with SG as it is. I use a custom function early on and do all my lighting in there. It's in an easily maintained main.hlsl file the custom function points to.

What do you mean? It's not going to change your code cos it's just a glorified code combiner and not a compiler, which comes later.

I can see now how much hell it is for asset store authors, but it's not that bad for individuals on games (with a few features to come).

Is pulling existing lighting from HDRP/URP into your own vert/frag shader a possibility, maybe with some tweaks on Unity's side? Perhaps surface shader-lite.

 

I have a post which gets into how they could make this easier but they have not responded to it.

https://forum.unity.com/threads/making-srp-shaders-easier-to-write.775085/#post-5158433

The problem is not just having a consistent lighting function to call; rather the ever changing combinations of special features as well, like all the VR rendering hooks, shadow cascade uvs being computed on the vertex in some cases, but per pixel in others in 7.2. New passes being added for deferred or raytracing. Having to manually keep up with all these changes and ship new versions for each one when the asset store structure only only allows per Unity version uploads, then making and testing across all of these versions when you make your own changes. On top of that, some code is platform dependent and on platforms I can’t even test on because I don’t have access to them, so all you can do is try to port it and wait for a user to report an error. And some of the changes to the structure are large enough to require a complete rewrite of my templates; I already have 4 versions of the code targeting 3 LWRP version and one URP version (note some versions just don’t work anymore), and the latest URPs SG code structure is radically different, so I’ve actually been upgrading the version from 7.16 hoping I’ve found all the changes because the adapter will require a complete rewrite for 7.2, which will most likely break tessellation and my vertex based workflow for meshes.

this whole thing is stupid and totally avoidable, and has made my job 100% keeping up with SRP issues, and totally not worth the money the entire product line makes to do. I wrote all of MucroSplat on Surface Shaders because this was the exact issue I was dealing with on MegaSplat, so now I have it times 3 because they seem to believe that asset store authors should be abstracting their pipelines differences in their products or split the tiny market in 3 when they themselves don’t even pull compatibility between their own pipelines off.

 

Shader graphs hide code complexity - That's the basic job of any node which is not just a wrapper for an intrinsic. As such, it's very easy to write less optimal shaders and not even realize you're doing it. In my view, shader graphs are wonderful for shaders which are close to the art- one off's and special effects, etc. But they fall down massively when designing shader systems.

Could you imagine what it would look like to rewrite the Lit shader, including all of its optimizations and features, in a shader graph? I know of no shader graph that could do that right now, on any platform, and rightfully so because that isn't the reason to have a shader graph. A shader graph is fundamentally about trading off some flexibility and performance for ease of use- ease of use which opens the task to a larger audience so that you can get more specific shaders designed for the art use case. But there's a cost to those abstractions, especially as complexity grows (both in the user interface becoming unmanagable, and the code being sub optimal).

 

Built-in renderer is still my all time favourite,

It never get's updates, so it never breaks ( some things still manage to break ).
And the new mobile devices are getting faster every year so performance is no longer the only issue,
I mean the new Samsung phone has 16 gb of Ram, that's much more than on a playstation 4.

 

Awesome! The PPv2 support was much needed! For some reason when I use URP's Integrated post-processing I get flickering when using Bloom. But when I change to using URP with PPv2 the flickering is gone and it works fine. Do you know what could that be?

I made a more detailed thread about the problem here:
https://forum.unity.com/threads/bug...h-urp-7-2-1-universal-render-pipeline.839968/

 

Installing URP 8.0.1 now. Fingers crossed.

EDIT: Whoops. Too early. Still no ShaderGraph 8.0.1 in the Package Manager.

 

With Unity not attending GDC where can I go to see the public roadmap

 

Tesselation will be a HDRP only feature?
What about URP?
The classic renderpipeline also had tesselation. If we want feature parity we would need tesselation to work on URP too.