Feature Request Custom master node, is it on the roadmap?

I believe the SG team already know people want it, but I couldn't find a thread about it in this forum, so here is my request for it.

To be honest, after going through many feature request threads here, I realize many of these problems could have been solved if we are given the chance to write a master node.

I have solved these problems using a custom master node in 2018.3 (with 4.x release):

- Custom vertex shader.
- Custom keyword.
- Toggle things like ZWrite/ZTest.
- Rewrite the parser and create custom template tags.

(Basically trying to make it as flexible as Amplify Shader Editor)



SG is perhaps the main reason I couldn't easily migrate to 2019.x releases, I am not going to blame anyone but myself, but hey, I think supporting that could cut your feature requests in half

(I skimmed past the GDC video, pretty sure this isn't available in 5.x, so apologize if there is an alternative.)

 

+1 for this. Custom Master Nodes is currently the only possible way I found to implement real toon lighting that supports all lights: https://forum.unity.com/threads/shadergraph-request-allow-a-custom-lit-masternode.663250/

....and gives users an option to solve almost all problems that could eventually show up

After some consideration, I think It'd be a fine solution to just make it easy and well-documented to create MasterNodes (as opposed to what I was suggesting in my thread). So far I was only able to modify existing PBR code in order to achieve my result, but I haven't figured out how to actually add a new custom MasterNode.

Are you saying it is now impossible to create MasterNodes in 2019.1?

 

mebe the best could be for SG to allow code nodes ^^

just like the one in blender.

therefore allowing custom master node ?

 

Could we at least reach a middle ground where the API is made not-internal again even though there will be no documentation? It would at least give us some kind of option for working with custom lighting/etc.... I'm sure we could reverse-engineer existing MasterNodes and it's better than it being impossible

Or does your team have plans for making it more approachable in the future?

 

Hi Alexandra, I am wondering if there can be a workaround for this issue:

- Because we are too deeply integrated into SG 4.x API, it's holding us back from using Unity 2019 and LWRP 5.x
- We would like to use a supported version of LWRP. (4.x isn't supported, Unity 2018 LTS will be stuck with it)
- I wonder if there is any chance, for us to run SG 4.x on Unity 2019, with LWRP 5.x
- When SG 5.x is up to the task, we will happily deprecated SG 4.x

It's a lot to ask, and I don't expect SG 4.x to ever be supported. But to us, since SG is really a Shader generating tool, it's not as critical as making sure we use a supported SRP.

(We spent quite a lot of time switching from ASE to SG during Unity 2018, but it looks like we have to switch back, if no recourse is given on this topic.)

 

The problem with that is a lot of users are now dependent on LWRP and you are stopping them from updating and therefore gathering feedback for the newer versions of unity, effectively making a subset of people who have been testing for you unable to test any further. I am sure I dont need to point out how this is not a good thing when it comes to getting well rounded testing feedback.

Im not sure I see how this decision makes sense. Its a little irritating hearing LWRP is out of preview in 2019.1, and yet features that worked in previous version now break and therefore stop us updating and actually using the 2019.1 features that we really need. Its a bit of a silly position to be in and can be avoided by making it not internal and putting a pinned thread saying that its not internal so people can access it but no support will be given or documentation until ready.

Users are already hacking around it anyway as mentioned here: https://forum.unity.com/threads/sha...-a-custom-lit-masternode.663250/#post-4469533

So why not just make it not such a hurdle to those who have chosen to come on this journey with you and adopt LWRP so they can give you feedback etc.

At the very least flash a giant warning message next time on the blog post about 2019.1 being released explaining this in the bit that says LWRP is out of preview, as it was very misleading given the current limitations.

Anyway good luck to you and the team, but hope this is resolved soon as its a long time to wait just to author a simple toon lighting shader using NdotL and step.

EDIT: like above user, we have also had to switch between ASE and SG a ton and would love not to have to switch back just because of this.

 

Since its been a little while, I wanted to check if there was an updated timeline on having the Master Node API exposed and usable from asset store packages? In our particular case the ability to add our own master node would transform our offering as it would open up a key shader in our system to artists.

Other relevant threads were mentioned above but I didn't easily find them, please let me know if there's a status elsewhere, or better place to post this.

Thanks!

 

+ For the question. I want to implement custom lighting (stylized) with HDRP. I need proper decals with lighting and tiled render in HDRP does it.
Does it still make sense to modify HDRP package and add custom master node or there is better API underway?

 

Before LWRP, URP, and HDRP, I could extend the surface shaders to output additional channels that would be rendered to an array of buffers made from a collection of RenderTextures. This lets me extract all sorts of additional data that's helpful for machine learning. While AOV extracts some of the things I need, it doesn't get all of it; for instance, being able to assign a unique object id to each game object and then pass that to the fragment shader which outputs it to a pixel is quite handy. Being able to create a custom MasterNode with the ability to output additional channels would be quite helpful.

 

Also just chiming in to say a custom master node / output channel would be really nice.

As someone who is comfortable writing shaders from code, I'd still be interested in using the Shader Graph to author specific shader effects, while defining a general custom lighting model in code (since it feels more maintainable to me there).

 

Only if you assume we're asking for a) documentation b) stability. We're not.

Go head and leave it undocumented. We can read the source.

Go ahead and break it in every point release. We're grown ups and we accept that's the price to pay for using semi-internal stuff.

Feel free to put up big scary warnings everywhere. Feel free to not offer any support or help on the forums.

There IS an option that has no cost for you and a huge benefit for us. It's called "take away the guard rails for those that don't want them".