The 137b4f2 payload, re-landed now that #110 is resolved: the missing-indoor-
textures correlation was the pre-existing #105 staged-texture-flush drop
(fixed in c787201), not a near-plane mechanism. znear=0.1 merely raised #105's
trigger probability — a closer near plane makes close-up geometry newly
visible, inflating per-frame prepare/upload pressure indoors and growing the
never-flushed tail. Exactly the handoff's only-credible-link hypothesis,
verified instead of assumed.
Retail: Render::SetFOVRad sets znear=0.1 flat (decomp :342173, initializer
:1101867). 0.1 < the 0.3m camera-collision sphere, so a wall the collided eye
presses against no longer falls inside the near plane — the §4 corner
see-through-wall closes.
Verification on the 0.1 arm (the arm that struck 2-of-3 on 2026-06-10):
nearplane-reland-1.log — [tex-flush] after=0 on all 45 lines, 68,291 [shell]
lines with zero zh>0 batches, all four dat tripwires silent, no [wb-error].
ISSUES.md: #105 + #110 moved to Recently closed with root cause + evidence.
Pending user re-gate: corner press (wall stays solid) + distance scan for
z-shimmer (none expected; retail ships 0.1 with D24).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Bisect (user-gated): two consecutive runs on 0.1 lost indoor textures; the 1.0 bisect run rendered clean. #105 tripwires silent on the bad runs (GL-side). No known mechanism links the near plane to texturing - #110 filed to investigate (RenderDoc / flip-testing) before re-landing retail's znear=0.1, which the corner see-through fix depends on. Comments on all four cameras point at #110 so the retail value is not re-landed blind.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The collided camera eye sits 0.3m from walls (viewer_sphere radius); a 1.0m near plane clipped the wall face away, so pressing the camera into a corner showed the clear color through the wall (gate result: unchanged by the flood fix - it was never a flood bug). Retail sets Render::znear = 0.1 flat in SetFOVRad (decomp :342173, initializer :1101867). All four cameras aligned. Also files #107 (indoor spawn wedge, 3-for-3), #108 (cellar-up terrain sweep across door opening), #109 (exit-door texture/background oscillation) from the 2026-06-10 visual gate; gate confirms the dac8f6a flood fix: room-room + indoor-outdoor transitions clean.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The user noted that the previous 35 u/s default felt too fast for
exploring scenery — overshooting buildings and skipping past entities
constantly. Drop default to 12 u/s (≈AC's run speed), and bind Shift
to a 50 u/s boost for fast travel between landblocks. Backwards
compatible: the new boost parameter on FlyCamera.Update has a default
of false, so any existing caller behaves the same.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
User-reported visuals after Phase 5c ObjScale landed:
- Nullified Statue is bigger but "distorted" and half-sunken into the
foundry
- WASD/Space/Ctrl camera speed too fast
Fixes:
1. Scale multiplication order. Phase 5c used `scaleMat * PartTransform`,
which in C# row-vector Matrix4x4 semantics means "scale first (in
mesh-local space), then apply PartTransform." For multi-part meshes
where each part has an attachment translation, this scales the mesh
but leaves the attachment offset un-scaled — so child parts drift
relative to each other and the base anchor ends up below the ground.
Offline scenery hydration has always used the opposite order:
`PartTransform * scaleMat`, meaning "transform first, then scale the
resulting position." Matching that order fixes both distortion and
sinking in one change, and makes live entities consistent with
scenery's proven path.
2. FlyCamera.MoveSpeed 100 → 35. 100 world units/sec is ~half a landblock
per second at AC scale — fine for terrain-scouting but too aggressive
for inspecting specific entities like the foundry statue. 35 is a
little faster than walk pace and feels right for visual iteration.
