nx_fbx2nxa.nx

nx_fbx2nxa.nx -- binary FBX GEOMETRY -> NXANIM01 (VERT + TRIS). The missing first half of the FBX rig ingest: nx_nxa_skin <in.fbx> <in.nxa> <out.nxa> fills SKEL+SKIN but requires an in.nxa that already carries the mesh, and NOTHING produced one from an FBX -- fbx_read (nx_fbx_import, the consolidated geometry reader) had exactly ONE caller and it was a probe that prints counts. This organ is the second caller the consolidation was built for: fbx_read -> NXA writer, in the exact section shapes nx_nxa_skin copies and nx_asset_floor_gate reads. usage: nx_fbx2nxa <in.fbx> <out.nxa> exit 0 OK | 2 usage | 3 unreadable/not-FBX | 4 no-geometry | 5 multi-geometry (refused BY NAME) | 6 write-failed UNITS, stated not guessed: fbxc_f64_fx returns value x 1024 (the lib's contract, its comment); the FBX native unit is the CENTIMETRE (FBX SDK convention; Fab/UE exports ship cm). NXA VERT is 0.01 mm (spec correction seq1285), so one cm = 1000 VERT units and the conversion is fx * NXA_UNITS_PER_CM / FBXC_FX_SCALE. The receipt prints the measured height in mm so a donor authored in some other unit is VISIBLE in one glance instead of silently wrong; and the axes the rig floor grades (counts and ratios) are unit-independent, so a mis-united donor still counts its joints correctly. UnitScaleFactor parsing is deliberately deferred until a donor measurably needs it -- deferring is stated here, not hidden. MULTI-GEOMETRY IS REFUSED BY NAME, not merged wrong: fbx_read keeps the LARGEST Vertices array but ACCUMULATES triangles across every Geometry node, and those indices reference each node's OWN vertex space -- concatenating them against one vertex array is a shredded mesh with plausible counts (the exact failure shape the import lane keeps meeting). One Geometry node is the honest v1; the refusal names the count so the donor can be re-exported merged. license_tier: ORIGINAL No hw writes (Rule 26). expect_exit: 0