Toon Shader

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:
1) 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.
2) 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).

I also made the thread the official discussion thread about Toon Shader (roadmap card)

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.

Keeping a tab on this,

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.6379257--710583--Unity_Gf6YI4xoW6.jpg

It better use gradient texture created by script so it's easy to control

It's been only 2 days since I last posted, and it's the weekend :(

Looks good! Is it coded or Shader Graph?

1 Like

Ahahahahah sorry, it's just that I only have the weekends free to dedicate time on that.

It's shader graph with the main lighting functions being coded in an hlsl file and used in custom function nodes.

Reviving this thread since I just posted the toon shader on the art-assets branch.

As with all things here, it can evolve. Feel free to give suggestions on how to improve it!

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?

6503356--732415--2020-11-08 20 42 15.png
6503356--732418--2020-11-08 20 42 03.png
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.

6504873--732639--Screenshot 2020-11-09 at 15.45.17.png

I'll add them back and see if it fixes it.

1 Like

Yes, fixed (and pushed to the art-assets branch).

6504930--732645--Screenshot 2020-11-09 at 16.02.19.jpg


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.

Hi shader lovers,

I am thinking about the task "Emission support", how do you imagine it will work with the constraint of the project (URP + Unlit shaders)?

The solutions I can figure out are:
- Add extra mesh placed over the glowing area and the area around with transparent additive color shader
- Add an image effect shader over the camera frustum to post effect the image with glow effect.

Do I miss something here? What should be the most appropriated solution according to you?

"Emission support" means HDR map, not glow effect itself.
Extra mesh is not a good idea for this, especially with skinned meshes.

And I think we need custom paintish post effects for Bloom and DoF.

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:


1 Like