HDR rendering always on (Classic lighting fallback); HDR switch = HDR display output, default on #1326

New issue

Open

opened 2026-10-30 06:05:09 +00:00 by sky_line · 0 comments

sky_line commented

2026-10-30 06:05:09 +00:00

Owner

Request (revised by the owner)

Split the old "HDR and Emissive" switch in two:

Rendering is always HDR with emissive. HDR lighting, exposure, tonemapping, bloom and full-strength emissive PBR are on by default for everyone. The old clamped "vintage" look moves to a separate "Classic lighting" fallback switch, off by default, in an out-of-the-way place (Advanced graphics), for users who prefer the old look. It's a look option, not a performance tier: tonemapping costs well under a millisecond even on low-end cards. It is a candidate for removal in a later cleanup pass, along with the clamped LDR path.
The HDR switch only controls HDR output to the monitor, default on, so HDR displays are picked up automatically: HDR output when the display and compositor support it, SDR otherwise. Off forces SDR output. Rendering is HDR either way.

Settings migration: existing users with RenderDisableVintageMode off (vintage) get the new rendering anyway; their old value doesn't map to Classic lighting. Classic lighting is opt-in only.

Today

The renderer works in linear HDR internally and tonemaps (ACES / AgX / filmic / Reinhard / LUT) down to SDR. The swapchain is always B8G8R8A8_UNORM in SRGB_NONLINEAR (indra/newview/vkgfx/vk_swapchain.cpp, the format choice prefers that pair). HDR10 and scRGB are only recognised for logging (vkColorSpaceName), never requested. So an HDR monitor gets SDR.

Scope

Swapchain: with the setting on and VK_EXT_swapchain_colorspace available, prefer HDR10 (A2B10G10R10_UNORM_PACK32 + HDR10_ST2084), else scRGB (R16G16B16A16_SFLOAT + EXTENDED_SRGB_LINEAR), else fall back to SDR. Set VK_EXT_hdr_metadata from the display's reported luminance. Recreate the swapchain when the setting changes or the window moves to a display with different capabilities.
Tonemap: an HDR output variant of the current tonemapper that maps to the display's peak luminance (PQ encode for HDR10, linear for scRGB) instead of SDR white. Exposure and bloom stay as they are. SDR output must be unchanged byte-for-byte.
UI and HUDs: composite at a fixed paper white (e.g. 203 nits, adjustable later if needed) so menus and text aren't dim or blinding.
Snapshots: the normal snapshot stays SDR (tonemapped as today), and anything uploaded to Second Life (inventory, profile, textures) is always SDR. Two new save-to-disk options in the snapshot floater:
- Also save HDR copy: next to the SDR file, write an HDR image of what the HDR display showed: AVIF (10-bit, PQ / Rec.2020, with CICP and HDR metadata) by default, or PNG with a cICP chunk (PQ / Rec.2020). Only offered when HDR output is active.
- Save EXR: a linear, unclamped scene-referred OpenEXR (half float, before tonemapping, exposure applied or recorded in the header) for editing and grading. Available whenever HDR and Emissive is on, even on SDR displays.
- Both work for normal, high-resolution (tiled) and 360 snapshots, use the same file name with a different extension, and are off by default.
Platforms: Linux needs an HDR-capable compositor (KDE Plasma 6 Wayland). Windows works through the standard swapchain colour spaces. Log the chosen format and colour space at startup (already done via vkColorSpaceName).

Notes

HDR output still needs a tonemap, but a different one: scene luminance (sun, emissives) far exceeds any display's peak, so the HDR curve keeps midtones near-linear around paper white and only rolls highlights off into the display's real peak (from the display's HDR metadata), instead of compressing the whole range into SDR white. Exposure stays as it is.
A peak-brightness or paper-white slider can come later if users need it.
The new renderer under development will get HDR output in its post stage as well.

## Request (revised by the owner) Split the old "HDR and Emissive" switch in two: 1. **Rendering is always HDR with emissive.** HDR lighting, exposure, tonemapping, bloom and full-strength emissive PBR are **on by default** for everyone. The old clamped "vintage" look moves to a separate **"Classic lighting"** fallback switch, off by default, in an out-of-the-way place (Advanced graphics), for users who prefer the old look. It's a look option, not a performance tier: tonemapping costs well under a millisecond even on low-end cards. It is a candidate for removal in a later cleanup pass, along with the clamped LDR path. 2. **The HDR switch only controls HDR output to the monitor**, **default on**, so HDR displays are picked up automatically: HDR output when the display and compositor support it, SDR otherwise. Off forces SDR output. Rendering is HDR either way. Settings migration: existing users with `RenderDisableVintageMode` off (vintage) get the new rendering anyway; their old value doesn't map to Classic lighting. Classic lighting is opt-in only. ## Today The renderer works in linear HDR internally and tonemaps (ACES / AgX / filmic / Reinhard / LUT) down to SDR. The swapchain is always `B8G8R8A8_UNORM` in `SRGB_NONLINEAR` (`indra/newview/vkgfx/vk_swapchain.cpp`, the format choice prefers that pair). HDR10 and scRGB are only recognised for logging (`vkColorSpaceName`), never requested. So an HDR monitor gets SDR. ## Scope 1. **Swapchain:** with the setting on and `VK_EXT_swapchain_colorspace` available, prefer HDR10 (`A2B10G10R10_UNORM_PACK32` + `HDR10_ST2084`), else scRGB (`R16G16B16A16_SFLOAT` + `EXTENDED_SRGB_LINEAR`), else fall back to SDR. Set `VK_EXT_hdr_metadata` from the display's reported luminance. Recreate the swapchain when the setting changes or the window moves to a display with different capabilities. 2. **Tonemap:** an HDR output variant of the current tonemapper that maps to the display's peak luminance (PQ encode for HDR10, linear for scRGB) instead of SDR white. Exposure and bloom stay as they are. SDR output must be unchanged byte-for-byte. 3. **UI and HUDs:** composite at a fixed paper white (e.g. 203 nits, adjustable later if needed) so menus and text aren't dim or blinding. 4. **Snapshots:** the normal snapshot stays SDR (tonemapped as today), and anything uploaded to Second Life (inventory, profile, textures) is always SDR. Two new save-to-disk options in the snapshot floater: - **Also save HDR copy:** next to the SDR file, write an HDR image of what the HDR display showed: AVIF (10-bit, PQ / Rec.2020, with CICP and HDR metadata) by default, or PNG with a `cICP` chunk (PQ / Rec.2020). Only offered when HDR output is active. - **Save EXR:** a linear, unclamped scene-referred OpenEXR (half float, before tonemapping, exposure applied or recorded in the header) for editing and grading. Available whenever HDR and Emissive is on, even on SDR displays. - Both work for normal, high-resolution (tiled) and 360 snapshots, use the same file name with a different extension, and are off by default. 5. **Platforms:** Linux needs an HDR-capable compositor (KDE Plasma 6 Wayland). Windows works through the standard swapchain colour spaces. Log the chosen format and colour space at startup (already done via `vkColorSpaceName`). ## Notes - HDR output still needs a tonemap, but a different one: scene luminance (sun, emissives) far exceeds any display's peak, so the HDR curve keeps midtones near-linear around paper white and only rolls highlights off into the display's real peak (from the display's HDR metadata), instead of compressing the whole range into SDR white. Exposure stays as it is. - A peak-brightness or paper-white slider can come later if users need it. - The new renderer under development will get HDR output in its post stage as well.

sky_line added the

rendering

feature

labels

2026-10-30 06:05:09 +00:00

sky_line added this to the Slipstream project

2026-10-30 06:05:09 +00:00

sky_line changed title from ~~HDR display output (HDR10 / scRGB), controlled by "HDR and Emissive"~~ to HDR rendering always on (Classic lighting fallback); HDR switch = HDR display output, default on

2026-10-30 06:12:40 +00:00

sky_line referenced this issue

2026-10-30 06:24:41 +00:00

Snapshot: avatars only, transparent background #1328