CultLib/docs/research/span-chain-and-site-field.md

Facts for cultmath-tapes:question:span-chain-shape and cultmath-tapes:question:site-ground-field (2026-10-14)

Eyes, read only. Tags: [src] primary source text read (paper or code); [doc] vendor or library documentation, or a committed CultLib doc; [web] web summary, second-hand where noted (WebFetch/WebSearch summarisers, not the paper text); [abs] derived by reasoning, not a measurement. Not repeated here: docs/research/integration-native-noise-domain.md, culling-efficiency-oracle-prior-art.md (its section 3 already carries Keeter MPR, Heidrich 1998, Gamito and Maddock 2007, Knoll Tables 1-2 fps ratios, Sharp and Jacobson, Mitchell timings), tape-register-model.md (Fidget and MPR tape, allocator, interpreter overhead). Raw downloads and pdftotext output: w/ beside this file (not meant for commit).

Part A. span-chain-shape

A1. Taylor models and Taylor forms (Berz, Makino; Neumaier's review)

• [src] Neumaier, Taylor forms: use and limits (2002, https://arnold-neumaier.at/ms/taylor.pdf, read via pdftotext). Taylor forms "compute recursively a high order polynomial approximation to a multivariate Taylor expansion, with a remainder term that rigorously bounds the approximation error" (section 1). Storage and work are proportional to C(n+d, d) coefficients for degree d in n variables, times the number of arithmetic operations. Centered forms are "the degree 1 case of Taylor forms".
• [src] Same, section 1: "Rigorous multivariate Taylor arithmetic with remainder, for the four elementary operations and composition exists at least since 1984 (Eckmann et al.)". Composition gives "arbitrary analytic standard functions for which polynomial enclosures with error bounds are available" (section 3). Berz's group popularised the variant named Taylor models from 1996; COSY INFINITY is the implementation. Two coefficient conventions: Eckmann et al. use narrow interval coefficients with a norm-bound remainder; COSY uses floating-point coefficients plus an interval remainder.
• [src] Same, section 3: first-order Taylor models "are a simplified version" of slope-based centered forms in which "the width of the linear coefficients is moved to the remainder term"; "comparisons between first order Taylor models and the mean value form ... are not available". Slopes are more accurate than simple Taylor-form implementations because of the subdistributive law.
• [src] Same, section 4: interval evaluation has linear approximation order; centered forms have quadratic approximation order (overestimation proportional to box width squared) "under mild conditions excluding near-singular cases". Near stationary points a Taylor form of narrow intervals "suffers from the same problem as other centered forms".
• [src] Same, section 3: "Over sufficiently wide boxes, the Taylor form shares the fate of any centered form, that it usually gives a large overestimation and may even be poorer than naive interval evaluation. It is not designed for such applications".
• [src] Same, section 7: three overestimation sources: wrapping (depth of the computational graph, "long sequences of nested operations depending on a limited number of variables only"), cancellation, dependence. "The amount of wrapping is related to the level of nestedness, i.e., the depth of the reduced computational tree obtained by combining linear combinations into single nodes", but the size and sign of the coefficients decide how much occurs; a complete analysis is "possible only for well-structured simple cases".
• [src] Same, section 11, worked example f(x)=1/(1-x) - 1/(2-x) ... at x=[-r,r]: naive interval radius 5r/4+O(r^3); centered form 3r/4+9r^2/8; arbitrary-order Taylor expansion gives radius 3r/4+7r^2/16, "marginal additional improvement factor of 1-11r/12 only". Neumaier's reading: when the quadratic approximation property is already effective, higher order gives little; check the computable overestimation bound (his Theorem 8.1) against the width and raise the order only if it is too large.
• [web] (second-hand, via search summary of Makino's 2004 slides, https://rec.ce.gatech.edu/rec2004/presentations/Makino.pdf, not read in full) If the remainder bounds of f and g are O(h^(n+1)) then those of f+g and f*g are too; intrinsic functions are composed from binary operations plus an extra interval whose width scales at least with the (n+1)-st power of a bound B of a function that scales at least linearly with h; hence order n+1 scaling survives composition.
• [web] (second-hand) Caltech paper https://resolver.caltech.edu/CaltechAUTHORS:20130919-113604950 ("Convergence analysis of Taylor models and McCormick-Taylor models"): proves convergence order of q-th order Taylor models is at least q+1 for addition, multiplication and composition under mild assumptions; the summary says the bounds are verified sharp on simple numerical examples. That paper is on McCormick-Taylor variants, so constants may differ from COSY's.
• [web] (second-hand) The remainder interval in validated ODE integration "can never decrease", so the dependency impact grows with integration steps; shrink wrapping and preconditioning are added for that (Neumaier section 13-14 discuss wrapping in discrete dynamical systems and ODE enclosures, [src], not applicable to a feed-forward chain except as the definition of wrapping above).
• [src] Streeter and Dillon, Automatically Bounding the Taylor Remainder Series (arXiv 2212.11429v3, abstract read): takes a function in symbolic form built from known atomic functions, a reference point, a trust region and an order k; derives sharp polynomial bounds on the remainder of exp, log, etc.; "combines those bounds through the function's composition" with "an interval arithmetic variant of Taylor-mode automatic differentiation". Open-source JAX implementation. The abstract page gives no comparison against interval arithmetic or Taylor models and no benchmark numbers.
• [abs] The Span Lab's per-span model (linearise the chain, bound the error with 0.5 K h^2, K from a chain of speed, acceleration, Jacobian and second-derivative bounds; map Pass 8) has the structure of a first-order Taylor model with a Lagrange-form remainder from a second-derivative bound. Its remainder order is h^2, equal to the "quadratic approximation order" Neumaier states for centered forms. [doc] for the lab's construction: F:\Projects\eureka-handoff-aux-2026-10-14\eyes-nebula-labs\facts.md section 1a and docs/cultmath-interval-ground-cut.md Pass 8.

A2. Mitchell 1990, Knoll et al. 2009, Gamito and Maddock: how a chain is represented

• [src] Mitchell, Robust Ray Intersection with Interval Arithmetic (Graphics Interface 1990, pp. 68-74, https://graphicsinterface.org/wp-content/uploads/gi1990-8.pdf, pdftotext read). The surface is a ray-substituted one-variable function f(t)=F(S+tD). The test is a three-valued root inclusion ("yes", "no", "maybe"; bisect on "maybe"): Step 1 evaluate the interval extension of f, no zero means no root; Step 2 evaluate the interval extension of the derivative, no zero means monotonic, so refine by a standard method; Step 3 both contain zero, bisect; Step 4 stop at machine-accuracy width.
• [src] Same, section 3: "Given an expression F(x,y,z) in symbolic postfix form, a simple interpreter can compute an interval evaluation. By application of the chain rule for differentiation, the value of grad F can be computed concurrently." Derivative of f is the interval extension of D . grad F. Monotonic functions have trivial interval extensions (e^[a,b] = [e^a, e^b]); abs is [0, max(|a|,|b|)]; sine and cosine use known extrema locations to give "exact upper and lower bounds". Division must return [-inf, inf] when the divisor interval contains zero (superquadric |x|^0.75 has a derivative singularity at 0). Rounding: single precision was "sufficient" for the images; outward rounding is "safer but more computationally expensive". So the chain is one compiled postfix expression, value and gradient bounds computed together, with bounds per elementary node.
• [src] Knoll, Hijazi, Kensler, Schott, Hansen, Hagen, Fast Ray Tracing of Arbitrary Implicit Surfaces with Interval and Affine Arithmetic (CGF 28(1), 2009; https://www.sci.utah.edu/~knolla/cgrtia.pdf, pdftotext read): the user supplies an implicit function in text; "we use a simple recursive-descent parser to generate these routines in the output Cg shader": one routine for f and one for its inclusion function (interval or affine extension), generated by shader metaprogramming and compiled as one shader. "Because the shader compiler identifies common subexpressions, [inline code] is seldom necessary for improving performance" (section 5.1). Whole expression as one generated function, not stage functions.
• [src] Same: GPU algorithm is stackless interval bisection with a fixed per-ray maximum depth derived from a user precision epsilon; benchmarked at 1024x1024 on an NVIDIA 8800GTX (GPU) and a 4-core Xeon 2.33 GHz (SSE). RAA "generally 1.5-2x faster than interval arithmetic" for moderate cross-multiplication, "3 to 4 times faster" for high-overestimation forms (Barth decic, Horner forms); IA stays "far more efficient for superquadrics" because of an efficient integer-power rule; "IA is currently required for extensions of division, transcendentals, and fractional powers" (section 5.4 as cited). Quality: "RAA generally converges far more quickly than IA, given lesser bound overestimation at low epsilon"; RAA "has worse numerical conditioning" than IA.
• [src] Same, section 6.1.3 text: GPU implementations of the Mitchell algorithm (interval evaluation then Newton-style refinement) "perform far worse than naive bisection, particularly at higher epsilon", attributed to "the high cost of evaluating the gradient interval, and both worse instruction-level coherence on the GPU and spatial coherence in the SSE CPU algorithm"; interval Newton and quasi-Newton variants "empirically suggested far worse results" on the SIMD CPU implementation. The paper's Table 1 figures (e.g. Mitchell surface IA 63/34/19/13 fps vs RAA 80/64/59/56 fps across four epsilon values; Barth decic IA 29/13/7.1/4.9 vs RAA 25/19/17/16) are in the figure caption region of the extracted text; the table layout is mangled and I did not re-derive the row mapping.
• [doc] Already committed: Gamito and Maddock 2007 (noise ray casting, reduced affine arithmetic, evaluations per ray) in culling-efficiency-oracle-prior-art.md section 3. The Gamito paper https://eprints.whiterose.ac.uk/id/eprint/3562/1/gamito4.pdf (downloaded, 10 pages) describes procedural noise as "a sum of kernel functions ... that depend on the displacement vectors between x and the node points", each evaluated in affine arithmetic; I did not find a warp chain in it.
• [src] Zanni, Synchronized-tracing of implicit surfaces (arXiv 2304.09673, text read in part): states two representations of a field expression on GPU: "function calls directly hard coded inside a shader ... good performance can be achieved for reasonable size expressions at the expense of shader recompilation each time the expression is modified", versus the expression as data with an interpreter (post-order tree, Grasberger 2016; tape for an arithmetic DAG, Keeter 2020). It uses node-level interpreters rather than a math-expression interpreter: they "decrease the number of switch executions and require less storage of data" and "can support fully procedural nodes", at the price of a more complex shader that needs recompiling if the primitive/operator family changes. Its blobtree has "space deformation moved to the leaves (our implementation only supports rotation and translation of primitives)". It restates that Hart's sphere tracing uses a Lipschitz bound, and that Segment tracing (Galin et al. 2020) uses "directional Lipschitz bound on ray subintervals", with a variant for deformed surfaces (Seyb et al. 2019).
• [web] (abstract only; the paper PDF at diglib7.eg.org returned an HTML login page to curl) Galin, Guerin, Paris, Peytavie, Segment Tracing Using Local Lipschitz Bounds (CGF 39(2), 2020, pp. 545-554, https://diglib.eg.org/handle/10.1111/cgf13951): computes the Lipschitz bound locally over a ray segment; "describe the computation of the Lipschitz bound for different operators and primitives"; reports significantly fewer field-function queries than previous methods without extra acceleration structures; no figures in the abstract. I did not read its per-operator rules.

A3. Keeter MPR and Fidget: stage functions vs one compiled tree

• [doc] Already committed in tape-register-model.md section 1: MPR and Fidget evaluate the whole shape as one flat clause tape (clause = opcode plus output slot plus up to two input slots), interval arithmetic over the tape picks min/max branches and records choices, then the tape is shortened per tile (6056 clauses to a mean of 356 in 64^2 tiles and 28 in 8^2 subtiles; culling-efficiency-oracle-prior-art.md section 3). Interpreter overhead versus a compiled kernel about 19x (58 ms/MP vs 3 ms/MP) on the 6056-clause model. Fidget main branch: wgpu interpreter does not support register spills.
• [doc] culling-efficiency-oracle-prior-art.md section 3 also records Keeter's text that many smooth blends "lead to less useful interval evaluation results" (MPR section 5) and that reduced affine arithmetic is named as a way "to more tightly bound intervals" (section 6).
• [abs] None of the sources read for A1-A3 evaluates a chain of nested warps of noise. In every one, the chain is one expression (postfix in Mitchell, generated shader code in Knoll, flat tape in MPR/Fidget) and bounds come from per-node rules; no source reads as exposing "stage with its own bound" as a unit of composition except Zanni's node-level interpreter (blobtree nodes) and Segment tracing's per-operator Lipschitz rules (abstract only).

A4. Closed-form span integration and pre-integration (Engel 2001)

• [src] Engel, Kraus, Ertl, High-Quality Pre-Integrated Volume Rendering Using Hardware-Accelerated Pixel Shading (HWWS 2001, pp. 9-16, https://www3.cs.stonybrook.edu/~mueller/teaching/cse616/engel.pdf, pdftotext read). The per-segment opacity and colour between a front sample sf and back sample sb over segment length d are precomputed into lookup tables of three parameters (sf, sb, d); the tables depend on the transfer function so "any modification of the transfer functions requires an update of the lookup tables" (section 3.5). Reductions: assume a constant segment length (2D table in sf, sb; "a good approximation for most perspective projections"), or approximate the d dependence as linear; local transfer function change recomputes only entries with sf <= s <= sb or the reverse; and the integral can be accelerated by cumulative integral functions (so each table entry is a difference of two 1D integrals). The paper states an analytic evaluation of the volume rendering integral "is possible in some cases, in particular for linear interpolation and piecewise linear transfer functions", "not feasible in general". Test hardware GeForce3 64 MB; the tables are lookups in the pixel shader.
• [src] Same: the sampling of the scalar field along the ray is decoupled from the transfer function, so the Nyquist limit of the scalar field alone applies ("the Nyquist frequency for this sampling is not affected by the transfer functions"); the segment between the two samples is treated through the table, with the scalar assumed varying between sf and sb.
• [web] (second-hand) Rottger et al. 2003, https://diglib.eg.org/items/99a1d638-d8c8-4ad9-bd8d-1c041524c3e2 ("Smart Hardware-Accelerated Volume Rendering"): cited by a search summary for oversampling needed even with pre-integration; not read.
• [abs] Engel's pre-integration is exact for the integral of the transfer function composed with the assumed in-segment interpolant of the scalar; the error against the true field is the interpolant error over the span (the thing the Span Lab's 0.5 K h^2 bounds). Engel's quantity that is tabulated is a function of the span endpoints' scalar values; the Span Lab's closed form is the clamp of a linear function integrated exactly (map Pass 8 integral_clamp_linear).

Part B. site-ground-field

B1. WebGL2 constraints for splat and kernel rendering

• [web] (search summary) WebGL2 has no compute shaders and no storage buffers; GPU sorting must be emulated by transform feedback or render-to-texture passes. Bitonic sort passes: "1/2 (log^2 n + log n)" passes, arithmetic heavy (a 2004 GPU particle engine paper, https://www.cs.cit.tum.de/fileadmin/w00cfj/cg/Research/Publications/2004/GPU_Particle_Engine/uf_sig04_slides.pdf, not read). A texture-based sort library's capacity is "max texture width squared", example 4096^2 = 16,777,216. I found no WebGL2 GPU radix sort implementation or measurement in this pass.
• [web] Splat viewers in practice sort on the CPU in a worker and read order back to the GPU. antimatter15/splat (https://github.com/antimatter15/splat, README fetched): "splat sorting is done asynchronously on the cpu in a webworker", sort at roughly 4 fps while render is 60 fps, about 150 ms to sort about 1M splats on the author's machine, WebGL 1.0 "WebGL 2.0 adds nothing essential", demo about 1M splats; artifacts appear "when jumping between camera orientations on opposite sides, because the sort hasn't caught up". The author tried order-independent approaches: stochastic transparency looked grainy, weighted blended OIT "didn't work".
• [doc] Spark (World Labs, three.js, WebGL2; https://sparkjs.dev/docs/system-design/ and https://sparkjs.dev/docs/performance/): each viewpoint "reads back a list of all splat viewpoint distances from the GPU, then determines the splat draw order using an efficient bucket sort algorithm, run in a background worker thread", drawn in one instanced call, "the sort order lags the render by at least one frame, but possibly more on older devices" (search summary of the system-design page; a launch post says "two-pass radix sort in a Web Worker", sources disagree). Budgets (performance page): Quest 3 1M splats or less; Android phone 1-2M; iPhone 1-3M; computer 1-5M. Splats "must be blended back-to-front, which is the main reason rendering is demanding on mobile GPUs"; each splat is two triangles covering a Gaussian out to sqrt(8) standard deviations; ~1M splats make the per-splat transform overhead (SplatAccumulator) a bottleneck on some systems; "500K splats from a Trellis object at small screen scale can bottleneck GPU rendering and blending". antialias should stay false; high pixel ratio costs blending throughput.
• [web] (search summary, PlayCanvas docs) default renderer sorts on the CPU in a worker; the GPU sort path is "experimental, and WebGPU only"; WebGL devices fall back to CPU sorting. A mobile 3DGS paper summary (https://arxiv.org/pdf/2511.16298) states sorting "dominates the computations in 3DGS on mobile platforms"; not read.
• [src] EXT_float_blend (Khronos registry, https://registry.khronos.org/webgl/extensions/EXT_float_blend/): without it, blending with a 32-bit float draw buffer is INVALID_OPERATION; with it, drawing to 32-bit float buffers with blending enabled is allowed. The page does not address 16-bit float blending. EXT_color_buffer_float (.../EXT_color_buffer_float/) makes RGBA16F, RGBA32F and R11F_G11F_B10F color-renderable and says output is not clamped; the page does not address blending. [web] Esri (https://www.esri.com/en-us/software-engineering/blog/articles/support-for-transparency-and-emissive-materials-on-limited-webgl-devices): their float OIT needs EXT_float_blend, "not available on a significant subset of iOS devices"; float buffers cost 30 bytes/pixel for transparency plus emission, "about 110 MB on an 11-inch iPad"; their fallback "OIT8" packs accumulation into RGBA8 fixed point (each fragment divided by 16 on write, multiplied on composite): range 0-16, about 4 bits of precision per fragment, banding hidden by dithering, values overflow toward white after roughly 16 overlapping surfaces, emission capped at 16. No frame-time figures. I did not find a device-population percentage for EXT_float_blend or EXT_color_buffer_float (webglstats pages returned blog index text).
• [web] Weighted blended OIT (McGuire and Bavoil 2013): two accumulation targets (accumulated premultiplied colour*weight and alpha product/revealage) plus a composite; sources describe it as order-independent, bounded memory, approximate ("fragment colors and depths are combined approximately", luma.gl docs; "not physically correct", Open CASCADE write-up). Cesium: needs only MRT and float textures. One third-party engine note reports poor handling of near-opaque layers (single report). Not read from the paper.
• [web] Depth peeling (Everitt 2001): one geometry pass per layer; dual depth peeling N/2+1 passes; multi-layer depth peeling "up to 8x speed-up ... at the price of several MRT buffers". The only WebGL material found was a 2012 WebGL1 thread (no MRT, no MIN/MAX blend) and no WebGL2 measurement.
• [web] Moment-based OIT (Munstermann, Krumpen, Klein, Peters, I3D 2018, https://momentsingraphics.de/I3D2018.html, https://cg.ivd.kit.edu/mboit.php, abstract and teaser read): works on the logarithm of transmittance so contributions sum additively; a first additive pass builds 4/6/8 power moments or up to 4 trigonometric moments; a second additive pass composites; storage 112 bits per pixel (six power moments) or 224 bits (three trigonometric); Peters' postscript notes half memory with rasterizer ordered views (not WebGL2). No WebGL2 port found. [web] Moment-based 3D Gaussian splatting (arXiv 2512.11800, summary read): order-independent, no sorting, two additive passes (moments, then quadrature of radiance) plus normalisation; trained with Vulkan/Slang, not WebGL; PSNR below sorted 3DGS on all three datasets (e.g. MipNeRF-360 25.96 vs 27.43) though qualitatively better on translucent overlaps per the authors; no frame rates reported.

B2. 3DGRT and EVER

• [web] 3DGRT, Moenne-Loccoz et al., 3D Gaussian Ray Tracing (arXiv 2407.07090, HTML fetched through a summariser, first 100 000 of 123 271 characters): BVH over particles each wrapped in a regular icosahedron (20 triangles) scaled to where response exceeds alpha_min = 0.01, hardware ray tracing; the any-hit program keeps the k = 16 closest hits by insertion, shaded in batches; hit ordering uses the bounding-primitive intersection distance, sample point is the analytic maximum along the ray. Table 2, one RTX 6000 Ada, fps: 3DGS 238 / 319 / 267 (MipNeRF360 / Tanks&Temples / Deep Blending); 3DGRT reference 55 / 143 / 77; 3DGRT 78 / 190 / 119. The text calls forward rendering "only about 2x" slower while the table implies about 3x to 4.3x. BVH build above 30 ms per million particles for icosahedra (Figure 9); training about 5x slower per step; memory 383 / 489 / 287 MB vs 3DGS checkpoint 763 / 422 / 704 MB. Generalised kernels (degree n=2... "generalized Gaussians") roughly double speed (277 vs 143 fps on Tanks&Temples). Limitations: slower than rasterisation for pinhole cameras, BVH rebuild for dynamic scenes, no automatic antialiasing, stochastic sampling prevents SSIM losses.
• [web] EVER, Mai et al., Exact Volumetric Ellipsoid Rendering for Real-time View Synthesis (arXiv 2410.01804, HTML fetched through a summariser): constant-density ellipsoids each with a single (view-dependent) colour; between consecutive ray intersection points colour and density are constant so the volume rendering integral is evaluated in closed form; overlap handled by tracking running density and premultiplied colour totals as the ray enters and exits each ellipsoid; per-ray sorting via NVIDIA OptiX BVH (rebuilt each training step, 2-20 ms), multi-hit queue borrowed from 3DGRT. RTX 4090 at 720p unless noted: about 36 fps Mip-NeRF 360 outdoor, 66 indoor, 30 Zip-NeRF; at dataset test resolution 36 / 24 / 44 fps vs 3DGS 224 / 559 / 560; tracing 20-71 ms per frame; "about 10x slower than 3DGS and uses more memory"; densification cap 7M primitives. Model is emission and absorption only, no scattering; popping metric LIP7 0.0 vs 0.0315 for 3DGS on Tanks&Temples. Anisotropic rotated ellipsoids enlarge their bounding boxes; an anisotropy regulariser trades quality for speed.
• [web] WebGPU ray tracing status (search summary, non-authoritative blogs): hardware ray tracing and ray query "not yet part of the WebGPU specification, though proposals exist"; no browser shipping it found; a software compute-shader tracer exists (WebRTX, Chrome-tested, unstable spec). No WebGL2 route to either 3DGRT (OptiX/RT cores) or EVER.
• [doc] The committed probe's kernel cascade is a CPU C# ray walker (hash grid, Amanatides-Woo DDA, early exit at sum of tau >= 7) over compact-support kernels with closed-form line integrals (integration-native-noise-domain.md, sections "Composition" and "Measurements"). Its measured cost ratios are CPU single-thread ratios against the march, same run: void L2 0.48x, L3 1.24x, L4 1.81x, L6 2.57x of the march cost; wells L2 0.23x, L6 1.20x; integrals are about 0.4 us of a 74 us pixel and traversal dominates (93 roots visited for 8 hits at L6). Kernel Lab page (c09d2762) is described in eyes-nebula-labs/facts.md section 1b: budget KBUDGET 420000 kernels and IDXCAP 4096*3072 bin entries, two-phase crossfade (2 copies per kernel). This pass found no WebGL2 measurement of either field.

B3. Comparison basis: marched procedural field (span framework) vs kernel cascade, orbiting-camera backdrop

• [doc] Site constraints from the file-era spec (F:\Projects\CultLib\docs\cultmath-interval-ground-cut-site-ground.r3.spec.json, never run): fullscreen WebGL2 backdrop behind the masthead; sun orbit period 72 s, camera follows low inside the hollow; half-float history for TAA; shared fallback path for "slow device, hidden tab, reduced motion, missing WebGL2 and missing half-float"; per-frame sample cap S_budget and a controller that adapts S and dpr to measured GPU ms; the operator-verification list includes the phone ("read the logged GPU ms per pass and the controller's final S/dpr; say whether it got warm after five minutes"). The CSS wash is the stated fallback ground. gamecult-site origin/main af6e206: no ground shader, no vendored CultMath GLSL (map Pass 8).
• [abs] Per-frame cost scaling. Marched field (full-screen fragment work): cost ~ pixels x samples per pixel x field cost per sample; the Span Lab replaces fixed steps by spans, so samples ~ spans per ray, each span a chain evaluation (value, Jacobian, bound) rather than one field sample (the lab's maxSpans cap 8..1000, default 400; its tol controls span count; facts.md section 3). Cost is independent of any scene object count, so fill rate (pixels x dpr) is the knob; the r3 spec scales dpr and S. Kernel cascade as rasterised splats: vertex work ~ kernel count K (sort and transform, Spark: ~1M is a bottleneck on some systems), fragment work ~ sum over kernels of covered pixels (overdraw ~ kernels per pixel x pixels; the probe's CPU walk saw 20-36 kernels per pixel at L2-L6 on the void), blend traffic on a float target per fragment (16F or 32F per B1). Cost scales with detail level (kernels per level multiply in the cascade: 8, 12, 8, 7), the frame knob is kernel LOD plus resolution scale.
• [abs] Memory. Marched field: no per-scene geometry; state is uniforms (the lab's SPEC has about 60 scalars), a 4 Rw flow texture in r3, TAA history textures (colour, transmittance, depth), pre-pass mask. Kernel cascade: per-kernel record (the lab bakes centre, axes, peak, tint, flow vector, children indices; eyes-nebula-labs/facts.md section 1b), caps in the lab: KBUDGET 420 000 kernels; GPU upload as textures or instance buffers; plus the sort/order buffer if emission is order-dependent and any OIT accumulation targets.
• [abs] Authoring model. Marched / span framework: authored field is a function (brushes, ramp, warp chain with parameter block) evaluated per point or span; edits are parameter changes with no rebuild; bounds must be derivable for each stage or the span evaluator is blind (Part A). Kernel cascade: authored as generator parameters (levels, children, keep, asp, rot, seed) that rebuild the kernel set on CPU on change ("Cascade items trigger rebuild", Kernel Lab SPEC); the set is explicit data, so the same data can be exported and no per-pixel bound derivation is needed, but fibrous look is the cascade's own ("fibrous look, cannot be marched" per the question text) and a field defined by a function (e.g. a warp chain) has no kernel representation in these sources.
• [abs] Transmittance and emission under additive blending (reasoning, not tested). For absorption only, T = exp(-sum_k tau_k), where tau_k is the closed-form line integral of kernel k along the pixel's ray; a sum is order independent, so additive blending into a float or fixed-point target gives T exactly up to precision (B1 notes: 32F blend needs EXT_float_blend, which is absent on some iOS devices; 16F blending is not addressed by the two Khronos pages read; RGBA8 fixed-point packing overflows after about 16 overlaps in Esri's scheme). Emission integral of e(t) T(t) along the ray depends on T at each depth, so ordered compositing is needed (sorted splats, or OIT approximations: WBOIT, moment OIT, depth peeling at N passes) or a single-scatter approximation that drops the T(t) factor. EVER (B2) is the cited exact treatment of this ordering problem, by per-ray sorted traversal with RT cores.
• [abs] Neither approach in B2 sources has been run in WebGL2 in this pass. No fps number in this file comes from a WebGL2 run.

Gaps

• Taylor models: no primary Makino-Berz composition theorem text read (only Neumaier's review, search summaries of Makino's slides and the Caltech convergence paper); no remainder-growth-per-stage numbers for a chain of noise-like functions found; no graphics paper using Taylor models for ray marching found.
• Knoll Table 1 row mapping not re-derived; Galin et al. per-operator Lipschitz rules and query counts not read (PDF behind login to curl); Fidget/MPR chain composition covered only by the committed doc; no source found that composes bounds across warp stages of noise.
• WebGL2: no device-share numbers for EXT_float_blend, EXT_color_buffer_float or 3D texture size; no WebGL2 GPU radix sort source; no WebGL2 depth-peeling or WBOIT measurement; 16F blending support not confirmed from a spec page; 3DGRT and EVER read through summarisers (EVER and 3DGRT HTML not read to the end).
• No WebGL2 measurement of the Kernel Lab or the Span Lab on a phone exists in the sources read; comparison part B3 is [abs] plus the CPU ratios in the committed probe doc.