This makes the texture available as k_tex0, not tex0 – make sure you are referencing k_tex0 in your code, otherwise it will use the color tex (in this case, it will use the original color tex, undoing the results of the sharpening shader)
I do recommend to rename tex0 into something less confusing, like “src” (like CommonFilters uses)
Since every renderQuadInto create an off-screen buffer, I am wondering if it is possible to reduce this resource requirement if I have a long chain of stages ? Is it possible to rewrite part of FilterManager.py to use just a few off-screen buffer for this daisy chain effects ?
Hmm, you could use MRT to have multiple outputs per buffer, but I’m not sure whether that will actually be faster than having a chain of buffers. Since there’s only one quad in that buffer, I don’t expect it should be too slow - is it?
I don’t think it’s an issue. If you can show me a better way to do it, I’d love to implement it. But you really do need a chain, I think, since each filter depends on the previous one (this is why you can’t use MRT as well).
Does OGRE use a chain of filters like this as well?
Since I don’t know the details, I just imagine that it can use 2-3 buffers for a chain (from a normal program point of view). Of course I have not considered any limitation in panda architecture.