The rendering frontier, inside RadianceLab

The earlier Python experiments now have a small C++ research instrument inside RadianceLab. It owns its own progressive CPU film and analytic scene; opening it does not replace or change PPIntegrator, the main GPU path tracer, or an existing saved scene. This is an opt-in native experiment, not a claim that these methods already support the editor's arbitrary meshes, materials, lights, heterogeneous media or every scattering order.

The purpose is practical: compose a recording, inspect how a connection succeeds, then show its failure case. The C++ renderer evaluates transport or visibility anew. It does not replay the old PNGs.

Three experiments

The tri-sheet study is a forward three-scatter path. It is not the separate tridirectional proposal in which a medium subpath is sampled independently and joined to camera and photon subpaths. That more speculative relay remains a browser schematic and research proposal. The distinction matters: the middle leg is real volume transport here, but it is not evidence of a new independent-subpath sampling strategy.

All film passes accumulate with double-precision sums. A render budget controls work per UI update, not the total history. Changing scene, camera, method, medium parameters or geometry resets the film. Cache settings and screen movement also invalidate the cached visibility. Exposure and display glow only change presentation. Raw PFM output keeps signed corrections; it is not clamped or bloomed.

The overlaid path guides show representative topology, not a selected accepted Monte Carlo sample. In the cache study the cyan line is the actual kind of visibility query being cached, not a camera transport leg. The UI labels this explicitly.

Rotational atlas: the same physical ledger

The native port follows physical_suite.py and the physical-suite derivation. A directional point emitter is at the origin, the two volume vertices are

y = t1 b
x = y + t2 c = o + s d

Both distances lie in [0.12, 3.2], all volume vertices lie inside a homogeneous sphere of radius 3.5, and s >= 0. The source and medium use normalized Henyey–Greenstein angular functions. The source angular distribution is an emission model, not an extra scattering event.

The common target is

integral F delta^3(t1 b + t2 c - o - s d)
         dt1 dt2 dmu1 dphi1 dmu2 dphi2 ds

F = power HG(mu1; source_g) sigma_s^2
    HG(mu2; g) HG(c dot -d; g) exp(-sigma_t * optical_length)
    * visibility_of_all_three_legs * finite_support

The three rotational charts release (t1, phi2), (t2, phi2) and (t2, phi1) respectively. The plane releases (t1, t2). Stable quadratic solving retains both valid crossings, the linear limit and one copy of a double root. Reconstructed endpoint residuals are checked before contribution. No positive Jacobian floor, radiance clamp or visibility approximation is applied.

The balanced mixture assigns 0.3 / 0.3 / 0.3 / 0.1. At each reconstructed path its denominator is the sum of mixture probability × residual-coordinate density × absolute crossing determinant. Every contributing segment is visibility-tested. Beer attenuation uses the segment's length inside the medium, excluding vacuum between the sphere and camera.

The independent reference samples distance along the camera ray and a first volume vertex, then explicitly connects the two. It contains the remaining 1 / t2² connection factor and does not use quadric roots, plane intersections or atlas determinants.

Tri-sheets: three distance-pair charts

Now use three flight directions b,c,e and three distances:

y = t1 b
z = y + t2 c
x = z + t3 e = o + s d

All three distances have the same finite interval as above. Each chart retains one distance and solves the other two plus camera distance by a 3×3 linear system:

All directions are sampled from normalized angular distributions: emitter HG for b, then medium HG for c relative to b and e relative to c. Their azimuths span the full circle. The common residual density is angular_pdf / distance_range. In balanced mode each chart has probability 1/3; the MIS denominator is that residual density times the mean of the three absolute determinants.

The physical factor has three powers of sigma_s, two internal phase functions, the third phase function toward the camera, and Beer attenuation/visibility over four reconstructed legs. Singular charts produce no contribution; they are not rescued by clamping a determinant. Another chart can help only where it has nonzero support.

An independent reference samples the camera distance and two forward vertex distances/directions, then connects to the camera vertex. Its final connection carries 1 / t3². This validates the finite-window target through a different parameterization, not the performance of every possible future plane family.

Visibility cache: signed correction, explicit scope

The diagnostic sheet is

X(phi,u) = R_z(phi) (.58, .50u, .90u) + (0,0,1.60)
phi in [0,2pi), u in [-1.35,1.35]

Each query joins a sheet point to the fixed endpoint (3.8,-3.5,3.7) and tests actual segment–box occlusion. A finite atlas stores visibility at cell centers. The smooth weight is recomputed at the current point: HG phase, attenuation, inverse-square falloff and sheet area Jacobian, matching the earlier conditional probe. The color palette and rim factor visualize the field. They are not a complete transport estimator or a claim of physically emitted sheet radiance.

Exact mode tests every point. Cache-only uses the cell prediction and can be biased. Corrected mode independently tests a point with probability p > 0:

V_hat = V_cache + Bernoulli(p) * (V_exact - V_cache) / p

Conditional on any frozen prediction, E[V_hat] = V_exact. A false-light correction is negative, sometimes strongly so. The progressive linear film retains it. Display clamps negative RGB only when converting the average to an image. A noisy early display therefore does not have the same expectation as the signed linear film; the raw PFM is the numerical artifact.

Screen movement invalidates the atlas automatically in this native implementation. The older Python “stale screen” experiment remains useful as a deliberate failure demonstration, but this UI does not silently reuse a stale atlas. Build-query and per-sample-query counts are separate. Neither count alone proves a wall-clock speedup or lower equal-time error.

Verification performed

PrismFrontierTest runs without a graphics context. The initial integrated test passed 581,166 scalar/invariant checks:

• two real crossings, double-root deduplication, stable small roots and linear degeneracy;
• the correction expectation for both binary predictions/truths at four probabilities, retaining negative values;
• deterministic accumulation across split step() calls, continuing beyond a small batch count;
• presentation leaves the linear film unchanged;
• finite films and nonempty support for every exposed physical chart;
• exact film equals corrected film bit-for-bit at p=1;
• the cache is built once per configuration, rebuilt after moving geometry, and fine slats exercise negative residuals;
• independent finite-window volume integration comparisons, using 140,000 film-position samples for each physical study.

Initial clear-scene numerical results (seeded; arbitrary radiance units):

Agreement within sampling uncertainty is an implementation check, not a proof of correctness for every scene or a performance benchmark. Difficult-scene convergence, equal-time error against the main PP implementation, general heterogeneous media, refractive meshes, adaptive chart selection and independently sampled medium bridges remain outside this bounded port.

The deterministic sampleRay() hook also allows root-by-root comparison against the existing Python ledger. Recording/capture tools can write display images and raw PFM from the exact native panel core. See the recording instructions added alongside this document for launch and capture commands.

Integration checks and recordings

The native application and research UI compile in the isolated AIO build. Twelve hidden-window captures cover the original three receiver tabs and all three frontier startup modes at 1280 and 760 pixels wide, with no OpenGL errors or ImGui assertions.

A per-sample comparison against the pre-existing NumPy physical ledger checks 52,500 samples across cylinder, cone, hyperboloid, plane and independent reference, over slit, difficult and clear scenes. 7,055 samples contribute; maximum absolute native/Python difference is 1.634e-11, with no tolerance failures. The adverse scene comparison explicitly keeps the native medium settings when constructing the Python oracle.

Retained native films include 512-pass rotational and 768-pass tri-sheet views at 320 by 200 pixels. They remain finite-sample images, not converged references. Both use the same +4 EV display and optional display-only glow.

At 192 by 120 pixels and 256 passes, the broad-screen visibility comparison gives RGB linear RMSE 0.0284184 for cache-only and 0.00594011 for corrected, relative to the matched finite exact film. Fine-screen values are 0.0312936 and 0.00659992. These are one-seed finite-film checks, not general error or speed claims. The broad corrected run performs 147,309 exact queries plus 384 cache-build queries, compared with 1,218,858 exact queries in the baseline, and retains 10,796 negative corrections. Query reduction alone does not establish a speedup.

For repeatable native captures, build PrismFrontierCapture and run:

.\build-local\bin\Release\PrismFrontierCapture.exe .work\frontier-rotational 0 0 0 512 320 200
.\build-local\bin\Release\PrismFrontierCapture.exe .work\frontier-sheets 1 0 0 768 320 200
.\build-local\bin\Release\PrismFrontierCapture.exe .work\frontier-cache 2 0 2 256 192 120

Arguments are output directory, study, scene, method, passes, width and height. Study IDs are rotational 0, tri-sheets 1, cache 2. Scene IDs are slit 0, difficult 1, clear 2. Physical methods are balance 0, members 1–3, plane 4 (rotational only), reference 5. Cache methods are exact 0, approximate 1, corrected 2. Exports contain unclamped signed PFM, display PNGs and settings/counters; effective dimensions respect the core's 1024-pixel per-axis limit.