PBR linear output: guidance on opt-in seam and minifier-only bundle delta

[bakovskydamian]

Use case

We are prototyping a generic opt-in path that allows a PBR scene to render its completed linear RGB result into a floating-point render target so that the application can own post-processing and final presentation.

The intended split is:

PBR lighting / IBL / emissive / plugins / fog → linear HDR render target

Then application-owned:

exposure → tone mapping → display gamma / presentation

Proposed API

enablePbrLinearOutput(scene: SceneContext): void;

Called on a fresh scene before mesh/build/registration work. It is opt-in, idempotent while fresh, and has no runtime disable; a new scene is required to return to display output.

For opted-in PBR, the final exposure, tone-mapping, display-gamma, clamp and contrast processing is omitted. Alpha is unchanged.

Current implementation shape

The prototype follows the same general family as other optional Lite enablers:

• Lazy WeakSet owned by the enabler.
• Resolver installed only when the feature is enabled.
• Optional resolver call in the PBR build path.
• No feature work during frame rendering.

The currently open implementation in PR #674, at 441b245e215e87fd8d19f3a1de1ca24c29846e24, uses a similar enabler/WeakSet/resolver shape.

Functional proof

Focused fixtures pass against source, lib and dist builds:

• rgba16float, 4x MSAA + resolve, with linear PBR readback [14.34375, 14.34375, 14.34375].
• Fog and unlit preserved.
• Alpha MASK and double-sided preserved.
• CSM and a public MaterialPlugin contribution preserved.
• Two scenes with opposite policies remain isolated on one device, in both build orders and after rebuilds.
• Default output remains unchanged.
• No WebGPU validation errors in the focused fixtures; 57 devices acquired and 57 destroyed.

Bundle result

Fetched runtime bytes, measured with the same toolchain and lockfile against c9958540d15e457e2f4ba2be55d17dcfb0b09e39:

Scene	Base	Candidate	Delta
scene1	89481	89476	-5 B
scene10	52574	52577	+3 B
scene214	69338	69338	0 B
scene216	53756	53759	+3 B

For scene10 and scene216, inspection of every emitted runtime chunk found no retained linear-output feature semantics/code.

The +3 B is caused by three occurrences of an existing baseColorMod identifier receiving a two-character minified name (te) instead of a one-character name (J / Y). All other emitted edits sum to zero bytes. A complete edit list reconstructs the candidate chunks byte-for-byte.

For precision, the raw diff also contains changed chunk hashes and a historical diagnostic ID changing from 459 to 460, with the same decoded message and zero byte delta. The +3 B growth itself is entirely identifier renaming. No minifier manipulation or unrelated byte compensation was used.

Primary questions

Does Babylon Lite consider this minifier-only byte movement an unrelated-scene bundle regression that must still be eliminated, or is the architectural requirement satisfied when no feature semantics/code remain in the unused bundle?

Is there a preferred existing PBR opt-in seam pattern we should use instead?

Lifecycle guard

There is one API-lifecycle question still open.

The enabler can reject scenes that already contain meshes/groups or are built, but during the first registration of an otherwise empty scene there is currently no existing state we found that reliably distinguishes "fresh" from "registration already in progress" before _built is set.

Is there an existing scene lifecycle state/seam that optional pre-build enablers should use for this guard, or should this simply be documented as a pre-registration contract?

Scope

• No bundle ceilings/baselines were changed.
• No fork is being proposed.
• No private API is required by callers.
• The prototype remains local and has not been pushed or submitted as a PR.
• We are asking for guidance before polishing/submitting the patch; this is an unfinished prototype.

[deltakosh]

The bundle size changes are totally ok, feel free to send the PR, I'll be happy to review it

[Popov72]

Thanks for the detailed investigation. The small bundle-size movement described here is not a concern by itself.

Regarding the API shape, I don't think a scene-level enablePbrLinearOutput(scene) enabler with a WeakSet, resolver, pre-registration restriction, and permanent scene policy is the right abstraction.

The frame graph already owns render-target routing and post-process ordering. Conceptually, the application should be able to:

1. Render the scene directly into an application-owned rgba16float target.
2. Insert its own post-process tasks after that render task.
3. Perform the final tone mapping/gamma/presentation pass into the swapchain.

A separate copy is only necessary if the application needs to preserve an intermediate result.

There is one important complication in the current implementation: PBR exposure, tone mapping, gamma, clamp, and contrast are currently emitted inside the material fragment shader. Consequently, copying the scene target after rendering would copy already processed display output rather than linear HDR. The missing capability is therefore not primarily a copy operation; it is a way for a render task to request linear material output.

The transmission implementation already performs nearly this exact split: it retargets the render task to a linear rgba16float offscreen target, suppresses material image processing for that render, and appends an image-processing task for final presentation. I would prefer extracting that linear-output behavior into a generic render-task/frame-graph option instead of introducing another PBR-specific scene enabler.

For example, the eventual shape could be equivalent to:

createRenderTask({
    name: "scene-linear",
    rt: hdrTarget,
    imageProcessing: false,
});

The exact property name is open to discussion, but the important point is that output policy belongs to the render task/pass that owns the target. Internally, PBR still needs a shader variant that omits image processing, but callers should not have to configure that through a separate scene-lifecycle API.

So the use case is valid, but before submitting the current implementation, please consider refactoring the existing transmission linear-output path into a reusable render-task capability and building the application-owned post-processing chain on top of the existing frame-graph tasks.