Skip to content

Shared WebGLRenderTarget pool or configuration? #377

@donmccurdy

Description

@donmccurdy

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:

  1. 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.
  2. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions