Description:

Bug

On the first render frame after loading a GSplat asset, the sorter worker
(inline Blob URL) immediately crashes with Uncaught ReferenceError: n is not defined.
The splat does not render. No errors before this point — graphics device creation,
asset loading, and depth prepass setup all succeed.

Reproduction

• PlayCanvas Engine 2.19.0 (loaded from jsDelivr CDN)
• WebGPU backend (Mac Mini Intel UHD Graphics 630, macOS Sequoia 15.7.4, Chrome/Brave 26)
• GSplat asset loaded via LOD-streamed lod-meta.json (compressed, ~10M splats)

Stack trace

Uncaught ReferenceError: n is not defined
at new c (blob::2:64)
at Mk (blob::3:177)
at blob::3:3035

Worker Created
iE @ playcanvas.min.js:14054 // (minified PlayCanvas)
createSorter @ playcanvas.min.js:15814
initCpuSorting @ playcanvas.min.js:15814
_createRenderer @ playcanvas.min.js:15814
wE @ playcanvas.min.js:15814
createManager @ playcanvas.min.js:15814
updateConfiguration @ playcanvas.min.js:15814
qR @ playcanvas.min.js:15814
getLayerData @ playcanvas.min.js:15814
render → rAF loop

Expected

Worker initializes correctly, splat renders.

Actual

Worker throws, splat does not render. Reveal-shader-injection (post-load,
patches gsplat material) succeeds though — issue is in sorter worker init,
not in material patching.

Works fine in

v2.18.0 (same code, same browser, same asset)

Possibly related v2.19.0 changes

• "Deprecate GSplatComponent#unified and default it to true"
• "Hybrid Raster Renderer with Compute Projector"
• "WebGPU Compute Radix Sort (4-bit portable + OneSweep NVIDIA)"

The CPU sorter path (initCpuSorting) is being hit despite WebGPU being
active — possibly a fallback that wasn't supposed to trigger on WebGPU,
or the new Compute path mistakenly delegates to the broken CPU sorter.