nx_gsplat_density_gate.nx

nx_gsplat_density_gate.nx -- ADAPTIVE DENSITY: does adding primitives where the residual asks for them actually reconstruct better, or is it tessellating noise? *** THE ACCEPT RULE, PRE-DECLARED BEFORE THE IMPLEMENTATION WAS WRITTEN *** A before/after comparison is NOT good enough here and the reason is specific: densification changes the primitive count, so "loss fell after densifying" is satisfied by simply fitting longer. The two arms therefore get the SAME TOTAL FITTING BUDGET and differ only in whether density is adapted: ARM A (control): 2*FD_STEPS gradient steps at the starting count, no densification ARM B : FD_STEPS steps, ONE densify, FD_STEPS steps ACCEPT iff lossB < lossA. Densification then has to earn its result against the fitter working equally hard without it -- which is the only comparison that can distinguish adapting density from spending more iterations. *** REACHABILITY IS ASSERTED FIRST, ARITHMETICALLY, BEFORE ANY ARM IS BELIEVED -- AND IT IS TWO *** QUESTIONS, NOT ONE. THIS GATE'S FIRST RED PROVED THAT, AGAINST ITS OWN AUTHOR. v1 built a fixture whose third feature lay BEYOND every primitive's support and asserted exactly that as its reachability tooth. The tooth PASSED and the run came back RED with gmean=0 -- because the gradient is accumulated ONLY over each primitive's own footprint, so a feature that no primitive touches contributes NOTHING to any gradient. The densifier could not feel the residual it was being asked to fix. THE FIXTURE PROVED THE WRONG REACHABILITY, AND THE TOOTH CERTIFIED IT. T0a SIGNAL reachable -- the unresolved detail must lie INSIDE the covering primitive's support, or no gradient carries it and no criterion can ever fire. T0b IMPROVEMENT reachable -- that detail must be separated by more than the information floor of one pixel, or more primitives cannot represent what one cannot. Both are computed from the LIVE conic (gs_splat_rx on the rendered pa), never from a comment. ⚠AND THE UNDERLYING LIMIT IS REAL AND SHARED WITH PUBLISHED 3DGS: densification GROWS primitives where support already exists; it does not DISCOVER regions nothing covers. Those are the business of initialisation (a point cloud), not of adaptive density. Naming it here so the next reader does not re-file this fixture bug as a densifier bug. *** THE ANTI-VACUITY TOOTH, AND THE FAILURE IT IS BUILT FROM *** The sibling gate's T14 v1 asserted only `mv_full > 0` -- a bound ANY number satisfies -- and so it PASSED on a result 46 billion units out. The vacuous-tooth defect, committed inside the gate built to prevent it. The bounds here are ones only a working implementation can meet: T4 out > in -- a "densified" run that silently added nothing FAILS T6 lossB < lossA -- at equal budget; a fit that ends no better than the control has bought nothing, and one that ends WORSE has diverged T7 both at once -- adding primitives without reducing residual IS tessellating noise, so neither half alone is allowed to carry the verdict T6's bound is the CONTROL's own measured loss, not a chosen epsilon -- there is no tunable number in