MagicBeanDev/Hookshot

Archived

Watch

Fork 0

Ground rendering, glowing plant stems and disappearing ground fog (v2.0.3, RTX 5080) #757

Closed

opened 2026-11-08 20:10:30 +00:00 by vexyon · 7 comments

vexyon commented

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

(Migrated from github.com)

Hookshot version

v2.0.3

What kind of problem

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

What happened

Version: v2.0.3 (45620e8)
OS: NixOS, Hyprland
GPU: NVIDIA RTX 5080
CPU: Intel i9-14900K

What happens

Ground: the ground looks wrong in some areas of Kokiri Forest. It depends on the zone: some areas look fine, others don't.
Plant stems and flowers: flower stems and plant stalks glow bright green.
Ground fog: the ground fog sometimes disappears and comes back.

All three were already present in earlier versions (v2.0.0, v2.0.2) and are still there in v2.0.3.

Steps to reproduce

Load a save in Kokiri Forest.
Walk around the village and look at the ground, the flowers and the ground fog.

Where in the game

Kokiri Forest

How often

Every time

Graphics card and driver version

RTX 5080 driver 595.112.07 kernel Linux 6.18.62

CPU, RAM and operating system

Intel i9 14900k NixOS kernel 6.18.62

Changes from the defaults

No response

Other software hooked into the game

No, nothing hooked in

hookshot_log.txt

hookshot_log_v2.0.3.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 v2.0.3 ### What kind of problem Graphics (missing, black or wrong-coloured things, lighting, flicker) ### What happened **Version:** v2.0.3 (45620e8) **OS:** NixOS, Hyprland **GPU:** NVIDIA RTX 5080 **CPU:** Intel i9-14900K ### What happens - **Ground:** the ground looks wrong in some areas of Kokiri Forest. It depends on the zone: some areas look fine, others don't. - **Plant stems and flowers:** flower stems and plant stalks glow bright green. - **Ground fog:** the ground fog sometimes disappears and comes back. All three were already present in earlier versions (v2.0.0, v2.0.2) and are still there in v2.0.3. ### Steps to reproduce 1. Load a save in Kokiri Forest. 2. Walk around the village and look at the ground, the flowers and the ground fog. <img width="2551" height="1439" alt="Image" src="https://github.com/user-attachments/assets/dc58e2ec-3cda-4e49-b499-782a236d9e23" /> ### Where in the game Kokiri Forest ### How often Every time ### Graphics card and driver version RTX 5080 driver 595.112.07 kernel Linux 6.18.62 ### CPU, RAM and operating system Intel i9 14900k NixOS kernel 6.18.62 ### Changes from the defaults _No response_ ### Other software hooked into the game No, nothing hooked in ### hookshot_log.txt [hookshot_log_v2.0.3.txt](https://github.com/user-attachments/files/34554003/hookshot_log_v2.0.3.txt) ### Screenshots or video <img width="2551" height="1439" alt="Image" src="https://github.com/user-attachments/assets/54bd81ea-72a2-424a-8b6a-8cc4b054f8c2" /> <img width="1894" height="1378" alt="Image" src="https://github.com/user-attachments/assets/6e14e192-313c-48ca-aa58-9b5166984cc2" /> <img width="1894" height="1378" alt="Image" src="https://github.com/user-attachments/assets/e384e9bb-167e-4dc7-846d-ca2d8b6534a4" /> ### 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.

elammarin commented

2026-11-08 20:21:38 +00:00

(Migrated from github.com)

same with 9070xt and 7800x3d, 2.0.2 was fine

CoreBytee commented

2026-11-08 23:47:59 +00:00

(Migrated from github.com)

I'm still experiencing glowing foliage on 2.0.5 with my 4060 running on arch

elammarin commented

2026-11-08 23:51:05 +00:00

(Migrated from github.com)

same as @CoreBytee , still the same bug present on 2.0.5 running on 9070xt and 7800x3d. Lighting has been fixed but not the glowing vegetation

hckrman101 commented

2026-11-09 00:02:22 +00:00

(Migrated from github.com)

Findings: glowing / missing flower stems (Kokiri Forest, mesh foliage colour pass)

Version: current main (b1799142, #640 reverted), Linux, NVIDIA RTX 3090
Related: this issue, #667, #696 (glowing stems, near foliage), #674 (flower petals too white)

What happens

Next to Link's house in Kokiri Forest, the flower patch by the path looks like this:

Lichii (reference): dark green/brown stems, lavender petals, fern fronds and grass tufts around the rock.
Hookshot: the stems are thin bright green lines (with bloom), the petals are pink/white, and most of the ferns and grass near Link are gone or show only as short green (sometimes red/orange) slivers.
In other sessions the stems don't show at all and the flower heads float, with green/red specks where the grass blades should be. The colours depend on memory timing (another report saw them change with RX_VK_MIRROR), so "glowing" and "missing" look like two faces of the same bug.

Same save, same spot, both at the spawn camera:

The draws

Found by hiding programs live with RX_VK_SKIP_FILE:

program	stage	what it is	hidden
`5ba7cf23d6857836`	task+mesh, fragment = alpha test, colour mask 0	depth pre-pass of the stems/grass	the stems vanish completely (the "no stems" look)
`89ca750f9852b7ca`	task+mesh + fragment, depth test EQUAL	colour pass over the same indirect draws	the stems are left flat white (the pre-pass's colour)

So geometry, culling and the pre-pass are fine: the stems are there and in the right place. The colour 89ca750f's fragment program computes is wrong.

What `89ca750f`'s fragment reads

Mesh outputs: Generic0.x, 1.x, 2.x, 4.xyz, 5.xyz, 6.x, 7.xyz, 8.xyz, 11.xyz + position. Exactly what the mesh program writes (no unwritten components).
FrontFace (two-sided stems: the normal is flipped by facing).
9 implicit-LOD + 2 explicit-LOD samples. All 10 textures resolve to real images: three 128x128x88 2D arrays (BC formats), a 512x512x64 3D texture, a 128x128 cube, 1024 / 2048 2D textures, two 1536x864 / 384x216 render targets.
Per-object light lists: a 32-bit index list through storage buffer c0[0x510], then 96-byte light records c0[0x520] + idx*96 + 16/32 (four 128-bit loads).

Ruled out (this report and the earlier ones)

Unbound global memory: RX_VK_MISS_LOG=1 RX_VK_MISS_LOG_PROG=89ca750f shows 0 misses. The "storage buffer NOT bound" programs of #696 are not this one (another report changed that search; the glow stayed).
Textures: every handle resolves (RX_VK_LOG_IMG=89ca750f); none hits the "handle is a storage pointer" rule.
Depth-EQUAL precision, NaN guard on mesh fragments, RX_VK_PARALLEL, RX_VK_KEEP_FINALIZED_MB=0, the mesh "firsts" (from the earlier reports).
Front face: flipping the front face of cull-none mesh draws (diagnostic only) changes the petals' shading but not the stems' glow.
RX_VK_NO_F16=1 can't be used as a test: it breaks the whole picture (the upscaler network).

Where to look next

The colour is a lighting result that follows the stems' world orientation and the wind. That points at the light-list / probe path (c0[0x510] indices, c0[0x520] records, the 3D texture and cube map) or at the normal built from the mesh outputs and the BC normal/material arrays, rather than at geometry. A next step would be dumping 89ca750f's light-record reads (the index list and the four 128-bit loads) for one stem pixel and checking them against the same frame in Lichii, which draws the patch correctly.

Reproduce

Load a save in Kokiri Forest next to Link's house (spawn point by the flower patch on the path).
Look at the purple flowers at the right of the path.
RX_VK_SKIP_FILE=<file> with 89ca750f9852b7ca in it turns the stems white; with 5ba7cf23d6857836 the stems disappear.

Update: the glow is the per-vertex ambient (SH probe) colour, computed too high in the mesh program

Measured inside 89ca750f's fragment shader at a glowing stem pixel, against a normal grass fragment further away:

	glowing stem	normal grass
final green	1.02	0.19
`Generic11.xyz` received from the mesh stage	(1.19, 17.14, 15.71)	(0.24, 2.36, 1.73)

One term is the whole glow: albedo × (Generic11.y × a c6[1088]-scaled factor + a small rest) = 0.095 × 10.7 ≈ 1.015. The other four terms the shader adds up are below 0.05 together.
Not the lights: the light index list (c0[0x510]) and the 96-byte records (c0[0x520]) look sane (e.g. a light of radius 20 at (-45.2, 112.7, -18.7), likely the lantern above the patch), and the glow is there even on fragments where no light is accumulated. Normals are unit length; world positions match the spot.
Not the textures or the 3D volume: none of the textures is on the glowing path, and the term with the 3D-texture sample is multiplied by 0 here.
What Generic11 is: the mesh program writes it as a per-vertex spherical-harmonics irradiance evaluation, per colour channel (the SH constants 0.282095 and 0.162868 are in the IR). Its coefficients come from about four 128-bit global loads, a weighted blend of light probes, through a pointer read from the storage buffer at c0[0x780]+32, then probe index × 16. RX_VK_MISS_LOG shows 0 misses, so those reads land in a bound buffer. (The guess here that the probe data itself was stale turned out wrong; see the next update.)

Next: a probe in the mesh stage records the raw SH words, their blend weights and addresses for the vertices that come out too bright, to see which buffer and page they're read from and whether that memory was last written by the CPU (mirror sync) or by a GPU pass.

Update 2: the probe data is right; the error is in the mesh program's ambient computation (or one of its later inputs)

A probe in 89ca750f's mesh stage recorded what it reads for the vertices that come out too bright:

The inputs match memory. The SH probe words, their index words, the grid header and the per-stage constants (c0[0x770]+48/80/96, c4 at 80/544/548/900) are identical to guest memory at the same addresses. They're CPU-written, nothing writes them after play starts (RX_VK_WATCH_CPU, RX_VK_WATCH_GPU_WRITE), and no GPU pass writes into them. So it isn't mirror sync or a stale copy.
The blend looks sane. The probe weights are all positive (sums 0.47–0.87), every probe is valid, and the lookup lands inside the probe grid. The mesh stage's c4 is its own binding.
Where the glow comes from: one sub-term of the ambient colour, about 5 on the stems vs 0.5 further away: the probe blend × c0[0x770]+96.x × 0.282, then a further chain of the same kind. Everything checked so far is correct, so the wrong part is somewhere in the rest of that chain (a later read landing on another field, or arithmetic that doesn't match the hardware). Only part of the ~2,800-instruction cone has been probed.

Also ruled out:

switch	stems
current main (`32df58e0`, legacy global-memory pass by default)	still glow, a bit dimmer
`RX_VK_PRECOMPILE=0 RX_VK_NO_PROGRAM_CACHE=1` (everything translated in play)	still glow
`EDEN_NX2_UNDEF_ZERO=0`	still glow
`RX_VK_NOOPT=1`	still glow
`EDEN_NX2_GM_LEGACY=1` vs the port	`89ca750f`'s mesh and fragment IR are identical; the stems only dim
`EDEN_NX2_GM_COMPETING=0`	stems and leaves vanish and the flower heads float: the "missing stems" look of this issue, from another program than `89ca750f`

Next: the cone needs a reference value per vertex to bisect against (Generic11.y for the same vertex from a correct renderer, or the mesh IR evaluated on the CPU over the same guest memory). That's a bigger step than the probes so far, so it's paused here; anyone with an idea where to look in that chain is welcome to pick it up.

## Findings: glowing / missing flower stems (Kokiri Forest, mesh foliage colour pass) **Version:** current main (b1799142, #640 reverted), Linux, NVIDIA RTX 3090 **Related:** this issue, #667, #696 (glowing stems, near foliage), #674 (flower petals too white) ## What happens Next to Link's house in Kokiri Forest, the flower patch by the path looks like this: - **Lichii (reference):** dark green/brown stems, lavender petals, fern fronds and grass tufts around the rock. - **Hookshot:** the stems are thin bright green lines (with bloom), the petals are pink/white, and most of the ferns and grass near Link are gone or show only as short green (sometimes red/orange) slivers. - In other sessions the stems don't show at all and the flower heads float, with green/red specks where the grass blades should be. The colours depend on memory timing (another report saw them change with `RX_VK_MIRROR`), so "glowing" and "missing" look like two faces of the same bug. Same save, same spot, both at the spawn camera: ![Lichii vs Hookshot, same save and spot](https://raw.githubusercontent.com/hckrman101/Hookshot/pr-images/stems-compare.png) ## The draws Found by hiding programs live with `RX_VK_SKIP_FILE`: | program | stage | what it is | hidden | |---|---|---|---| | `5ba7cf23d6857836` | task+mesh, fragment = alpha test, colour mask 0 | depth pre-pass of the stems/grass | the stems vanish completely (the "no stems" look) | | `89ca750f9852b7ca` | task+mesh + fragment, depth test EQUAL | colour pass over the same indirect draws | the stems are left flat white (the pre-pass's colour) | So geometry, culling and the pre-pass are fine: the stems are there and in the right place. **The colour `89ca750f`'s fragment program computes is wrong.** ## What `89ca750f`'s fragment reads - Mesh outputs: Generic0.x, 1.x, 2.x, 4.xyz, 5.xyz, 6.x, 7.xyz, 8.xyz, 11.xyz + position. Exactly what the mesh program writes (no unwritten components). - `FrontFace` (two-sided stems: the normal is flipped by facing). - 9 implicit-LOD + 2 explicit-LOD samples. All 10 textures resolve to real images: three 128x128x88 2D arrays (BC formats), a 512x512x64 3D texture, a 128x128 cube, 1024 / 2048 2D textures, two 1536x864 / 384x216 render targets. - Per-object light lists: a 32-bit index list through storage buffer `c0[0x510]`, then 96-byte light records `c0[0x520] + idx*96 + 16/32` (four 128-bit loads). ## Ruled out (this report and the earlier ones) - Unbound global memory: `RX_VK_MISS_LOG=1 RX_VK_MISS_LOG_PROG=89ca750f` shows 0 misses. The "storage buffer NOT bound" programs of #696 are not this one (another report changed that search; the glow stayed). - Textures: every handle resolves (`RX_VK_LOG_IMG=89ca750f`); none hits the "handle is a storage pointer" rule. - Depth-EQUAL precision, NaN guard on mesh fragments, `RX_VK_PARALLEL`, `RX_VK_KEEP_FINALIZED_MB=0`, the mesh "firsts" (from the earlier reports). - Front face: flipping the front face of cull-none mesh draws (diagnostic only) changes the petals' shading but not the stems' glow. - `RX_VK_NO_F16=1` can't be used as a test: it breaks the whole picture (the upscaler network). ## Where to look next The colour is a lighting result that follows the stems' world orientation and the wind. That points at the light-list / probe path (`c0[0x510]` indices, `c0[0x520]` records, the 3D texture and cube map) or at the normal built from the mesh outputs and the BC normal/material arrays, rather than at geometry. A next step would be dumping `89ca750f`'s light-record reads (the index list and the four 128-bit loads) for one stem pixel and checking them against the same frame in Lichii, which draws the patch correctly. ## Reproduce 1. Load a save in Kokiri Forest next to Link's house (spawn point by the flower patch on the path). 2. Look at the purple flowers at the right of the path. 3. `RX_VK_SKIP_FILE=<file>` with `89ca750f9852b7ca` in it turns the stems white; with `5ba7cf23d6857836` the stems disappear. ## Update: the glow is the per-vertex ambient (SH probe) colour, computed too high in the mesh program Measured inside `89ca750f`'s fragment shader at a glowing stem pixel, against a normal grass fragment further away: | | glowing stem | normal grass | |---|---|---| | final green | 1.02 | 0.19 | | `Generic11.xyz` received from the mesh stage | (1.19, 17.14, 15.71) | (0.24, 2.36, 1.73) | - **One term is the whole glow:** albedo × (`Generic11.y` × a `c6[1088]`-scaled factor + a small rest) = 0.095 × 10.7 ≈ 1.015. The other four terms the shader adds up are below 0.05 together. - **Not the lights:** the light index list (`c0[0x510]`) and the 96-byte records (`c0[0x520]`) look sane (e.g. a light of radius 20 at (-45.2, 112.7, -18.7), likely the lantern above the patch), and the glow is there even on fragments where no light is accumulated. Normals are unit length; world positions match the spot. - **Not the textures or the 3D volume:** none of the textures is on the glowing path, and the term with the 3D-texture sample is multiplied by 0 here. - **What `Generic11` is:** the mesh program writes it as a per-vertex spherical-harmonics irradiance evaluation, per colour channel (the SH constants 0.282095 and 0.162868 are in the IR). Its coefficients come from about four 128-bit global loads, a weighted blend of light probes, through a pointer read from the storage buffer at `c0[0x780]+32`, then probe index × 16. `RX_VK_MISS_LOG` shows 0 misses, so those reads land in a bound buffer. (The guess here that the probe data itself was stale turned out wrong; see the next update.) Next: a probe in the mesh stage records the raw SH words, their blend weights and addresses for the vertices that come out too bright, to see which buffer and page they're read from and whether that memory was last written by the CPU (mirror sync) or by a GPU pass. ## Update 2: the probe data is right; the error is in the mesh program's ambient computation (or one of its later inputs) A probe in `89ca750f`'s mesh stage recorded what it reads for the vertices that come out too bright: - **The inputs match memory.** The SH probe words, their index words, the grid header and the per-stage constants (`c0[0x770]+48/80/96`, `c4` at 80/544/548/900) are identical to guest memory at the same addresses. They're CPU-written, nothing writes them after play starts (`RX_VK_WATCH_CPU`, `RX_VK_WATCH_GPU_WRITE`), and no GPU pass writes into them. So it isn't mirror sync or a stale copy. - **The blend looks sane.** The probe weights are all positive (sums 0.47–0.87), every probe is valid, and the lookup lands inside the probe grid. The mesh stage's `c4` is its own binding. - **Where the glow comes from:** one sub-term of the ambient colour, about 5 on the stems vs 0.5 further away: the probe blend × `c0[0x770]+96`.x × 0.282, then a further chain of the same kind. Everything checked so far is correct, so the wrong part is somewhere in the rest of that chain (a later read landing on another field, or arithmetic that doesn't match the hardware). Only part of the ~2,800-instruction cone has been probed. Also ruled out: | switch | stems | |---|---| | current main (32df58e0, legacy global-memory pass by default) | still glow, a bit dimmer | | `RX_VK_PRECOMPILE=0 RX_VK_NO_PROGRAM_CACHE=1` (everything translated in play) | still glow | | `EDEN_NX2_UNDEF_ZERO=0` | still glow | | `RX_VK_NOOPT=1` | still glow | | `EDEN_NX2_GM_LEGACY=1` vs the port | `89ca750f`'s mesh and fragment IR are identical; the stems only dim | | `EDEN_NX2_GM_COMPETING=0` | stems and leaves vanish and the flower heads float: the "missing stems" look of this issue, from another program than `89ca750f` | Next: the cone needs a reference value per vertex to bisect against (`Generic11.y` for the same vertex from a correct renderer, or the mesh IR evaluated on the CPU over the same guest memory). That's a bigger step than the probes so far, so it's paused here; anyone with an idea where to look in that chain is welcome to pick it up.

NotRexed commented

2026-11-09 05:55:51 +00:00

(Migrated from github.com)

Fixed in v2.0.6 (https://github.com/NotRexed/Hookshot/releases/tag/v2.0.6): the bright red/green/neon plant stems, flowers and branches came from a shader translation bug that gave an instruction the wrong input (PR #759). Please update from the launcher; reply here or open a new issue if it still happens. The ground rendering and disappearing ground parts are tracked in #994.

vexyon commented

2026-11-09 06:27:15 +00:00

(Migrated from github.com)

Confirmed on v2.0.6 (NixOS, Hyprland, RTX 5080): plant stems, flowers and ground fog look right now. Thanks a lot! I’ll follow #994 for the ground.

hckrman101 commented

2026-11-09 06:49:54 +00:00

(Migrated from github.com)

Confirming #922 fixes the Kokiri Forest case too (the flower patch next to Link's house, from the findings above).

The stems' mesh colour pass there (d38b0d52a94ab5a8) had the same marker clash in ten instructions, for example FFMA R239, R28, R216, R239 → R216->X239, R216->X216. In the per-vertex ambient (SH probe) sum that turned x·w + acc into x·acc + acc: red lost a probe term, and green and blue came out about 10× too bright (measured 2–22 against about 0.2 in a reference renderer), hence the cyan-green glow. With #922's rule the program lowers with no number mapped twice, and the patch looks right: dark stems, purple petals, no glow, normal grass.

Reference | before | with #922:

Confirming #922 fixes the Kokiri Forest case too (the flower patch next to Link's house, from the findings above). The stems' mesh colour pass there (`d38b0d52a94ab5a8`) had the same marker clash in ten instructions, for example `FFMA R239, R28, R216, R239` → `R216->X239, R216->X216`. In the per-vertex ambient (SH probe) sum that turned `x·w + acc` into `x·acc + acc`: red lost a probe term, and green and blue came out about 10× too bright (measured 2–22 against about 0.2 in a reference renderer), hence the cyan-green glow. With #922's rule the program lowers with no number mapped twice, and the patch looks right: dark stems, purple petals, no glow, normal grass. Reference | before | with #922: ![before/after](https://raw.githubusercontent.com/hckrman101/Hookshot/pr-images/stems-fixed-922.png)

Commenting is not possible because the repository is archived.