PartWriteOptions.fadeMs ​

Contract 2.0.0 · package sha256 a857eca95b35921109faf997094bb4192f12527d9d0fcd4be7e97f06425bad6e · generated from configurator-runtime.d.ts by services/onsite-scripter/scripts/build-contract-docs.mjs; edit the source, not this file.

Property of PartWriteOptions · stable · since 2.0.0

fadeMs?: number;

Material crossfade, ms: baseColor, normal, orm and alpha crossfade, each side sampled at its own placement (uv, scale or sizeM, offset, rotationDeg), and scalars tween on the same clock. A sheen whose enabled flips tweens its intensity from or to 0 on that clock, drawn with the sheen variant from the first faded frame to the last (its weight never below 1e-4 there, which draws as no sheen), so the program changes only when the fade lands, to the target's own. Each part the write changes fades from what it drew, and a part outside it keeps its look, also when it already wears the incoming material. Readiness also prepares every shader the fade draws before the commit is shown, so a fade links none: for a flipping sheen, the sheen variant of the material the fade draws. Where the browser can't link shaders in the background (no KHR_parallel_shader_compile), preparing is a main-thread link wherever it runs. Where the device's texture units (MAX_TEXTURE_IMAGE_UNITS) can't hold the samplers both sides need, the fade blends baseColor alone, scalars still tween, and the other maps swap at its first frame, so a click never recompiles. It resolves, starts and is taken over as durationMs says, with the material in place of the pose: a newer write to the same rule takes over from what is drawn, its maps from the look this fade goes to once the fade has drawn a frame (a write back to the look it comes from reverses it; before that frame, from the drawn look), and resolves this one (spec section 6.3); a field it writes to this fade's own target value is no takeover. Counts as 0 under reduced motion (spec section 6.2).

Default: 0

Generic-API test (spec 3.1) ​