Blown-out highlights are the first thing players notice when you flip on Godot 4.7's new HDR output — and if your GLB models carry emissive materials authored for SDR, that's exactly what happens. Godot 4.7 finally lets the engine's internal HDR rendering reach the actual display instead of getting clamped at the last step, and every glowing lamp, neon sign, or magic crystal you imported now renders closer to what the renderer always intended. That's great for atmosphere. It's rough on any emissive value someone eyeballed against the old tonemapper.
What HDR output actually changes in Godot 4.7
Godot has rendered scenes internally in HDR for years — that's how glow, exposure, and overbright elements have always worked. What shipped in 4.7 is the missing last step: piping that internal range out to a screen that can actually show it, instead of squeezing everything back into standard range before it hits your monitor. On a compatible display, the sun in an outdoor scene can now read as genuinely brighter than the clouds around it, with detail preserved in both.
Getting there took more than a display flag. The AgX tonemapper was reworked in 4.6 specifically to behave under HDR, and glow was switched to a Screen blend mode applied before tonemapping so it doesn't crush the extra range you just gained. Godot's design goal was that toggling HDR should only *expand* dynamic range — not brighten the whole image or boost saturation. If a scene suddenly looks blown out or oversaturated after enabling it, something in your material setup isn't HDR-aware, and emissive GLB materials are the most common offender.
GLB emissive materials break first — check these values
glTF's `KHR_materials_emissive_strength` extension lets an artist push emissive brightness past 1.0, and plenty of free and marketplace GLB models lean on strength values of 10, 20, even 50 to fake a glow under SDR's hard clamp. Under the old pipeline, that number got squashed back down regardless, so nobody noticed how extreme it was. Under HDR output, that ceiling is gone — a strength-40 emissive that looked like a tasteful glow in SDR can read as a pure white blob once the display can actually show the range.
Before you enable HDR on a project full of downloaded assets, open each glowing GLB in 3D Studio and check the material panel's emissive strength value rather than guessing from the SDR preview — the number tells you more than the render does. BitSoul's Lo-Fi Street Lamp is a useful test case: its lamp head is authored with a moderate emissive strength specifically so it holds up in both SDR and HDR without a second material pass.
Rough field guide for what to expect once HDR output is on:
| Authored emissive strength | SDR appearance | HDR appearance |
|---|---|---|
| 1–3 | Soft glow | Soft glow, slightly more detail in the bright core |
| 5–10 | Bright glow | Noticeably brighter, edges start to bloom harder |
| 15–30 | "Fake bloom" glow | Often blows out to flat white, loses shape detail |
| 40+ | Usually already clipped | Reads as a solid overbright shape, no gradient left |
If a model in your project sits in that 15+ range purely to compensate for SDR clamping, dial it back once HDR is on rather than leaving both values fighting each other.
Enable HDR output without breaking older Godot projects
HDR output isn't automatic — it has real prerequisites, and skipping one means the toggle does nothing.
| Requirement | What to set |
|---|---|
| Platform | Windows, macOS, iOS, visionOS, or Linux/Wayland (X11 has no HDR support) |
| Renderer | Forward+ or Mobile only — Compatibility (and therefore Web export) can't do it |
| Windows driver | Direct3D 12 — default since projects created on 4.5+, older projects must set `Rendering > Rendering Device > Driver.windows` to `d3d12` |
| Linux driver | Set `Display > Display Server > Driver.linuxbsd` to `wayland` |
| Apple driver | Metal or Vulkan (default) |
Once those boxes are checked, toggle Display > Window > HDR > Request HDR Output in Project Settings — no editor restart needed. For per-window runtime control, or to let players opt out from a graphics menu instead of forcing it:
```gdscript
# Toggle HDR at runtime and let players back out from settings
func set_hdr_enabled(enabled: bool) -> void:
var win := get_window()
if DisplayServer.window_is_hdr_supported(win.get_window_id()):
DisplayServer.window_set_hdr_output_enabled(enabled, win.get_window_id())
else:
enabled = false # fall back silently on unsupported hardware
```
Ship that toggle rather than forcing HDR on — most players don't have a properly calibrated HDR display, and a hard-coded HDR default is how you get bug reports that are really just a Windows color management setting.
Gotchas before you ship
Web exports get none of this — Compatibility renderer only, so keep emissive values sane for SDR regardless of what you tune for desktop. Linux support is Wayland-only, so don't assume every Linux player benefits even on modern hardware running X11. And because Godot's HDR design goal was "expand range, don't brighten the image," a scene that looks globally brighter rather than just more detailed in highlights is a sign some shader or post-process step isn't HDR-aware yet, not a sign HDR is "working." Test the same scene on a plain SDR monitor too — that's still most of your audience, and any model tuned only for HDR will look wrong there.
If you're pulling in more than a handful of GLB props, this is worth doing before your next build rather than after a QA pass flags "everything looks weirdly white" — start with anything already flagged in the glTF import fixes you've already had to chase down, and cross-check against the PCSS shadow changes from the same release, since lighting and emissive interact more under HDR than they did before. If you hit the inverse problem — materials that look correctly bright in HDR but wash out to gray in Unity's SDR-only pipeline — the fix for that is different and covered in the emissive glTF materials rundown. Browse more game-ready GLB props at the BitSoul marketplace if you need fresh test assets with sane emissive values already baked in.
---
*This post is part of the Ultimate Guide to Free 3D Game Assets — BitSoul's complete reference for formats, texturing, rigging, optimization, and engine integration.*