Ah, that wasn’t my intention. Internal stages belong to a filter instance - logical stage merging only controls which filter instances go into which FilterStage. So there is no case where only the internal stages would be merged - it’s either the whole filter or nothing.
The way I’m planning to implement VolumetricLighting is to insert an extra BloomFilter in the main pipeline, but with its “participates in compositing” flag cleared. This BloomFilter will live in the same logical stage with VolumetricLightingFilter, with a smaller sort so that it goes first.
Then VolumetricLighting registers the “bloom3” texture (or whatever has been set as “source”), and FilterStage walks its list of filters backward (starting from that particular instance of VolumetricLighting), looking for one that provides it.
This is just a few lines of code, and in any case I think this “flattened pipeline” solution is simpler than having filters contain other filters.
Yes.
I expect that internally, the Filter implementations will do that anyway (either that or the variant with “%{myuniform}s” % myparams).
So maybe we don’t need anything special here? I’ll see how it looks, and then return to this.