Postprocessing: Why use this over default three postprocessing? [question]

[timnlupo]

Hello! Great work on this library, it's really awesome. Related to #78, I was wondering about your perspective on why to use this library over the default three postprocessing? I normally avoid third-party repos but the ease of use and consistent maintenance of this project is very attractive. For context, I'm working on a mobile project so performance is very important. Thanks so much :)

[vanruesc]

Thank you! I'm glad that people find this library useful :)

I normally avoid third-party repos

I personally only look at the maintenance status of libraries. When was the last commit? Does it have proper documentation? How much thought went into bundler compatibility? Is the code base clean and future-oriented or messy and poorly structured? Does the API make sense? Does the maintainer respond to feature requests and suggestions? How many issues and PRs are there? If most of these questions can be answered positively, then it doesn't really matter where the library is coming from, I'd say.

I was wondering about your perspective on why to use this library over the default three postprocessing?

In my opinion, three's postprocessing library is still in a weird place. It started out as example code and still hasn't really moved from that spot. The following issues with the official postprocessing examples led me to create this library:

• No documentation.
  
  
  
  • The API must be understood from examples.
  
  
• The examples use outdated ES5 syntax which makes tree-shaking impossible.
  
  
  
  • Classes use fragile dependency code such as if ( THREE.DigitalGlitch === undefined ) console.error( "THREE.GlitchPass relies on THREE.DigitalGlitch" );
  
  
• Importing something from an examples directory puts me off.
• The typescript definition clutter is annoying.
• No proper bundling and minification pipeline to support efficient CDN use cases.
• There are multiple passes that solve the same problem.
  
  
  
  • SAOPass, SSAOPass, BloomPass, UnrealBloomPass, BokehPass, Bokeh2Pass.
  
  
• No proper support for outputEncoding.
  
  
  
  • It's also weird that three doesn't use hardware encoding/decoding. I recently investigated the history of the encodings GLSL code in three and still couldn't figure out why they implemented it in software but I think it has to do with the PMREM and cubemap code.
  
  
• I don't agree with the auto-render-to-screen implementation.
• No automatic depth texture management for passes like SSAOPass and BokehPass.
• No initialization mechanism for passes, meaning passes never have access to important information or the renderer before rendering starts.
• Passes use a fullscreen quad instead of a single triangle, causing additional fragment calculations along the screen diagonal.
• No shader merging.
• You don't actually need a camera to render postprocessing effects, but WebGLRenderer.render requires a camera so we have to use a weird dummy camera for no good reason.

There have been discussions lately that partially address the future of postprocessing in three. I plan on changing the EffectComposer to act more like a plugin than a wrapper. However, there seems to be some sort of problem with how WebXR affects post processing and I don't own VR hardware to investigate that.

There's also https://github.com/mrdoob/three.js/pull/18322 which I don't agree with.

In my opinion, three needs some sort of plugin system to support WebXR alongside postprocessing in a non-hacky, modular fashion. Then, even if the postprocessing code from the examples moved to core, it would remain as an independent module that interacts with three through a public interface. That way, it could freely be replaced with another postprocessing implementation, such as this library, if so desired.

This is a bit off-topic, but I also think that three should be a monorepo 🤔 Things like GLTFLoader should be organized in subprojects with proper independent semantic versioning:

import { WebGLRenderer } from "@three/core";
import { PostProcessor } from "@three/postprocessing";
import { GLTFLoader } from "@three/loaders";

[timnlupo]

Great, thank you!