[Xehanort88]

What

An HDR sidecar may give bloom.prefilter = { threshold, knee, clamp }: Unity post-processing's bloom prefilter. The bloom setup clamps the light to clamp per channel, then multiplies it by max(b - threshold, s) / max(b, 0.0001), where b is its brightest channel and s = clamp(b - threshold + knee, 0, 2 knee)^2 / (4 knee + 0.0001). Every pixel at or above the clamp blooms alike.

• It runs where bloom.threshold would (pyramid level round(log2(radiusScale))) and takes its place when both are given.
• The setup shader switches on a uniform. No new program, and effects without the field draw as before.
• clamp is optional (Unity's default 65472).
• The renderer reads the sidecar's prefilter when a caller passes none, so an editor built before this revision previews such effects correctly once it loads this runtime file.
• The editor's sidecar check and HDR preview pass it through.
• Runtime revision 20261029.1; docs/HDR-EFFECT-OVERLAY.md documents the field.

Why

The engine's bloom had only UE 4's luminance threshold, with no clamp. Rogue Trader (Unity) clamps every channel to 0.8 before its threshold (capture 17482, prefilter pass: clamp 0.8, threshold 0.674, knee 0.464). Without the clamp, an effect with light near 10x white bloomed unclamped and flooded its dark core. A fit of the six Gaussians with UE's threshold left 64 % of the game's bloom unexplained; with this prefilter, 1.9 %.

First user: RT Dark Lance HDR (animation 1005 in a test project).

Tests

• editor/tests/hdr-overlay.test.cjs: 25 pass. Four new: the prefilter drives the setup pass, the default clamp, invalid prefilters fail closed, the sidecar fallback.
• hdr-preview-render 9, hdr-preview-twin 5 and effekseer-in-scene 10 pass.
• Checked in battle: the same effect on the old runtime floods to a white bar; on this runtime its core shows.

Also merged into feat/optional-struct-fields (abdc82e), whose editor previews used it.

🤖 Generated with Claude Code