Retail's Region dat stores SkyObjectReplace.Luminosity / Transparent /
MaxBright as percentages in the 0..100 range. Our shader expects
fractions in 0..1. We were passing raw values (luminosity up to 100)
straight into the sky fragment shader's rgb-multiplier:
rgb = sampled.rgb * uTint.rgb * uLuminosity;
At the "Sunny" DayGroup's noon keyframes (verified via live diag),
Luminosity = 100 → shader multiplied the cloud texture RGB by 100 →
min(rgb, vec3(1.2)) clamped all channels to 1.2 → pure white sky.
Also gave the dawn/dusk purple sky effect on top of the pale texture.
Fix: SkyDescLoader.ConvertTimeOfDay divides Luminosity, Transparent
and MaxBright by 100 when loading each SkyObjectReplace. The Rotate
field stays as degrees (values like 270° are genuine headings, not
percentages).
Transparent was accidentally surviving via a 0..1 clamp downstream,
but we fix it for consistency and so brightness-attenuating values
in the 0..99 range (partial fade during dawn/dusk) work correctly
instead of rounding to full-transparent.
WorldBuilder's SkyboxRenderManager does NOT apply these fields at
all — that's why they never hit this bug. Our port applies them for
per-keyframe day-night fades, so we needed the unit conversion.
Also picked up in this commit (incidental, already running):
- Sky render: per-submesh blend mode from TranslucencyKind.Additive
for sun/moon-style self-bright objects (Additive bit 0x10000).
Luminous flag 0x40 intentionally NOT mapped to additive — that
flag is on the sky dome + cloud sheets and making them additive
produced the previous "fully white" iteration of this bug.
- ToD default seed: DayTicks/16 (Midsong = hour 9 = true noon)
instead of DayTicks*0.5 which landed on Gloaming-and-Half (sunset)
due to DerethDateTime's +7/16 day-fraction offset. Pre-TimeSync
view now correctly starts at noon.
- Lightning flash: brighter white-blue (vec3(1.5,1.5,1.8)) instead
of dim grey; ceiling relaxed during flash so the strobe actually
blows out. Cadence (strike intervals, decay) unchanged.
- Saved docs/research/2026-04-21-sky-deep-audit.md with the
decompile+ACE+ACME+WorldBuilder research done to corner this bug.
Open follow-up (not fixed here): sky clouds are white at noon /
don't get the dusk/night purple tint. Our sky shader is fully unlit
— doesn't apply sun/ambient directional light like the terrain
shader does. AmbientColor in the keyframe data carries the right
tint (purple at midnight, magenta at dusk) but we pass
uTint = Vector4.One instead of the keyframe value. Next commit will
wire directional-sun + ambient into sky.frag so cloud meshes pick
up the time-of-day color.
All 717 tests green. User-confirmed: sky colors are now "much
better" after this change (previously fully white).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
182 lines
6 KiB
Markdown
182 lines
6 KiB
Markdown
# Deep Audit: Sky Rendering Bug
|
|
**Date:** 2026-04-21
|
|
**Issue:** Sky renders fully white despite keyframe data being pale blue/orange; framebuffer cleared to black.
|
|
**Hypothesis:** At least one of 7 sky objects is painting white across the view; rendering pipeline produces white, not data.
|
|
|
|
## Angle 1 — Retail Decompile: What the Sky Renderer Actually Does
|
|
|
|
### Finding: Could Not Locate Retail Sky Render Function
|
|
|
|
**Status:** COULDN'T LOCATE
|
|
|
|
After search of chunk_00400000.c through chunk_007F0000.c, found only one match:
|
|
- docs/research/decompiled/chunk_00500000.c:7340 comment about GameTime effects on sky
|
|
|
|
No functions containing sky, Sky, SkyObjects, CEnvironment, or D3D render-state constants found.
|
|
|
|
---
|
|
|
|
## Angle 2 — ACE: What Server Messages Drive Sky / Weather / Time?
|
|
|
|
### Retail Source: EnvironChangeType Enum
|
|
- references/ACE/Source/ACE.Entity/Enum/EnvironChangeType.cs:4-48
|
|
|
|
Only fog overlays and sound effects; NO mesh/texture/geometry changes:
|
|
|
|
```csharp
|
|
public enum EnvironChangeType {
|
|
Clear, RedFog, BlueFog, WhiteFog, GreenFog, BlackFog, BlackFog2,
|
|
RoarSound, ... /* sound effects only */
|
|
}
|
|
```
|
|
|
|
Sent via: GameMessageAdminEnvirons (admin-only, not broadcast)
|
|
|
|
### Our Code: Network Handling
|
|
- src/AcDream.Core.Net/Messages/GameEvents.cs:1-481 — No sky/weather parsers
|
|
- src/AcDream.Core.Net/WorldSession.cs — No AdminEnvirons handler
|
|
|
|
**Verdict: MISSING**
|
|
But the bug symptoms (fully white sky) are NOT consistent with WhiteFog overlay; this is client-side rendering failure, not a server message issue.
|
|
|
|
---
|
|
|
|
## Angle 3 — ACME: Improved Sky Rendering
|
|
|
|
### Finding: No ACME-Specific Sky Renderer
|
|
|
|
ACME contributes only animation/model reference; does not override WorldBuilder SkyboxRenderManager. We port vanilla WorldBuilder unchanged.
|
|
|
|
---
|
|
|
|
## Angle 4 — WorldBuilder Vanilla: Re-read for Details
|
|
|
|
### Key Finding: Per-Submesh Blend Mode Divergence
|
|
|
|
**WorldBuilder (references/WorldBuilder/.../SkyboxRenderManager.cs:301-318):**
|
|
```csharp
|
|
foreach (var batch in renderData.Batches) {
|
|
// ... bind texture, sampler ...
|
|
_gl.DrawElementsInstancedBaseVertex(...);
|
|
// NO BlendFunc call per batch
|
|
}
|
|
```
|
|
|
|
**Our Code (src/AcDream.App/Rendering/Sky/SkyRenderer.cs:175-196):**
|
|
```csharp
|
|
foreach (var sub in subMeshes) {
|
|
if (sub.IsAdditive)
|
|
_gl.BlendFunc(BlendingFactor.SrcAlpha, BlendingFactor.One);
|
|
else
|
|
_gl.BlendFunc(BlendingFactor.SrcAlpha, BlendingFactor.OneMinusSrcAlpha);
|
|
// ... draw
|
|
}
|
|
```
|
|
|
|
We set blend state PER SUBMESH; retail does NOT. This adds a failure point: if IsAdditive classification is wrong, one mesh renders with wrong blend mode.
|
|
|
|
---
|
|
|
|
## Angle 5 — Our Code: End-to-End
|
|
|
|
### A) Data Loading
|
|
src/AcDream.Core/World/SkyDescLoader.cs: MATCHES retail
|
|
|
|
Loads Region 0x13000000, parses 7 sky objects with correct color data.
|
|
|
|
### B) Blend Mode Classification
|
|
src/AcDream.App/Rendering/Sky/SkyRenderer.cs:314
|
|
|
|
```csharp
|
|
bool isAdditive = sm.Translucency == TranslucencyKind.Additive;
|
|
```
|
|
|
|
**CRITICAL COMMENT (lines 311-313):**
|
|
```csharp
|
|
// NOTE: earlier revision also treated SurfaceType.Luminous = 0x40
|
|
// as additive, but that flag is present on the sky DOME itself and
|
|
// on cloud sheets — turning those additive blew the whole sky to
|
|
// white. Luminous means self-illuminated, not additive.
|
|
```
|
|
|
|
This documents a PAST WHITE-SKY BUG caused by misclassifying Luminous as additive.
|
|
|
|
Question: Is the current fix correct? Did we introduce a NEW misclassification?
|
|
|
|
### C) Shader Luminosity
|
|
src/AcDream.App/Rendering/Shaders/sky.frag:36-59
|
|
|
|
```glsl
|
|
vec3 rgb = sampled.rgb * uTint.rgb * uLuminosity;
|
|
```
|
|
|
|
If sampled texture is white (1,1,1) and uLuminosity=1, output is white.
|
|
|
|
---
|
|
|
|
## Root-Cause Hypothesis Ranked by Confidence
|
|
|
|
### Hypothesis 1 (HIGH CONFIDENCE): IsAdditive Misclassification
|
|
|
|
**Evidence:**
|
|
- Comment at SkyRenderer.cs:311-313 documents past white-sky incident from Luminous misclassification
|
|
- We changed code to only treat Additive=0x10000 as additive, skipping Luminous=0x40
|
|
- But IsAdditive is computed once at upload and NEVER re-checked or validated
|
|
- We diverge from retail by setting blend per submesh, creating a failure point
|
|
|
|
**Symptom matches:**
|
|
- Sky fully white = additive blend of white mesh over black framebuffer
|
|
- Black clear makes problem visible
|
|
|
|
**Acceptance test:** Log SurfaceType flags for all 7 sky objects and verify IsAdditive classification matches retail expectations.
|
|
|
|
### Hypothesis 2 (MEDIUM CONFIDENCE): Texture Decode Produces White
|
|
|
|
**Evidence:**
|
|
- TextureCache.GetOrUpload at SkyRenderer.cs:188
|
|
- If surface texture is decoded incorrectly, white pixels result
|
|
|
|
**Acceptance test:** Compare decoded texture bytes against expected color data.
|
|
|
|
### Hypothesis 3 (LOW CONFIDENCE): Luminosity Override
|
|
|
|
**Evidence:**
|
|
- Diag shows luminosity values max at 0.78 (not > 1)
|
|
- Shader applies multiplicatively; shouldn't blow white unless texture is already near-white
|
|
|
|
**Less likely:** Keyframe data is not driving the issue.
|
|
|
|
---
|
|
|
|
## Next Fix: Verify IsAdditive Classification
|
|
|
|
**Target:** src/AcDream.App/Rendering/Sky/SkyRenderer.cs:276-325 (UploadSubMesh)
|
|
|
|
**Action:** Add logging to print SurfaceType flags and IsAdditive result for each sky mesh surface.
|
|
|
|
**Concrete change:**
|
|
```csharp
|
|
private SubMeshGpu UploadSubMesh(GfxObjSubMesh sm) {
|
|
// ... setup ...
|
|
bool isAdditive = sm.Translucency == TranslucencyKind.Additive;
|
|
|
|
System.Diagnostics.Debug.WriteLine(
|
|
$"Sky Surface {sm.SurfaceId}: Translucency={sm.Translucency}, IsAdditive={isAdditive}");
|
|
|
|
return new SubMeshGpu { ... };
|
|
}
|
|
```
|
|
|
|
Run test, check Debug output against SurfaceType enum definitions and retail behavior.
|
|
|
|
**Acceptance test:** No sky object shows:
|
|
- SurfaceType.Luminous (0x40) misclassified as IsAdditive=true
|
|
- SurfaceType.Additive (0x10000) misclassified as IsAdditive=false
|
|
|
|
---
|
|
|
|
## Conclusion
|
|
|
|
Bug is client-side rendering pipeline, not data or server messages. Most likely cause: **IsAdditive misclassification on a dominant sky mesh (dome or sun)**. The codebase already documents a past white-sky incident from this exact error.
|
|
|
|
Verify by logging SurfaceType flags for all 7 sky objects and comparing against retail specifications.
|