Compatibility with other postprocessing solutions

[PontusHorn]

The <Pass> component is quite handy in its ease of use. However, its implementation seems to depend on the post-processing examples in three.js, so if you want to use something like the postprocessing package it seems you're out of luck. Any thoughts on adding support for this?

In the case of the postprocessing package, the basic API is not quite drop-in but still pretty similar (there's an EffectComposer and a default RenderPass with the same constructor signatures as the three.js examples), so it probably wouldn't be too hard to specifically support this package as an alternative. In theory I suppose there could be other solutions with varied APIs, so one could argue for a more generic way to hook into the render cycle, but in practice I don't know of any other postprocessing solutions, so going that far might be overengineering.

[grischaerbe]

You are right, the <Pass /> component was a bit of a quick shot.
Actually I didn't come across the post-processing library you are referring to before. It looks like it's the perfect fit for most post processing concerns. But you are also right in that I would like to implement a more generic way of hooking into the render cycle. For the projects I'm doing with threlte I find myself constantly adding things which would make a perfect fit for a threlte-extras project/library. So this whole post processing topic could actually go there, especially if it's involving external (non-three.js) libraries. What is your opinion on that?

[PontusHorn]

I tend to prefer more targeted add-on libraries over catchall extras libraries as they often end up sprawling a bit. Sometimes it's a better fit though, e.g. if many of the extras are interconnected.

I think my ideal setup would be:

• Some way to hook into the render cycle, so as to not get in the way of the user.
• A layer of opinionated abstractions for the various effects and passes provided by the postprocessing library, focusing on ease of use (tweaking these effects can be pretty daunting if you're new to them, so sensible defaults, good autocompletion and simple docs can be a great value).

[FreddieRa]

Joining this thread, it would be nice for a plug-and-play way to use effects like https://github.com/mrdoob/three.js/blob/master/examples/webgl_effects_ascii.html since it's not entirely clear at the moment how to get hold of the renderer for effects like this.

[grischaerbe]

So with the new monorepo we could have a package @threlte/postprocessing, what do you think?

[ixxie]

@grischaerbe with the availability of useRenderer this can be closed possibly?

[grischaerbe]

Yep, useRender makes implementing a custom render pipeline a breeze.