Official 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?

 

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.

 

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

 

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.

 

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?

 

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

 

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:

 

And I'm playing around with Strokes map:


(don't mind ugly fresnel effect at the end xp)

 

Again, thanks for your feedback!

Regarding the implementation of transparency support in the main shader to enable cutout transparency, It seems that the following change should be enough:

Actually the idea is to force the alpha channel to be 1 along the pipeline and from the tint color (not sure what should be the usage of alpha channel for tint color) and next inject back the alpha of the color map at the end of the process.

ToonShading:


Toon:


Example of result with the lantern color map where the glass is transparent:


I will update my PR to add this change in the main toon shaders.
And for Glass Shader, I can simplified it to remove the refraction part.

 

Here is a new proposal for the lantern based on your @cirocontinisio feedback.

To change the habit here is the final result:


The solution:
- I removed the refraction part of the shader and add a Fresnel effect to highlight the curvature of the glass what do you think about it?


- The mesh is not split anymore just assigned 2 materials to different face set in mesh edit mode in Blender:


And stack two materials in the MeshRenderer in Unity:

 

Fresnel / Rim effect needs to be stylised as well.

Here's how glass looks in my game right now (super WIP):

It has two-step rim:
- Sharp outline-bevel-like to show the thickness of glass.
- Smooth to highlight the curvature.
Then alpha is multiplied by that amount of fresnel.

I took inspiration from Super Mario 3D World:


You may notice that there is little Refraction pass that is half visible and affects only background objects outside of glass.
And you can clearly see that thick parts have much solid refraction to catch the lighting and highlight surrounding nicely.
Maybe we can do the same?

 

Hello @Neonage, thanks for the feedback.

I agree with you about stylizing the Fresnel effect to make it more toon style. So no gradient but more a tick border.
To achieve that I have just added a step node after the Fresnel one to control the thickness.



(I removed the glow effect on the phoenix before pushing my code for the PR)

Regarding refraction, I agreed with @cirocontinisio, the glass of this lantern might be too thin to generate a noticeable refraction. My initial idea to introduce refraction was to make the glass noticeable and not just fully transparent or semi transparent, but I think Fresnel effect might be enough for the need here.
In Mario, these tubes of glass are really a main asset of the game design, so it makes sense to invest on a polish glass rendering. But not sure for this game that a mind blowing glass effect is expected by the players.

I have opened a brand new PR for this contribution, it was simpler to start from scratch for me, especially because I also added the transparency cutoff support to the main toon shader, as seen here with the leaf.

 

Does anyone know how to add normal map support?

 

It's for my own project. I was searching for a toon shader for a long time and this one fits my game really well but I use a lot of normal maps.

 

That did it. Thank you.
Please read and tell me if there is a more performant way to do this since I am going to use this for mobile.

For anyone interested here is how I did it.

Opened "MainLight" subgraph, added a Texture2D property, plugged it in a Sample Texture 2D, plugged that in "B" from a Normal Blend node, and in "A" I plugged the Direction output from the Custom Function.

To make this public and be able to add a Normal Map texture from the inspector I had to add the same ("Normal Map") Texutre2D property in: ToonLightingModel, ToonShading and in the Toon. And don't forget to connect everything up.




I'm interested to see how would a normal map with the outline implemented look. I think that will really sell the normal map lie. If anyone knows how to do this please tell me.

 

I am in the middle of creating the 3D assets so I can't tell for sure. I am not expecting to use normal maps on Non-Static objects.
But for terrain with dirt and cliff rocks, I am thinking it might help me reduce a lot of polygons.

For the apple example, yeah it's almost useless.

 

I found a problem with the toon shader.

The dynamic objects don't receive lighting information from lightprobes. You can test this by setting the directional lighting to baked. The objects become black.

 

That sounds great! I had been trying to remove specular color from ramping using colorspace conversion but I got too focused on a subgraph that allowed you to control which channels were ramped. My original idea was to ensure only Value was ramped and then pass in the specular color and possibly blend the albedo output into the specular color.

I felt like this would be especially important for objects without specular masks, as different colored surfaces on the same object were receiving the same specular light color.

I'm going to go ahead and push to my forked version of the repo - even if what I have doesn't get merged I have some ideas in there I'd like to explore here on the forum.

https://github.com/daneobyrd/open-project-1/tree/art-assets

 

Haha I started to feel it was getting a little complex. I think that’s mainly because I started using lerps instead of branches to control how the specular was being handled. If I had more control over the Shader GUI I think it would look less confusing.

I think the way you are handling it sounds much cleaner but I’m concerned that it might be harder to get more natural looking specular highlights. My main aim was to allow artists to control how the specular tint would blend with the albedo output/any light color in the scene. This includes harder opaque options (i.e. the slimes) and softer tones with transparency for shading character skin.

Most of the fields on my inspector are determining when different factors are introduced. I combined many of these values into two vector4 properties thinking that the fewer total properties we have the better. I wasn't sure what impact bool and branch nodes had on performance so I opted for lerps. Many of these fields are contextual though, and I only left visible as a precaution (such as the stepped specular).

Here’s a list of what I currently have:

Ramp H S V | Specular Map (Vector4)

• X, Y and Z ports independently set whether to ramp each HSV channel. These inputs are fed into a lerp node that intake a ramped and unramped color channel. HSV are then combined and converted to RGB and fed through the specular_out for whichever subgraph it is in.
• If V is not ramped then I ignore the H and S multipliers in favor of ramping the RGB color input uniformly, a simple color ramp.
• I did this mainly to preserve the way some things are currently set. For example, the additional light’s specular calculations was in RGB colorspace and used a color ramp.
  
• Lastly the W port controls the specular map’s contribution (lerp).

Specular Steps | Use (Vector4)

• The slimes rely on a step node set to (0.5, 0.5, 0.5). This property does not need to be exposed but I did so just in case.
• This allows you to ramp the specular light using only a step node rather than a sample gradient node. The step node receives RGB values so it is used as a color ramp.
• The W port controls the step contribution vs using a gradient to ramp HSV values.

Albedo / Specular Color Contribution (Vector2)

• X blends the Tinted Albedo output with the specular calculations from the main light and additional light subgraphs. This could be swapped out with an emission map easily.
• Y controls specular color contribution later in the graph, isolating ramping. This is essentially your method of removing light color from ramping, then using Specular Color to tint the specular light calculations. When color is used in the HLSL calculation, any light color other than white has some transparency. This allows for opaque tinted specular light without using steps.

Albedo Post Hook Contribution (not exposed)

• This property is used in the fresnel version of the shader for the slimes. It can be used similarly to the Albedo contribution I control with Albedo / Specular Color Contribution.

Many of the choices I made were based on not wanting to impede how the slimes are being shaded @treivize. The first two properties listed are fed into a custom subgraph, SpecularColorContribution.

 

Also this looks great! I was typing up my other reply when you posted this. I had similarly combined both subgraph’s specular outputs in the ToonShading subgraph. I thought it would be nice to move the ramping to the main ToonShading subgraph but I was too timid to do it myself.

 

Maybe we will not encounter the need for it, but it seems a bit strange from my own point of view that darker the albedo is less reflective is the surface. A black smile critter for instance has almost no specular due to the multiply node between albedo and lights & speculars:



I am definitely not experienced enough in this domain to judge if what I am suggesting is the right thing to do, but if this multiply is needed, maybe we should add a capacity to over load the specular contribution with an Exp function controlled by a new Specular parameter...

 

I have done it! I created two subgraphs, Albedo and Albedo_Fresnel. This eliminates those two inputs on the main ToonShading subgraph.

Pull request: https://github.com/UnityTechnologies/open-project-1/pull/240

 

In all this testing I started to get confused too. At one point I wasn't sure which property was Hue Saturation or Value. I think it would be nice to have main light color contribution to the specular calculations but it does add a few headaches.

One way to fake this would be to blend the Albedo output with the specular. This could be called Surface Color Contribtion. Maybe this is all solved with a specular map or an emission map. Your solution works great and in the end, Albedo contribution to specular light isn't a must-have, especially since you can manually tint the specular light.

 

I am concerned by this one:

 

Yes, it was my understanding too and my attempt in my last update in the slime critter PR (here there is a mistake since the specular color was already included in the output of the ToonLightning model: