equirectToCubeFaces

function equirectToCubeFaces(source: EquirectSource, size: number): Float32Array[]

import { equirectToCubeFaces } from '@driftengine/core';

Parameters

In depth

Backend-neutral, and it produces exactly what the projection already takes. The output is the shape a bake produces — six size * size * 4 arrays of linear RGBA in cubemap order — so a loaded environment joins the captured path at the same place a bake does, and everything downstream of the cube is one implementation rather than two.

The face basis is imported rather than restated. This is the fourth place that table would have appeared, and its failure mode is the one the 2026-08-17 rule is about: a mirrored face projects perfectly well onto a wrong answer, and the last time two copies disagreed it took projecting both backends' cubes onto one shared basis to find a sign in the linear Z band.

The convention, stated because there is no universal one

• Row 0 is the zenith. v = acos(y) / pi, so the top of the image is +Y. Inverting this puts the sky underfoot, and every surface is then lit from below with nothing in the picture to say why.
• The centre column is -Z. u = 0.5 + atan2(x, -z) / 2pi, which is the engine's own camera convention — yaw 0 looks toward -Z and positive yaw turns toward +X — so +X lands three quarters of the way across. Choosing the mirror of this passes every brightness check and every sky-is-up check, and shows only as a reflection that turns the wrong way.

What it costs is bilinear sampling per texel of the destination, once, at load. What would make it wrong is a source small enough that the cube is upsampling it — at that point the faces carry interpolation rather than image, and the honest answer is a smaller cube.