EffectComposer2 #15694
EffectComposer2 #15694
Conversation
EffectComposer2 is a successor to the post-processing stack EffectComposer. Its advantages are: 1. A simpler but more flexible Pass API. Passes specify a list of input and output buffers that they need instead of having "readBuffer" and "writeBuffer" passed in. It's intended that in the future buffers can contain depth, normal etc. information in addition to color information. There's no more "renderToScreen" flag for each pass - instead the final color render target for EffectComposer gets passed to the render() function. 2. Common functionality is shared between render passes. For now just the RenderPass and ShaderPass are ported to the new EffectComposer2, with more to follow. The postprocessing pixelation example is updated to use EffectComposer2.
All the passes that this example uses are ported to EffectComposer2.
SAOPass2 still renders the depth and normal buffers itself instead of receiving them as inputs, but it's now compatible with EffectComposer2.
|
This is still a work in progress, uploaded for discussion. |
The color rendering was actually done by the RenderPass2 prior to SAOPass2, so SAOPass2 is only concerned with rendering the depth on top of that. This is a step towards moving the scene rendering entirely out of SAOPass2.
The bloom pass is a bit of a special case since the same buffer acts as both an input and output buffer for it, and the pass needs to be able to sample it as a texture. Passing the default framebuffer to the UnrealBloomPass2 doesn't work. So EffectComposer2 now supports having a pass that's only able to render to a texture. In case it's the final pass when rendering to the default framebuffer, then EffectComposer2 will copy the pass output from the texture to the default framebuffer.
Here EffectComposer2 has an advantage over EffectComposer that a separate copy to screen pass does not need to be set up. If the SSAARenderPass2 is set to "accumulate to texture" mode, then it will still render to the buffer provided by EffectComposer2, and EffectComposer2 will automatically perform the copy.
Oletus
force-pushed
the
effect-composer2
branch
from
183258e to
e228498
Compare
This ensures that unused render targets don't get created. It's determined automatically whether the render targets need a stencil buffer or not based on the presence of mask passes.
Oletus
force-pushed
the
effect-composer2
branch
from
e228498 to
56800d9
Compare
|
I like how you've removed the confusing "readBuffer" and "writeBuffer" from EffectComposer. I also like that you've sort of added the ability to pass a camera to fillQuad (renderWithClear) e.g. in ShaderPass. There still is a problem with that that it breaks use of Layers just like the original postprocessing. Would you consider passing a camera to ShaderPass, just like any other pass? fillQuad.camera could be renamed to fillQuad.defaultCamera for clarity. I can't quite comment on the rest at this time - it's been a while too since you submitted this. Are you still working on this? |
|
I'm not actively working on this right now. Some of the smaller enhancements were merged to the existing EffectComposer in PRs #15976 and #16033 . It would still be nice to create an upgraded version of EffectComposer that would get rid of the confusing usage of "readBuffer", but this is a tricky change to make since all the postprocessing passes need to be upgraded, and this change didn't seem to create much interest back when I started on it. Maybe we could make further small changes while keeping things backward compatible like renaming the parameters so that the names would be more intuitive. |
|
I'm not quite sure what you refer to when you talk about problems with layers. Applying regular camera layers doesn't make sense when a postprocessing pass is filling the screen with a single quad, and as far as I know when some passes perform scene rendering with an override material regular camera layers are being applied like they should. |
I have a project where I need to turn groups of objects and some postprocessing elements off at times. Using Layers is a good way to do that, by design. I guess Pass.enable could be used, but in my experience that leads to unexpected results due to buffers not being swapped when they need to etc. The Layers of the fillQuad is easily set as it's a public property already. Camera used to be hidden. I agree it's an uncommon case, and it could be seen as a workaround the real problem which is that Pass.enable is tricky to use. :) |
|
With MRT now in the core, I think this should be revisted again. We also need some pooling for render targets |
|
I don't use the EffectComposer a lot (I in general use a custom one). I wrote a course though and I wanted the students to be able to use post-processing easily. I actually discovered that a lot of post-process weren't following the same API. Some post-process don't handle the resizing correctly, example with the Bokeh Pass. Should we give a try to an improvement to the effect composer? Or should we track down the effect that aren't following conventions? |
I would start with that since we easier have results. Discussing a new API for post processing is a bigger thing. |
|
I can give a shot to fixing some of the post-process. Not the same issue, but I still think we need to add an API to re-use / share the render targets |
|
Closing, see #12115 (comment). |
4 participants
EffectComposer2 is a successor to the post-processing stack EffectComposer. Its advantages are:
A simpler but more flexible Pass API. Passes specify a list of input and output buffers that they need instead of having "readBuffer" and "writeBuffer" passed in. It's intended that in the future buffers handled by EffectComposer2 can contain depth, normal etc. information in addition to color information. There's no more "renderToScreen" flag for each pass - instead the final color render target for EffectComposer2 gets passed to the render() function.
Common functionality is shared between render passes.
The API for the passes has changed so that passes written against EffectComposer are not compatible with EffectComposer2, so this is added alongside the old EffectComposer instead of replacing it. However, the outward-facing API is mostly the same with the exception of removal of the "renderToScreen" flag.