WebGLRenderer always renders into a WebGL2 FBO whose memory row 0 is
the bottom of the viewport → false.
WebGPURenderer always presents a top-down framebuffer convention
to user code regardless of whether the underlying backend is real
WebGPU or Three.js's WebGL2 compat fallback (forceWebGL: true /
natural compat). Three.js's WebGPURenderer normalises Y internally
so TSL/NodeMaterial output is byte-identical across its two
backends. The user-observed result: even under forceWebGL, a
passthrough sample at NDC (-1, -1) reads the top-left texel of the
source target, matching real WebGPU's UV (0, 0) convention.
The discriminator is therefore the renderer class, NOT the backend
flag. An earlier heuristic branched on renderer.backend.isWebGLBackend
to distinguish real WebGPU from compat WebGL2, but that flag is about
the backing API, not the effective framebuffer Y orientation.
Branching on it left the image visibly flipped under
?webgpuForceWebgl because the geometry factory assumed WebGL's
bottom-up FBO while WebGPURenderer was producing top-down output.
— exported only so SceneManager can pass the result through
createRendererCapabilities. Outside of capability construction,
read caps.framebufferYDown instead.
Detect the effective framebuffer Y orientation.
WebGLRendereralways renders into a WebGL2 FBO whose memory row 0 is the bottom of the viewport →false.WebGPURendereralways presents a top-down framebuffer convention to user code regardless of whether the underlying backend is real WebGPU or Three.js's WebGL2 compat fallback (forceWebGL: true/ natural compat). Three.js's WebGPURenderer normalises Y internally so TSL/NodeMaterial output is byte-identical across its two backends. The user-observed result: even underforceWebGL, a passthrough sample at NDC (-1, -1) reads the top-left texel of the source target, matching real WebGPU's UV (0, 0) convention.The discriminator is therefore the renderer class, NOT the backend flag. An earlier heuristic branched on
renderer.backend.isWebGLBackendto distinguish real WebGPU from compat WebGL2, but that flag is about the backing API, not the effective framebuffer Y orientation. Branching on it left the image visibly flipped under?webgpuForceWebglbecause the geometry factory assumed WebGL's bottom-up FBO while WebGPURenderer was producing top-down output.— exported only so SceneManager can pass the result through
createRendererCapabilities. Outside of capability construction, readcaps.framebufferYDowninstead.