Feedback ShaderGraph: updates on roadmap & long-requested features?

Off the top of my head: I can think of a few missing features that are, in my opinion, holding SG back:

• No tessellation
• No terrain MasterNodes
• No UI MasterNodes (I guess it makes sense to wait for Runtime UIElements and not support the current soon-to-be-legacy UI though)
• It would be great to have GetMainLight/GetAdditinalLights as built-in nodes so we don't have to write custom functions for them
• No support for declaring/using StructuredBuffers in shaders
• No public API to create custom MasterNodes
  • this drastically limits the potential of third party assets, and therefore cripples the entire tool itself. The community loses any hope of using cool/useful master nodes made by other talented people. And no asset store publisher will want to rely on people using a custom version of the SG package
• Responsiveness/UX polish in general. It takes one full second to bring up the add node menu (Is there a reason for this? VFXGraph doesn't have that problem)
  • If this happens because SG needs to look through project files for custom subgraphs, etc.... could we have an option to turn this off or to refresh manually?

_________________________
More suggestions from thread:

• The ability to declare a property as instanced in Shader Graph.

Are there any news/plans regarding these points?

 

Look up how much time it took to implement zoom in/out in the animator window and extrapolate when those missing features will be implemented.

 

Hoping to find the right dev to ask these questions to. Sorry for all the tagging, but I've seen many threads about these topics aver the last year and most of them have no recent answers
@alexandral_unity
@mortenm
@LandonTownsend
@SebLagarde
@zacharyd890
@Andy-Touch

any roadmap details that can be shared would be appreciated

 

I asked for a grid backdrop (a tiny UX and QoL improvement) a few years ago, and I even got a response from Unity staff -- "Agree, we need this along with snapping to the grid". Nothing was made.

And I am not speaking about unpolished and appalling UI in comparison with quality assets like Amplify.

 

Emphasis on this point.
If Unity hadn't closed the API about a year ago, your first 4-5 points would already be implemented by a publisher and available on the asset store.

 

Out of curiosity; how do you handle this in your asset? Do you provide the full modified SG package, or is there secretly a way to make custom master nodes?

 

There is a hack-ish way to do it, that I've shared with at least 2 other publishers so it's very close to public knowledge at this point. The same publishers (I think) decided it wasn't worth the trouble, and I can only agree.
I don't recommend any way of custom nodes at all, as you have to keep up and closely follow every single commit in Unity' SRP and ShaderGraph github. Stuff breaks very often and isn't documented (because it's a private API, which make sense). Btw you would have the exact same problem with a local ShaderGraph version.

I only chose to continue because I already had customers relying on the asset (I released it with 2018.3 when it was still a public API...) and didn't want to let them down.
Wouldn't do it again, but feel free to PM me for more details.

 

No Tessellation node in SG is a big one for me.

 

Custom nodes period are a pain because they can often require modifications in multiple places, not just the node definition itself. Probably why they shut down custom nodes.

Mono.cecil is pretty much the standard tool here. You can use it to open up internals, or just add your own classes to the assembly. Widely used easy to find information on. The real work is just keeping up with changes in SRP.

 

That's the part where I'd be potentially ready to side with Unity on this issue, depending on their reasons

If giving us a good Node API means SRPs & ShaderGraph must be forever haunted/limited by bad early design decisions that they cannot change (because it would cause breaking changes and people would complain), then I'm not sure getting this NodeAPI would be worth it

For me, the best possible outcome would be:

• Give us a public Node API, even if poorly documented
• Never be afraid to make breaking changes that force devs to convert what they've done with the Node API

Eventually, things will stabilize naturally. But as long as the people working on SG feel like it's still subject to change, I think we should be completely accepting of breaking changes and consider that fixing things after upgrades is our responsibility. Otherwise, we'd be kind-of bullying unity into making a bad product for us

 

I agree with @PhilSA. Any serious project should probably be version locked on their editor and package versions outside of necessary patches. That's what the LTS releases of unity are for. Different package versions are already marked as verified for different editor versions so possible breaking changes with custom master nodes should be expected.

 

@quixotic Please consider giving us the node API back and just put a warning sign saying "this will break between versions" - it's the best of both worlds that way. As @PhilSA said "Any serious project should probably be version locked".

Treat us like adults and let us take responsibility for our choices.

 

Except that asset store authors basically have to provide support across all versions - doing anything less greatly reduces our potential sales, leads to 1 star reviews, which means not being featured by Unity for the rating, etc. Unity breaks something in each SRP every single release.

Like today I got a report of a user having an issue in HDRP 7.2.1, but my HDRP adapter was written for 7.1.8, so I upgrade my project to 7.2.1 and it crashes unity. It crashes unity on load even after a library clear. This is using Unity 2019.3.f6. Turns out the package requires a higher version of Unity, but the package manager lets me download the newer version in an older version of Unity and then just crashes. And since the asset store only lets us upload a version of our assets for each major unity release (2019.2, 2019.3, etc) there's not actually a way for me to ship a product that works for both users of 2019.3f0 and 2019.3.3f1 (or whenever they made the change).

You can talk all about keeping a project locked on a version of Unity, but it's practically impossible in real productions. The Star Trek game I worked on at Disruptor Beam got pulled through the 5.x series, and eventually forced to upgrade all the way to 2018 while running as a live product due to both bugs only being fixed in newer versions that we were being blocked by, and changes to the app ecosystem requiring us to upgrade.

Now, with packages being not sync'd to unity versions, the problem is even worse. And to compound that, ever asset is expected to keep up with these changes and somehow make their stuff compatible with all these different versions. For sheer sanity I'm going to force people to upgrade to 7.2.1, but if they have another asset which hasn't made those changes, then they will have to make a choice of removing one of those assets from their project because they can only run one version of an SRP at a time.

This combination of multiple render pipelines with no abstraction + Unity versions + package versions is sheer madness.

[q] @quixotic Please consider giving us the node API back and just put a warning sign saying "this will break between versions" - it's the best of both worlds that way. As @PhilSA said "Any serious project should probably be version locked". [/q]

Unity has a method to automatically upgrade C# code on new versions. They've used this for years to prevent these types of issues, and they could do so here as well. But for whatever reason, they just don't want to.

 

I understand that dealing with all those different permutations of versions/packages must be extremely difficult, but I also doubt that Unity is holding back on the Node API and making breaking changes just out of sheer laziness or villainy. From your perspective you see issues with Unity making breaking changes, but from Unity's perspective they probably see issues with not making breaking changes. They might know about all cool things the SRPs will never get if they stop making changes. Or they might know about how opening up the Node API and making sure everything is auto-upgraded would slow development down to turtle speed. Who knows?

The SRPs were a very good solution to a very important problem that Unity has had since its beginning; trying to do everything all at once and being great at none of them. The separation into 2 separate pipelines that work totally differently makes perfect sense, and I'm ready to bet that this makes it more difficult to come up with a strategy to write shaders that work for both pipelines and that can be easily upgraded. I personally have never created an entire engine that supports almost every device/platform out there, and offers rendering solutions for anything from mobile to AAA, and must roll out updates while millions of people are using it, so I really cannot have an educated opinion on that.

We also have to be careful about what we ask for. Do we truly want to force Unity to never make another breaking change in the SRPs again and therefore potentially condemn the SRPs to never receive improvements that they would desperately need in order to stay competitive? To me, the decision isn't obvious.

What I'm trying to say is that I totally understand & agree that it's difficult for asset store publishers to keep up with the situation, but also maybe this situation is justified. Both can be true at the same time. Maybe it just takes time to come up with a proper Node API and have everything automatically upgraded. I dunno. We are also discussing 2 different topics simultaneously here, so my points might be confusing:

1. Should Unity feel free to make breaking changes? (I think they should)
2. Should Unity give us a public Node API (I think they should)

I would blame Unity for not communicating enough about the state of ShaderGraph and SRPs, but I don't feel like I know enough about the situation to clearly decide that Unity are making the wrong decisions yet. I'm hoping the GDC thing @quixotic mentioned will shed some light (even if technically it's not going to be GDC anymore)

 

SRP's are a great idea, it's the execution that's lacking. They need an abstraction layer for shaders, end of story. For instance, I can write a surface shader in Unity 5.2 and it will work in 2020.1 just fine. Further, it will inherit every change and rendering feature added to the shading model- Enlighten GI added, all the different modes of rendering VR, the progressive light mapper, new lighting modes like subtractive, etc. They all just magically show up in your shaders because surface shaders abstract you from those problems, providing a shader which not only doesn't break, but remains compatible and gets new features as you update to new Unity versions.

I suspect no one liked maintaining surface shaders and have heard as such. They also had some design issues, fine, create a new and better system that solves those problems then. But rather than do this they completely ignored the issue (I know, I brought it up 4 years ago in a meeting at GDC with them when they pitched it) and pushed the job of that system onto every person who writes shaders in the engine. If we follow this same pattern, imagine if once Unity introduced a visual scripting graph, they no longer let you write C# and forced you to write C++, but required you to use a different API for each platform you ran on. This is an accurate analogy of where shaders are in Unity right now. Use our limited graph, or die keeping up with a rapidly changing and undocumented pipeline.

People act like the difference between HDRP and URP makes shaders incompatible. It doesn't, I know, I have an adapter that runs surface shader code in both. For the most part, the inputs to the lighting equation are what matter, and they are the same between all 3 pipelines, with HDRP having a few extras (SSS, etc, which URP will likely get versions of eventually as it becomes "Universal"). The differences between the pipelines is primarily in how a pixel gets lit, not how you sample textures and come up with the inputs to those equations.

The node API was open in 2018.3. I know, I shipped a node to the asset store. In 2019.1 they closed off the API and forced us all to hack the assemblies to get access to the API, and you know what? It's barely changed since then, nothing that couldn't have been auto upgraded or put in some patch notes. Now maybe there's some big refactor coming at some point- but I kinda doubt it. I've written a shader graph, and the node API isn't the hard part. The main complaints I heard were people being surprised that the API had you writing code with strings a text, but that is exactly what every shader graph does.

Now let's say I'm back at my old company where we wrote our own SRP. We'd love it if our artists could use a shader graph- but out lighting model is simplified, and right now there's no way to provide our own master node because the API is closed. Additionally, aspects of the pipelines are hard coded to Unity's SRPs, so essentially we can't use the shader graph or VFX graph in our custom SRP. So the whole reason for adding SRPs is basically moot unless we're hand writing every shader, which if we want a shader graph means writing our own or forking Unity's and owning all that code through upgrades.

I don't want to force unity not to make breaking changes- I want them to be free to make these changes without causing a massive ripple of man hours for everyone in the industry who uses their stuff. Pretending that they cannot abstract the SRP's from this damage, and that the Node API is too complex to open, or worse that we don't need to make our own nodes, is silly.

 

I'd want to add this to the list :

• The ability to declare a property as instanced in Shader Graph.

I don't get why this is not a thing yet when Unity have been limiting and removing features in favor of performance.

 

Has the GDC cancellation interfered with those plans?

 

I think until Unity shares some information about their reasons for the NodeAPI situation, the best we can do is us saying "I bet it's difficult" or "I bet it's easy", so I'll just leave it at that. It's always possible that we're not seeing the full picture. There's DXR to consider, and DOTS rendering, and the new skinned mesh instancing, new features that could rely on compute shaders (HDRP only), VR, etc... All of these things are extremely under-construction, so who knows what complications they might add?

I'm really hoping we do get a clear explanation in time for the would-be GDC. And if the explanation is basically "we decided it wasn't worth it", then I will have been wrong and we can all convince Unity that it's extremely crucial to have this

 

I know, because I’ve had to keep up with the changes required to implement every one of these features. I’ve written the very abstraction layers they need to write and maintained them through changes.

 

Is instanced properties support not going to be in Shader Graph? Or will that be within a separate roadmap for SRP Batcher?

 

I noticed the roadmap does not contain anything about GetMainLight/GetAdditinalLights for urp. Currently requires a few hacks to get it working correctly, and only GetMainLight works. See this Twitter thread on what needs to be done to get main light working W/ shadows, the work flow is very hacky:
https://mobile.twitter.com/Cyanilux/status/1240636241252679681

 

This brings up a thought on practicality - not necessarily something I think needs to be acted on, but worth bringing up.

So in HDRP or deferred rendering in the Standard pipeline there's no concept of main light, which makes sense from the rendering perspective. What's funny to me is that even if the renderer doesn't support the concept of a main light, every game I've ever looked at ends up having this concept anyway. If you're running HDRP or deferred rendering with MicroSplat, some features require you to put a component on a light so the shader can treat it like the Main Light. And I know of a dozen other assets that do this too. So the light ends up with 10 components on it all setting different shader global for the shaders to read, and if the user forgets one something breaks.

In practice, most games end up with a 'Main Light' in the scene, deferred or not. And many shader features are just too expensive to treat otherwise (Parallax Occlusion Mapping with shadows, for instance). This kind of makes me wonder:

Should Unity have the concept of a Main Light, like it has a Main Camera? When checked, this would just set the position/rotation into some global shader so 10 components don't have to do it and we could all standardize on names, etc? This feels gross to me, but it's basically where we always end up anyway.

Better, could we get some concept of Dominant Light? I'm not sure if there's some data structure already available that this could be gathered from, but if you could know the dominant light direction/position hitting an object it would allow all these types of effects to work - and if that data was blended, then it would work fine with multiple lights as well. I know it breaks PBR purity, but this would be better than the hacks we end up with now.