Thread replies: 21
Thread images: 7
Thread images: 7
File: tonsharding.png (631KB, 1707x727px) Image search:
[Google]
631KB, 1707x727px
Someone here might remember about a year or two back a series of posts I made here about doing toon shading in Cycles. Of course, it never went anywhere and the end result was pretty ugly, but for anyone who may care and not know themselves already, I figured out a much better, simpler way to do it. I don't know if this is well known or not, or a recent addition, but I figured I'd post it because it's news to me and I had to figure it out myself(and because a quick Google search shows nothing better than what was there last time).
This is just a demo to show it to anyone interested. The point is simply to show the sharp red and green division(intended to represent light and shadow colors) on the face.
It's pretty simple. Just copy the setup in the picture if you want to try it. Replace red and green with whatever color you want, treat the object in the Texture Coordinate node as your light(or make it an actual light).
Note that this is pretty much a directional, infinite-distance lighting technique and isn't going to allow self-shadow either. There might be other nodes you can use for that, but I haven't found one yet.
A couple of things:
1. I'm using the Emission node but if you don't mind getting ambient occlusion in there AO nodes would probably work faster.
2. Why would you want to use Cycles for this? The primary reason would be GPU rendering, I guess.
3. Why wouldn't you just use the compositor? Because it's convenient to have it work in the viewport, I suppose.
Apologies if this is old news now.
>>
Again, the face is the only mesh I've set up with this shader, but here's a quick attempt at some colors you might actually use to demonstrate how you'd apply it. I just color picked the skin color from its arm and used a self-multiplied color for the shadow.
Another thing to note is that the closest thing to directional light in Cycles is a sun light, but if you try to use a Sun light as the object for the Texture Coordinate node, its rotation will affect the value which is something I don't think you want. I haven't tested much but it's probably better to just parent an Empty(aka null) to the light source you want to sync with the shader and use the empty in the Texture Coordinate node.
>>
>>520478
Ah, sorry, I'm an idiot. Parenting an empty to the light would still result in the rotation affecting the calculation. The issue here is that whatever object you use in the Texture Coordinates node should only be used for its position, and from what little testing I've done it looks like if the object is rotated then it affects the position value received by the node(so, just consider it to be the position of the light, assume the light points at the mesh, and don't rotate it). If you wanted to auto-sync it with another light, I guess using a Copy Location object constraint would work best.
>>
Spent a couple of minutes and came up with this. Really, really fucking easy. Kind of makes me mad that this isn't a default shader/feature in Cycles, but I guess it's not part of the roadmap, eh.
This is replacing the Emission node with AO nodes and cutting out the Light Path node. The scene's AO distance is set to 0, there's(black) AO shading setting it above that.
Hope all this helps somebody.
>>
>>520480
Ah, I just thought of it, but using this technique you could use this technique to make a pure toon shadow in any kind of shading setup by setting the main color in the Mix node to 1, subtracting 1 from the resulting color, and using an Add node to connect this node setup to a node setup of your choice. Because the result of the shadow calculation would be main color = 0 shadow = negative, and because Cycles allows negative light values, an Add shader would result in the color calculated by this shader(again, the main color is 0, so only a shadow) to be subtracted from the main shader.
Sorry for all the samefagging, I'll try to make this my last post but my OCD and excitement over this keeps bringing me back. I spent days on this last time if I remember right for an much shittier result.
>>
I don't mind, this is actually interesting.
>>
Uh... One more, I guess.
The viewport render preview(shift+Z) renders almost in real time using this. I don't think there's a way of getting a visually appealing render preview result this fast any other way with Cycles, or in Blender at all. This is with pretty much no sampling. By comparison Blender internal with similar setups is much slower for me. My graphics card is a GTX 980, so although it's good(?) it's not 1k+ budget level.
>>
>>520485
Most GPU/CPUs should be able to do a few samples of emission shaders in Cycles in a second or two.
That was even the case on my old toaster.
Now if Cycles can just get real-time compositing and Freestyle can stop sucking.
>>
Oh, another thing... you may want to keep an eye on the PBR branch(es?) of Blender. You should easily be able to do this stuff in GLSL. Not to mention, you could do this in Blender internal renderer in the viewport already.
>>
File: fryby.webm (660KB, 853x480px) Image search:
[Google]
660KB, 853x480px
A short flyby, render time was about a minute or two. A 1980x1020 image renders in about 4-5s.
>>520489
Yeah, even with samples it's fast, I just wanted to show the speed vs visual clarity at a minimum setting. Sorry if I've misinterpreted you.
>Now if Cycles can just get real-time compositing and Freestyle can stop sucking.
Post-process viewport shaders in Cycles would be a great addition for sure, I assume that's what you're getting at.
However, this might be an equivalent statement but access to a shadow map with self shadow in particular is the biggest flaw Cycles has for NPR to me. I should have noted that the hair shadow in the images I've posted is fake, it's just a semi-transparent mesh and not a real hair shadow. Until I can get working toon self-shadow in Cycles(WITH freely adjustable color independent of scene elements) I'd still probably use BI, even though my CPU is far weaker than my GPU.
I have a feeling that with the values given by the Texture Coordinate node now it may be possible to generate a self-shadow map, but if it requires at least two passes like I think it does, it might be impossible with Cycles' current implementation.
>>520490
It's easy in BI, but this is much, much faster than BI for me. My CPU is probably a little behind the times now compared to my GPU, which is mostly why I was looking into this this time around. Like I said above, though, no self shadow really hurts and makes this a poor option for anything but playing around or testing.
I suppose if you simply accepted that you're not going to be able to get self shadow you could just have a secondary setup with normal diffuse shaders to use as a self-shadow pass in compositing. But that's not ideal to me; the goal would be to be able to see a good preview of the final output while working.
Curious what you mean about GLSL though. I can do HLSL to some extent but I haven't gotten into GLSL yet. Can you incorporate GLSL shaders into Cycles?
>>
Anyone here have an opinion on what the best package for NPR rendering is? Max+Pencil?
Here's the 1920x1080 image mentioned above, rendered at low samples(render time=4-5s). Again, I should have mentioned it earlier, but the hair shadow is faked.
It's just a semi-transparent mesh, sadly there's no real self shadow and aside from compositing techniques I don't think a simple toon self-shadow with freedom of color choice is possible in Cycles at this moment. Which pretty much equates to this shader being unusable except as a supplement.
>>
>>520543
I was being unclear, but by "hair shadow" I mean the shadow of the hair on the face only, not the shadow on the hair itself. Sorry about that.
>>
>>520543
Why don't you use something like Unity where you can literally get this realtime ?
>>
>>520545
This is just a tech preview of a means to an end and Unity wouldn't really work for the end/desired workflow. In short I'm interested in this as another technique to use in a fully equipped modelling+animation+rendering package, this is only the development of a shading element and not a final shader.
>>
>>520545
And I guess your question was probably more about my concern about real-timeness, and the answer then is just that regardless of what you're working on having a real-time preview that's close to the final result is desirable, especially if you're animating. However, while the fact that it's fast is great(and so I brought it up), I'm more concerned about the final product of the render(and the freedom I have to shape and animate the model) in this case.
>>
File: selfshadow.png (1000KB, 1878x639px) Image search:
[Google]
1000KB, 1878x639px
For anyone unclear what I'm talking about with self-shadow and why this isn't very good, I created a simple compositing setup(using an extra, default-shader diffuse pass) that has self-shadow. The left is closer to what the shadowing should look like, ideally.
The left picture is the composited setup(with self shadow), the right is the uncomposited render(no self shadow). Even if the self shadowing isn't pretty here, you can see which shadows are being lost without self shadow(again, this is the hair only).
The ID mask is just stuff I did to target specifically the hair because I'm too lazy to set up the entire model, ignore it.
Unfortunately this slows the speed of the render and cannot be viewport-previewed.
>>
>>520542
>Post-process viewport shaders in Cycles would be a great addition for sure, I assume that's what you're getting at.
No, I don't mean viewport shaders like AO or DoF, if that's what you are thinking, I mean compositing.
>Curious what you mean about GLSL though. I can do HLSL to some extent but I haven't gotten into GLSL yet. Can you incorporate GLSL shaders into Cycles?
I mean the viewport when you have it set to "Material" display mode. That is GLSL. Blender's internal materials can do most of what you are doing here, though I'm not really sure what you are trying to accomplish with the self-shadowing. Cycles too has some basic material previewing, but it can't handle anything too complex.
>>
>>520475
You're back. It's been a while. I remember compiling that one thread of yours into a PDF for research purposes (I'm not kidding).
Fast forward to now and I remember devising a solution almost similar to yours but I haven't been able to really figure out what will work better on mine.
>>
Is the coloring om the skin/hair/shirt texture or procedural? I saw the previous pics, but that patches of red make it look hand-drawn. And I'm not sure at all about the shirt and hair.
>>
>>520849
Some of the elements on these are painted on the textures.
>>
>>520475
This is some really interesting stuff, do you have a blog or somewhere where you go into detail? And/or at least where you have mirrored this from/to so I can credit it for a uni paper?
Thread posts: 21
Thread images: 7
Thread images: 7