feat: derive the subdivision cap from an adjustable memory budget (proposal)

[Dgmtnz]

This is the one the other two were for: it is what actually lets a large
model export at a resolution the machine can afford, instead of failing with
an out-of-memory alert.

Context first — this one is a proposal, not a finished call

It changes default behaviour and adds a user-facing control, so it's a product decision. Happy to drop, reshape or split it. The two PRs it sits on stand on their own.

Depends on #114.

The problem

SAFETY_CAP is a hardcoded 16M/32M pair, justified by "~145 bytes per subdivided triangle". Measured, the pipeline peaks at 660 B/tri (327 after the memory PR). So those caps stood for 10.6 GB and 21 GB. No tab ever reached them — it hit the allocator first, and the export died with an out-of-memory alert instead of the "coarser than requested" warning the cap exists to produce.

navigator.deviceMemory is clamped to 8 by its own specification, so a 64 GB workstation and an 8 GB laptop got the same ceiling, and "I have the RAM, let me use it" was unexpressible.

Separately, computeRecommendedMaxTri clamps at a flat 2 M. diag-quality-ceiling.mjs (added) sweeps one model across physical sizes with a fine texture:

  size(mm)   suggested   detail-limited   budget-limited   suggested   binding
   (diag)     edge mm       edge mm          edge mm        out-tris    ceiling
       50      0.050         0.025            0.043          2.00M    SLIDER CLAMP
      100      0.090         0.025            0.086          2.00M    TRIANGLE BUDGET
      200      0.180         0.025            0.172          2.00M    TRIANGLE BUDGET
     1200      1.040         0.025            1.030          2.00M    TRIANGLE BUDGET

Every size gets exactly 2.00 M output triangles — the same count for a 50 mm part and a 1200 mm one, i.e. a ~24× coarser surface on the large one, silently.

The change

cap = budgetBytes / PIPELINE_BYTES_PER_TRIANGLE, with the budget a user setting (Advanced → Quality Ceiling), persisted, resolved on the page (the worker has no localStorage) and passed as settings.subdivisionCap.

A second ceiling is independent of RAM and I only found it by hitting it: V8 caps a single typed array at 2^31−1 bytes (measured — largest allocatable Float32Array is 2046 MB, page and worker alike). At a 32 GB budget the cap was nominally 101 M triangles; subdivision reached 65 M, then toNonIndexed asked for a 2.34 GB Float32Array and threw, on a machine with 30 GB free. So the cap is also bounded by 2^31 / 48 B/tri ≈ 44.7 M triangles, and the UI says when that, not the setting, is binding.

Allocation failures now degrade instead of throwing: subdivide() rolls back to the last complete level and reports safetyCapHit. Losing a finished multi-minute subdivision to one failed allocation isn't an acceptable failure mode.

Smart budgets against the same cap the export enforces, and the 2 M output clamp becomes proportional to the budget (floored at 2 M so it can never recommend less than today).

Effect

Budget	Cap	Suggested edge vs. today
2 GB	5.6 M	0.59× (coarser)
4 GB	11.2 M	0.84× (coarser)
8 GB	22.4 M	1.18× finer
16 GB+	44.7 M (structural)	1.67× finer

The rows below 8 GB are coarser than today's nominal setting — deliberately. Today's 12 M Smart budget needs ~7.9 GB of real memory at the current 660 B/tri, so on a machine that only has a few GB to spare it mostly ended in an out-of-memory alert. These numbers are what actually completes.

Caveats

• PIPELINE_BYTES_PER_TRIANGLE = 384 is measured two ways: 327 B/tri under Node with live typed-array accounting, and 384 B/tri in Chromium as the RSS rise of the browser processes over an idle baseline during a real export (15.0 M subdivided triangles, 665 MB → 6165 MB). The constant takes the browser figure, since the allocator charges for footprint, not for the subset V8 calls live. Both were measured on generated models on one Linux machine — worth re-checking against your reference models.
• The rollback path is defensive and unexercised by any test — with the structural cap in place it should be unreachable in Chromium.
• i18n: EN and ES only; the other 12 fall back to English.
• One machine, Linux + Chromium 131. The 2 GB per-allocation limit is unverified on Safari/Firefox.
• Pipeline fingerprints unchanged (10/10) — the cap doesn't bind at test sizes.