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

I'm pretty sure there was a hack week project for exactly this, as well as one recently to compile burst jobs to the GPU. I personally have not focused on this much because it seems like it would take substantially longer, and require a lot more code. It also means that when some new shader technology ships (mesh shaders, etc), you have to do a lot of code to support it, where as with raw HLSL it just kinda works once you do whatever application scaffolding you need (this is the same with shader graph, which usually lags way behind code shaders because you have to write all kinds of custom nodes and generation code to add support for new things).

 

Interesting idea! Do you want to prototype that? I've set up a basic shader importer and block-parser in case you're interested:
https://github.com/pschraut/UnityModularShaderPrototype

Spoiler

 

​

So, reading through it all, I don't understand how both can't be incorporated? Each release e.g. 2019.X can release with a "core" URP set that Unity officially supports for that version, to ease targets for the asset developers. They can also release the URP set and additional versions with bug fixes etc. as packages vs. using GIT, saving a step for their other customers that aren't asset developers specifically. And Unity can decide to support these between version packages as production ready, or beta only until the next full release, etc. and as a customer, asset developer, etc. you can decide where to land within those e.g. only each major version or up to X package, or whatever.

I don't see why we can't have both?

Separately, as to the comment about it not being different, from a business management process it is completely different. I work primarily in an entirely different field from game development related to business management, and developers just downloading from a GIT and placing into production without strong controls / authorizations around it is a big no no. It still happens all the time, but doesn't mean people don't get in trouble for it. Just saying.

 

Yeah that is a good point. If shipping SRP as core leaves these issues with URP unresolved, then it probably just isn't the right time to include them as core. The idea itself is fine, but that doesn't mean the change has to be made now, it may just be better to keep them as packages so that backporting key features is possible until they are more feature complete.

Alternatively you could have core SRP, and separate packages for new features (so the features can get backported), but I'm not sure how this would impact the development process, could be a bit messy since some features would need to be tightly integrated.

Either way I'm a bit concerned, as I haven't seen much from the Unity developers showing that they even recognise that restricting new URP features to new releases is a problem, let alone that they have any possible solutions for it.

 

forked, now compiles working shaders, unlit only right now:

https://github.com/slipster216/UnityModularShaderPrototype

There's a bare bones example, and one which does a snow shader as described above. There's a lot of funny behavior with how ScriptableAssetImporters work, such as not clearing the error list on import until the shader compiles fully, or not opening the file when you double click on it, wrong line numbers on errors, etc, but as a prof of concept it works.

 

That's great. Please let me know if there is anything missing on the tools/import side that would be useful to get the idea further across or would help to create those modular shaders as a showcase. I guess, I could add a "Show generated shader" button etc if that would be useful.

I noticed it too, but ScriptedImporter is in the experimental namespace, so I guess there is a lot more more funny things when used "for real" . But overall, for a prof of concept, it should be ok.

PS: If you could make a PR, I would merge your changes.

 

the video itself is already very attractive, everyone should open the "spoiler" and watch the video first.

and for jason's fork, I recommend convert the template file(https://github.com/slipster216/Unit...es/Resources/SurfaceShader_Template_Unlit.txt) to an actual .shader, just like amplify shader editor's design (https://wiki.amplify.pt/index.php?title=Unity_Products:Amplify_Shader_Editor/Templates)

because a .shader will make writing template file much easier and prevent errors(for people who want to write their own template files from scratch, and want to compile the shader to check warning and error and SRP batcher compatible .etc)

 

I mean, I likely won't take it much further. I might add struct stripping as an example of how that can be done or something. The real challenge has never been to write a surface shader model, it's always been in getting Unity to maintain it through their changes so we don't have to constantly diff their shaders and figure out what has changed.

For a PR I'd need to be added to your depot, it's write only right now..

 

I will try to sumarize my thoughts as much as possible, otherwise this would be too long and not that useful.

• The core API of SRP is mostly very very good because how low level it is, allowing what's impossible with the legacy pipeline. I made my own SRP with only what I need and how I need, something URP can't do because it makes assumptions that don't match my game (and that's not a problem). But this wasn't easy because:
• There's no documentation on how to make your own SRP. As stated before by others, current auto generated docs are not useful. Something that explains my problems with the next points.
• I had problems with the frame debugger (why is it not working with my SRP?), I'm still having issues with the scene view draw modes (How is this supposed to be really used? docs say nothing. https://docs.unity3d.com/ScriptReference/DrawCameraMode.html). I don't understand how gizmos really work (this API also configures a camera? idk, the docs say nothing https://docs.unity3d.com/ScriptReference/Rendering.ScriptableRenderContext.DrawGizmos.html).
• There's no example or a minimum barebones example of a basic pipeline. That results in the need of reverse engineer URP (large piece of complex convoluted code, specially because of it trying to being generic enough).
• There's no documentation on the shader side of the SRP core. More reverse engineer.
• There's no example or a barebones example of a custom SRP (I had to start with a tutorial from a third party to even know where to start, then reverse engineer URP by removing half of it to simplify it).
• There are methods that should be called at certain points during rendering (Example https://docs.unity3d.com/ScriptReference/Rendering.RenderPipeline.BeginFrameRendering.html) but nowhere they are listed.
• There are variables you very probably want to set up (_Time, _SinTime, _CosTime, _ScreenParams, _WorldSpaceCameraPos, lights, shadows), again, not said anywhere and require reverse engineering of URP. Specially lights and shadows were a pain to have them working.
  
• There are useful tricks I found by chance that I really needed. For example using DrawingSettings.SetShaderPassName (https://docs.unity3d.com/ScriptReference/Rendering.DrawingSettings.SetShaderPassName.html) with several pass names lets multipass shaders work as long as the pass have a name and are specified in order with this API. The documentation page seems broken, though, there's no title, and the auto generated documentation text is far from being clear about what this function really does.
• I still don't know how the Graphics API works together with SRP API and the ScriptableRenderContext object. It's not clear how they work together. That's in general the problem, there's not enough clarity, the documentation is not enough. Someone that isn't from the SRP team must try to use this API while the team looks at that person try to solve the puzzle SRP is.
• Just another example of documentation issues: https://docs.unity3d.com/ScriptRefe...tableRenderContext.SetupCameraProperties.html doesn't specify the specific variable names it sets up, and only gives a rough list of them, saying that it also may set up undefined stereo-specific shader variables and states.

There's also small nitpicks that can be a deal breaker for some:

• Can't get (EDIT: set or modify) a list of the renderers obtained by a culling result (https://docs.unity3d.com/ScriptReference/Rendering.CullingResults.html).
• Can't manually sort renderers, only configure a very limited set of parameters to control it (https://docs.unity3d.com/ScriptReference/Rendering.SortingSettings.html).
• Using CommandBuffers, can't resolve a temporary MSAA RT (https://docs.unity3d.com/ScriptReference/Rendering.CommandBuffer.GetTemporaryRT.html) to another temporary RT.
  
• Using CommandBuffers, can't obtain a temporary RT with a specific wrap mode, only repeat mode (https://docs.unity3d.com/ScriptReference/TextureWrapMode.html).
• When a shader is not compatible with the SRP batcher, the errors are not detailed enough (for example, error

  Material Property is found in another cbuffer other than "UnityPerMaterial" (variablename)

  doesn't specify the cbuffers, files and line number it appears on. This is important as the variable can be declared by Unity's own shader code, like the variable

  _Cutoff

  ).
• CanvasOrder sorting criteria can only be used with UI. This is not specified anywhere, and it's also not specified how this sorting works (I assume it uses the order in the hierarchy) https://docs.unity3d.com/ScriptReference/Rendering.SortingCriteria.CanvasOrder.html. This could be useful to render stuff alongside the canvas, or just for whatever artistic reason someone has in mind, though manual sorting may obsolete this problem.

I have to say that I found a bug related to SRP and in 2 days Unity got back and started fixing it (though it has been a month and they are still at it (made public here https://issuetracker.unity3d.com/is...sulting-in-incorrect-render-order-slash-depth) so that's very good as I usually see bugs as something to work around as assume they won't be fixed, but in this case they are incredibly active.

To finish, the best thing SRP provided me was having total control of the rendertargets used at any moment, and being able to redefine the renderqueues (ranges, sorting modes and adding custom ones), including being able to perform actions between them (in my case its something like this: Opaque, Skybox, Grab depth, Decals, Transparent, Grab Screen, Transparent with distortion, Post effects, HUD)

 

Sorry for the late response, needed to read and re-read the original post and digest it for a while.

Everything in the post looks great. Others have expressed concerns that are valid. Not much more I can add there.

I am wondering if the real mistake was creating URP from LWRP instead maybe a better path would have been to keep LWRP, HDRP, and then create URP from the ground up to match the builtin render and also be extremely customizable.

The way I interpret the SRP:

Custom built SRP - user built by graphics engineers knowing exactly what their respective requirements are

LWRP - template designed and OPTIMIZED for low end hardware

URP - template designed to be customized for those not wanting(or lack of manpower) to engineer a custom built SRP from the ground up

HDRP - template designed and OPTIMIZED for latest hardware

I really like the design and idea behind the SRP system but it is a tough system to engineer and explain to users.

I want to point out the word OPTIMIZED here on the LWRP and HDRP . I think a lot of pain points are assumptions that the LWRP and HDRP currently should be fully customizable but if you do that you lose the ability of those respective templates to be very fast and well optimized for the target hardware.

In other words if I choose LWRP I have access to a set of features that are guaranteed to work very fast and MAY have slight customization. For instance you do not have access to real time point light shadows in LWRP because they are a not as performant, deferred etc.

On a side note whether the SRP is in Unity CORE or as a package does not matter to me. Maybe a design decision could be is something a system or a tool. Systems go in core, tools go in packages for example

SRP is a system so it goes in core
New input system is a system so it goes in core
Probuilder is a tool so it goes in the package manager
VFX graph is a tool so it goes in package manager

Cheers to the Unity team, There is no easy path, all of us here know this.

 

To be precise, LWRP is no longer a thing, URP completely superceded it.

 

@mirrormask First of all --this is great news and thanks for making this post to address these topics and the communities' feedback. It is one of the hallmarks of Unity. One major missing feature in ShaderGraph that ties into this SRP / Shader API roadmap still appears to be unanswered. Perhaps it is planned / encapsulated in what has been said here? but I don't see this being specifically mentioned in the original post or in this thread (or in the ShaderGraph roadmap or any roadmap talks that I can find) so let me highlight it:

We need a Custom Master Node API.

Not just a Shader API for writing SRP shaders (in the spirit of ShaderLab surface shaders) or deeper custom code node features exposed to the UI. (Though those are welcome also.) It seems like every asset developer that is unable to use or fully embrace ShaderGraph is unable to do so (and still using Amplify or just writing raw SRP shaders etc) is because of a lack of a Custom Master Node API. There is also a laundry list of custom master nodes that I and others at companies big and small would like, e.g. render texture and structured buffer output master nodes, raymarching / volumetric master nodes, custom ocean surface master nodes, any sort of custom lighting, you name it. And while Unity might be planning some of these as official master nodes, I don't think anyone is banking on Unity to maybe someday write the master node that does exactly what they want. Currently it's worse than just not having an API... aside from all the guesswork, you often can't extend SRP or Shader Graph, VFX Graph without duplicating entire classes just to change 2 lines of code or completely forking the entire package codebase because of all the private and protected members due to (well intentioned but absurd) OOP encapsulation "best" practices. (Not to blame Unity specifically. It was a software industry-wide group effort. The blunderous realities of what the OOP paradigm became in practice today is even highly criticized by Alan Kay the inventor of Object Oriented Programming himself. An example of its misgivings is seen here nonetheless.)

Also worth noting Amplify Shader Editor has a custom template / master node API already and that certainly wouldn't be the first time someone's said "Amplify has this feature already." Unity could maybe just acquire them like they did Bolt recently? ha. This isn't really about Amplify though, this is / should be an obvious feature on the roadmap.

It bridges the gap between shader programmers and technical artists, putting that power in the hands of your customers, not forcing us to choose to between:
"This is just what ShaderGraph + SRP lets us do and we can't extend it any further (without hacky guesswork that is a nightmare to maintain)"
or
"Well we can't use ShaderGraph at all now for this, we just have to write HLSL + ShaderLab using the SRP Shader API to get the job done.. but our technical and lookdev artists can't readily understand or customize it."

Thank you for your time and consideration.

 

I've merged your changes and fixed a bunch of other issues, see commit history:
https://github.com/pschraut/UnityModularShaderPrototype

 

consider adding instanced light. I just learned that particle lights use the default ultra slow light path, which makes no sense.

 

By instanced light do you mean deferred lighting / rendering? and by default ultra slow light path do you mean forward lighting / rendering? And/or if you could share a link to the source that you learned this information that would be helpful.

While Particle Light rendering for the traditional ParticleSystem should be addressed if there is needed optimization, it's worth mentioning that the Visual Effect Graph roadmap has Particles Lights planned as a feature, presumably with deferred rendering (on supported hardware) that will be very performant following suit with all of the existing rendering methods Visual Effect Graph employs.

The VFX Graph roadmap also has features planned for CPU Simulation and High-End Mobile Support which are some of the other top reasons (aside from Particle Lights) that one may choose to use ParticleSystem instead of VFX Graph.

(Low-End Mobile doesn't apply here as rendering many real-time lights would need to be avoided altogether / is going to have poor performance on Low-End Mobile regardless of the render path. Deferred rendering can actually be slower than Forward rendering on many mobile GPUs or Deferred is not supported at all, as mobile GPUs often use a tiled architecture that is quite different from PC or console GPU architecture.)

Unity Graphics: Visual Effects Graph Roadmap
https://portal.productboard.com/unity/1-unity-graphics/tabs/9-visual-effect-graph

 

Sorry I used the wrong word, I meant slow method of lighting: non instanced.
https://forum.unity.com/threads/forcing-vertex-lighting.928758/#post-6081063
https://forum.unity.com/threads/gpu-instanced-deferred-lights.746327/

 

aye, I bring this up a lot after the 14 years of production work here, and other engines, its exhausting to get lip service all the time from Unity, with more options today, Unity can't keep up this lip service, so we will see what happens....I will give them a chance, but this will be my last......( i'm near done with Unity anyways,..) but I will hang out to see if they change) Great reply by the way, its like you read our minds.

 

I agree with you, but no matter if we like it or not, this is how the industry has moved with visual even Substance Designer, is visual and is more powerful than any texturing tool on the market...

What they should do as UE has...is sure have shader graph, and tools like Amplify....Etc...this is where artist, who can't code....and its the way many engines are going.....
but still allow those that want to code old school, HLSL to do so, which is basically the current way with built in...

keep it this way.....

Allow users to make custom nodes, but also code in text....HLSL....

But to make it one way or the other is foolish... and many games will never be finished, no matter if we like it or not, shader coders are less and less..

I can name 3-4 in Unity that are any good......Jason, Tom, Scott.... That isn't a lot.... (I can program 30 years) so I don't care either way, but from experience of consulting, and working for many game engines over the two decades of being in the gaming industry, I can tell you there are way less, and there is no way these 3 guys and a hand full of others can make everyone games...

but they make assets and others do as well, Unity should have that access to HLSL.....for users ....

The AVG user for Unity, has no idea how to program in general in C# let alone HLSL, no offense of course...

So visual needs to exist, even AAA engines have visual ....and for good reason it works, if optimized properly they work fine, UE, I never seen a game have issues, with performance with visual.....shading...So..

we need to stop with the visual vs text nonsense.. and think about its users....and allow both.... it shouldn't be only visual, but it shouldn't be only text, it makes no sense to do that....allow both like built in has.....

 

Just a standard HDRP project, this renders both URP and HDRP completely unusable for me. No amount of re-importing and upgrading of materials fixes this.

When is this crap going to be sorted out?

 

I have noticed that Kronnect has started developing Unreal engine assets. I'm also starting to see more Unreal developers available as freelancers.

Right now its mainly low budgets and the need to develop for Nintendo Switch that is keeping me with Unity. With any kind of a revenue breakthrough or more powerful Switch 2, Unreal Engine 5 is looking very attractive.

 

There are several UE4 games on Switch, not sure why you think you need Unity for it. Some of them even run at 60fps, most notably that Yoshi game, complete with SSAO, bloom and depth of field, while in my personal (and painful) experience you have to bend Unity into a pretzel to get good performance on Switch for any 3D game that doesn't look like it is aimed at $50 phones.

 

The deadly premonition 2 is an open world switch game made with unity ... it run so badly the director had to made an apology, it run worse than their custom engine made for the first game... that's what represent unity for project that aren't simple 2d platformer.

 

The youtube comments on that game are quite entertaining and the fans seem to love it, despite its technical imperfection.

Spoiler

 

There is a large network of porters specialised at bringing Unity games to consoles. Check out the Thomas Brush video today on his Switch release, he uses a whole network of people and companies to develop and port games to consoles. To my knowledge that doesn't exist right now for small/solo developers for Unreal.

With that said if you're a 2-3 man shop using Unreal you're more likely to be able to handle multi-platform development yourself.

Unity, despite its performance being volatile, runs without crashing or instability for me and my customer base despite lots of custom assets and live-service development. This is just anecdotal but Unreal is a lot more temperamental. If you are doing things like using freelance programmers for core features (like me) this core stability is critical.

I would like to see Unity focus more on inbuilt performance features - creating a great mesh baking/atlasing function would be really useful.

 

There is something very wrong with DP2, if you watch the Digital Foundry analysis you'll see that performance doesn't change even if you just look at the floor ( or in other videos at the sky ). I suspect we'll see a patch sooner or later for it and in my opinion its unlikely to be a Unity issue, more a rushed released and something is bugged issue.

 

I didn't said it was unity fault, I say it represent unity on the outside for that genre. I got wind of this game through usual unity bashing on internet.

Which bring the question, genuinely for my own, what are game with similar technical challenge that run on switch with unity. So at least I know counter example.

 

"Unity Framerate" is a game genre.
After 10 minutes watching this video I can tell with utmost confidence that this game could be made of few polygrones (already there) with tearing uvs all over (ditto) and bad animation (also) and be awesomeness incarnate.

 

I haven't seen anything of that game yet, but if the developers used multiple instances of the standard Unity terrain with SpeedTree vegetation, that would explain some of the terrible performance, as those devour main thread time pretty quickly regardless of where the camera is looking.

I am working on two Switch ports of games that rely on Unity terrain and it has been a major struggle to reclaim CPU time. In one of them culling alone takes over 15ms per frame due to the usage of speedTree. We rolled a custom solution for terrain that replicates the chunk-based LOD using compute shaders and procedural indirect rendering. Even then we have to add all sorts of extra optimizations because simply setting propertyBlock values and calling DrawProceduralIndirect a couple dozen times can be unreasonably expensive, so we'll have to run our own frustum culling to avoid calling those for invisible terrain instances.

Basically, our porting process involves replacing or heavily modifying as much built in Unity stuff as possible because it's all too horribly slow.

 

That's interesting. Culling does seem slow. It can take so much time even if a camera has a layermask that only allows it to see a coupe of objects (or even just one). I Also noticed MaterialPropertyBlock being a bit slow, but I thought maybe I did something wrong. Maybe I didn't?

 

It's something you don't see normally on the Unity profiler, but from when I profile with external tools things like MaterialPropertyBlock.SetTexture() and MaterialPropertyBlock.SetMatrix() add up very quickly. Same goes for building command buffers (which accounts for a good chunk of the CPU time spent by post processing, right after the terribly expensive volume blending).

 

But SRP is all around CommandBuffers. Does the slowdown also apply there? That would be pretty bad

 

I haven't had the time to actually test SRP projects on Switch (or at all), so I can't tell. It seems if you can re-issue pre-built command buffers (instead of clearing and re-building them every frame) and your materials property blocks aren't changing things aren't too bad, but I'm not sure if the SRPs do that.

But basically all the C# APIs used to send/prepare stuff to be drawn have a non-negligible cost. Which is why I'm suffering through converting as much as I possibly can to be managed by compute shaders and indirect drawing.

 

Interesting stuff, but as i'm not a Switch developer I have no knowledge or access, but this to me sounds like either a fundamental hardware issue which all developers have to find a way to deal with or something is very wrong in the engine that Unity needs to fix.

Have you posted bug reports on this or tried to talk to Unity about it as this does not appear to be normal behavior. It would also be in Unity's interest to get this looked at quickly especially with the high profile nature that DP2 has had.

I would not be surprised if SpeedTree was used, perhaps you can tell from watching the Digital Foundry video. However the fact that performance does not change when looking directly up or down, when the majority of the world objects should be efficiently and quickly culled still suggests to me something else is going on. Might even be as stupid as console spam of errors

Edit:
Forgotten to mention I think there is some blame to give to the developers as at one point the DF video ( 11:35) talks about delay on firing a weapon, which strongly suggests to me lack of pooling/caching/loading code of any type in the game. Though I think the delay here is caused by the loading of the destruction of the crate, yet after the first one the rest of the gun shots/create destruction has no delay.

 

Thanks for sharing the video!

It starts with a catchy introduction: "We're hearing a lot of controversy about the shocking state that Deadly Premonition 2 has shipped in for Nintendo Switch." and from what they shown in the video, it's spot on.

I find it really disappointing to see Nintendo let a game "in a shocking state" pass their approval process. Of course people are going to release all sorts of garbage if you let them.

I miss the early and stricter TCR, TRC and Lotcheck compliance testing processes, where games actually had to reach a certain technical quality level.

Things like 10 sec freezes during a loading screen would have caused your submission to fail few years ago (10+ years). Let alone running at 15 fps with frequent 1s freezes during gameplay.

But that's the overall trend in software quality.

 

Yeah, DP2 does look like a classical case of "first time Unity game" with maybe a dash of "did most development on PC and didn't check performance on the target device until it was too late". They probably didn't know that the obvious way of doing things is Unity is often slow and needs to be worked around for performance. The 1s freezes? Probably GC spikes, need to pool stuff. The 10s+ loading screen freeze? Too much stuff in a single additively loaded scene, need to split into multiple scenes so objects don't Awake/Start all at once. The list of gotchas goes on.

And no, I haven't reported a bug case, and I refuse to. This isn't some corner case or weird use of the engine, it's core engine functionality running badly on a major console platform. This kind of stuff should be actively tested and worked on, not sat on until enough bug reports come.

BTW, I just saw in another thread an Unity engineer admit both culling and draw calls being more expensive than they should be due to "aging architecture", which also limits the SRPs because they have to go through it just like built in does.

 

Can you share the link to the post?

 

Sure.
https://forum.unity.com/threads/shadowed-point-lights-performance-is-weird.819300/#post-6100767

 

Hmm, Ok well this is different.

DrawCalls have always been expensive and always will remain expensive, that is why there has been considerable investment in reducing calls via various techniques, batching and the like. The newer 3D API's ( Vulken/dx12) were meant to improve this, but I've never dug into how, but one would assume Unity takes advantage of the changes where possible on those API's.

I thought when you posted about the issues it was something new or specific, nothing I've read on that thread really seems applicable to DP2 outdoor environments or problems in general, unless Unity have completely ignored the changes in the new 3D API's. I think from my limited experience with SpeedTree there may be some additional issues as there always seems to be something wrong with it in one way or another at various times.

Anyway thanks for the info, but i'd rather not discuss this or DP2 further in more detail in this thread as at this point I think we're derailing the original purpose? Maybe just finish up with another reply, but if you have specifics to discuss, start a new thread and i'll jump on over.

 

You're right, we should stop derailing this thread.

BTW, Unity performs horribly in DX12.

 

Unity basically provides an API that runs on all graphics APIs. Unity needs a layer of abstraction in between. Vulkan and Dx12 are very low-level, which is why it takes a lot more abstraction to bring the same functionality of the UnityAPI to life, which then cancels some of the performance advantages and also takes longer to implement.

 

Don't use Unity for WebGL. Use BabylonJS or Three.js or Playcanvas. You will never go back. I just wish Unity just forgot about OpenGL2 and WebGL for URP. They would save themselves so much pain.

 

The good news is Unity will be able to forget sometime after WebGPU replaces WebGL in the not so distant future. It's a modern GPU compute capable graphics API for the web and beyond, and as such makes it a much better (and less painful) target for SRP / URP / HDRP.

More info on WebGPU:
http://webgpu.io

Here is also a WebGL / WebGPU roadmap thread created by Unity devs on the forums if you would like to discuss this further or give feedback specific to Unity on the web (and keep this thread on topic.)
https://forum.unity.com/threads/webgl-roadmap.334408/

 

Not so distant in human years maybe. Probably an eternity in dog years until browsers will support it without flags.

 

I don't remember asking you what to use, and this is not the thread topic.
It's a platform that Unity supports, and as long they support it, they should consider this platform when working on base tools/engines/pipelines like the SRP.

 

This is why we've got to be careful not to derail other people's threads . Everythign posted here is now off-topic .

Can we delete the last twenty five posts? (I may have missed one, but it appears that's how long since there's been a real on-topic comment). I have no objection to those posts normally, but:

1. they're completely off-topic here
2. they de-rail a massively more important topic
3. they are spamming all of us who've been using the thread for its original purpose (including the Unity team).

(I get emails everytime someone else decides that it's now a free-for-all and they should add their OT thoughts too )

Normally I wouldn't say anything, but: this thread is important. This is the culmination of years of effort to prevent some disasters coming very soon in the pipeline for Unity's rendering systems, and represents the primary interaction between the people at Unity trying to adapt and find the best solution, and the people outside Unity trying to add their input and insights (which a lot of teams at Unity don't have, since they neither make games nor use Unity nor extend it as normal developers).

 

I dislike the idea of just deleting posts, even though I agree we went off topic.
Could they perhaps be moved to a new thread with some catch all topic name which is then locked?

 

Yeah, when I said "delete", I hoped that the original posters would start a new thread and copy/paste into it. Nothing wrong with the posts, they're just in the wrong place. In other communitiies, with more active moderation teams, I'd expect a mod to split the thread and move them to a new thread (but I get the impression that feature is missing from the Unity forums software)

 

Update on my previous post in this thread which is very on-topic to the SRP and Shader API conversation here. I know many developers have also been unable to find any official statement from Unity regarding a Shader Graph Master Node API, assuming it would be on the roadmap or specifically mentioned in the original post here. I recently found this mention of a forthcoming Custom Master Node API on a pull request for "Master Stacks" nodes on the Unity Graphics repo on Github that is paving the way for an API:

https://github.com/Unity-Technologies/Graphics/pull/571

Very good news that a Master Node API is already planned with work being done to prepare for it. Hopefully this feature makes its way to the public Shader Graph roadmap productboard soon as well.

 

Just another voice to iterate that being able to output the same project to URP on mobile and HDRP on desktop is ***the*** most important feature for us. We need to look AAA on desktop, and "whatever" on mobile. But we have an existing user base of a million users for the old version of the app, and not existing on mobile is not an option.

We even switched to Unreal Engine half a year ago, starting over, because we needed the ability to output the same project from low to high quality from a single project. We're only back here because Epic is playing pattycake with our future. Unity is in fact a better fit for our app, but being able to be truly cross-platform was so important that we were willing to do everything from scratch in Unreal just to get that.

And now we might start over from scratch in Unity again, only because Unity intends to unify their pipelines enough that it's possible to target low to high from a single project. We don't mind any amount of pain, as long as it's possible at all.