threejs-compatibility-fallbacks

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Three.js Compatibility Fallbacks

Three.js 兼容性回退方案

Treat fallback as an explicitly authorized product branch. Canonical WebGPU/TSL work and native WebGPU quality tuning remain with their owning skills.

将回退视为经过明确授权的产品分支。标准WebGPU/TSL开发工作以及原生WebGPU质量调优仍由其所属技能负责。

1. Activate the branch

1. 激活分支

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.

在选择实现方案前，记录以下所有信息：

用户明确提出的WebGPU不可用回退请求；
已初始化的
```
WebGPURenderer
```
提供的证据，证明指定目标上
```
renderer.backend.isWebGPUBackend !== true
```
；
标准特性的所属方及具体特性；
已接受的视觉、物理、时序、交互、性能及维护损失范围；
兼容性分支的维护负责人。

仅在

await renderer.init()

之后才能获取后端真实状态。当WebGPU初始化完成后，回归至标准所属方处理。若用户未明确提出请求，则从标准路径报告WebGPU不可用的阻碍。在构建独立的兼容性渲染器之前，销毁用于探测能力的渲染器。

当上述五项激活信息已记录且标准实现未发生变更时，此步骤完成。

2. Classify canonical behavior

2. 归类标准行为

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.

列出标准特性的几何、辐射度、颜色、时序、交互、状态所有权及生命周期不变量。将每一项归类为：

```
preserved
```
（保留）：数量及验证逻辑保持一致；
```
weakened
```
（弱化）：保留数量，说明变更后的错误、支持情况、节奏、过时性或范围，并冻结新的限制条件；
```
removed
```
（移除）：标记该能力不支持，并移除相关依赖声明。

在跨系统边界处，保留意味着保持相同的单位、帧/原点、时间间隔和采样阶段、所有者、生产者/消费者版本、支持/过滤规则、有效性/过时性/错误、速率与集成语义、单向或双向响应范围、稳定标识、不可变的前后展示状态、重置行为以及GPU完成依赖。语义不同的近似处理属于弱化或移除。将稳定帧的GPU到CPU回读操作置于帧关键路径之外。

当每一项标准声明都具有唯一的处置方式，且每一条弱化或移除的记录都明确其对用户可见的影响时，此步骤完成。

3. Select the first honest representation

3. 选择首个真实呈现方案

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.

针对每个特性，按以下顺序选择方案：

当交互可移除时，使用预计算或静态的标准输出；
具有声明的上传节奏、延迟、内存分配及动态性损失的受限CPU/离线生成方案；
移除特性并匹配相应UI/文档及声明移除；
经过明确维护接受后的独立遗留分支。

在选择不可用能力的方案时，请查阅降级决策矩阵。仅在实现或验证遗留/API分支时才查阅r185 API映射；需针对已安装版本重新验证每个符号。

当所选呈现方案是满足所有

preserved

不变量及所有

weakened

不变量的冻结限制条件的最早选项，且所有剩余损失均已明确时，此步骤完成。

4. Isolate ownership

4. 隔离所有权

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.

为兼容性分支分配独立的导入、构建/部署入口、测试、产物、能力限制及维护负责人。在分支内保留一个场景信号图及一个色调映射/输出转换负责人。记录颜色与数据纹理域、资源创建/重置/调整大小/销毁，以及标准资产与兼容性资产之间的边界。

当GPU性能声明需要时间戳时，在初始化前使用

trackTimestamp: true

构建分支渲染器。遗留分支仅可在激活后使用

WebGPURenderer( { forceWebGL: true } )

；它仍属于兼容性产品，而非标准渲染器。

当禁用或删除兼容性入口点后，标准构建及运行时图保持不变，且每个分支所属资源都有唯一的所有者及销毁路径时，此步骤完成。

5. Validate the changed claims

5. 验证变更后的声明

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.

当安装每个保留或弱化的声明时，调用

$threejs-visual-validation

。与该负责人配合，以标准证据为基准，仅捕获生成声明所需的视图、追踪信息及诊断数据，并测试其适用的重置、调整大小/DPR、过渡、拆卸及销毁/重建路径。持久化资源必须在声明的预热阶段后达到稳定状态。

若负责人缺失，则进行报告并对受影响的声明返回

INSUFFICIENT_EVIDENCE

；请勿在此技能内构建替代验证逻辑。缺失时间戳同样会导致所需的GPU归因结果为

INSUFFICIENT_EVIDENCE

；仅展示或CPU时长可作为端到端证据。

当每个保留的声明都有判定结果，每个移除的声明已从产品语言中删除，输出转换有唯一负责人，且生命周期/资源声明要么在验证后达到稳定状态、要么验证失败、要么仍为

INSUFFICIENT_EVIDENCE

并明确缺失的证据时，此步骤完成。

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.

为每个特性返回一行记录：

特性	目标	保留	弱化	移除	呈现方案	验证

同时记录激活信息、独立入口点及维护负责人、输出负责人、生命周期结果、不支持的声明、任何缺失的验证负责人，以及每个

INSUFFICIENT_EVIDENCE

判定所需的确切证据。