[Tracking] Lighting: overexposure, over-bright bloom, crushed or black shadows, black faces #1004
Labels
No labels
accessibility
autorelease: pending
autorelease: tagged
bug
dependencies
documentation
duplicate
enhancement
github_actions
good first issue
help wanted
invalid
question
testing wanted
wontfix
No milestone
No assignees
2 participants
No due date set.
Dependencies
No dependencies set
Reference
MagicBeanDev/Hookshot#1004
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This issue collects every open report of lighting problems (overexposure, bloom, crushed shadows, black faces), so there is one place to follow it. The individual reports were closed pointing here; their logs, screenshots and discussion stay in each linked issue.
Summary
Problems reported:
The bright red/green plant stems are a different bug, fixed in v2.0.6 (PR #759).
Affected GPUs and versions
Evidence from the logs
RX_VK_TAAU_KEYS=- RX_VK_MMA_SOFTWARE=1. v2.0.5 fixed dark or black faces (character lighting), so older reports here need a retest.Workarounds
RX_VK_TAAU_KEYS=- RX_VK_MMA_SOFTWARE=1(#36).Reports merged here (17 issues, about 28 people)
Adding a report
Please update to v2.0.6 first (https://github.com/NotRexed/Hookshot/releases/tag/v2.0.6; Update next to Play in the launcher). Please add: screenshot, place, GPU, version, and
hookshot_log.txt.All tracking issues
The overexposed lighting was fixed in 2.0.5, but returned in 2.0.6
RX 7800 XT / Windows 11, current main (
0828863) + #1130 head (6f76660): Ganon's Castle area (adult Link) is washed out by a blocky white glow, plus large blurred coloured discs.hookshot_env.txt(empty). Built from source: main plus #1130, no other patches. The two mods "Dump fix" and "PS5 UI" are active.not translated: a network left out on this cardand rejected computes (the image networks are left out on RDNA3, as in #1006).RX_VK_TAAU_KEYS=-orRX_VK_ASTC_RGBA8=1. The screenshot is from a play session, not a scripted route, and it is one frame, so I cannot say whether it is constant or pulses (#1005).Update: after leaving the area and coming back in, the glitch was gone completely, including the sky. So on this build it is not constant: it appeared on the first entry and cleared on re-entry (no restart in between). I could not tell the cause from the log. I will add the screenshot in a follow-up, and watch whether it comes back on later entries.
Same area, but a different presentation on Linux, so adding this here in case it is the same root cause.
Hookshot v2.0.11, built with the Linux AppImage from a .nup
Game: [0400486024DEC000][v131072].nup, 23.3 GiB
OS: SteamOS 3.9.5, KDE Plasma 6.7.3, kernel 7.2.7-valve2-2-neptune, Wayland
Hardware: ASUS ROG Flow Z13, Ryzen AI Max+ 395, Radeon 8060S integrated, 32GB RAM, 16GB RAM / 16GB VRAM split
FPS: 47 to 49, no frame generation
In Kokiri Forest at the start, the whole scene is blown out white, not just the light sources. Trees, ground, and water lose almost all detail, while Link and the HUD still have color. Opening video and title screen look normal.
I do not see the blocky pixelated bloom or black textures from the original report, just constant whole scene overexposure. Happy to file this separately if you think it is distinct, or attach hookshot_log.txt here.
Update: tried RX_VK_TAAU_KEYS=- and RX_VK_MMA_SOFTWARE=1 in hookshot_env.txt on v2.0.11, Linux, Radeon 8060S. No change, Kokiri Forest is still blown out white.
Two findings on v2.0.11 (Windows 11, RTX 5080, driver 621.14), for the haze reports here (#914, #1311). Both also happen on the stock v2.0.11 build.
1. Deku Tree white haze: OoT draws into a BC4 array that Hookshot does not let it draw into.
Every run logs, at the Deku Tree, for each of the array's 16 layers:
With the usage added to that log line it reads
wanted usage 0x10, the image's 0xf: the game asks for the BC4 array's block views (R16G16B16A16_UINT, 8 bytes = one BC4 block) as colour attachments (its GPU BC4 encoder renders the blocks), and BC images are made withoutCOLOR_ATTACHMENT, somake_viewrefuses before trying. The array keeps whatever the memory held, which would fit the haze coming and going between runs (#914: "for a while").Test change in
vk_texture.cpp, the BC branch of the image's usage: addVK_IMAGE_USAGE_COLOR_ATTACHMENT_BITwhenvkGetPhysicalDeviceImageFormatPropertiesaccepts it with the existingMUTABLE | BLOCK_TEXEL_VIEW_COMPATIBLE | EXTENDED_USAGEflags, and strip it in the existing fallback that stripsSTORAGE. On NVIDIA the views are then all made (0 "not made" lines). I have not been able to confirm the haze is gone, since it does not show on every run.2. Hyrule Field: the distant haze pulses (also with the game's own upscaler, and on the stock build).
On a 60 fps capture, standing still near the Kokiri exit looking at the castle, the distant plain's average brightness swings about ±7 % with a period of ~24 frames, while the foreground and the sky stay steady.
With
RX_VK_PROBE=2(plus a local F8 trigger keeping 64 frames, and 3D textures sampled at 3/4 depth), the centre pixel through the frame:bbbc575ff0e57176(0.41–0.44);1a7482c0ec9991ea(full-screen, onto the scene) adds a pale veil (0.43 → 0.59) and swings 0.52 ↔ 0.64 over ~24 frames. Skipping it removes the pulse but breaks the water and distant trees, and the frame rate drops, so it is the composite, not the cause;RX_VK_LOG_IMG): four 128×72×96 3D volumes (B10G11R11, and R16F), a 256×256 RGBA16F table, a 4×4 RGBA32F, full- and half-res depth, two 1280×720 RGBA16F, the scene;1e2fcee33a0c7209and27ee9883e2a20323on alternate frames (two B10G11R11 + one R16F each; the slice at 3/4 depth reads ~0 on the other program's frames, so probably slice-interleaved). On its own frames the scattering value at the centre swings 0.16–0.34 and the R16F one 18–57 from one update to the next while nothing moves. That is where the pulse comes from.Not it:
RX_VK_WB_DIFF=0,RX_VK_DEAD_TARGETS=0,RX_VK_NO_EVICT=1,RX_VK_NO_DESC_REUSE=1, Game speed Per frame / Real time, Frame pacing off, frame generation off, DLSS or the game's upscaler, our local settings (none of them changes it).So the volumetric fog's two update programs give values that jump between updates; perhaps something they read per frame (a jitter / noise index, the previous volume, or a time value) is not what the game expects.
Correction to point 1 above: with that usage change (BC images made with
COLOR_ATTACHMENT), the cutscene with Zelda in the castle courtyard drops to ~3–4 fps (GPU ~7 ms a frame, but each submit waits ~20 ms:capture: a submit 20.66 ms (lock 19.72, …),writes collected 20.28). Back to normal without it. So it is not usable as is; drawing the BC4 blocks probably needs another route (render into an uncompressedR16G16B16A16_UINTimage and copy the blocks into the BC4 array).In the v2.0.12 branch: shadow edges are filtered now (depth-compare samplers use linear filtering), which smooths the blocky, hard shadow edges reported here. Closing those reports at release.
Fire Temple: very dark rooms on AMD, fixed by the
RX_VK_TAAU_KEYS=-+RX_VK_MMA_SOFTWARE=1workaround**hookshot v2.0.11 (source d6369f1e)Without the workaround: most of the room is close to black. Only Navi's glow and a few edges are visible; Link and the walls around him are almost unlit. The lava room is lit by the lava, but everything away from it (Link, the platforms, the walls on the left) is crushed to black.
With the workaround (
RX_VK_TAAU_KEYS=-andRX_VK_MMA_SOFTWARE=1, nothing else changed): the same rooms are lit normally, and Link, the Goron and the walls are all readable. Performance is about the same, 45-55 FPS either way.One thing I noticed with the workaround: in the lava room there's some visible colour banding on the ceiling and walls (flat steps instead of smooth gradients). Not a big problem, but it might be related.
hookshot_v2011_lighttest_20261109_233707.txt
Outside Zora Town: Water Fall issues on AMD,
Version: v2.0.11
GPU: AMD Radeon RX 9060 XT
CPU / RAM: Ryzen 9 5950X, 32 GB
OS: Windows 11 Home
hookshot_log.txt
https://github.com/user-attachments/assets/4f550c45-2d12-43c9-89dd-bebb39cc07f3
Still happening on v2.0.11.
System: Ryzen 7 5700X3D · RTX 5070 Ti (NVIDIA driver 32.0.16.2114 / 621.14) · 32 GB RAM · Windows 11 Pro build 26300 · Vulkan. 100-180 FPS, performance fine.
Version: v2.0.11 (some screenshots taken on v2.0.10; resumed the same save in the same area on v2.0.11 hours later and the bugs are unchanged).
Progress: ~2+ hours in, young Link, Spanish language. Now on Death Mountain Trail.
Death Mountain Trail: big areas of rock/terrain render pitch black with hard edges, like broken shadow maps or missing lighting. Link's face and body also go very dark in some spots.
For AMD, #1507 fixes the dark lighting and glowing bloom I saw on an RX 5500M: 64-lane graphics warps, and Lichii #273's fragment shuffle fallback. It still needs a tester on RDNA2 or newer.
A clarification for the AMD workaround reported above (
RX_VK_TAAU_KEYS=-plusRX_VK_MMA_SOFTWARE=1), from reading the v2.0.12 code and a RX 7800 XT log; I have not tested the dark rooms myself (no Fire Temple on this save).matrix multiplies in software (the cooperative matrices lack 16x8x16 f16), the TAAU network is replaced by the stand-in by default:taau_key(vk_draw.cpp~6254) usesfd029a317a9a4b94whenmma_softwareis on, and-otherwise.RX_VK_MMA_SOFTWARE=1(vk_coopmat.cpp~581-586) only forces that same software path, so on such a card it should change nothing. The part that matters isRX_VK_TAAU_KEYS=-, which makes the real network run in software; on AMD it costs GPU time (issue #52: most of a frame on a RX 9070 XT). On the RX 7800 XT I measured about +1.3 ms of 10.6 on an older build.-withRX_VK_MMA_SOFTWARE=1alone in the same room, it would show which switch does the work.Update: Fire Temple dark rooms are fixed on v2.0.13 with no workaround (RX 6700 XT)
Retested the same two rooms from my earlier comment (the caged Goron room and the big lava room with the bridges) on v2.0.13, with no
RX_VK_lighting settings: noRX_VK_TAAU_KEYS, noRX_VK_MMA_SOFTWARE.hookshot v2.0.13 (source 54e42459)Result: both rooms are lit normally now. Link, the walls, the doorway and the chest are all readable, where on v2.0.11 the same rooms were close to black without the workaround. About 57 FPS, GPU time about 7.8 ms a frame.
From the log, in case it helps: the card still uses software matrices by default (
matrix multiplies in software (the cooperative matrices lack 16x8x16 f16)), and on v2.0.13 a second network,9dc98871eb7fc101, runs alongsidefd029a317a9a4b94. On v2.0.11 onlyfd029a317a9a4b94appeared.Correction to my earlier comment: the colour banding I mentioned (flat steps instead of smooth gradients on the lava room's ceiling and walls) is still there on v2.0.13 without the workaround, so it isn't caused by the workaround.
@lucasmazzoni45-del: since the rooms already look right with no settings on v2.0.13, I haven't done that test. I can still run
RX_VK_TAAU_KEYS=-alone andRX_VK_MMA_SOFTWARE=1alone in the same rooms if it would still be useful.hookshot_v2013_20261110_131010.txt
Linux / RADV, RDNA2, v2.0.13: interiors crushed to near-black, with only a small lit pool around Link and Navi (screenshot attached)
Adding a data point to this tracker. This is the "crushed / black shadows" family, but on Linux with RADV, which I do not see among the AMD dark-room reports here (the ones I can compare with are on AMD's Windows driver).
What the screenshot shows. An interior with a wooden floor and a rug. A small area around Link's feet and around Navi's glow is lit with normal warm colour; everything more than a short distance away (crates, walls, furniture) is flat grey-blue / near-black, with almost no colour and no visible light falloff. The geometry is all present — this is not a missing-object report (#1002) — it simply receives no ambient or fill light. The presentation looks like the "before" images in @Leontfk's Fire Temple comment in this thread ("most of the room is close to black. Only Navi's glow and a few edges are visible; Link and the walls around him are almost unlit"), though my room is less completely black than those.
Scope (important): this is not a whole-pipeline lighting failure on my card. In a second screenshot taken minutes later outdoors at the ranch in daylight (
screenshot-7-ranch-surface.jpg, which I am reporting in #1002 instead), the sky, grass, the horse's shading, its cast shadow and the house are all normally lit and exposed. So the crushed-dark presentation seems specific to certain interiors. That outdoor screenshot has a different problem — flat, near-untextured surfaces (the white stone arch, the house walls) — which belongs to #1002, not here. I mention it so this report is not read as "all lighting is broken on RADV".Where / how often: I did not write down the in-game room name for this screenshot, so I cannot name it yet; I can supply it on the next run. I have not A/B'd the same room across restarts, so I cannot say whether it is deterministic.
v2.0.13 (source cfc565a2), Linux native build0400486024DEC000v131072,25,622,267,860bytes (23.86 GiB); officialnx2/nup.py --verify:verified 372587 records, 161114 unique extents: 0 badFull system environment
7.2.14-arch1-1, glibc 2.4426.04-1(Wayland), plasmalogin greeter; SDL33.4.18-1, Wayland1.26.0-11002:73ff, subsystem148c:2429, VBIOS113-001-X01, 10224 MiB Hynix VRAM (sysfsmem_info_vram_total=10720641024bytes)1:26.2.6-1(mesa,vulkan-radeon,lib32-mesa), Vulkan loader1.4.363.0-1,linux-firmware 20261019-1; the only ICD isradeon_icd.json(no AMDVLK)AMD Radeon RX 6750 GRE 10GB (RADV NAVI22), Vulkan 1.4,driver 0x6802006=VK_MAKE_VERSION(26,2,6)VkLayer_LS_frame_generation.json(lsfg-vk-bin 1.0.0-4), MangoHud0.8.4-1, gamescope WSI3.17.0-1, MESA anti-lag, MESA device_selectlspciand the kernel misidentify this card as "Navi 23 / Radeon RX 6600" because AMD reused the0x73ffdevice ID for the China-only RX 6750 GRE 10GB andpci.idslacks the148c:2429subsystem; RADV reports NAVI22 correctly.hdr=0in the options and the log saysvi: QueryDisplayHdrStatus -> SDR, so this is not the HDR colour-conversion problem of #1613.Settings in effect (as text, per the contributing rules — the
.iniand env files themselves are not attached):No lighting-related
RX_VK_line is set: in particular noRX_VK_TAAU_KEYSand noRX_VK_MMA_SOFTWARE. TheNO_MESH/PRECOMPILE=0/NO_FOLLOWlines are a workaround from v2.0.12 for a pipeline-compilation hang on this driver; I have not A/B'd removing them for this lighting symptom. An external frame-generation implicit layer (lsfg-vk-bin) is installed but I have not confirmed whether it is active for the game process. No ReShade or other injectors.Log evidence
The attached
hookshot_log.txtcontains:Why I am posting here rather than in #1002 or a new issue
#1002 collects invisible/missing objects, which is a different symptom (I have a separate report there with six screenshots). This tracker asks for "screenshot, place, GPU, version, and
hookshot_log.txt"; all are provided above or explicitly noted as pending.Two things may make this a useful data point:
hookshot_vk.socontainsRX_VK_TAAU_KEYS,RX_VK_MMA_SOFTWAREandRX_VK_NETWORK_KEEP, but notRX_VK_WARP64orRX_VK_FRAG_SHUFFLE_FALLBACK. The PR title says "on AMD's Windows driver", so my question is: does that 64-lane / fragment-shuffle fix apply to RADV as well? I am on RDNA2 (Navi 22), which the PR says still needs testers for.Hypothesis only, not a diagnosis: for these interiors only, the software-matrix / network path in #52 and #1006 (the cooperative-matrix probe rejects RDNA, so image networks are stood in or left out) may leave the scene without its ambient/fill composite, leaving only the nearby dynamic lights. Daylight exteriors on the same card look normally lit (see the Scope note above), so I am not claiming a global lighting failure. I have not A/B'd this and am not claiming a causal mechanism. I also have not yet tried the workaround in the issue body (
RX_VK_TAAU_KEYS=-+RX_VK_MMA_SOFTWARE=1); both strings exist in my build.Happy to do any of these next, whichever is most useful: attach a log from the exact same run, A/B
RX_VK_TAAU_KEYS=-alone andRX_VK_MMA_SOFTWARE=1alone in the same room, or test a build with #1507 on RADV.Attachments
screenshot-6-dark-room.jpghookshot_log.txthookshot_log.txt: hookshot_log.txtMore reports of this, collected here:
32df58e(v2.0.5-32) with #922, #761 and #850 merg; NVIDIA RTX 5080, driver 621.14; Intel i9-13900K, 32 GB DDR5, Windows 11 Pro)Tracker upkeep note (merged pull requests and code checked against main
51da0464; no new test run was made for it).The tracker can mark #1485's filtered depth comparisons, #1507/#1657's subgroup/shuffle repairs, #1338/#2327's specific BC-target repairs and #2289's preserved early sampler/texture registrations as landed. These are distinct lighting mechanisms, and their code is present on main
51da0464. RADV shuffle behavior and compressed 2D attachments still have the separate #1893 and #2001 work, while the remaining volumetric pulse is not diagnosed by those changes. Please keep the tracker open and ask for a current log from the same run as each remaining picture. The earlier Fire Temple confirmation predates #1507's merge and should not be attributed to it.