I want to add that the merge of HBAOPass was premature, imo. I’ve written my concerns in HBAO pass is not the "real" HBAO, but N8AO · Issue #27295 · mrdoob/three.js · GitHub and Examples: webgl_postprocessing_ao (SSAO, SAO, N8AO, HBAO, GTAO) by Rabbid76 · Pull Request #27296 · mrdoob/three.js · GitHub and I do vote to remove the HBAOPass from the repository.
No one is against this PR.
I’m okay with adding an external example for the postprocessing package but I’m against replacing EffectComposer and the pass classes. Post processing is an important component for a 3D library and it has to be part of the main repository. The core project needs to define/standardize how passes should be implemented and must provide the component that processes the pass/effect chain in an optimized fashion.
I don’t think EffectComposer is that much worse like claimed by @drcmda. Statements from him like “jsm/ec renders your whole scene for every pass you give it” are just wrong (btw: not the first time he writes misleading nonsense like that). After the feature update in the summer, the last relevant bits that are missing is buffer sharing (meaning you generate e.g. a normal buffer just once and share it in all relevant passes) and uber shader generation, imo. Buffer sharing could be added to the current EffectComposer with no breaking changes. I’ve planned to do this and also have a mental roadmap but just had not the time so far. I would be glad if someone else from the community could help with implementing Allow post effects to request access to depth and normal passes · Issue #7668 · mrdoob/three.js · GitHub. We could chat about the details and I would also review the code as good as possible. Having this in EffectComposer would close the performance gap to postprocessing in certain use cases.
The uber shader generation is cool but I have originally not planned to add it to EffectComposer because of the respective complexity. When we start implementing post processing for WebGPURenderer with TSL and node material, we can implement this feature in a very elegant fashion and also provide WebGPU/WebGL support at the same time which postprocessing does not, afaik.
However, I’m excited to hear about @PavelBoytchev plans and would love to see this in action! Maybe this is something we can also integrate in the main repository 
.
To clarify, external projects are fine and I have never claimed they are bad or unfavorable in some fashion. Actually, I am one of the collaborators that often voted to move certain features out of the repository into third party packages so we (the core team) can focus on other stuff. But certain components are ciritical and should be part of the main repository. Post processing is one of it.