Render Passes for NPR shaders in Blender
Allow render passes on NPR shaders, like in previous versions of Blender. Now for instance in 3.2, the 'diffuse light', or 'specular pass' comes back as blank when using 'shader to rgb' node.
This new approach will severely limit the use of compositor with simple NPR style shaders if so, as you can only pump everything through one pass (emission). Unless there is a new approach to this node setup I'm not aware of. Other NPR shaders with a colour component also get lost when going between passes.
I've attached screenshot of old behaviour which allows blender to be used for NPR projects at scale.
New approach just returns this
Initially reported as a bug as it seems very weird to go back on this feature, but apparently it's intended functionality going forward, so I'm putting it here as a feature proposal - hopefully will return.
The upcoming realtime compositor and Eevee next has me excited for Blenders future in NPR work, but without being able to separate out passes effectively, both are essentially useless to NPR work.
Below is an example of a simple fixed width line pass around a diffuse light and spec passes for an example of the kind of work that is impossible with the new set up. (some quite large clients are very excited about this kind of work and is where Blender has been really shining)
and another screen printed style, also impossible without the compositor and shaders working together effectively. ( colours are multiplied over each other after the render, like a screen print)
another approach moving forward, might be to have a shader node that forces particular parts of the shader tree through to certain passes? (specular, emission, diffuse)
EDIT: Here's a workaround I figure out for in the meantime for anyone interested.
For those wondering, I've found a solution using a node tree I had to flatten out normals. Basically I flatten out the base BSDF normals completely and build up from there, using another BSDF with modifications as the factor.
So far it returns diffuse light, diffuse colour. Shadow colour is currently on the emission pass, and I'm hoping that specular light/colour can be implemented too.
It works pretty well for more complex shaders with textures and AO baked in etc too. Although it might be a bit heavy, I'm not entirely sure. Hopefully this opens up NPR shaders for use with the compositor a bit again in the meantime.
8 Comments
Could you provide the link of where you saw this reported as bug and then declined as intended behavior?
To me, it doesn't sound like render passes should not support displaying the data they should carry...
That being said, looking at your shader I can see that your setup is, strictly speaking "illegal". You plugged a color data in a socket that expects a shader data. Luckily for you Eevee and Cycles are able to interpret it anyway, but in more strict renderers this would result in an error.
Theoretically speaking, what you do would be the exact thing as passing your color data through an Emission Shader node, then itself passed to the material's surface input.
And this should definitely be visible in at least the emission pass.
In addition, if you were on Cycles, the ideal solution would be to also make the shader not emissive outside the reflections and direct camera visibility, like so:
Thanks! Yep, no problem - here is the link developer.blender.org/T100166
What you are describing using the emission shader is down as an actual bug in 3.2! :) You can see Clement has made a note of it, so happy it's being addressed.
Having said that, it doesn't address being able to composite effectively with separate passes. In NPR, generally speaking, having it all go through an emission shader, as opposed to the main render output produces the same result. And yes; although technically 'illegal', Blender already outputs the combined render result correctly. So it's odd that you can't rebuild what you see in the render/viewport in the compositor. The secret sauce of compositing (NPR especially) is being able to separate out and rebuild the image in a compositor with modifications.
Thanks for the tip about cycles, it could help. I'm currently trying to build a workaround shader for now in 3.2, but its quickly growing in complexity :S There could be a linked multi-scene solution for now using both render engines. I'll keep tinkering away at it :)
That confirms my thoughts: the node tree should not send color data into the shader socket. And since the current NPR shades on Blender are basically cheated shadows baked in the color data then sent as a shadeless color display: that's done using an emission shader, that's why it ends up in the emission pass.
Then if you need to further differentiate things, you can always use either AOVs or cryptomatte.
In the future, I'd hope that Blender could rework the toon shader - which is currently basically not used at all in most NPR. What it should produce, as in other softwares, should be basically a flat shading, which would be the shader version of our current workarounds of using a combination of shader then baked to color data via the Shader to RGB node.
Yes a more versatile toon shader would be great. For now, I'm hope full this will work again in Eevee-Next. If you are interested I've put my current workaround in the initial post.
Hi thanks for this request. Note that in Eevee-next the whole renderpasses are rewritten to be more mature. Previously the render passes where extracted from the materials, but in eevee next the shaders build up the render passes and keep them around. If everything works out this means that Shader2RGB doesn't scramble the render passes anymore.
Every change will add other consequences/limitations, but it is still to early to say what those eventually will be. It would be great if you would be able to give us feedback when Eevee-next is in alpha stage.
Thanks Jeroen! This is excellent news if it pans out.
For now I can stick to 3.1 and fingers crossed it works out with Eevee-next. I'll definitely be keeping an eye out for Eevee-next Alpha and happy to give any feedback I can.
I've posted my current workaround if your interested in the initial post.
I agree with you that not having anymore dedicated pass for diffuse light when using shadertorgb it's a pity, but I don't understand why for the workaround you had to build that node-tree using normals. Can't you just use a black and white color ramp with the stops in the same positions as the colored one and use that with a shader AOV to have your mask?
imgur.com/a/UnVbC7K