| name | threejs-compatibility-fallbacks |
| description | Fallback unavailable WebGPU features through an isolated compatibility branch. Use only when the user explicitly asks how to handle an initialized non-WebGPU backend; then classify canonical behavior as preserved, weakened, or removed. |
Three.js Compatibility Fallbacks
Treat fallback as an explicitly authorized product branch. Canonical WebGPU/TSL
work and native WebGPU quality tuning remain with their owning skills.
1. Activate the branch
Record all of the following before selecting an implementation:
- the user's explicit request for unavailable-WebGPU fallback;
- proof from an initialized
WebGPURenderer that
renderer.backend.isWebGPUBackend !== true on the named target;
- the canonical owner and exact feature;
- the accepted scope of visual, physical, temporal, interaction, performance,
and maintenance loss;
- the compatibility branch's maintenance owner.
Backend truth is available only after await renderer.init(). When WebGPU
initializes, return to the canonical owner. When the explicit request is absent,
report the unavailable-WebGPU blocker from the canonical path. Dispose the
capability-probe renderer before constructing a separate compatibility renderer.
This step is complete when the five activation facts are recorded and the
canonical implementation remains unchanged.
2. Classify canonical behavior
List the canonical feature's geometric, radiometric, color, temporal,
interaction, state-ownership, and lifecycle invariants. Classify each one:
preserved: the same quantity and proof still apply;weakened: keep the quantity, name the changed error, support, cadence,
staleness, or envelope, and freeze a new gate;removed: mark the capability unsupported and remove dependent claims.
At a cross-system boundary, preservation means retaining the same units,
frames/origin, time interval and sample phase, owner, producer/consumer version,
support/filter, validity/staleness/error, rate-versus-integrated semantics,
one-way or two-way reaction scope, stable identity, immutable previous/current
presentation state, reset behavior, and GPU completion dependency. An
approximation with different semantics is weakened or removed. Keep
steady-frame GPU-to-CPU readback outside frame-critical paths.
This step is complete when every canonical claim has exactly one disposition
and every weakened or removed row names its user-visible consequence.
3. Select the first honest representation
Use this order for each feature:
- precomputed or static canonical output when interaction can be removed;
- bounded CPU/offline generation with declared upload cadence, latency,
allocation, and lost dynamics;
- feature removal with matching UI/documentation and claim removal;
- an isolated legacy branch after explicit maintenance acceptance.
Read
the downgrade matrix when selecting
among unavailable capabilities. Read the
r185 API map only when implementing or verifying
the legacy/API branch; reverify each symbol against the installed revision.
This step is complete when the selected representation is the earliest row
that passes every preserved invariant and every weakened invariant's frozen
gate, and every remaining loss is explicit.
4. Isolate ownership
Give the compatibility branch separate imports, build/deployment entrypoint,
tests, artifacts, capability gate, and maintenance ownership. Keep one scene
signal graph and one tone-map/output-transform owner inside the branch. Record
color versus data texture domains, resource creation/reset/resize/disposal, and
the boundary between canonical and compatibility assets.
When a GPU-performance claim requires timestamps, construct the branch renderer
with trackTimestamp: true before initialization. A legacy branch may use
WebGPURenderer( { forceWebGL: true } ) only after activation; it remains a
compatibility product rather than the canonical renderer.
This step is complete when disabling or deleting the compatibility entrypoint
leaves the canonical build and runtime graph unchanged, and every branch-owned
resource has one owner and disposal path.
5. Validate the changed claims
Invoke $threejs-visual-validation for every preserved or weakened claim when
it is installed. With that owner, use canonical evidence as truth, capture only
the views, traces, and diagnostics that produce the claim, and exercise its
applicable reset, resize/DPR, transition, teardown, and dispose/recreate paths.
Persistent resources must plateau after declared warm-up.
If the owner is absent, report it and return INSUFFICIENT_EVIDENCE for the
affected claims; do not construct replacement validation inside this skill.
Missing timestamps likewise make required GPU attribution
INSUFFICIENT_EVIDENCE; presentation or CPU duration is end-to-end evidence
only.
This step is complete when every surviving claim has a verdict, every removed
claim is absent from product language, output conversion has one owner, and
lifecycle/resource claims either plateau or fail under validation or remain
INSUFFICIENT_EVIDENCE with the missing evidence named.
Output
Return one row per feature:
| Feature | Target | Preserved | Weakened | Removed | Representation | Validation |
|---|
Also record the activation facts, isolated entrypoint and maintenance owner,
output owner, lifecycle result, unsupported claims, any missing verification
owner, and the exact evidence needed for each INSUFFICIENT_EVIDENCE verdict.
