7 Commits

Author SHA1 Message Date
xfy
3749ee5691 fix(camera): eliminate gimbal-lock flip by decoupling right from forward
basis() derived `right` from `forward × world_up`, which degenerated to
a zero vector when forward aligned with world-Y (pitch = ±π/2) — the
cross product vanished, normalization produced garbage, and crossing
the pole flipped the image 180°.

Right now depends on yaw alone: Vec3::new(cos yaw, 0, -sin yaw). It is
a unit vector in the y=0 plane for any yaw, so it never goes to zero
regardless of pitch. In the original upper hemisphere (cp > 0) this is
exactly the old value after normalization, so existing views are
unchanged; it additionally stays perfectly horizontal for all pitch,
fixing a subtle roll the cross-product form introduced below the equator.

With the singularity gone, pitch is unclamped from [0.05, π-0.05] to
[-π+0.05, π-0.05]: the camera can now cross both poles and reach below
the disk plane without flipping. The ±0.05 margin only avoids the exact
origin-axis points where forward = ∓Y and yaw becomes meaningless.

yaw is also wrapped to (-π, π] on each drag so it cannot drift out of
the UI slider range (which would snap the view when the slider is later
touched); cos/sin periodicity makes the wrap visually lossless.

The UI pitch slider range is widened to match. Stale "gimbal pole"
comments that described the old restriction are corrected.

basis() still returns (eye, forward, right, up), so the uniform bridge
in plugin.rs and both shaders are untouched.
2026-07-14 16:36:36 +08:00
xfy
699a8c974e ui: use std::f32::consts::PI instead of approximate 3.14 literal
Fixes clippy::approx_constant errors caused by using the hardcoded value 3.14
for camera yaw and accretion disk tilt sliders. Using std::f32::consts::PI
resolves the errors and uses the precise constant value.
2026-07-14 15:09:36 +08:00
xfy
7cb5c2880a feat: add Spin slider + ISCO/Horizon read-only labels 2026-07-14 14:37:10 +08:00
xfy
e158c8c668 feat: wire render_scale via offscreen render-to-texture + upscale 2026-07-14 14:09:39 +08:00
xfy
1e8cd93bc3 fix: keep full-screen quad filled on window resize
The quad mesh was built once at startup with the initial aspect ratio, so
widening the window afterward left empty edges. Add a FullscreenQuad marker
component and a fit_quad_to_window system that rescales the quad's Transform
to the live aspect each frame (only mutating on change).

Also remove the misleading 'Render scale' slider — it isn't wired to a real
sub-resolution render target in Phase 1 (the full-screen quad always renders
at window resolution). Lowering Steps is the real perf lever. Documented in
a code comment for future work.
2026-07-13 10:00:42 +08:00
xfy
7e0ac65d55 feat: full egui control panel + pointer routing 2026-07-13 09:57:54 +08:00
xfy
983413e9af feat: egui UI wired with live disk brightness + steps 2026-07-10 10:54:22 +08:00