DriftEngineModel loading · function
textureColorSpaces
How each of an asset's images should be sampled, decided from what its materials call them.
Explained in Importing models.
function textureColorSpaces(materials: readonlyimport { textureColorSpaces } from '@driftengine/assets';Parameters
| Parameter | Type | Description |
|---|---|---|
materials | readonly { readonly albedo: number; readonly normalMap: number; readonly ormMap: number; readonly emissiveMap: number; }[] | |
count | number |
In depth
A colour map and a data map need opposite treatment and the container does not say which is
which — it says only that material n names image k as its albedo, or its ORM, or its
normal. So the roles are read off the materials, and an image nothing names falls to linear,
which is the harmless answer for an image nothing samples.
srgb for a base colour and an emissive map: glTF specifies both as sRGB-encoded, and handing
those bytes to a shader undecoded treats display values as light — mid-tones arrive far brighter
than the author's, and it stays invisible until an output transform washes the surface out.
linear for a normal or ORM map, whose numbers are the data. Decoding a direction or a
roughness as though it were a colour bends every one of them toward its floor.
A conflict resolves to linear. An image named as a colour map by one material and as a
data map by another is a file nobody meant to write, and of the two ways to be wrong this is the
milder: an sRGB-decoded ORM map bends roughness and metallic toward zero and turns the surface
to polished chrome, where an undecoded colour map is merely pale.