nx_mesh.nx

nx_mesh.nx -- typed 3D mesh container. L1 canonical primitive. Closes a bits-up gap: graphics stack (nx_raster + nx_zbuf + nx_tex_sample + nx_vertex_pipeline + nx_render_pass) operates on RAW i64 arrays for vertices, UVs, and triangle indices. No typed envelope. Per the bits-up canonical-layer cardinal, that's a missing L1 container -- every graphics consumer should compose against `NxMesh` rather than re-deriving the layout convention each time. Same role for graphics that NxTensor plays for compute and Image plays for pixel buffers. ===== Layout convention ========================================= verts: [n_verts * 4] i64 per-vertex: (x_q14, y_q14, z_q14, packed_color) matches nx_vertex_pipeline + nx_voxel_mesh existing layouts so buffers compose directly. uvs: [n_verts * 2] i64 (NULL if mesh has no texture) per-vertex: (u_q10, v_q10) matches nx_tex_sample's Q10 UV convention. indices: [n_tris * 3] i64 triangle vertex indices per-triangle: (i0, i1, i2), counter-clockwise winding for front-face by convention. All buffers caller-owned or substrate-allocated via mmap; the NxMesh struct owns the LIFETIME of any buffers it alloc'd. ===== Why a struct + not just docs ============================== Two callers (nx_render_pass + nx_voxel_mesh) already work with these layouts. Per the rule-of-three + DRY cardinal: factor at 2-and-a-half (one of the existing callers + the new graphics work that wants meshes). The struct also lets us add verdicts at the boundary -- caller can't accidentally pass a 3-vert mesh as if it were 4-vert.