nx_glbnorm_lib.nx

nx_glbnorm_lib.nx -- ONE OWNER for EMITTING A SPEC-CORRECT UNIT NORMAL INTO A glTF NORMAL ACCESSOR. WHY THIS EXISTS, MEASURED RATHER THAN ARGUED (2026-08-25). Every .glb this estate publishes was invalid per glTF 2.0. KhronosGroup/glTF-Validator 2.0.0-dev.3.10 -- the specification body's own reference implementation -- run under node over all 18 .glb files fetched from https://nishifamily.com by curl (third-party client, third-party TLS, separate host), uncapped (maxIssues 0), returned: files=18 clean=0 with_errors=18 threw=0 sum=18 -> 33,682 errors of which ACCESSOR_VECTOR3_NON_UNIT x 33,656 -- every NORMAL emitted by nx_gltf_export sat at ~1000 scale (worst report: "not of unit length: 999.7844767748697") where the specification requires unit length. The other 26 are three unrelated signatures in six files, recorded in the gate header. THE BUG'S JUSTIFICATION WAS A COMMENT, NOT A MEASUREMENT. Two files asserted that "renderers re-normalise" -- nx_gltf_export.gl_vnormals and the nx_vnormals_lib header. The validator ranks it an Error, not a warning. SIX of our own gates ran GREEN over this code and none could see it, because every one of them measured our code against our own expectations. The referee's rule is a single line, read out of its own shipping bytes rather than recalled: if (Math.abs(Math.sqrt(r) - 1) > 0.00674) -> ACCESSOR_VECTOR3_NON_UNIT so the bar is an ABSOLUTE tolerance of 0.00674 on |length - 1|. GN_TOL_FP below is derived from it. WHERE THE FIX BELONGS, AND WHERE IT DELIBERATELY DOES NOT. vn_smooth_area (nx_vnormals_lib) is the shared owner of smooth per-vertex normals and emits at VN_SCALE = 1000. That scale is NOT the defect: it also feeds nx_obj_export, where OBJ importers rescale and no specification is violated. Rescaling the shared owner would silently change a proven artifact and the 18/18 gate that pins it, to fix a violation that exists only at the glTF write site. So the normalisation lives HERE, at the write site, and vn_smooth_area is left exactly as it is. THE ARITHMETIC IS EXACT, NOT APPROXIMATE, AND EVERY CONSTANT BELOW IS DERIVED. Dividing by 1000 is not representable in binary32. Dividing by a POWER OF TWO is a pure exponent subtraction and is exact, so a normal is rescaled to length 2^GN_K and emitted as the rational m / 2^GN_K, which vm_int_to_f32 encodes with no loss at all. GN_K = 23 MAXIMAL. Every emitted numerator satisfies |m| <= 2^GN_K * (1 + 1/lq) < 2^24, and every integer below 2^24 is exactly representable in binary32. GN_K = 24 is not. GN_M = 18 MAXIMAL for the envelope below. The root is taken at 2^GN_M extra bits of precision, lq = floor(2^GN_M * sqrt(s)), which needs s << 2*GN_M to fit i64: s <= 3 * GN_IN_MAX^2 = 50,331,648, and 50,331,648 << 36 = 3.46e18 < 2^63 = 9.22e18. GN_M = 19 overflows. Without this refinement the floor of a plain integer root would contribute a relative error near 1/1000 -- three orders worse than everything else here, and the single largest term in the budget. GN_IN_MAX = 4096 A MATCHED PAIR WITH GN_M, not an independent choice. It must admit both producers unreduced -- VN_SCALE 1000 and tm_vnorm's fx4096 -- and 4096 is the largest power of