cartoon shader using the normal

I want to use the cartoon shader in a scene that is completely white, in hopes that it would put in the outlines to make a certain effect. However, the commonfilter’s cartoon filter applies a sobel filter to the render result to detect edges, which means there are no edges in the completely white scene. I tried to write my own shader in the hopes that I could use the sobel filter on the normal of each pixel, which would differentiate between faces facing different directions in the completely white scene, but according to:
panda3d.org/manual/index.ph … der_Inputs
There is no fragment shader input for normal.
How would I make shader that does this?

You will probably want to do this as a postprocessing effect. The normal vector isn’t available to a postprocessing shader; it needs to be passed in using an auxiliary target.
When setting up the scene buffer, request an auxiliary color target. Then, you need to add the AuxBitplaneAttrib.ABOAuxNormal flag to the scene and call scene.setShaderAuto() to make it fill in the normal vector into the auxiliary render target.
Then you can use addRenderTexture to bind a texture to that auxiliary render target and pass that into your postprocessing shader.

FilterManager partially automates this process. Technologicat is currently working on an overhaul of CommonFilters, making it easier to add custom filters. I believe he also has many updates to the cartoon shaders. If you’re willing to wait for his changes, that may be an alternative.

Great, I got the shader working perfectly. Thanks!

Whoops, I spoke too soon. How do i make the auxiliary buffer find the normal of transparent objects?
And is it possible to make the depth buffer ignore transparent objects?
And, also, I wanted to add one colored object with vertex colors, but the line,“render.setShaderAuto()” causes all vertex colors to go completely white. How do I avoid this?

You mean completely transparent objects? If you want those to show up in the normal buffer, you have to disable alpha testing. That would go right against your other goal, though, which is not to render transparent objects in the depth buffer, which would happen if you enabled alpha testing.

If you really want to render some fragments in the normal buffer but not into the depth buffer, you may need a muti-pass render set up with different alpha test settings between passes.

Sorry, I should have been more clear. What was causing problems is that I have a partially transparent object, but It shows up in the depth buffer but not in the auxiliary buffer. This causes my shader to go bananas. As long as both buffers agree, I can get it to work as intended, but I would prefer that the object show up in both buffers.

Hmm, I’m not 100% sure why this could happen, but I’m starting to get a feeling that this is due to the lack of per-target color blend controls in Panda. This is a feature I’ve been meaning to add to Panda in the future, but I simply haven’t gotten around to it.

Assuming “myNodePath” is a NodePath that refers to the object in which you want to use vertex colors, this might do the trick:

from panda3d.core import ColorAttrib
myNodePath.setAttrib(ColorAttrib.makeVertex())

It should tell the autoshader to use the vertex color information for the object myNodePath. This seems to be off by default.

And yeah, as rdb said, I’m working on overhauling CommonFilters to make it easier to extend.

As for cartoon shading, there’s a bug in the cartoon ink filter included with Panda - it misses some edges, because it doesn’t consider the normal’s z component. The generated documentation page on AuxBitplaneAttrib states that only the R,G components are used for the normal in the aux buffer, but this is incorrect. If you look at panda/src/pgraphnodes/shaderGenerator.cxx in the Panda sources, searching for _out_aux_normal, you’ll notice that the main autoshader outputs all three components of the normal (to .xyz, equivalently .rgb, of the aux render target). The ink filter should maybe be fixed while I’m at it…

Also, the default inker doesn’t do any antialiasing. I have two alternative improved inking algorithms coming up, right after the CommonFilters overhaul is finished.

Aside from the inking, I’m also adding specular quantization and smoothed light/dark transitions to the light ramping in the main shader, but judging by your description, that might not be relevant for your application.