View-dependent ray-march dropout of thin / non-uniformly-scaled geometry (slab vanishes at grazing angles)

[kmatzen]

Observation

A local project rendered as three sharp "fins/spikes" sitting on a thin slab, which looked wrong at a glance. Project tree (looks fuzz/random-generated — note values like x: -1.9296…, scale: 0.2012…):

{
  "kind": "linearPattern",
  "params": { "axisX": 1, "axisY": 0, "axisZ": 0, "count": 3, "spacing": 20 },
  "children": [{
    "kind": "translate", "params": { "x": -1.9296184514936314, "y": 0, "z": 0 },
    "children": [{
      "kind": "scale", "params": { "x": 0.20127571037331896, "y": 2.578296191303632, "z": 1 },
      "children": [{
        "kind": "union", "params": { "smooth": 0 },
        "children": [
          { "kind": "box", "params": { "width": 100, "height": 30, "depth": 50 } },
          { "kind": "translate", "params": { "x": -5.224608338673388, "y": 0, "z": 0 },
            "children": [ { "kind": "sphere", "params": { "radius": 20 } } ] }
        ]
      }]
    }]
  }]
}

Triage — investigation & evidence

1. Not caused by #75 (SDF-soundness rework). Rendered this exact tree on main immediately before #75 (4737458) and on the #75 branch (e949117): pixel-identical viewport (0 / 543,560 pixels differ; diff bbox empty). #75 changes the distance-field bound, not the zero-level-set, so the surface is unchanged — as expected.

2. The scale node is correct. Rendered scale(0.20, 2.58, 1) → sphere(r=20) in isolation → a clean, smooth ellipsoid (semi-axes ≈ 4 × 51 × 20), no pinching or pointed tip. No distortion from the non-uniform scale.

3. The "fins" are correct geometry + camera angle, not a defect. In the project the scaled box becomes a ~20×77×50 slab and the scaled sphere an ellipsoid ~8×103×40; they're unioned and tiled ×3 by the linear pattern. Each ellipsoid (103 tall) is taller than the slab (77), so only its rounded top cap pokes above — and a rounded cap cropped by the slab edge at that view angle reads as a "fin/point."

Disposition

Not a viewport rendering bug — the ray-marched viewport is faithful to the input. Low severity. The input appears to be a randomized/fuzz project rather than an intentional model.

Remaining to close this out

One thing not yet verified: the exported mesh. The viewport is GPU ray-marched, but STL/3MF export goes through a different pipeline (interval-pruned octree + dual contouring at 64³, per #75). Thin, high-aspect-ratio features (an 8×103×40 ellipsoid, and the ~4-wide scaled slab) are exactly where dual-contouring can under-resolve. Worth confirming an export of this project (or a lone thin scaled ellipsoid) produces a faithful mesh, not a faceted/pinched one — that would be a meshing issue distinct from everything above, and would land under #75's own octree/interval changes.

Filed as a triage record per request; reproduction assets and screenshots were captured during investigation.

[kmatzen]

Correction — this IS a real (view-dependent) rendering bug

My initial disposition ("not a viewport bug") was wrong: I only checked one camera angle. Orbiting the camera reproduces it clearly.

Reproduction: load the project, orbit toward a near-edge-on view of the slab. The slab's filled surface disappears — only its silhouette outline remains — and pattern copies drop out too. It reappears as you rotate back. (Captured across an orbit sweep during investigation.)

Root cause (confirmed, and it is not #75)

It's an interaction between the soundness scaling of a non-uniform scale/transform node and the fixed-budget sphere tracer:

1. transform codegen multiplies the child distance by min(sx, sy, sz) (src/worker/sdf/codegen.ts, ~L207) — the correct 1-Lipschitz correction for a non-uniform scale. For this project's scale(0.20, 2.58, 1) that factor is 0.2, so every reported distance is 5× smaller than the true distance.
2. The viewport ray-marcher is fixed-budget (src/engine/SdfMesh.ts): 256 iterations (L82), stepping t += abs(d) * 0.7 (L98), and if (!hit) discard; (L101).
3. Net: each step advances only 0.7 × 0.2 × true ≈ 0.14× the real distance, so the marcher needs ~7× the normal step count. At grazing/edge-on angles the ray traverses a long near-field span before reaching the thin (~4–20mm) slab, exhausts its 256 steps, and the fragment is discarded → the surface vanishes for those view directions.

Why #75 is not responsible: both the × min(...) correction and the 256-step discard marcher are identical in the commit immediately before #75 (4737458) — verified in source. At a non-dropout angle, pre-#75 and #75 render pixel-identical (0 / 543,560 diff). #75 changed the field bound elsewhere but never this path. So this is pre-existing, general to any model with a large scale-ratio / thin non-uniformly-scaled geometry — the fuzz project just happened to hit it.

Severity

Medium — silent, view-dependent disappearance of valid geometry in the viewport. Doesn't corrupt the model or (necessarily) the export, but it's alarming and misleading during editing.

Fix options

• Anisotropic marching (correct fix): for a non-uniform transform, march in the child's local space (transform ray origin+direction) instead of squeezing the whole field by min(scale). Well-conditioned regardless of scale ratio; more complex with nested transforms.
• Adaptive step budget / over-relaxation: raise the step relaxation toward 1.0 for well-behaved fields, or scale the iteration count / minStep by the known field scale factor so a heavily-downscaled field still converges.
• Cheap mitigation: raise the 256 cap (GPU cost) — treats the symptom, not the cause.

Supersedes the "not a viewport bug" disposition above.

[kmatzen]

Closing out the one item left in the triage — whether the exported mesh is faithful for this thin, high-aspect geometry, since export goes through the interval-pruned octree + dual contouring from #75 rather than the ray-marched viewport.

Meshed the exact project through the export path (verifiedBounds → octree with interval pruning → dualContour), at two resolutions:

	res 64	res 128
vertices / triangles	11,874 / 23,744	47,806 / 95,608
voxel size	2.05mm	1.03mm
max |sdf| at any mesh vertex	0.052mm	0.014mm
vertices >1 voxel off the surface	0 / 11,874	0 / 47,806
solid samples outside the meshing grid	0	0

Mesh extent x[-12.0, 48.1] y[-52.0, 52.0] z[-25.0, 25.0] against a solid extent of x[-11.8, 47.7] y[-51.5, 51.5] z[-24.4, 24.4] (the latter grid-sampled at 120³, so it under-reports the true boundary by up to half a sample — the mesh being marginally larger is expected, not overshoot).

No pinching, faceting, or clipping. Every vertex sits on the zero level set to well within a voxel, and the error falls ~4x when the voxel halves (0.052 → 0.014mm), which is plain discretisation converging rather than a systematic defect. The 8x103x40 ellipsoid and the ~4-wide scaled slab both resolve cleanly.

So the disposition in the triage holds for the export path too: not a meshing bug. Nothing outstanding here from #75's octree/interval changes.

[kmatzen]

Verified the over-relaxed marcher against this project by simulation, and it holds up. Two findings, one of which corrects a number in the analysis above.

The fix works

Reimplemented both marchers against evaluateSDF and swept 432 camera angles (18 elevations × 24 azimuths), casting a 20×20 ray grid per angle and counting rays that provably hit the surface (dense reference march) but that the marcher fails to converge on — i.e. exactly the fragments that reach discard.

marcher	rays lost, of 54,788 true hits
plain 0.7 relaxation, 256 steps	564 (1.03%), spread across 100+ angles
enhanced sphere tracing, ω=1.6, 384 steps	0 (0.00%)
same, 1024 steps	0 (0.00%)

The dropout reproduces on the old marcher and vanishes entirely on the new one. Note the third row: the step-budget increase is not what fixes it — 384 and 1024 are both clean, so the over-relaxation is carrying the result. The budget could stay at 256 if the GPU cost mattered, though the headroom is cheap insurance.

Worth adding that the soundness precondition for Keinert's backtrack — the field must never overstate distance — is exactly what #75 pinned down and property-tests. The two changes fit together: over-relaxation is only safe on a conservative field.

Correction: the under-report factor is 12.8×, not 5×

The analysis above reads the factor off min(sx,sy,sz) = 0.2 and concludes distances are 5× short. That is the wrong quantity. The field is squeezed by min(scale) while the geometry is stretched by max(scale), so the worst-case ratio is max/min:

fieldScale(root) = 2.578 / 0.201 = 12.81

(fieldScale in src/worker/sdf/bounds.ts computes precisely this, and composes it through nested transforms and booleans.) So the field under-reports by up to 12.8×, not 5× — the problem was about 2.5× worse than described, which makes the clean sweep above a stronger result rather than a weaker one.

Not yet covered

The simulation exercises the algorithm against the CPU evaluator, not the compiled GLSL. Given the CPU/GPU parity suite already pins those two together for the field itself, the remaining gap is the marcher loop in SdfMesh.ts — an orbit-based e2e that asserts non-empty coverage at grazing angles would close it. Happy to add that if wanted.

[kmatzen]

Correction to the severity above (measured, not eyeballed)

My previous comment said the slab's fill "disappears — only its silhouette outline remains." That over-stated it: I misread dark-but-lit filled faces as empty background.

Measuring the same grazing angle rigorously (sampling pixel colors, not eyeballing):

• Points well inside the slab read (53, 67, 108) — a lit, filled face — even on the unpatched build. Background is ~(24, 24, 42).
• Pre-fix vs a fixed build differ by only ~2% of the viewport; the fix renders ~4% more filled pixels. So there is a real but modest view-dependent dropout at this angle, not a wholesale vanish.

What stands: the mechanism is real and correctly identified — a non-uniform scale multiplies the field by min(sx,sy,sz) (here 0.2), and the fixed-budget sphere tracer under-steps, so a thin/grazing region can fail to converge and get discarded. The severity varies with view angle; I was not able to reliably reproduce a severe (large-area) dropout, and the modest one I did capture is recovered by the fix below.

Prototyped fix: replace the plain 256-step sphere tracer with enhanced sphere tracing (Keinert et al. 2014 — over-relax the step, back off on overshoot; provably never skips a surface) at omega 1.6 with a 384-step budget. Verified: box / default project / rotated views render unchanged (no overshoot artifacts), and the grazing-angle dropout region is recovered. Pushing omega→2.8 / 512 steps gave no measurable additional gain, so this is a robustness improvement, not a complete cure for arbitrarily-extreme scale ratios — the only complete fix is anisotropic marching (march in the child's local space), which is a larger change.

Net: downgrading severity to low–medium, keeping the ticket open for the anisotropic-marching proper fix; the enhanced-tracing mitigation can land as an incremental improvement.