Hi, i’m looking at the current implementation of the toon shader given in the project to see if i can add my own contribution to it.
Seems a nice time to actually learn a bit more about shading in urp since i’ve been mostly on the legacy pipeline until now.
RIght now i’m fiddling with the main toon gradient sampling and i got a couple of questions:
About the gradient itself: is there a particular reason to keep it an internal structure instead of having a texture containing a gradient to sample? The latter would give way more freedom to the artists to edit them.
Is there a general limit on how much should be done inside a single custom function?
I actually left the Toon Shader a bit half baked, I was going to go back to it. Let me push a few changes tomorrow, and we can resume the conversation?
In any case:
You’re totally right, although I don’t know if different toon materials should have different gradients
I don’t think so because, at the end of the day, either you write it yourself or you use multiple nodes to make it, the resulting HLSL code is the same (or, almost).
Up until now i just played a bit with it without making important progress, since i have to understand where things are compared to legacy, i’ll wait the updates before doing anything important to it.
Although I don’t see the need for gradient given the concept art style full of harsh colour transition.
But if it was me I would probably ditch toon shading for a vertex color shader with split baked shadow vertex and distance illumination of light, aka no ndotl compute, and post process line art extracted with normal depth and a color channel as a mask. That would allow a one to one replication of the illustrative style of the concept art instead of the usual sad sorry and sloppy toon shader we see people defaulting to. But it out the burden on modelling to work on keeping the dynamic shape of the illustration. Its probably not on the skill level of the artists though
If you go toon shader at least take cues from the Japanese unite talks about unity Chan or the English talk of miyoho at unite Korea about honkai impact. Just because it’s anime don’t mean the lesson aren’t universal. And since they already solved major hurdle you won’t have to reinvent the wheel and per time chasing solutions.
The idea for a gradient in this case is to let artists author different types of harsh transitions easily. The fact that it could theoretically support smoother transitions as well is more of a side effect rather than the intention. We could predefine a finite amount of hardcoded transitions, but i personally prefer the flexibility of editing a gradient for that.
It would be nice to try, but it would make artists job harder, and make harder later down the line to make changes and adjustments to the style as needed.
Since i haven’t seen any updates on the shading branch of the repo i went on and started building up a separate shader as a test.
Currently supported:
Main light Diffuse and Specular highlight
Additional Lights Diffuse and Specular highlight
Shadows
To do:
Baked GI
Ambient color
Current Issues:
High intensity lights tend to blow up the character a bit too much, but that may be due to missing post processing in the test scene. Needs more testing.
The shader uses 2 separate gradient textures for diffuse and specular, so that the artist can tweak each one separately.
Shadow attenuation is also being kept into consideration while sampling the gradients, so casted shadows will behave accordingly to the gradient as well instead of being an effect on top.
Are there specific requirements to the UVs resulting from the toon shader? When making the 3D models, we need to know. I am specifically thinking about
no overlapping UV (the same spot on the texture used twice or more)?
not wrapping texture around sharp edges, instead making separate island with xxx pixels inbetween?
Hi great work on the toon shader so far! I am having a problem with the latest change which separated the toon shader into sub-graphs. The top screenshot is the toon shader when it was all contained within a single shadergraph applied to the ground while the second screenshot is with the latest shader.
As you can see, now that it’s been split into subgraphs objects no longer cast real time shadows onto each other. I tried to investigate all the subgraphs to find any differences in implementation but I couldn’t spot anything changed that would make the difference. Any ideas?
I think I found the issue!
Both the Toon and ToonPlusWind shaders don’t have the keywords related to lighting. They were lost in the merge, which is very strange since you can see the shader with the wind just before your post, in @treivize 's post.
Interesting.
wow! I was trying to figure out the problem too right now. Indeed, I had the impression it was working when I opened the PR. About the keywords, I am not sure how they work, but maybe they are not propagated over two sub graph level…
Because for sure, if the Toon shader is defined like done in ToonShading sub graph, shadows are cast without having to specify the keywords again.
A ticket to raise to Unity Shader Graph team maybe
In the latest commit, they were not there at all. Not in the top-level graph.
Somewhere along the way, the two ShaderGraph files lost all keywords, not sure how. So it was “working as intended”, but we should try to understand for the future how we lost them (if it was my mistake, or indeed a bug). Let’s just keep an eye out if we happen to subgraph things again.
Ok, thanks for your feedback Neonage, so it is what I had in mind with my second option. Ok I will have a look how to go with this option then
Sorry another thing I wanted to share with you before going to sleep. Transparency support, I did some tests with the lantern and a suggestion will be to split the geometry into two part, the glass and the metallic caps to apply a dedicated shader to the glass:
