Repository navigation
Shared WebGLRenderTarget pool or configuration? #377
Description
Is your feature request related to a problem?
Related:
Many passes construct their own render targets, either unconditionally (GaussianBlurPass#L40) or when not otherwise specified (CopyPass#L32-L43). The second behavior is better than the first, but I wonder if we could do even more for supporting different user workflows. Consider:
- User A has an unlit 2D application with lots of screenspace effects, and wants to render into an 8-bit sRGB render target to keep precision and performance.
- User B has a photorealistic 3D application with both HDR effects (bloom, tone mapping) and additional effects after the tone map, and wants to render into a 16-bit Linear-sRGB render target at least until the tone map, and may or may not want high precision after that.
Describe the solution you'd like
I think the minimum goal would be to allow enough configuration in all passes so that none are incompatible with either of these workflows, as long as you configure every pass correctly and consistently.
Perhaps it would be even better to share render targets — or at least their configuration — somehow? For example:
import { Pipeline } from 'postprocessing';
// in application code
composer
.setPipelineOptions( Pipeline.SCENE_LINEAR, { type: HalfFloatType } )
.setPipelineOptions( Pipeline.DEPTH, { depthPacking: RGBADepthPacking } );
// in FooPass.js::render
this.renderTarget = this.composer.requestRenderTarget( Pipeline.SCENE_LINEAR );
// ...
this.composer.releaseRenderTarget( this.renderTarget );The API proposal is probably half-baked at this point. I'm not sure how safe it would be to reuse render targets in different passes. But would be interested to hear others thoughts on whether this makes sense, and could make it easier to configure a full pipeline correctly.
Activity
vanruesc commentedon Jun 25, 2022
Thanks for the input!
This will be addressed by the redesign in v7 which will introduce render pipelines, explicit input/output (uniforms and render targets) for passes and effects as well as a centralized frame buffer manager that will pick up on the explicit IO. These goals are next on the road map, but I'm currently working on bilateral blur for SSAO which doesn't go as smoothly as I had hoped...
Reusing buffers is indeed tricky since there are so many different settings involved, but it should be possible to at least reuse some buffers across passes. Render targets in effects can probably not be reused across effects because they are required to remain unchanged in the context of the render operation of the outer
EffectPass.I'll open a discussion ticket similar to #82 for feedback once the v7 concepts are done and the ideas are more concrete.
vanruesc commentedon Feb 9, 2025
Closing this in favor of #633.
Resource management in v7 has already progressed a lot and the last remaining (and big) feature is automatic buffer sharing which should be doable now since all passes and effects use resource wrappers that support override values.
At this stage, we probably won't need another discussion ticket.