cockpit torso: fix upside-down /torso-live and /torso-map (Y-up rotation)#58
Conversation
/torso-live and /torso-map rendered head-down: the decode used (x,y,z)->(x,-z,y), which the Rust preview driver compensated with a screen-space Y-flip, but three.js uses standard Y-up with no flip -> inverted. Replace with (x,y,z)->(-x,z,y): a PROPER rotation (det +1, so triangle winding + gl_FrontFacing stay correct, no mirror) that stands the body head-up in three.js Y-up (model +Z superior -> +Y up). Applied to all three three.js views (mesh, surfels, map); the preview driver + /torso turntable frames re-rendered to the same orientation so all four agree. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TzqvDqbFRzyx17EkLKBoZF
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
Warning Review limit reached
More reviews will be available in 28 minutes and 30 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (20)
📒 Files selected for processing (3)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…er toggles + transparency Adds MY interactive cockpit viewer, additive to the other session's /torso* (#57/#58 — their TorsoMesh/torso.mesh are untouched; main.tsx gains only one import + one route). - cockpit_bake (new fma bin): bakes the full body → cockpit/public/fma_body.mesh, the same SPM1 wire the cockpit already decodes, but the per-vertex `opacity` byte carries a clean LAYER id (1 skin·2 muscle·3 organ·4 skeleton·5 vessel·6 nerve·7 connective·8 other) instead of a continuous alpha — so each layer can be toggled exactly. Color is the converged `tissue` byte (is_a); geometry is the BodyParts3D is_a OBJ set, vertex-cluster decimated (a Rust port of bake_torso_mesh.py's cluster_decimate). 329K verts, 745K tris. - cockpit/src/FmaBody.tsx (new): loads /fma_body.mesh, renders the solid THREE.Mesh with the same (-x,z,y) upright decode as TorsoMesh (head-up), and a shader that gates each layer via uEnabled[9] (indexed by the vertex layer id) + a global alpha. UI: a button per layer (skin/muscle/organ/skeleton/vessel/nerve) toggling visibility, and a solid↔transparent switch. Skin off by default so the anatomy shows. - cockpit/src/main.tsx: + route /fma-body (additive; /torso* unchanged). - README: fix the v3 image (the removed dot-graph PNG → the skeleton render) and document cockpit_bake + /fma-body. Verified: cockpit `npm run build` (tsc && vite build) is green (102 modules). The live browser render was not exercised in this environment (no browser) — the component mirrors the working TorsoMesh exactly and shares its decode, so it should render head-up on deploy. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GJ4NVBSjq1w5h7RmTbVafb
What
Follow-up to #57 (merged). After #57 landed, the live three.js views rendered upside down —
/torso-live(the filled mesh) and/torso-map(the picker)./torso(the pre-rendered turntable) was fine.Why
The decode rotated the BodyParts3D model with
(x,y,z) -> (x,-z,y). The Rust preview driver (which renders/torso's frames) compensates with a screen-space Y-flip, so its output is head-up. But three.js uses standard Y-up with no such flip, so the same decode renders the body inverted.Fix
Use
(x,y,z) -> (-x, z, y)instead — a proper rotation (det +1):gl_FrontFacingare unchanged, so the mesh's two-sided Phong lighting stays correct (a naive Y-negate would be a reflection and break winding).Applied to all three three.js views (
TorsoMesh,TorsoSplat,TorsoMap). The preview driver and the/torsoturntable frames were re-rendered to the same orientation, so all four views now agree.Verification
tsc --noEmitclean; cockpitnpm run buildgreen.🤖 Generated with Claude Code
https://claude.ai/code/session_01TzqvDqbFRzyx17EkLKBoZF
Generated by Claude Code