Postprocessing: General questions about your shaders and render pipeline

[gigablox]

I was looking through the open issues hoping someone would have congratulated you on getting all of these examples to work so well with the r92 build. Congratulations this is awesome work!

I can speculate why you went through so much effort to build this postprocessing lib separate from the Three repo - but I'm curious to hear you explain it for yourself :)

• What was the reasoning behind creating this lib in the first place?
• How does your render pipeline differ from Three.js and is there any performance benefits?
• Are the shaders direct ports from Three.js ones or have you modified/optimized many of them?

[vanruesc]

Thanks for the kind words!

What was the reasoning behind creating this lib in the first place?

I created this library as part of a research project with the aim to learn how post processing works. I closely examined and revised all the post processing examples, including the shader code, and acquired a sound understanding of the available effects. I also wanted to have a documented post processing library that I could rely on if I ever needed one because the post processing code from three.js is not officially published on NPM and the examples are not as actively maintained as the main code base.

How does your render pipeline differ from Three.js?

There are some differences in the way passes are initialized, resized and disposed as well as some other API differences. For example, a pass will be initialized explicitly when it is added to the list passes. This allows it to warm up custom render targets to prevent awkward hiccups at the start of the render loop.

Apart from that, the postprocessing library still roughly mirrors the post processing examples from three.js and the render pipeline is pretty much the same. However, I actually plan on changing that quite drastically in the near future if time permits because the current approach is not very efficient. I will open a discussion for that soon to explain my plans in more detail and maybe get some feedback beforehand.

Are there any performance benefits?

At present, there are no substantial performance benefits. However, the BlurPass uses the Kawase convolution technique instead of the Gaussian approach and takes advantage of independent texel-fetches.

As I mentioned above, I intend to change the render pipeline because the current one is inefficient. The general idea is to merge passes at runtime to reduce the amount of fullscreen render operations which will greatly improve performance for the case where multiple passes are being used.

Are the shaders direct ports from Three.js ones or have you modified/optimized many of them?

Most shaders have been cleaned up by removing unused variables but as far as I can remember there was no need for many optimizations. Some shaders have been modified to support a high quality screen blend mode. The shader used in the FilmPass uses various preprocessor conditionals to exclude unused code. Passes that depend on depth information like the BokehPass have been adjusted to support logarithmic depth.

Although unrelated to performance, the OutlinePass supports skinning, morphing, clipping planes and dark outline colors as opposed to the original one from three.js. Some passes, like the ToneMappingPass and GodRaysPass, also support dithering to remove banding artifact.

I occasionally check the commit history of the three.js examples to incorporate new improvements if there are any 😇

[gigablox]

Thankyou for putting time into your explanation.

merge passes at runtime to reduce the amount of fullscreen render operations which will greatly improve performance for the case where multiple passes are being used.

^ can't wait for that.

[vanruesc]

I will open a discussion for that soon to explain my plans in more detail

I've outlined my thoughts on pass merging in #82.