nx_vpick_lib.nx

nx_vpick_lib.nx -- DC4 of the /compare/dcc board: RAY-PICK and a TRANSFORM GIZMO for the sovereign browser viewport. nx_meshview_wasm already RENDERS and ORBITS a real indexed mesh through our own software rasteriser compiled to WASM (zero WebGL, zero Emscripten, zero third-party code). Nothing in that viewport can be SELECTED or DRAGGED, so it is a viewer and not an editor. This library is the missing half: turn a click into a triangle, turn a drag into an axis-constrained translation, and hand that translation to the operation stack as an OP instead of writing it into the vertex buffer. THE GIZMO NEVER MUTATES GEOMETRY. vp_gizmo_delta takes no mesh pointer at all -- it cannot write a vertex even by accident -- and vp_apply_drag pushes ES_OP_ADD / ES_OP_RADD onto an nx_editstack_lib stack. That is the whole point of the rung: a drag becomes an entry in the log, so it is undoable, redoable, replayable bit-exactly, and re-evaluable at depth, exactly like every other edit. A gizmo that wrote vertices directly would be a gizmo whose work cannot be undone without a snapshot. CHECK-BEFORE-BUILD. nx_capsearch was asked first (corpus_complete=1 over 6892 tools and 5517 libs) and nx_vpick is absent from the tree (nx_shelltool find, corpus_complete=1 over 61581 files). THREE incumbents were then READ, not guessed, and each is named with the measured reason it is not the answer: * mtk_ray_tri (nx_meshthick.nx) IS a Moller-Trumbore ray/triangle test and is the closest thing the estate had. It works in fx256, it REQUIRES a unit-length direction, it returns ONLY a scalar distance, and it collapses parallel, behind, outside-the-triangle and no-intersection into a single 0-1 return -- a negative answer that cannot say which negative it is. A picker needs the barycentric coordinates (to place a manipulator on the hit), needs to tell a DEGENERATE triangle from a parallel ray, and must not be forced to normalise a screen ray: normalisation costs an isqrt and discards the sub-unit precision a pixel-accurate pick depends on. Its own consumer nx_castview.nx already carries a standing warning about converting Q14 rays into its fx256 scale. * r3_ray (nx_recon3d.nx) back-projects a pixel to a ray, but from a 3x3 BASIS plus a focal length, and normalises the result. The viewport camera is not that model: it is yaw + orbit distance + half-fov through rc_perspective_cs. Feeding one convention's rays to the other camera is how a pick lands on the wrong triangle. * nx_raycast_voxel.nx is DDA traversal of a voxel grid, not an indexed triangle mesh. THE CAMERA CONVENTION IS COPIED, NOT INVENTED. Everything below is the exact inverse of what mv_render_loaded_cam and mv_proj1 do in nx_meshview_wasm: model -> eye eye = T(0,0,-dist) * Ry(yaw) * model (roty exactly as the renderer builds it) eye -> clip rc_perspective_cs(cos(fovh), sin(fovh), w*Q/h, Q, far) clip -> screen sx = (ndcx + 1) * w / 2 , sy = (1 - ndcy) * h / 2 so screen -> model is: undo the viewport map, divide out f = cot(fovh) and the aspect, set eye-space z to -1, then apply Ry(yaw) TRANSPOSED (a rotation's transpose is its inverse) and place the eye at Ry(yaw)^T * (0,0,dist). The trig is rc_sin_q14 / rc_cos_q14 -- the renderer's OWN Bhaskara approximation, COMPOSED rather than re-implemented, so a pick can never drift from the picture it was taken on. The scale unit is RC_Q, imported from nx_render_core for the same reason: one Q in the estate.