viewer: slow first-person walk/run/jump speeds

[wass08]

What does this PR do?

Slows down first-person navigation, which felt too fast. Applied identically to both the GLB walkthrough controller (packages/viewer) and the editor's first-person controls (packages/editor) so the two surfaces stay consistent.

• Walk: 4 → 2 m/s
• Run (Shift): 5.5 → 5 m/s
• Jump (jumpVel): 6 → 5 (~1.83 m → ~1.27 m peak)

How to test

1. bun dev and open a scene.
2. Enter first-person / walkthrough mode.
3. Walk with WASD — movement is noticeably slower (2 m/s) and more deliberate.
4. Hold Shift to sprint — clearly faster than walking (5 m/s, 2.5× gap).
5. Press Space to jump — peak is lower (~1.27 m), no longer overshooting low ledges.

Screenshots / screen recording

N/A — tuning of movement constants only, no visual/UI change.

Checklist

• I've tested this locally with bun dev
• My code follows the existing code style (run bun check to verify)
• I've updated relevant documentation (if applicable)
• This PR targets the main branch

---

Note

Low Risk
Only numeric movement props on two first-person call sites; no auth, data, or shared physics logic changes.

Overview
First-person movement felt too fast, so BVHEcctrl tuning is reduced in both the editor street-view controller and the baked GLB walkthrough so behavior stays aligned.

Walk (maxWalkSpeed) goes from 4 → 2 m/s, sprint (maxRunSpeed) from 5.5 → 5 m/s, and jump (jumpVel) from 6 → 5, which lowers peak jump height and makes low ledges easier to clear without overshooting.

^{Reviewed by Cursor Bugbot for commit 36132bb. Bugbot is set up for automated code reviews on this repo. Configure here.}

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
pascal	🔴 Failed	–	Jun 29, 2026, 5:08 PM

💡 Tip: Enable Workflows to automatically generate PRs for you.