Visual regressions after latest update: foliage LOD pop-out, crushed black shadows, untextured green geometry

EjianYT commented

2026-11-08 20:24:32 +00:00

(Migrated from github.com)

Hookshot version

2.0.3

What kind of problem

Graphics (missing, black or wrong-coloured things, lighting, flicker)

What happened

1. Foliage LOD: tree leaves disappear at short distance

Leaves on trees vanish after moving only a small distance away. The LOD transition distance seems far too short, or the lower LODs are missing their leaf geometry.

Trees are not floating anymore. FIXED

2. Shadows are crushed to near-black

Shadowed areas and characters in shade render almost pure black with no ambient/fill light. Characters standing against the sun become silhouettes (screenshot 1), and Link loses nearly all detail in the shade by the bell (screenshot 4).

3. Some textures don't load and render as flat green

Some surfaces render as solid/untextured green instead of their texture:

Tree branch cards show pale flat green/teal strips instead of the bark/branch texture (screenshot 3).
Grass/plant blades render as bright neon green (screenshot 4).

This looks like a missing texture or fallback material.

Where in the game

Everywhere

How often

Every time

Graphics card and driver version

RTX 5080, driver 621.14

CPU, RAM and operating system

AMD Ryzen 7 7700X, 32 GB DDR5-4800, Windows 11 Pro 26H2 (build 26300.9818)

Changes from the defaults

Ultrawide = Monitor's shape (21:9). Only other mod: Xbox UI (romfs, button icons only).

Other software hooked into the game

No, nothing hooked in

hookshot_log.txt

Screenshots or video

Before you send it

I'm on the newest release, or the problem is still there on it.
I searched the open issues for this problem.
I'm not attaching game files, keys, hookshot.exe, the .bin caches or saves.

### Hookshot version 2.0.3 ### What kind of problem Graphics (missing, black or wrong-coloured things, lighting, flicker) ### What happened ### 1. Foliage LOD: tree leaves disappear at short distance Leaves on trees vanish after moving only a small distance away. The LOD transition distance seems far too short, or the lower LODs are missing their leaf geometry. Trees are not floating anymore. FIXED ### 2. Shadows are crushed to near-black Shadowed areas and characters in shade render almost pure black with no ambient/fill light. Characters standing against the sun become silhouettes (screenshot 1), and Link loses nearly all detail in the shade by the bell (screenshot 4). ### 3. Some textures don't load and render as flat green Some surfaces render as solid/untextured green instead of their texture: - Tree branch cards show pale flat green/teal strips instead of the bark/branch texture (screenshot 3). - Grass/plant blades render as bright neon green (screenshot 4). This looks like a missing texture or fallback material. ### Where in the game Everywhere ### How often Every time ### Graphics card and driver version RTX 5080, driver 621.14 ### CPU, RAM and operating system AMD Ryzen 7 7700X, 32 GB DDR5-4800, Windows 11 Pro 26H2 (build 26300.9818) ### Changes from the defaults Ultrawide = Monitor's shape (21:9). Only other mod: Xbox UI (romfs, button icons only). ### Other software hooked into the game No, nothing hooked in ### hookshot_log.txt [hookshot_log.txt](https://github.com/user-attachments/files/34554213/hookshot_log.txt) ### Screenshots or video <img width="3439" height="1439" alt="Image" src="https://github.com/user-attachments/assets/0196eafd-8e25-438c-a38a-673e5200dc00" /> <img width="3439" height="1439" alt="Image" src="https://github.com/user-attachments/assets/4357afaa-b1d2-43e4-b2ab-46e4fbfdc723" /> <img width="3439" height="1439" alt="Image" src="https://github.com/user-attachments/assets/6051d786-7ef2-40ef-8483-b806608686f7" /> <img width="3439" height="1439" alt="Image" src="https://github.com/user-attachments/assets/dac48b52-47a8-4fd5-93d4-932f2dd6cd55" /> ### Before you send it - [x] I'm on the newest release, or the problem is still there on it. - [x] I searched the open issues for this problem. - [x] I'm not attaching game files, keys, hookshot.exe, the .bin caches or saves.

Mastax1234 commented

2026-11-08 20:32:43 +00:00

(Migrated from github.com)

Same, I was wondering what was going on, latest build is bugged

luansaopaulo8-svg commented

2026-11-08 20:34:10 +00:00

(Migrated from github.com)

I feel like each update is making things worse instead of better.

EjianYT commented

2026-11-08 21:28:40 +00:00

(Migrated from github.com)

Update on v2.0.4:

Foliage LOD (leaves vanish at a short distance): still there. Not fixed by Fritchii's port either, since it
happened on v2.0.3 with the port on.
Crushed shadows / Link as a silhouette: fixed on v2.0.4. This matches the dark Link regression that cabb432
turned the port off for.
Side effect: with the port off by default, the floating trees are back on v2.0.4 (see #729).
Flat green textures (branch cards, grass): still there on v2.0.4, so not part of the lighting regression.

Same PC: RTX 5080 (621.14), Ryzen 7 7700X, 32 GB, Windows 11 Pro 26H2, Ultrawide 21:9, Xbox UI mod only.

Update on v2.0.4: 1. Foliage LOD (leaves vanish at a short distance): still there. Not fixed by Fritchii's port either, since it happened on v2.0.3 with the port on. 2. Crushed shadows / Link as a silhouette: fixed on v2.0.4. This matches the dark Link regression that cabb432 turned the port off for. Side effect: with the port off by default, the floating trees are back on v2.0.4 (see #729). 3. Flat green textures (branch cards, grass): still there on v2.0.4, so not part of the lighting regression. Same PC: RTX 5080 (621.14), Ryzen 7 7700X, 32 GB, Windows 11 Pro 26H2, Ultrawide 21:9, Xbox UI mod only.

KrysGG commented

2026-11-08 21:57:10 +00:00

(Migrated from github.com)

A/B of the Fritchii port's switches (RTX 5080, driver 621.14, i9-13900K, 32 GB, Windows 11): its native-pointer rules are what take out the grass and leaves

Data for re-enabling the port (cabb432 keeps it behind EDEN_NX2_GM_LEGACY=0). Tested on a source build of v2.0.3 (45620e8), where the port was the default, with the same save at the same spot in Hyrule Field, side by side with a Switch 2 console at the same time of day. Each run had one line in hookshot_env.txt:

`hookshot_env.txt`	Grass / broad-leaf canopies	Flowers	Lighting	`storage buffer NOT bound (reads zeros)`
(none: port on)	all grass and canopies missing (pines fine)	—	matches the console here	0
`EDEN_NX2_GM_COMPETING=0`	missing, same as above	—	matches the console here	0
`EDEN_NX2_GM_NATIVE=0`	grass and canopies back	lupine spikes white (purple on the console), small flowers as white specks	ok	40
`EDEN_NX2_GM_LEGACY=1` (v2.0.4+ default)	back	white or glowing foliage cards	drops to near black and back every few steps in the field	40

So the pairing alone (NATIVE=0) keeps the foliage, and the native rules fix the flower colours but take out the grass and canopies. That suggests the native rules are the part to narrow, not the pairing.

The 40 zero reads are the same programs in both runs: stage 7 c5+0x60 (68642bb810ee3e7c, 6b4dea601798c255, 739acd678ae08655, d905f52b7517c681), 51183fe750d5d0c8 c5+0x1d0, 4f0c0b40ab3a32cd c5+0x228, and stage 5 c3+0x60 (a54f19e927d8faef, b612216258832b9c).

No device lost in any of these runs. Logs available on request. Screenshots below.

Switch 2 (Left) - Hookshot (Right)

**A/B of the Fritchii port's switches (RTX 5080, driver 621.14, i9-13900K, 32 GB, Windows 11): its native-pointer rules are what take out the grass and leaves** Data for re-enabling the port (cabb432 keeps it behind `EDEN_NX2_GM_LEGACY=0`). Tested on a source build of v2.0.3 (45620e8), where the port was the default, with the same save at the same spot in Hyrule Field, side by side with a Switch 2 console at the same time of day. Each run had one line in `hookshot_env.txt`: | `hookshot_env.txt` | Grass / broad-leaf canopies | Flowers | Lighting | `storage buffer NOT bound (reads zeros)` | |---|---|---|---|---| | (none: port on) | **all grass and canopies missing** (pines fine) | — | matches the console here | 0 | | `EDEN_NX2_GM_COMPETING=0` | missing, same as above | — | matches the console here | 0 | | `EDEN_NX2_GM_NATIVE=0` | **grass and canopies back** | **lupine spikes white** (purple on the console), small flowers as white specks | ok | 40 | | `EDEN_NX2_GM_LEGACY=1` (v2.0.4+ default) | back | white or glowing foliage cards | **drops to near black and back every few steps** in the field | 40 | So the pairing alone (`NATIVE=0`) keeps the foliage, and the native rules fix the flower colours but take out the grass and canopies. That suggests the native rules are the part to narrow, not the pairing. The 40 zero reads are the same programs in both runs: stage 7 `c5+0x60` (68642bb810ee3e7c, 6b4dea601798c255, 739acd678ae08655, d905f52b7517c681), 51183fe750d5d0c8 `c5+0x1d0`, 4f0c0b40ab3a32cd `c5+0x228`, and stage 5 `c3+0x60` (a54f19e927d8faef, b612216258832b9c). No device lost in any of these runs. Logs available on request. Screenshots below. Switch 2 (Left) - Hookshot (Right) <img width="2000" height="590" alt="Image" src="https://github.com/user-attachments/assets/8c4800c4-5c54-4fee-95bf-174ce5980b33" /> <img width="2000" height="592" alt="Image" src="https://github.com/user-attachments/assets/b0f669a5-dcab-4203-8613-9d60845d6029" /> <img width="2000" height="591" alt="Image" src="https://github.com/user-attachments/assets/ef363cc1-280d-43cd-986b-f8611413874f" />

Nitnek commented

2026-11-08 22:29:55 +00:00

(Migrated from github.com)

This adds to @KrysGG's A/B above. It looks at which programs draw the white grass, and what they bind, with the port off.

Some data on the white/neon grass (point 3), on an RTX 3070 8 GB, Windows 11. The build is v2.0.4 (58af2c0) + #761 with the port off (the default), and the place is a save in Hyrule Field near Lon Lon Ranch, where the near grass blades are white.

How the white comes about. In an RX_VK_DUMP frame, the main colour target is first filled with a flat bright green (pass 489438d734e2463a, HDR max ~3.6). Then each mesh pair draws its depth and then its colour, the colour pass testing EQUAL. The white blades are pixels that the depth program covered and the colour program never did, so the fill shows through.

Which pair. RX_VK_DRAW_STATS at that spot, comparing a run with RX_VK_EQ_BIAS=64 (the Intel margin from 629e2af, forced on):

program	role	args	mesh threads	clip in → out	fragments	with `RX_VK_EQ_BIAS=64`
`3bde059fb051af1f`	depth	`@116ba9a000` (91 groups, 2885)	2912	6308 → 6023	342 577
`d4abbcb4c2140609`	colour	same	2912	6308 → 6600	395	12 641 657

Both get the same groups, but the colour program clips a different number of primitives and covers almost nothing. With the margin, it covers 12.6 M fragments of black and cyan shapes in the wrong places. So this is not EQUAL precision: the colour program computes other positions than its depth twin.

What differs. RX_VK_DRAW_STATS_PROGS=3bde059fb051af1f,d4abbcb4c2140609, task stage (s6):

depth 3bde059f: s6 ssbo1 at 0x116ba94000 size 0x4040 (762 of 4112 words non-zero)
colour d4abbcb4: s6 ssbo1 at 0x116ba70000 size 0x4040 (0 of 4112 words non-zero)

These are two entries of the same per-category region that the culling (b612216258832b9c) writes, three entries apart. 0x116ba70000 is also the args of 43ec86f35fd937b9/8a8304edb7bdf4bf, which run 0 groups here. So the colour task seems to take its instance list from another entry of the table than its depth twin does. (The word counts are guest memory as submitted, which may not be what the GPU culling wrote there.) The mesh stages bind different buffers too, the other way round: depth s7 ssbo1 0x116ba3d000 is all zero, colour s7 ssbo3 0x116ba49000 has 1536 words.

This would also fit the size of the white area. It matches the near range (~10 m) that keeps its leaves and grass with EDEN_NX2_GM_LEGACY=0, where the far range is lost instead. The port's pointer rules pick the right entry for these near programs and the wrong one for the far ones, and the legacy tracking does the opposite. I haven't found yet which constant-buffer word each task's ssbo1 comes from. I can dump more at this save if you tell me what would help.

This adds to @KrysGG's A/B above. It looks at which programs draw the white grass, and what they bind, with the port off. Some data on the white/neon grass (point 3), on an RTX 3070 8 GB, Windows 11. The build is v2.0.4 (`58af2c0`) + #761 with the port off (the default), and the place is a save in Hyrule Field near Lon Lon Ranch, where the near grass blades are white. **How the white comes about.** In an `RX_VK_DUMP` frame, the main colour target is first filled with a flat bright green (pass `489438d734e2463a`, HDR max ~3.6). Then each mesh pair draws its depth and then its colour, the colour pass testing EQUAL. The white blades are pixels that the depth program covered and the colour program never did, so the fill shows through. **Which pair.** `RX_VK_DRAW_STATS` at that spot, comparing a run with `RX_VK_EQ_BIAS=64` (the Intel margin from `629e2af`, forced on): | program | role | args | mesh threads | clip in → out | fragments | with `RX_VK_EQ_BIAS=64` | |---|---|---|---|---|---|---| | `3bde059fb051af1f` | depth | `@116ba9a000` (91 groups, 2885) | 2912 | 6308 → 6023 | 342 577 | | | `d4abbcb4c2140609` | colour | same | 2912 | 6308 → **6600** | **395** | **12 641 657** | Both get the same groups, but the colour program clips a different number of primitives and covers almost nothing. With the margin, it covers 12.6 M fragments of black and cyan shapes in the wrong places. So this is not EQUAL precision: the colour program computes other positions than its depth twin. **What differs.** `RX_VK_DRAW_STATS_PROGS=3bde059fb051af1f,d4abbcb4c2140609`, task stage (s6): - depth `3bde059f`: `s6 ssbo1 at 0x116ba94000 size 0x4040` (762 of 4112 words non-zero) - colour `d4abbcb4`: `s6 ssbo1 at 0x116ba70000 size 0x4040` (**0 of 4112 words non-zero**) These are two entries of the same per-category region that the culling (`b612216258832b9c`) writes, three entries apart. `0x116ba70000` is also the args of `43ec86f35fd937b9`/`8a8304edb7bdf4bf`, which run 0 groups here. So the colour task seems to take its instance list from another entry of the table than its depth twin does. (The word counts are guest memory as submitted, which may not be what the GPU culling wrote there.) The mesh stages bind different buffers too, the other way round: depth `s7 ssbo1 0x116ba3d000` is all zero, colour `s7 ssbo3 0x116ba49000` has 1536 words. This would also fit the size of the white area. It matches the near range (~10 m) that keeps its leaves and grass with `EDEN_NX2_GM_LEGACY=0`, where the far range is lost instead. The port's pointer rules pick the right entry for these near programs and the wrong one for the far ones, and the legacy tracking does the opposite. I haven't found yet which constant-buffer word each task's `ssbo1` comes from. I can dump more at this save if you tell me what would help.

KrysGG commented

2026-11-08 23:40:09 +00:00

(Migrated from github.com)

@Nitnek thanks, your depth/colour pair analysis was the key. More data on the same pair from my side (RTX 5080, driver 621.14, v2.0.5 cd9cebb6, port off, Hyrule Field). Near lupines are white and the same lupines are purple from a distance, so it is the near LOD pair. (This is likely the white/glowing flowers tracked in #659.)

What I could rule out, at the same spot:

check	result
task stage buffers (`RX_VK_DRAW_STATS`, only 3bde059fb051af1f and d4abbcb4c2140609)	identical in both: s6 ssbo0..3 = 0x11719725c0, 0x116ba6a000 +0x4040, 0x107f7d6580, 0x112a2e7f00
mesh stage instance data	same buffer: depth s7 `c0+0x770`, colour s7 `c0+0x790`, both 0x116ba9a000, same indirect args
camera data (`RX_VK_IR` of both mesh stages)	both project with the same view-projection, `c3+48..108` of the same ubo (0x112e75e500), and read the same vec3 at +64 of 0x116b921100 (depth as c4, colour as c5)
the colour mesh stage's 144 pointer-chased global loads (pointer at +8 of `c0+0x780`'s buffer)	`RX_VK_MISS_LOG=1`, `RX_VK_MISS_LOG_PROG=d4abbcb4c2140609`: 0 misses
driver rounding	Position outputs decorated `Invariant` (local test): no change, dropped

Fragments at that spot: depth 63 337, colour 4 194 (clip in 3228 for both, clip out 3211 vs 3221).

So with the same inputs the two mesh stages still put the blades in different places, and your RX_VK_EQ_BIAS=64 run says it is the colour program that lands in the wrong places. The colour stage is the one with the pointer chase (122 LoadGlobal128, 22 LoadGlobal32, 10 LoadStorage64); the depth stage reads only c0+0x770's buffer and its record from c5 at +32..56. The next step I see is the colour stage's actual vertex positions on the GPU; I can dump more at this save if you have a tool in mind.

@Nitnek thanks, your depth/colour pair analysis was the key. More data on the same pair from my side (RTX 5080, driver 621.14, v2.0.5 cd9cebb6, port off, Hyrule Field). Near lupines are white and the same lupines are purple from a distance, so it is the near LOD pair. (This is likely the white/glowing flowers tracked in #659.) What I could rule out, at the same spot: | check | result | |---|---| | task stage buffers (`RX_VK_DRAW_STATS`, only 3bde059fb051af1f and d4abbcb4c2140609) | identical in both: s6 ssbo0..3 = 0x11719725c0, 0x116ba6a000 +0x4040, 0x107f7d6580, 0x112a2e7f00 | | mesh stage instance data | same buffer: depth s7 `c0+0x770`, colour s7 `c0+0x790`, both 0x116ba9a000, same indirect args | | camera data (`RX_VK_IR` of both mesh stages) | both project with the same view-projection, `c3+48..108` of the same ubo (0x112e75e500), and read the same vec3 at +64 of 0x116b921100 (depth as c4, colour as c5) | | the colour mesh stage's 144 pointer-chased global loads (pointer at +8 of `c0+0x780`'s buffer) | `RX_VK_MISS_LOG=1`, `RX_VK_MISS_LOG_PROG=d4abbcb4c2140609`: 0 misses | | driver rounding | Position outputs decorated `Invariant` (local test): no change, dropped | Fragments at that spot: depth 63 337, colour 4 194 (clip in 3228 for both, clip out 3211 vs 3221). So with the same inputs the two mesh stages still put the blades in different places, and your `RX_VK_EQ_BIAS=64` run says it is the colour program that lands in the wrong places. The colour stage is the one with the pointer chase (122 LoadGlobal128, 22 LoadGlobal32, 10 LoadStorage64); the depth stage reads only `c0+0x770`'s buffer and its record from c5 at +32..56. The next step I see is the colour stage's actual vertex positions on the GPU; I can dump more at this save if you have a tool in mind. <img width="484" height="316" alt="Image" src="https://github.com/user-attachments/assets/30b31bd1-4451-4d36-9306-cdc4b01b5d7b" /> <img width="662" height="349" alt="Image" src="https://github.com/user-attachments/assets/9981f79a-48a4-4f50-bfa2-7ecf4e72d2ab" /> <img width="2000" height="591" alt="Image" src="https://github.com/user-attachments/assets/f4b327e3-952c-4c5f-9b8c-9298913a65ae" />

MMajor87 commented

2026-11-09 00:44:08 +00:00

(Migrated from github.com)

Data point from Windows, RTX 4080 16 GB, i9-14900KF:

Lighting (point 2): on v2.0.3, EDEN_NX2_GM_LEGACY=1 in hookshot_env.txt (what v2.0.4 made the default) fixed the light / shadow flicker and the light-shaft clipping near geometry on this card. With it, the full per-present GPU wait we had been testing for the #570 flicker was no longer needed.
Flat / wrong plant textures near Link (point 3): still there on official v2.0.5 here; gone with PR #761 merged onto v2.0.5 (details in #761). That fits the analysis above of the colour task taking an empty culling entry: #761 is about compute programs prepared before the game reading their storage buffer table from the wrong place, which leaves some of the foliage culling's draw lists empty.

One thing for anyone A/B-testing these switches: every EDEN_* (and several RX_VK_*) environment line is hashed into the program cache's stamp as the raw NAME=VALUE string (vk_shader.cpp, the _environ loop at the end of disk_stamp). So adding EDEN_NX2_GM_LEGACY=1 explicitly, or removing it, re-prepares every shader once even though 1 is the default since v2.0.4. Hashing the effective value of each switch instead of the raw line would avoid those full re-prepares.

Data point from Windows, RTX 4080 16 GB, i9-14900KF: - **Lighting (point 2):** on v2.0.3, `EDEN_NX2_GM_LEGACY=1` in `hookshot_env.txt` (what v2.0.4 made the default) fixed the light / shadow flicker and the light-shaft clipping near geometry on this card. With it, the full per-present GPU wait we had been testing for the #570 flicker was no longer needed. - **Flat / wrong plant textures near Link (point 3):** still there on official v2.0.5 here; gone with PR #761 merged onto v2.0.5 (details in #761). That fits the analysis above of the colour task taking an empty culling entry: #761 is about compute programs prepared before the game reading their storage buffer table from the wrong place, which leaves some of the foliage culling's draw lists empty. One thing for anyone A/B-testing these switches: every `EDEN_*` (and several `RX_VK_*`) environment line is hashed into the program cache's stamp as the raw `NAME=VALUE` string (`vk_shader.cpp`, the `_environ` loop at the end of `disk_stamp`). So adding `EDEN_NX2_GM_LEGACY=1` explicitly, or removing it, re-prepares every shader once even though 1 is the default since v2.0.4. Hashing the effective value of each switch instead of the raw line would avoid those full re-prepares.

NotRexed commented

2026-11-09 05:56:00 +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. 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.

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. 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`.

Rows
Columns

Visual regressions after latest update: foliage LOD pop-out, crushed black shadows, untextured green geometry #763

Hookshot version

What kind of problem

What happened

1. Foliage LOD: tree leaves disappear at short distance

2. Shadows are crushed to near-black

3. Some textures don't load and render as flat green

Where in the game

How often

Graphics card and driver version

CPU, RAM and operating system

Changes from the defaults

Other software hooked into the game

hookshot_log.txt

Screenshots or video

Before you send it