La tabla de formatos de vértice con sus tamaños

La lista de formatos de atributo parece un enum largo y aburrido, y es en realidad la palanca más directa que tienes sobre el ancho de banda de la etapa de geometría. Un vértice de una malla típica ocupa 48 bytes si lo escribes sin pensar y 24 si eliges los formatos con criterio, con una pérdida de calidad que en la mayoría de los casos no se puede ver.

La tabla

Los formatos de un solo componente de 8 y 16 bits son una incorporación relativamente reciente a la especificación; los de 32 bits y los de varios componentes están desde el principio.

Las cuatro reglas de lectura

El sufijo dice cuántos componentes. Sin sufijo, uno; x2, dos; x4, cuatro.

No existen versiones de tres componentes salvo en 32 bits. Hay float32x3, uint32x3 y sint32x3, y no hay float16x3 ni unorm8x3 ni nada parecido. La razón es la alineación del hardware: un atributo de 6 bytes o de 3 bytes obligaría a lecturas no alineadas. Cuando necesites tres componentes de 16 bits, usas la versión de cuatro y desperdicias el último, o replanteas la codificación.

El prefijo dice cómo se convierte:

• uint y sint llegan al shader como enteros, sin conversión de valor. Un byte con valor 200 llega como 200u.
• unorm divide entre el máximo del tipo y produce un flotante entre 0 y 1. Un byte con valor 255 llega como 1.0.
• snorm produce un flotante entre -1 y 1. Un byte con valor 127 llega como 1.0.
• float convierte de medio flotante o entrega el flotante tal cual.

Los dos especiales. unorm10-10-10-2 empaqueta cuatro valores normalizados con 10, 10, 10 y 2 bits en 4 bytes, y es la mejor relación calidad-tamaño para normales y para colores de baja precisión con un canal extra. unorm8x4-bgra es un unorm8x4 con los componentes en orden azul, verde, rojo, alfa, y existe porque es el orden en el que muchos formatos de imagen y muchos motores antiguos guardan el color.

Comprimir un vértice real

Este es el vértice que sale de escribir sin pensar, tal como lo entrega un importador ingenuo:

Y este es el mismo vértice eligiendo formatos con criterio:

La mitad de bytes por vértice. En una malla de doscientos mil vértices eso son casi cinco megabytes menos de memoria y, sobre todo, la mitad de tráfico en cada pasada que dibuje esa malla.

El descriptor correspondiente:

{
  arrayStride: 24,
  attributes: [
    { shaderLocation: 0, offset: 0,  format: 'float32x3' },  // posicion
    { shaderLocation: 1, offset: 12, format: 'snorm16x2' },  // normal octaedrica
    { shaderLocation: 2, offset: 16, format: 'unorm10-10-10-2' },  // tangente y signo
    { shaderLocation: 3, offset: 20, format: 'unorm16x2' },  // uv
  ],
}

Y el vertex shader que lo descomprime:

fn decodificarOctaedrica(e : vec2f) -> vec3f {
  var v = vec3f(e.xy, 1.0 - abs(e.x) - abs(e.y));
  let t = max(-v.z, 0.0);
  v = vec3f(
    v.x + select(t, -t, v.x >= 0.0),
    v.y + select(t, -t, v.y >= 0.0),
    v.z,
  );
  return normalize(v);
}

@vertex
fn vs(entrada : EntradaVS) -> SalidaVS {
  var s : SalidaVS;
  s.clip   = camara.viewProj * modelo.matriz * vec4f(entrada.posicion, 1.0);
  s.normal = decodificarOctaedrica(entrada.normalCodificada);
  s.uv     = entrada.uv;
  return s;
}