LCC Web SDK 0.6.2

The SDK ships two packages with an identical API over two different host engines. These pages load the same dataset through each, and expose every setting the SDK actually honors.

Cesium →

Georeferenced on the WGS84 globe. Adds the SDK's transform API (undeclared in the .d.ts) plus a jog-slider placement rig, and self-drives its own render loop.

three.js →

Local Z-up scene with first-person navigation. The only package with a WebGPU path, a working setSmooth(), and a PLY render system.

What this harness establishes about the SDK

Both packages, one API: The two .d.ts files are byte-identical apart from one interface, so differences are engine-level, not API-level.
Settings are two-tier: LCCRender is a module-level singleton: its manager is built on the first load() call, and every LoadOptions field except dataPath and modelMatrix is then frozen. The panel badges each control Live or Reload accordingly.
The .d.ts is incomplete: The rollup stripped 8 LoadOptions fields (leaving orphaned doc-comments behind) and omits ~15 shipped methods, including setDepthSorting, estimateScanAngles and all of Cesium's transform API. All of them are wired up here.
Capabilities vary by backend: On raw PLY every LOD setter is an empty stub; setSmooth() is real only on three.js + LCC v2; clearIndexDB() works only on LCC v1; WebGPU throws on LCC v1. Unsupported controls are disabled with the reason shown.
Demo dataset: Stanford University, LCC v2 — 60,732,649 splats across 7 LOD levels, 222 files, 793 MB. epsg: 0, so Cesium needs an explicit modelMatrix.
Licensing: The watermark check bypasses localhost and 127.0.0.1 only. Anywhere else, an empty appKey yields a 50%-alpha watermark — and keys are hostname-bound.