mirror of
https://github.com/hanzo-templates/three-webgpu.git
synced 2026-10-30 20:52:04 +00:00
zeekayandHanzo Dev
7f56d30320
Neon Reef: ONE WebGPURenderer construction picks the best backend the browser
actually has, so the same bundle is a WebGPU demo on Chrome/Edge and a WebGL2
demo everywhere else. TSL node materials push the vertex wave onto the GPU; 900
instanced shards draw in a single call.
Why this exists: static-SPA builders cannot ship a game. Proving hanzo.app can
meant finding what actually stopped it, and three things did:
1. POST /v1/projects/:slug/deploy carries the entire build in ONE request body
and the public edge caps a body at 4 MiB (measured: 4194304 accepted,
4198400 gets the opaque fasthttp "Error when parsing request"). Godot emits
a 43 MB engine wasm; Unity 22 MB + 5.7 MB of data. The artifact lane cannot
express a game at all, so these ship through the release lane instead: stage
to the object store, then POST /v1/sites/:slug/publish promotes it
server-side with no body.
2. Engine loaders emit NON-fingerprinted filenames (index.js, <name>.loader.js)
and clients/sites.CacheControlFor only marks a content-hashed name
immutable. A redeploy therefore leaves the CDN and the browser running the
OLD loader against the NEW wasm. That is not a visible error: emscripten
prints "still waiting on run dependencies" forever and the canvas stays
300x150. Every template here fingerprints its own asset names so the case
cannot recur.
3. A cross-origin-isolated document (COEP: require-corp) BLOCKS a plain
cross-origin script, so the shared a.hanzo.ai runtime needs
crossorigin="anonymous" on exactly the pages that opt into isolation.
Co-authored-by: Hanzo Dev <[email protected]>
9 lines
271 B
JSON
9 lines
271 B
JSON
{
|
|
"name": "three-webgpu",
|
|
"private": true,
|
|
"type": "module",
|
|
"scripts": { "build": "esbuild src/main.js --bundle --format=esm --minify --target=es2022 --outfile=app.js" },
|
|
"dependencies": { "three": "^0.185.1" },
|
|
"devDependencies": { "esbuild": "^0.25.0" }
|
|
}
|