MagicBeanDev/Hookshot

Archived

Watch

Fork 0

[AMD RX 9070 XT] Bushes and grass disappear up close (mesh stage), visible from far away #696

Closed

opened 2026-11-08 17:27:00 +00:00 by Shantill-y · 4 comments

Shantill-y commented

2026-11-08 17:27:00 +00:00

(Migrated from github.com)

Builder version

v2.0.2

How you built

Hookshot Builder app (Windows)

Game files given to it

A .nup

The error

Hi! I'm playing on an AMD card and most of the foliage now works on v2.0.2, but bushes and grass still vanish when you get close. Sharing what I found in case it helps.

**Setup**
- Hookshot v2.0.2 (source 998ef8f9), Windows
- GPU: AMD Radeon RX 9070 XT, Vulkan 1.4, driver 0x8001a0 (the PC also has an AMD iGPU, device 1)
- Log says: `subgroups: default 64 lanes, 32-64, pinned to 32 on stages 0xf0`

**What happens**
- Bushes and grass render fine at a distance.
- When Link walks up to them, they disappear.
- If I hit a bush, it shows up for a split second while it breaks and the leaf particles appear, so the object is there; only the normal close-range draw seems to fail.
- Since v2.0.2 I'm also seeing bright green sticks at the base of the grass and on some branches. It might have been there already in v2.0.1, I'm not 100% sure.

**What the log shows**
On v2.0.2 every shader translates (`0 failed`), but these 5 mesh programs (stage 7) keep reporting unbound storage buffers:

    storage buffer NOT bound (reads zeros): program d905f52b7517c681 stage 7 c5+0x60
    storage buffer NOT bound (reads zeros): program 739acd678ae08655 stage 7 c5+0x60
    storage buffer NOT bound (reads zeros): program 6b4dea601798c255 stage 7 c5+0x60
    storage buffer NOT bound (reads zeros): program 68642bb810ee3e7c stage 7 c5+0x60
    storage buffer NOT bound (reads zeros): program 51183fe750d5d0c8 stage 7 c5+0x1d0

The "size" values it prints look like floats (0x3f800000, 0x40800000, 0x40555555...), so maybe c5+0x60 is being read as a buffer address when it's actually constants? Just a guess.

**Env vars I tried**
- `RX_VK_NO_A2C=1`: fixes bushes from far away. Up close they still vanish.
- `EDEN_NX2_UNDEF_ZERO=1`: more stable overall, Link flickers a bit less.
- `RX_VK_NAN_GUARD=1`: stops the Link flicker, but distant bushes disappear too.
- `RX_VK_SSBO_WIDE=1`: grass turns very dark.
- `RX_VK_SSBO_STRETCH=1`: no dark grass, still disappears up close.
- `RX_VK_PTR_SPLIT_FALLBACK=1`: no visible change.
- `RX_VK_NO_SUBGROUP_PIN=1`: worse, distant bushes gone and grass flickers.
- `RX_VK_NO_F16=1`: pink/yellow noise all over the screen.
- `RX_VK_NO_MESH=1`: no noise, but no grass at all.

I'm currently using `RX_VK_NO_A2C=1` + `EDEN_NX2_UNDEF_ZERO=1` as my daily setup.

Log and screenshots attached. Happy to test builds or other env vars if you need it. Thanks for the project!

Visual Studio or Build Tools version, and Windows SDK version

No response

Operating system and free space on the output drive

Windows 11 PRO, 800 GB Free

Before you send it

I'm on the newest release, or it still fails on it.
I searched the open issues for this error.
I'm not attaching game files or anything built from them.

### Builder version v2.0.2 ### How you built Hookshot Builder app (Windows) ### Game files given to it A .nup ### The error ```text Hi! I'm playing on an AMD card and most of the foliage now works on v2.0.2, but bushes and grass still vanish when you get close. Sharing what I found in case it helps. **Setup** - Hookshot v2.0.2 (source 998ef8f9), Windows - GPU: AMD Radeon RX 9070 XT, Vulkan 1.4, driver 0x8001a0 (the PC also has an AMD iGPU, device 1) - Log says: `subgroups: default 64 lanes, 32-64, pinned to 32 on stages 0xf0` **What happens** - Bushes and grass render fine at a distance. - When Link walks up to them, they disappear. - If I hit a bush, it shows up for a split second while it breaks and the leaf particles appear, so the object is there; only the normal close-range draw seems to fail. - Since v2.0.2 I'm also seeing bright green sticks at the base of the grass and on some branches. It might have been there already in v2.0.1, I'm not 100% sure. **What the log shows** On v2.0.2 every shader translates (`0 failed`), but these 5 mesh programs (stage 7) keep reporting unbound storage buffers: storage buffer NOT bound (reads zeros): program d905f52b7517c681 stage 7 c5+0x60 storage buffer NOT bound (reads zeros): program 739acd678ae08655 stage 7 c5+0x60 storage buffer NOT bound (reads zeros): program 6b4dea601798c255 stage 7 c5+0x60 storage buffer NOT bound (reads zeros): program 68642bb810ee3e7c stage 7 c5+0x60 storage buffer NOT bound (reads zeros): program 51183fe750d5d0c8 stage 7 c5+0x1d0 The "size" values it prints look like floats (0x3f800000, 0x40800000, 0x40555555...), so maybe c5+0x60 is being read as a buffer address when it's actually constants? Just a guess. **Env vars I tried** - `RX_VK_NO_A2C=1`: fixes bushes from far away. Up close they still vanish. - `EDEN_NX2_UNDEF_ZERO=1`: more stable overall, Link flickers a bit less. - `RX_VK_NAN_GUARD=1`: stops the Link flicker, but distant bushes disappear too. - `RX_VK_SSBO_WIDE=1`: grass turns very dark. - `RX_VK_SSBO_STRETCH=1`: no dark grass, still disappears up close. - `RX_VK_PTR_SPLIT_FALLBACK=1`: no visible change. - `RX_VK_NO_SUBGROUP_PIN=1`: worse, distant bushes gone and grass flickers. - `RX_VK_NO_F16=1`: pink/yellow noise all over the screen. - `RX_VK_NO_MESH=1`: no noise, but no grass at all. I'm currently using `RX_VK_NO_A2C=1` + `EDEN_NX2_UNDEF_ZERO=1` as my daily setup. Log and screenshots attached. Happy to test builds or other env vars if you need it. Thanks for the project! ``` ### Visual Studio or Build Tools version, and Windows SDK version _No response_ ### Operating system and free space on the output drive Windows 11 PRO, 800 GB Free ### Before you send it - [x] I'm on the newest release, or it still fails on it. - [x] I searched the open issues for this error. - [x] I'm not attaching game files or anything built from them.

👍 1

ENPFakeDeveloper commented

2026-11-08 17:46:27 +00:00

(Migrated from github.com)

Same symptom on AMD Radeon RX 6650 XT (Vulkan 1.4, driver 0x800161), Windows 11, hookshot v2.0.2 (source 998ef8f9), 1600x900. Bushes/grass are visible from far away but disappear as I get close; only branches remain, the leaves vanish.

My logs (3 sessions) show the same storage buffer NOT bound (reads zeros) for stage 7 at c5+0x60, c5+0x1d0 and c5+0x228, e.g. programs 68642bb810ee3e7c, 6b4dea601798c255, 51183fe750d5d0c8, 4f0c0b40ab3a32cd, 739acd678ae08655, d905f52b7517c681. The "addresses" look like floats (0x3f822b64, 0x44ca2618), so this matches the guess that float constants are being read as buffer addresses.

Other things in my logs: this GPU does not sample ASTC (decoded on upload), and a device-lost-fix build reports ~31 "does not lower" shader failures. I'll add a video of the issue below. Happy to test builds or env vars.

Analysis created with Claude; it may contain errors

https://youtu.be/YXcEmNwKbms

Same symptom on **AMD Radeon RX 6650 XT** (Vulkan 1.4, driver 0x800161), Windows 11, hookshot v2.0.2 (source 998ef8f9), 1600x900. Bushes/grass are visible from far away but disappear as I get close; only branches remain, the leaves vanish. My logs (3 sessions) show the same `storage buffer NOT bound (reads zeros)` for stage 7 at `c5+0x60`, `c5+0x1d0` and `c5+0x228`, e.g. programs 68642bb810ee3e7c, 6b4dea601798c255, 51183fe750d5d0c8, 4f0c0b40ab3a32cd, 739acd678ae08655, d905f52b7517c681. The "addresses" look like floats (0x3f822b64, 0x44ca2618), so this matches the guess that float constants are being read as buffer addresses. Other things in my logs: this GPU does not sample ASTC (decoded on upload), and a `device-lost-fix` build reports ~31 "does not lower" shader failures. I'll add a video of the issue below. Happy to test builds or env vars. Analysis created with Claude; it may contain errors https://youtu.be/YXcEmNwKbms

ENPFakeDeveloper commented

2026-11-08 19:36:08 +00:00

(Migrated from github.com)

Possible lead for the "NOT bound (reads zeros)" foliage bug. zortos293/Lichii#410 (merged 2026-11-07, "bind loaded pointers that compete with a paired cbuf pointer (OoT near foliage)") changes src/shader_recompiler/ir_opt/global_memory_to_storage_buffer_pass.cpp. Per its description, CollectStorageBuffers paired a global access with a cbuf pointer too early; when the address is really a pointer loaded through that cbuf, the loaded path was read out of bounds as zeros, so near-leaf passes got all-zero records and trees lost their leaves within ~20 m. That matches the symptom here (far foliage fine, near leaves gone) and the file mentioned in #667.

It is also listed in Frizti/Fritchii#8. I have not applied it to Hookshot or checked that Hookshot's pass has the same structure, so this is only a lead, not a confirmed cause.

Analysis created with Claude; it may contain errors.

Possible lead for the "NOT bound (reads zeros)" foliage bug. zortos293/Lichii#410 (merged 2026-11-07, "bind loaded pointers that compete with a paired cbuf pointer (OoT near foliage)") changes `src/shader_recompiler/ir_opt/global_memory_to_storage_buffer_pass.cpp`. Per its description, `CollectStorageBuffers` paired a global access with a cbuf pointer too early; when the address is really a pointer loaded through that cbuf, the loaded path was read out of bounds as zeros, so near-leaf passes got all-zero records and trees lost their leaves within ~20 m. That matches the symptom here (far foliage fine, near leaves gone) and the file mentioned in #667. It is also listed in Frizti/Fritchii#8. I have not applied it to Hookshot or checked that Hookshot's pass has the same structure, so this is only a lead, not a confirmed cause. _Analysis created with Claude; it may contain errors._

Crono141 commented

2026-11-08 20:30:13 +00:00

(Migrated from github.com)

Same glowing stems here on Linux/RADV (RX 9070 XT, Mesa 26.2.4, Bazzite; current main plus #448/#487/#593/#423), so it isn't OS- or driver-specific. I spent a while narrowing it down; posting what I found in case it saves someone time.

The five storage buffer NOT bound programs are not the cause. Those come from the unbiased storage-buffer search walking down an index (through a select's condition) to a flags word in c5 (*c0[0x780] + index*16, the pointer loaded from memory). I changed that search to follow only additions; the NOT-bound lines went away, the glow did not.

What draws the stems (found by hiding programs live with RX_VK_SKIP_FILE):

5ba7cf23d6857836 (mesh) is a depth pre-pass: colour write mask 0, depth write on; its fragment is an alpha test that writes white.
89ca750f9852b7ca (mesh) is the colour pass over the same indirect draws, depth test EQUAL. Hiding it alone turns the stems plain white.

What the glow is: the stem's own colour, far too bright, with bloom. It follows the stems' world orientation (not the camera) and changes as the wind moves them; a purple flower nearby held glowing/normal for about a second at a time. With RX_VK_MIRROR=1 the wrong colours change (green and orange/red patches), so it depends on how memory reaches the GPU.

Where 89ca750f's fragment gets its light: per-object light lists — indices at c0[0x510] (offset from c3[0x950]), 96-byte records at c0[0x520] (+ index*96 + 32, four 128-bit reads), header through c3[0x948]. c0[0x520] is the light buffer from Fritchii's fixes in 3858629 (water textures from light records' handles; light probes ~130 MB past the pointer), so I suspect one of those two classes: a texture handle taken from a light record, or light/probe data read past its binding.

Ruled out (one at a time): undefined mesh output components, depth-EQUAL precision (EQUAL → LEQUAL with bias), NaN (applied the NaN guard to mesh fragments too), all of 89ca750f's memory accesses left to the run-time search, RX_VK_PARALLEL off, RX_VK_KEEP_FINALIZED_MB=0 (#593), RX_VK_NO_MESH_FIRSTS=1, skipped draws.

Happy to test on RADV.

Same glowing stems here on **Linux/RADV** (RX 9070 XT, Mesa 26.2.4, Bazzite; current main plus #448/#487/#593/#423), so it isn't OS- or driver-specific. I spent a while narrowing it down; posting what I found in case it saves someone time. **The five `storage buffer NOT bound` programs are not the cause.** Those come from the unbiased storage-buffer search walking down an index (through a select's condition) to a flags word in c5 (`*c0[0x780] + index*16`, the pointer loaded from memory). I changed that search to follow only additions; the NOT-bound lines went away, the glow did not. **What draws the stems** (found by hiding programs live with `RX_VK_SKIP_FILE`): - `5ba7cf23d6857836` (mesh) is a **depth pre-pass**: colour write mask 0, depth write on; its fragment is an alpha test that writes white. - `89ca750f9852b7ca` (mesh) is the **colour pass** over the same indirect draws, depth test EQUAL. Hiding it alone turns the stems plain white. **What the glow is:** the stem's own colour, far too bright, with bloom. It follows the stems' **world orientation** (not the camera) and changes as the wind moves them; a purple flower nearby held glowing/normal for about a second at a time. With `RX_VK_MIRROR=1` the wrong colours change (green and orange/red patches), so it depends on how memory reaches the GPU. **Where `89ca750f`'s fragment gets its light:** per-object light lists — indices at `c0[0x510]` (offset from `c3[0x950]`), 96-byte records at `c0[0x520]` (`+ index*96 + 32`, four 128-bit reads), header through `c3[0x948]`. `c0[0x520]` is the light buffer from Fritchii's fixes in 3858629 (water textures from light records' handles; light probes ~130 MB past the pointer), so I suspect one of those two classes: a texture handle taken from a light record, or light/probe data read past its binding. **Ruled out** (one at a time): undefined mesh output components, depth-EQUAL precision (EQUAL → LEQUAL with bias), NaN (applied the NaN guard to mesh fragments too), all of `89ca750f`'s memory accesses left to the run-time search, `RX_VK_PARALLEL` off, `RX_VK_KEEP_FINALIZED_MB=0` (#593), `RX_VK_NO_MESH_FIRSTS=1`, skipped draws. Happy to test on RADV.

👍 1

NotRexed commented

2026-11-09 05:53:43 +00:00

(Migrated from github.com)

Tracked in #994, follow there. That issue collects every report of floating trees and missing or vanishing vegetation, and this one is linked from it with its GPU, version and log details. It is a known issue in v2.0.6 and not fixed yet. The bright stems are fixed in v2.0.6 (PR #759); the plants vanishing up close are what the tracker follows. If it still happens on v2.0.6 (https://github.com/NotRexed/Hookshot/releases/tag/v2.0.6; Update next to Play in the launcher), please add a comment there with your hookshot_log.txt.

Commenting is not possible because the repository is archived.