A post-processing depth-of-field pass ran at 20 fps on an integrated GPU: defocus in the card shader instead

Not in the docs/L-H04YAI

three.js uploads video frames without sRGB decoding for a custom ShaderMaterial: decode them in the shader

What happened

three.js uploads video frames as they are and decodes them inside its own materials' shaders, so a custom ShaderMaterial sampling a video gets the raw sRGB values, while the pictures beside it arrive linear.

The fix

the card shader decodes the video sampler itself with three's sRGBTransferEOTF (if (uMap2Video 0.5) next = sRGBTransferEOTF(vec4(next, 1.0)).rgb;); pictures are left alone.

May be outdated for three 0.186

Not in the docs/L-7D7NAI

drei's MeshReflectorMaterial multiplies the reflection by the floor's colour: on a near-black floor it vanishes

What happened

the reflection is multiplied by the floor's own colour, and the dark stage's floor is near black, so at 1.2 nothing showed.

The fix

mixStrength is 60 on the dark stage and 1.4 on the light one, with metalness 0.5 on dark only.

The tools and the machine/L-XSV2AI

MeshReflectorMaterial's depth blur leaves a bright jagged fringe on a light background: turn it off there

What happened

it also leaves a fringe where a card meets the background: invisible on black, a bright jagged outline on the light theme's paper.

The fix

depthScale is 1.1 on the dark stage and 0 on the light one.

The tools and the machine/L-HJEQAI

drei's Environment cost a 3.3 s first frame on Windows (PMREM pre-filtering) and fetches its HDR from a CDN

What happened

on Windows, where WebGL runs on Direct3D, its PMREM pre-filtering made the first frame take 3.3 s on an Intel Iris Plus; and the preset downloads its HDR file from a CDN at run time, which a component that is sold must not depend on (that…

The fix

no environment map: the floor's reflections come from the reflector itself, and a hemisphere light plus a key light that follows the active card do the rest.

The tools and the machine/L-0C2MAI

Compiling three.js shaders inside the first frame blocks the page: compile with compileAsync while the frame loop waits

What happened

compiling inside the first frame blocked the main thread for 100–400 ms, and the demo's total blocking time was 700 ms.

The fix

the <Canvas starts with frameloop="never"; renderer.compileAsync(scene, camera) compiles every material in parallel where the browser supports KHRparallelshadercompile, and only then does the loop start. The quality governor also waits for…

May be outdated for three 0.186