threejs-compatibility-fallbacks

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.