Add: "Extended" range HDR support for supported displays #29656
Conversation
📦 Bundle sizeFull ESM build, minified and gzipped.
🌳 Bundle size after tree-shakingMinimal build including a renderer, camera, empty scene, and dependencies.
|
| renderer.toneMapping = THREE.ACESFilmicToneMapping; | ||
| // renderer.toneMapping = THREE.ACESFilmicToneMapping; |
There was a problem hiding this comment.
Important note – omission of tone mapping is an error in the PlayCanvas implementation, and others I've seen so far. We do still need tone mapping, for SDR as well as HDR, as we are still forming an image for a display. The display is of course brighter than before, and will require adaptations to the tone mappers.
There was a problem hiding this comment.
I'm aware, good point! – added to the DRAFT reasons above.
I did some testing on this as well: Mac displays are supposed to be ~3x brighter in HDR mode (1600 nits instead of 500 for SDR content), from my limited testing the practical range ("how far can I crank emissiveIntensity or environmentIntensity") seems to be ~20-30x brighter though. So there might already be tonemapping on the hardware side as well.
This image also behaves kind of suspicious: https://www.instagram.com/p/C_Byx6jRfuX/
When adjusting screen brightness while it's open, there are noticeable "steps" where the display goes into different modes (for a lack of better term: "tonemapping modes") with somewhat different relative feel.
There was a problem hiding this comment.
Oh, ouch! I was aware that adjusting screen brightness changed the available “HDR” headroom, and that this would be a problem with the current WebGPU HDR implementation, but I hadn't seen a clear demo of the issue like that. Really helpful illustration — thanks.
|
Related PR: |
|
Ah, thanks for referencing that PR, didn't see that – should I close this one then? |
|
Yes, let's focus on #29573. |
Related issue: #26479
Description
After seeing the PlayCanvas demo (https://engine-hlvhm84x4-playcanvas.vercel.app/#/graphics/clustered-lighting) in HDR mode, I thought I'd give it a spin on three.js as well. It looks good! (on supported screens, like all MacBooks)
I'm marking this PR as draft for a number of reasons:
Chrome 129 rolled out support for "extended" range widely, but only for WebGPU at the moment. While there is a WebGL proposal, it doesn't seem to be implemented so far.
Live Demo
Image does not blown out in the live link below on a HDR monitor
https://raw.githack.com/needle-tools/three.js/feature/extended-range-hdr-support/examples/webgpu_loader_gltf_anisotropy.html
This contribution is funded by Needle