Bug B from the sky-investigation handoff is fixed in 7b88fde — file the
Recently closed entry. Two new observations from the visual-verify
session that the user flagged when they could finally see the sky
clearly: cloud coverage looks faint vs retail, aurora ("northern
lights") not rendered at all. Both LOW severity (aesthetic feature
parity, not gameplay-breaking) and out of scope for the current
worktree, which is heading to Bug A (foreground rain, #1) next per
docs/research/2026-04-26-sky-investigation-handoff.md.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Erik
parent
7b88fde52d
commit
9567597814
1 changed files with 50 additions and 0 deletions
|
|
@ -292,10 +292,60 @@ missing is the plugin-API surface.
|
|||
|
||||
---
|
||||
|
||||
## #27 — Cloud meshes appear missing or faint compared to retail
|
||||
|
||||
**Status:** OPEN
|
||||
**Severity:** LOW (aesthetic feature-parity — doesn't break gameplay)
|
||||
**Filed:** 2026-04-26
|
||||
**Component:** sky / clouds
|
||||
|
||||
**Description:** After fixing Bug B (#26 — stars-as-square), the user observed during visual verification that cloud coverage in the sky doesn't match retail. Cloud meshes are authored in the dat (e.g. `0x010015B6`, `0x01004C35`-`0x01004C38`, `0x01004C36` etc) and `tools/StarsProbe` confirms they're loaded into the SkyObject lists with non-zero TexVelocity (so they get GL_REPEAT correctly under the post-#26 code path). They're not strictly missing — they're rendered — but their visual presence falls short of retail.
|
||||
|
||||
**Root cause / status:** Unknown. Hypotheses: (a) cloud surfaces' alpha/blend mode is too subtle (cloud surface flags or shader path under-emphasise the texture); (b) cloud meshes positioned/scaled wrong relative to the dome so they're inside the dome and occluded; (c) DayGroup keyframe interpolation suppresses cloud transparency at certain times of day; (d) some cloud SkyObjects we should be rendering are filtered out by a Properties bit we mis-handle (Props=0x02 might mean something more than "cloud — render it"); (e) retail uses an additive cloud blend that our Translucency classifier doesn't apply.
|
||||
|
||||
**Files:**
|
||||
- `src/AcDream.App/Rendering/Sky/SkyRenderer.cs` — sky pass; check per-cloud blend / luminosity / transparency.
|
||||
- `src/AcDream.Core/World/SkyDescLoader.cs` — Properties bit decoding.
|
||||
- `src/AcDream.App/Rendering/Shaders/sky.frag` — cloud transparency math.
|
||||
- `tools/StarsProbe/` — already dumps cloud GfxObj UVs + bounds; extend to dump per-DayGroup cloud surface flags.
|
||||
|
||||
**Research:** None yet. `tools/StarsProbe` output already enumerates which DayGroups reference which cloud meshes — start there.
|
||||
|
||||
**Acceptance:** Side-by-side launch of acdream and a retail client at the same `ACDREAM_DAY_GROUP` shows visually-comparable cloud coverage in the sky.
|
||||
|
||||
---
|
||||
|
||||
## #28 — Aurora ("northern lights") effect not rendered
|
||||
|
||||
**Status:** OPEN
|
||||
**Severity:** LOW (aesthetic feature-parity)
|
||||
**Filed:** 2026-04-26
|
||||
**Component:** sky / vfx
|
||||
|
||||
**Description:** Retail occasionally renders an aurora-borealis-style "northern lights" effect in the sky during certain weather/time conditions. acdream renders no aurora at all.
|
||||
|
||||
**Root cause / status:** Unknown — the mechanism hasn't been investigated. Aurora is NOT in the visible SkyObject lists (`tools/StarsProbe` shows the standard 7-object Sunny/Clear/Cloudy DayGroup composition, with extra weather objects in Rainy groups). Hypotheses: (a) it's a special PES on a low-probability DayGroup not yet enumerated; (b) it's a separate shader path not driven by `Region.SkyInfo`; (c) it requires a specific weather/time combo we haven't triggered; (d) it's an entirely separate `EnvironChangeType` system we don't decode.
|
||||
|
||||
**Files:** Unknown.
|
||||
|
||||
**Research:** None yet. Probably needs a retail-decomp grep for "aurora", "northern", a 360° survey of DayGroup PES contents, and possibly a deepdive into the `LScape::weather_enabled` and `EnvironChange*` paths.
|
||||
|
||||
**Acceptance:** When retail shows an aurora at a specific in-game time / weather, acdream shows a visually-comparable effect at the same time.
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
|
||||
# Recently closed
|
||||
|
||||
## #26 — [DONE 2026-04-26] Stars rendered as a square in one corner of the sky
|
||||
|
||||
**Closed:** 2026-04-26
|
||||
**Commit:** `7b88fde fix(sky): drive wrap mode from mesh UV range — fixes Bug B (stars-as-square)`
|
||||
**Resolution:** SkyRenderer's wrap-mode heuristic was `GL_CLAMP_TO_EDGE unless TexVelocity != 0`, which mis-classified the inner sky/star layer `0x010015EF` (UVs in `[0.398, 4.602]`, TexVel=0). Most of the dome sampled the texture's edge texels; only the small region where UVs fell in `[0,1]` showed actual texture content. Fixed by computing `NeedsUvRepeat` per submesh from the actual UV range during `GfxObjMesh.Build()` and driving the wrap-mode choice from that flag plus the existing scrolling check. Outer dome `0x010015EE/F0/F1/F2` (UVs strictly in `[0,1]`) keeps `CLAMP_TO_EDGE` so no seam regression. Probe `tools/StarsProbe/` (commit `991fb9a`) committed alongside as the diagnostic that found this.
|
||||
|
||||
---
|
||||
|
||||
## #25 — [DONE 2026-04-26] Phase K.3 — Settings panel + click-to-rebind UI
|
||||
|
||||
**Closed:** 2026-04-26
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue