pmndrs / pmndrs/react-three-examples

webgl_batch_lod_bvh: blocked on an upstream packaging gap in @three.ez/batched-mesh-extensions

Open
#4 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
TypeScript
Stars
2
Forks
1
PR merge metrics
No merged PRs in 30d

Description

What

webgl_batch_lod_bvh is not ported (Phase 2). Two independent, stacked blockers, checked
directly against what's installed:

  1. @three.ez/batched-mesh-extensions's WebGPU build is not importable. The installed
    package (0.0.12) genuinely ships a WebGPU build on disk (build/webgpu.js,
    src/index.webgpu.js, src/patch/ExtendBatchedMeshPrototype.webgpu.js all exist) — but
    package.json's exports field maps "." to build/webgl.js/.cjs only. There's no
    "webgpu" export condition and no subpath export, so Node/Vite's exports resolution
    refuses any path not listed there. A plain import '@three.ez/batched-mesh-extensions'
    always gets the WebGL build; reaching build/webgpu.js would need a private relative
    node_modules/... import into someone else's package layout, which isn't a real fix.
    Ledgered as UPSTREAM.md brief B51 — almost certainly a publishing oversight (the source
    clearly builds both targets), not an intentional WebGL-only package.
  2. Two more dependencies aren't installed: @three.ez/simplify-geometry (generates the
    demo's 4 extra LOD levels from the base mesh) and meshoptimizer (the simplifier's
    backend). Adding them needs pnpm install, outside an agent's rules of engagement.

Also worth noting: the r185 original is itself WebGLRenderer-only despite the webgl_
prefix pattern holding — it explicitly imports the WebGL build from a CDN, i.e. even
upstream picks WebGL on purpose for this demo. A port would still be WebGPU-first per this
repo's charter, once unblocked.

Why it matters

Single-demo blocker, not site-wide — one example stays unported until the upstream
packaging gap closes. Filing so it isn't silently forgotten and so the next person doesn't
re-investigate from scratch.

Recommendation already on file

docs/REVIEW-QUEUE.md #15: (a) file an issue/PR upstream against
@three.ez/batched-mesh-extensions adding a "webgpu" export condition — cheap, and
unblocks this immediately once released; (b) in the meantime, do NOT work around it with a
relative deep import + declare module shim — that's exactly the kind of fragile,
non-portable hack AGENTS.md's "no dependency patches" rule exists to keep out. Wait for (a)
or skip the example. Not touched; no partial file on disk.

Pointer

docs/REVIEW-QUEUE.md §15 and docs/UPSTREAM.md brief B51.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with docs/REVIEW-QUEUE.md §15 and docs/UPSTREAM.md brief B51. Verify that the upstream package exposes a WebGPU export and that the missing dependencies are installed before attempting the port. Done means the upstream packaging gap is resolved and the webgl_batch_lod_bvh example is ported without a relative deep-import workaround.

Written by the indexing model from the issue text.

Assessment

Tech stack
react, three.js, typescript
Domain
computer-graphics, web-dev
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.