Files

T

jeremy 854dbb5ce4 chore(agents): migrate to agents.md protocol — .agents/ wiki/plans/rules/skills

Root AGENTS.md is now a thin entry point + knowledge map; the batch-workflow
detail it duplicated already lived in .claude/skills/animation/SKILL.md.
Folded docs/ (dances registry + iclone-bridge stub), root plans/, and
devops-reports/ into .agents/wiki/ and .agents/plans/ per the per-repo .agents/
convention. Added .agents/SOUL.md, .agents/AGENTS.md, wiki/ARCHITECTURE.md,
wiki/architecture/, and wiki/master-plan.md (derived from the closed plans +
the dance registry's live ceremony-slot table). Fixed doc-path references in
exchange/GUIDE.md, the animation skill, and the iclone-bridge stub. All moves
via mv (git detected as renames) — no content deleted.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-07-24 15:02:47 -07:00

2.5 KiB

Raw Permalink Blame History

FIX ROUND: defects found in boat_prop.fbx by independent visual verification

Your self-verify passes but the boat is visually wrong. Renders of your FBX vs a raw import of the source GLB prove two defects. Fix tools/export_boat_prop.py, re-run until BOTH the existing self-verify AND the new checks below pass, then update plans/boat-prop-export-results-2026-07-17.md.

Defect 1 — hull is UPSIDE DOWN

In your export the canoe's carved prows curl DOWN below the waterline and the belly bulges up. Ground truth: bpy.ops.import_scene.gltf on the source GLB already gives a RIGHT-SIDE-UP canoe in Blender's Z-up frame (deck opening faces +Z, prows sweep up). The glTF importer performs the Y-up→Z-up conversion itself — your extra game→Blender axis conversion (the C3 matrix) double-rotates the mesh.

Correct transform chain (nothing else):

Import GLB; apply all transforms (bakes the importer's rotation into vertices).
Rotate about Z only so the bow lies along −Y (raw bow is along +X after step 1).
Scale ×8.5 uniformly; apply.
Translate Z only so min-Z = 0. Do NOT translate or recenter X/Y — the game uses the GLB's own origin (Defect 2).

Defect 2 — hull was recentered on X

The canoe is a SINGLE outrigger (one ama, one side) yet your export's X bounds are symmetric (±2.82) — you recentered by AABB. The game never translates X; keep the GLB's own lateral placement so the hull centerline stays where the seat markers assume it. After the fix, report which side the ama extends to (expect −X, the Seat_Fisher side, if the game-equivalent yaw is right; report honestly if it's +X).

New self-verify checks to ADD (these would have caught both defects)

Right-side-up: the hull's LOWEST vertex (z≈0, the keel) must lie near midships (|y| < 2.0 m), and the hull's HIGHEST vertices (prow carvings) must lie near the ends (|y| > 3.0 m). An upside-down canoe fails both.
Not recentered: the hull mesh's X bounds must be ASYMMETRIC about 0 (single outrigger): assert abs(abs(minX) - abs(maxX)) > 0.5 m.

Verification renders (run these yourself and STATE in the report what you see)

Render workbench snapshots (¾ view + side view) of the final FBX re-imported, e.g. camera at (14,−12,8) looking at (0,0,1.2). The canoe must sit prows-up on the waterline rectangle like a boat, not like a banana on its back.

Everything else from the original plan stands (guardrails §6 included: no commits, ariki-game read-only). The waterline-as-4-named-rails deviation is ACCEPTED — keep it.

2.5 KiB Raw Permalink Blame History Unescape Escape