3D hub ON AIR doorway visual-block fix

Project 📁 demo-project

Agent 🤖 claude

Created At 📅 2026-07-18 05:58:25

Git Branch 🌿 main

Git Commit 📌 ab08371

📝 Summary

A user reported: "I can walk from the spawn point toward the hub, and visually there's a wall blocking the way, but my character can just walk straight through it."

Used Blender ray casts to track down two separate layers of the same bug:

The studio's circular wall geometry left only a ~0.02m visual gap at the doorway (the actual frame opening is 2.85m wide), welding the upper half of the doorway shut
A shorter wall base (Studio_BaseA/Studio_BaseB) plus a decorative pipe ring (D_Hall_PipeRing) sealed off the lower, waist-height half of the same doorway

Godot's collision shapes were hand-authored separately and already left enough of a gap, so walking through worked fine the whole time — that mismatch between visual geometry and collision geometry is exactly why it "looked like a wall but you could walk right through it." Deleted the extra geometry from both layers and re-exported the glb, then verified with 40 fresh screenshots rendered on the machine's own local display (DISPLAY=:1, not an SSH-forwarded one) — the doorway is now fully clear, with both ON AIR door panels open symmetrically. Along the way, also fixed a real but minor camera bug: the follow camera's SpringArm3D had a one-frame snap-to-face glitch at the same threshold, now smoothed out.

🖼 Visual Evidence (2)

Looking back at the ON AIR doorway from the hub

AFTER

BEFORE

↔

BEFORE

AFTER

Comparison: Looking back at the ON AIR doorway from the hub

AFTER

Before: an actual in-game screenshot taken before the fix (standing in the hub, looking back), clearly showing what reads as a closed double door with a seam down the middle. After: an actual Godot screenshot from the same camera position after both fix rounds — the doorway is now fully clear.

Looking from the spawn point toward the hub (final confirmation)

The fixed, real in-game view: both ON AIR door panels rest open symmetrically at the sides of the frame, the "ON AIR" sign is fully visible, and you can see straight through to the studio's porthole window, with no leftover wall or pipe geometry blocking the doorway top to bottom.

🛠 Changes Made

Root cause fix 1: deleted four studio circular-wall segments (Studio_WallA_00 / Studio_WallA_01 / Studio_WallB_44 / Studio_WallB_43) that were mistakenly blocking the center/upper half of the ON AIR doorway
Root cause fix 2 (found by codex): deleted four wall-base pieces (Studio_BaseA_00 / Studio_BaseA_01 / Studio_BaseB_44 / Studio_BaseB_43) blocking the lower, waist-height half of the doorway, and cut the section of D_Hall_PipeRing crossing the passage, then re-exported hub_lobby.glb
Minor fix: HubCamera.gd now uses a manual raycast + asymmetric lerp instead of SpringArm3D's built-in collision response, avoiding a one-frame snap-to-zero in follow distance at the same threshold
Previously completed but not the root cause this time: ON AIR door panels now rotate open (±100°), the ON AIR broadcast interaction point moved from z=9.6 to z=11.4, and the lobby's top-left panel text got a black outline for contrast (HubWorld.gd, not committed yet at the time)

✅ Verification Checks

Located the blocking objects with Blender ray casts (round 1) Passed Command

💡 Ray-cast from the hub-side camera position at the two suspected door panels; hit Studio_WallA_00/01 and Studio_WallB_44/43 exactly, confirming it was the studio's circular wall, not the ON AIR door panels themselves

Bidirectional Blender ray cast (round 2, run by codex) Passed Command

💡 User still reported "a small issue left" after round 1; handed to codex to re-check with the same technique — a full bidirectional raycast sweep across X -1.0 to 1.0, height 0.35-1.7m found Studio_BaseA/B's four wall-base pieces and D_Hall_PipeRing; the same sweep reported CLEAR everywhere after the fix

glb re-exported without touching unrelated scenes Passed Command

💡 Confirmed use_active_scene=True took effect on both export passes; the unrelated arena scene (126 objects) was not touched or re-exported

Camera follow-smoothing fix verified with a real in-game camera walkthrough Passed Screenshot

📄 logs/camera_smoothing_walkthrough.txt

💡 Ran godot --rendering-driver opengl3 with the real follow camera walking through the threshold; follow distance now dips and recovers smoothly (3.4 -> 1.67 -> 0.86 -> 1.73 -> 3.04) instead of snapping to zero in one frame

Final visual confirmation after reloading the glb in the real Godot build Passed Screenshot

📄 images/doorway_final_ingame.png

💡 Re-rendered 40 screenshots using the machine's own local display (DISPLAY=:1, not an SSH-forwarded one), including standard camera angles and three 360-degree sweeps; the doorway is fully clear from every angle, both ON AIR door panels rest symmetrically at the frame's sides, with no leftover broken faces, floating geometry, or material misalignment

📋 Technical Logs

Logs recorded during command execution or automated test verification:

📄 camera_smoothing_walkthrough.txt (logs/camera_smoothing_walkthrough.txt)

Click to expand

HubCamera.gd follow-distance fix — instrumented walkthrough (real gameplay
follow camera, scripted player walking north through the ON AIR doorway).

Before the fix, SpringArm3D's own built-in collision response snapped
spring_length to the raycast hit distance within a single physics frame.
The invisible camera-only threshold plate at the doorway sits where the
player themselves walks through, so the instant they crossed it the
follow distance fell from ~3.4m to near-0m in one frame, then crawled
back out over the next few meters -- reads exactly like hitting an
invisible wall even though movement itself was never blocked.

After the fix (manual raycast + asymmetric lerp: fast pull-in near a
wall, slower release), the same walkthrough shows a smooth dip and
recovery instead of a snap:

walkthrough frame=6  player_z=10.38 arm_len=1.67
walkthrough frame=12 player_z=9.07  arm_len=0.86   <- tightest point, at the threshold
walkthrough frame=18 player_z=7.60  arm_len=1.73
walkthrough frame=24 player_z=6.14  arm_len=3.04   <- back to normal follow distance

Verified via godot --path . --rendering-driver opengl3 (llvmpipe software
rendering), Tool_HubScreenshot.tscn with an added diagnostic walkthrough
pass (not committed to the tool script -- reverted after use).