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]>
Neon Reef — Three.js WebGPU
A WebGPU-first scene that degrades to WebGL2 by itself: ONE WebGPURenderer
construction picks the best backend the browser actually has. TSL node materials push the
vertex wave onto the GPU; 900 instanced shards draw in a single call.
Live: https://three-webgpu.hanzo.app
Build
npm install && npm run build # -> app.js, referenced by index.html
Deploy to hanzo.app
An engine build is far bigger than the 4 MiB the public edge accepts in one request body, so games ship through the release lane, not the artifact lane: put the built tree in your object space, then publish it server-side.
# 1. declare the engine — `unity`, `unreal`, `godot` make clients/sites serve the
# site cross-origin-isolated (COOP/COEP) so multithreaded WASM gets SharedArrayBuffer
curl -X POST https://api.hanzo.ai/v1/projects -H "Authorization: Bearer $TOKEN" \
-H "X-Org-Id: $ORG" -H "Content-Type: application/json" \
-d "{\"slug\":\"my-game\",\"name\":\"my-game\",\"framework\":\"godot\"}"
# 2. stage the build to s3.hanzo.ai under <org>/_stage/my-game/
# 3. promote it into an immutable content-addressed release + flip the pointer
curl -X POST https://api.hanzo.ai/v1/sites/my-game/publish -H "Authorization: Bearer $TOKEN" \
-H "X-Org-Id: $ORG" -H "Content-Type: application/json" -d "{\"source\":\"_stage/my-game\"}"
Fingerprint your asset names. The site server serves a content-hashed filename
immutable and everything else with a plain max-age. A redeploy that reuses the same
asset name leaves browsers and the CDN running the OLD loader against the NEW binary —
for a WASM app that is a silent, permanent hang with no error, not a visible failure.
License
MIT (this scene). three.js is MIT, (c) the three.js authors.