I don’t see why. That seems unnecessarily restrictive. People should be able to create their own instances of the individual Filter classes, inherit from them, etc. Part of the flexibility that this overhaul would offer is that it would allow people to customise CommonFilters with their own filters by creating their own Filter class and adding it.
I imagine that CommonFilters can store a list of filters with a sort value each that would determine in which order they get applied in the final compositing stage…
I imagine methods like setVolumetricLighting() to become simple stubs that call something like addFilter(VolumetricLightingFilter(*args, **kwargs)).
Makes sense. By a “single stage”, you mean a part of the final compositing filter, or an individual render pass (like the blur-x and blur-y passes of the blur filter)? These are two separate concepts, though I suppose they don’t strictly need to be.
Ah, so CommonFiltersCore represents a single filter pass? (Can we call it something like FilterPass or FilterStage then?) Can we let the Filter class set up and manage its stages rather than the CommonFilters? It does sound like something that would be managed by each filter, although I suppose some filters might share a filter pass (ie. blur and bloom may share an initial blur pass). Hmm.
I don’t understand what you mean by “capturing a buffer”, could you please explain that? You can already use FilterManager with a buffer, if that’s what you meant, but I don’t quite understand the necessity of that.
Could the user achieve the same thing by subclassing Filter and adding this Filter to the same CommonFilters object?
Then I think that FilterStage would be a far more representative term, don’t you think?
One thing I don’t quite understand - is a stage a render pass by itself, or a stage in the final compositing shader?
Not all stages need an input color texture. SSAO, for instance, does not.
I think FilterConfig is obsoleted by the new Filter design, since each Filter can just take all of the properties in the constructor via keyword arguments, and have properties or setters that invalidate the shader when they are modified depending on the property. Each setter of a particular Filter could either update a shader input or mark the shader as needing to be regenerated.
I think that each filter could possibly be a Cg function with the arguments it needs passed to it for better organisation.
You could have a filter stage that’s added by default with a negative sort value with its only purpose being to set o_color, which is always applied first.
I agree that this probably belongs in the the individual Filter classes.
I think HalfPixelShift should be a global setting in CommonFilters and not a filter at all.
I think at this point it would help to hack up some pseudo-code that kind of shows how the systems work together and perhaps showing a example filter while skipping over the details. It would help to get a good overview and help me to understand your design better.
