Guía de uso y desarrollo de la extensión GLTF

Las extensiones glTF amplían el formato básico del modelo glTF. Las extensiones pueden introducir nuevas propiedades (incluidas propiedades que hacen referencia a datos externos, y las extensiones pueden definir el formato de estos datos), nueva semántica de parámetros, ID retenidos y nuevos formatos de contenedor. Las extensiones están escritas para una versión específica de glTF y pueden promocionarse al glTF principal en versiones posteriores de glTF.

glTF se usa ampliamente para presentaciones 3D en la Web. Si necesita convertir el modelo al formato glTF, puede usar la herramienta de conversión en línea NSDT 3DConvert :

1. Mecanismo de extensión GLTF

Todas las propiedades del objeto glTF (consulte glTFProperty.schema.json) tienen una propiedad de objeto de extensión opcional que puede contener nuevas propiedades específicas de la extensión. Esto permite que las extensiones extiendan cualquier parte de glTF, incluida la geometría, los materiales, las animaciones, etc. Las extensiones también pueden introducir nueva semántica de parámetros, conservar ID y nuevos formatos, incluido glTF.

Las extensiones GLTF no pueden eliminar los atributos glTF existentes ni redefinir los atributos glTF existentes para representar otros significados.

Ejemplos incluyen:

• Nuevas propiedades: la extensión KHR_texture_transform introduce un conjunto de propiedades de transformación de textura, como por ejemplo:

{
  "materials": [{
    "emissiveTexture": {
      "index": 0,
      "extensions": {
        "KHR_texture_transform": {
          "offset": [0, 1],
          "rotation": 1.57079632679,
          "scale": [0.5, 0.5]
        }
      }
    }
  }]
}

Las extensiones GLTF pueden agregar nuevos atributos y valores, como semántica de atributos o tipos mime para texturas. Como en todas las extensiones de Khronos (KHR), y como práctica recomendada para las extensiones de proveedores, estas funciones adicionales tienen como objetivo permitir el uso de respaldo seguro en herramientas que no reconocen extensiones en la matriz extensionsUsed.

Todas las extensiones utilizadas en el modelo se enumeran como cadenas en la matriz extensionsUsed de nivel superior; todas las extensiones requeridas se enumeran como cadenas en la matriz extensionsRequired de nivel superior, por ejemplo,

{
  "extensionsUsed": [
    "KHR_draco_mesh_compression", "VENDOR_physics"
  ],
  "extensionsRequired": [
    "KHR_draco_mesh_compression"
  ]
}

Esto permite que el motor determine rápidamente si admite las extensiones necesarias para representar el modelo sin tener que verificar las propiedades de extensión de todos los objetos.

Se considera necesaria una extensión si el cargador glTF típico no puede cargar el recurso sin admitir la extensión. Por ejemplo, cualquier extensión de compresión de malla debe enumerarse según demanda, a menos que el activo proporcione una malla alternativa sin comprimir. Del mismo modo, las extensiones de formato de imagen de textura deben enumerarse según sea necesario, a menos que también se proporcionen texturas alternativas para los formatos principales (JPG, PNG). En general, PBR u otros tipos de extensiones de material no deben incluirse en la lista requerida porque los materiales centrales de glTF pueden considerarse un respaldo válido para dichas extensiones y dichas extensiones no causarán fallas consistentes en el cargador de glTF.

2. Crear extensión GLTF

Para crear una nueva extensión GLTF, use la plantilla de extensión GLTF y abra una solicitud de extracción en este repositorio. Asegúrese de agregar la extensión al registro de extensiones glTF.

Si la extensión agrega una nueva matriz de nivel superior (al extender el objeto glTF raíz), sus elementos deben heredar todas las propiedades de glTFChildOfRootProperty.schema.json. Otros objetos introducidos por la extensión deberían heredar todas las propiedades de glTFProperty.schema.json. Según la convención glTF 2.0, el esquema debería permitir atributos adicionales. Vea KHR_lights_punctual como ejemplo.

Si la falta de soporte de extensión impide la carga correcta de la geometría, la especificación de extensión debe declararlo (y dichas extensiones deben mencionarse en el atributo glTF de nivel superior extensionsRequired).

3. Convención de nomenclatura para extensiones GLTF

Nota: Por razones históricas, es posible que las extensiones más antiguas no sigan estas pautas. Las futuras extensiones deberían hacer esto.

• El nombre debe comenzar con un prefijo en mayúscula, seguido de un guión bajo. Las extensiones de Khronos tienen el prefijo KHR, las extensiones de múltiples proveedores con EXT y otros prefijos que pueden estar reservados para extensiones de proveedores.
• El nombre debe utilizar letras de serpiente minúsculas después del prefijo, por ejemplo KHR_materials_unlit.
• El nombre debe construirse como <PREFIX>_<scope>_<feature>, donde el alcance es un concepto glTF existente (como malla, textura, imagen) y la característica describe la funcionalidad agregada dentro de ese alcance. Esta estructura se recomienda pero no es obligatoria.
• El alcance debe ser único (por ejemplo, malla, textura) a menos que sea inconsistente con una extensión de Khronos existente (por ejemplo, material, luces).

4. Extensión GLTF versus complemento GLTF

Además de las extensiones, también se pueden utilizar objetos extras para ampliar glTF. Esto es completamente independiente de las extensiones.

Todas las propiedades del objeto glTF permiten agregar nuevas propiedades a las subpropiedades del objeto extra, por ejemplo,

{
  "asset": {
    "version": 2.0,
    "extras": {
      "guid": "9abb92a3-39cf-4986-a758-c43d4bb4ab58",
    }
  }
}

Esto permite que el modelo glTF contenga propiedades específicas de la aplicación sin tener que crear una extensión glTF completa. Esto puede ser preferible para casos de uso especializados en los que la extensión no se adoptará ampliamente.

5. Centro de registro de extensión GLTF

Su extensión GLTF debe agregarse al registro de extensiones GLTF para que se utilice ampliamente. Consulte README.md para conocer los métodos de registro específicos.

Extensiones Khronos aprobadas por 5.1 glTF 2.0

La extensión Khronos utiliza el prefijo KHR reservado. Una vez aprobados por Khronos Group, están protegidos por Khronos IP Framework. Las extensiones destinadas a aprobación también pueden usar el prefijo KHR para evitar la alteración de nombre/código/versión. Los miembros de Khronos pueden presentar extensiones para su aprobación, que luego son votadas por la Junta de Patrocinadores de Khronos.

Khronos Group ha aprobado las siguientes extensiones:

• KHR_draco_mesh_compression

La extensión KHR_draco_mesh_compression define un esquema para usar la biblioteca de compresión de geometría Draco (no canónica) en formato glTF. Esto permite que glTF admita la transmisión de datos de geometría comprimidos en lugar de datos sin procesar. Esta especificación ampliada se basa en Draco Bitstream versión 2.2 (todo el contenido de esta especificación es normativo y está incluido en el alcance).

La sección de conformidad especifica qué debe hacer una implementación cuando encuentra esta extensión y cómo interactúa la extensión con las propiedades definidas en la especificación base.

• KHR_luces_puntual

La extensión KHR_lights_punctual define un conjunto de luces para usar con glTF 2.0. Las luces definen las fuentes de luz dentro de la escena.

Muchas herramientas y motores 3D admiten implementaciones integradas de tipos de luz. Con esta extensión, las herramientas pueden exportar estas luces y el motor puede importarlas.

Esta extensión define tres tipos de luz "puntuales": direccional, puntual y puntual. La cuasiluz se define como puntos infinitesimales parametrizados que emiten luz con dirección e intensidad bien definidas.

Un nodo hace referencia a estas luces y heredan la transformación de ese nodo.

Una implementación coherente de esta extensión debe poder cargar los datos de luz definidos en los recursos y debe representar los recursos utilizando esas luces.

• KHR_materiales_anisotropía

La extensión KHR_materials_anisotropy define las propiedades de anisotropía de los materiales, como las observables a través del metal cepillado. Se introduce un modelo de lóbulo especular asimétrico para considerar este fenómeno. La característica visual distintiva de este lóbulo es la apariencia alargada del reflejo especular.

• KHR_materials_clearcoat

La extensión KHR_materials_clearcoat define una capa transparente que se puede superponer a las definiciones de materiales glTF existentes. Clearcoat es una técnica comúnmente utilizada en renderizado de base física para representar una capa protectora aplicada a un sustrato.

• KHR_materiales_emissive_strength

El modelo de material central glTF 2.0 incluye emissiveFactor y emissiveTexture para controlar el color y la intensidad de la luz emitida por el material, y está limitado al rango [0.0, 1.0]. Sin embargo, en entornos PBR con reflejos e iluminación de alto rango dinámico, es posible que se requieran efectos de emisión más fuertes.

En la extensión KHR_materials_emissive_strength, se proporciona un nuevo factor escalar emissiveStrength, que controla el límite superior de la resistencia emisiva de cada material.

Esta intensidad se puede sombrear y atenuar utilizando los controles emissiveFactor y emissiveTexture del Core Material, lo que permite que la intensidad varíe en toda la superficie del material. Proporcionar un valor superior a 1,0 para emissiveStrength puede tener efectos en los reflejos, el mapeo de tonos, las floraciones, etc.

• KHR_materiales_ior

La extensión KHR_materials_ior permite al usuario establecer el índice de refracción en un valor específico.

El dieléctrico BRDF de materiales de rugosidad metálica en glTF utiliza un valor fijo de 1,5 como índice de refracción. Esto funciona muy bien con muchos plásticos y vidrio, pero no con agua u otros materiales como asfalto, zafiro o diamante.

• KHR_materiales_iridiscencia

La iridiscencia describe un efecto en el que el tono cambia según el ángulo de visión y el ángulo de iluminación: las películas delgadas de capas translúcidas causan interreflexión y, debido a la interferencia de las películas delgadas, ciertas longitudes de onda se absorben o amplifican. Los colores iridiscentes se pueden ver en pompas de jabón, películas de aceite o en las alas de muchos insectos.

Con la extensión KHR_materials_iridescent se puede especificar el espesor y el índice de refracción (IOR) de la película para implementar materiales iridiscentes.

• KHR_materiales_brillo

La extensión KHR_materials_sheen define brillos que se pueden superponer a las definiciones de materiales glTF existentes. Por ejemplo, las capas brillantes son una técnica común utilizada en el renderizado físico para representar telas y materiales textiles.

• KHR_materiales_especular

La extensión KHR_materials_specular agrega dos parámetros al material Metal Roughness: especular y color especular.

La reflexión especular permite al usuario configurar la intensidad de la reflexión especular en un BRDF dieléctrico. Un valor de cero desactiva los reflejos especulares, lo que da como resultado un material puramente difuso. El BRDF metálico no se ve afectado por este parámetro.

specularColor cambia el color F0 de los reflejos especulares en BRDF dieléctrico, lo que permite a los artistas utilizar el efecto conocido del material de brillo especular (KHR_materials_pbrSpecularGlossiness) en el material de rugosidad metálica.

• KHR_materiales_transmision

La extensión KHR_materials_transmission está diseñada para abordar el caso de uso más simple y común de la transparencia óptica: materiales infinitamente delgados sin refracción, dispersión o dispersión. Trabajar específicamente con materiales "delgados" (es decir, materiales donde solo se considera la superficie y no el volumen) permite muchas simplificaciones en el cálculo de aspectos como la refracción y la absorción.

Muchos materiales ópticamente transparentes no se pueden representar de una manera físicamente razonable con materiales centrales glTF 2.0 PBR. Esto se debe a que la especificación principal solo contiene el concepto de "alfa como cobertura" (expuesto a través del canal alfa de baseColorFactor y baseColorTexture). Muchos materiales comunes, como el vidrio y el plástico, requieren técnicas de renderizado significativamente diferentes.

• KHR_materiales_unlit

La extensión KHR_materials_unlit define un modelo de sombreado sin iluminación para materiales glTF 2.0 como una alternativa al modelo de sombreado de representación basada físicamente (PBR) proporcionado por la especificación principal. Tres casos de uso motivadores para materiales no luminiscentes incluyen:

1. Dispositivos móviles con recursos limitados, donde los materiales no emisores brindan una alternativa de alto rendimiento a los modelos de sombreado de mayor calidad.
2. Fotogrametría, donde ya existe información de iluminación y no se debe aplicar iluminación adicional.
3. Materiales estilizados que no requieren iluminación por motivos estéticos (como un aspecto "anime" o "dibujado a mano").

Estos casos de uso no son mutuamente excluyentes: un artista puede elegir un material no iluminado por motivos de interpretación y tomar decisiones estéticas para complementar esa elección. Por lo tanto, las implementaciones de cliente capaces de representar PBR no deberían "actualizarse" automáticamente a PBR completamente sombreado. Cualquier propiedad principal de PBR especificada en materiales no iluminados (excepto baseColor) solo se usa como alternativa para clientes que no admiten la extensión KHR_materials_unlit. La extensión, ya sea obligatoria u opcional en el recurso, indica una preferencia por un estilo visual sin iluminación.

• KHR_materiales_variantes

La extensión KHR_materials_variants permite una representación glTF compacta de múltiples variantes de materiales de un activo, con una estructura que permite una conmutación de baja latencia en tiempo de ejecución.

Un caso de uso típico es el comercio digital, donde a un usuario se le puede presentar, por ejemplo, un par de zapatillas y la posibilidad de cambiar entre diferentes colores.

• KHR_materiales_volumen

De forma predeterminada, los materiales glTF 2.0 describen las propiedades de dispersión de las superficies que rodean un volumen infinitamente delgado. La superficie definida por la malla representa la pared delgada.

La extensión KHR_materials_volume permite transformar superficies en interfaces entre volúmenes. La malla a la que se une el material define los límites de un medio homogéneo y, por tanto, debe ser múltiple. Los volúmenes proporcionan efectos como refracción, absorción y dispersión. La dispersión no es el tema de esta extensión.

• KHR_mesh_cuantización

Los atributos de vértice normalmente se almacenan utilizando el tipo de componente FLOAT. Sin embargo, esto puede resultar en una precisión excesiva, un mayor consumo de memoria y tamaño de transferencia, y un rendimiento de renderizado reducido.

La extensión KHR_mesh_quantization amplía el conjunto de tipos de componentes permitidos por el almacenamiento de atributos de malla para proporcionar una compensación entre memoria y precisión; según las necesidades de la aplicación, el almacenamiento de 16 u 8 bits puede ser suficiente.

El uso de almacenamiento de 16 u 8 bits a menudo requiere convertir valores de punto flotante sin procesar para que quepan en una cuadrícula uniforme 3D o 2D; este proceso a menudo se denomina cuantización.

Para simplificar los requisitos de implementación, esta extensión se basa en métodos existentes para especificar transformaciones geométricas en lugar de agregar transformaciones de cuantificación inversa especiales al patrón.

Por ejemplo, una malla estática lista para PBR generalmente requiere POSICIÓN (12 bytes), TEXCOORD (8 bytes), NORMAL (12 bytes) y TANGENTE (16 bytes) por vértice, para un total de 48 bytes. Con esta extensión, puede usar SHORT para almacenar datos de coordenadas de posición y textura (8 y 4 bytes respectivamente) y BYTE para almacenar datos normales y tangentes (4 bytes cada uno), para un total de 20 bytes por vértice, lo que generalmente funciona. Ignorar el impacto en la calidad.

Debido a que la extensión no proporciona una manera de especificar FLOAT y versiones cuantificadas de los datos, los archivos que usan la extensión deben especificarla en la matriz extensionsRequired; la extensión no es opcional.

• KHR_texture_basisu

La extensión KHR_texture_basisu agrega la capacidad de especificar texturas usando imágenes KTX v2 con súper compresión Basis Universal. Las implementaciones de esta extensión pueden utilizar imágenes como reemplazo de las imágenes PNG o JPEG disponibles en glTF 2.0 para aumentar la eficiencia de la transferencia de recursos y reducir el uso de memoria de la GPU. Además, es posible especificar niveles de mapa mip.

Al usar la extensión, se permite usar el valor image/ktx2 como atributo mimeType de una imagen a la que hace referencia el atributo fuente del objeto de extensión de textura KHR_texture_basisu.

En tiempo de ejecución, el motor debe transcodificar el formato de textura universal a uno de los formatos de textura comprimidos en bloques admitidos por la plataforma. Puede utilizar BasisViewer para ver texturas en formato Basis en línea.

• KHR_textura_transformación

Se pueden utilizar muchas técnicas para optimizar el uso de recursos de escenas 3D. La principal de ellas es la capacidad de minimizar la cantidad de texturas que la GPU debe cargar. Para lograr esto, muchos motores recomiendan empaquetar texturas de baja resolución para muchos objetos en un único atlas de texturas grande. El área del atlas generado correspondiente a cada objeto se define luego por los desplazamientos verticales y horizontales y el ancho y alto del área.

Para admitir este caso de uso, la extensión KHR_texture_transform agrega propiedades de desplazamiento, rotación y escala a la estructura texturaInfo. Estas propiedades generalmente se implementan como transformaciones afines en coordenadas UV. En GLSL:

varying in vec2 Uv;

uniform vec2 Offset, Scale;
uniform float Rotation;

mat3 translation = mat3(1,0,0, 0,1,0, Offset.x, Offset.y, 1);
mat3 rotation = mat3(
    cos(Rotation), sin(Rotation), 0,
   -sin(Rotation), cos(Rotation), 0,
                0,             0, 1
);
mat3 scale = mat3(Scale.x,0,0, 0,Scale.y,0, 0,0,1);

mat3 matrix = translation * rotation * scale;
vec2 uvTransformed = ( matrix * vec3(Uv.xy, 1) ).xy;

Esto es equivalente a Material#SetTextureOffset y Material#SetTextureScale de Unity, o Texture#offset y Texture#repeat de Three.js. A partir de ahora, la rotación UV no es ampliamente compatible, pero se incluye aquí para compatibilidad futura.

• KHR_xmp_json_ld

La extensión KHR_xmp_json_ld agrega soporte para metadatos XMP (Plataforma de metadatos extensible) (ISO 16684-1) a glTF. Los metadatos se utilizan para transferir información sobre los activos de glTF (como propiedad, licencia, fecha de creación). Los metadatos no tienen ningún impacto canónico en la apariencia y representación de los recursos glTF.

XMP es una tecnología para incrustar metadatos en documentos y ha sido un estándar ISO desde 2012. Un ejemplo del modelo de datos XMP se denomina paquetes XMP (ISO 16684-1$6.1). Los metadatos XMP están integrados en la extensión glTF de nivel superior como una matriz de paquetes de metadatos. Luego se puede hacer referencia al paquete de metadatos XMP desde objetos glTF de los siguientes tipos: activos, escenas, nodos, mallas, materiales, imágenes, animaciones. Los metadatos XMP a los que hacen referencia los activos de objetos de nivel superior glTF se aplican a todo el activo glTF.

Los metadatos XMP están organizados por espacio de nombres (ISO 16684-1$6.2). Esta extensión permite incrustar cualquier espacio de nombres de metadatos XMP en los activos glTF. El paquete de metadatos XMP en glTF utiliza un conjunto de funciones restringido de JSON-LD. Esto permite que el analizador JSON y el analizador JSON-LD lean paquetes individuales.

La serialización de metadatos XMP mediante JSON-LD se describe en Serialización JSON-LD de XMP (ISO 16684-3). La especificación JSON-LD describe el uso detallado de JSON-LD 1.1. Las limitaciones adicionales de glTF se describen en Limitaciones y recomendaciones de JSON-LD.

• EXT_mesh_gpu_instancia

La extensión EXT_mesh_gpu_instancing está diseñada específicamente para permitir que las instancias de GPU representen múltiples copias de una sola malla a la vez usando una pequeña cantidad de llamadas de dibujo. Es ideal para árboles, césped, señales de tráfico, etc. Las propiedades de traslación, rotación y escala permiten que la malla se muestre en muchas posiciones diferentes con diferentes rotaciones y escalas. Al igual que los atributos de vértice, los atributos de instancia personalizados pueden tener como prefijo un guión bajo (como _ID, _COLOR, etc.) y usarse para efectos específicos de la aplicación.

Si bien esta extensión almacena datos de malla optimizados para instancias de GPU, es importante tener en cuenta que (1) las instancias de GPU y otras optimizaciones son posibles y se recomiendan incluso sin esta extensión, y (2) existen otros significados comunes del término "creación de instancias", a diferencia de esta extensión.

• EXT_meshopt_compression

Los archivos glTF vienen con varios datos binarios (datos de atributos de vértice, datos de índice, deltas de destino de transformación, entrada/salida de animación) que pueden representar una gran parte del tamaño total de la transferencia. Para optimizar el tamaño de entrega, se puede utilizar compresión de propósito general como gzip; sin embargo, normalmente no captura algunos tipos comunes de redundancia en datos binarios glTF.

La extensión EXT_meshopt_compression proporciona una opción general para comprimir datos binarios, personalizada para tipos de datos comunes en buffers glTF. La extensión funciona en el nivel bufferView y, por lo tanto, es independiente de cómo se usan los datos, y admite geometría (datos de índice y vértice, incluidos objetivos de transformación), animación (tiempos y valores de fotogramas clave) y otros datos, como transformaciones de instancias para EXT_mesh_gpu_instancing.

De manera similar a las texturas ultracomprimidas (consulte KHR_texture_basisu), esta extensión supone que los datos de la vista del búfer están optimizados para la eficiencia de la GPU (mediante cuantificación y uso del mejor orden de datos para la representación de la GPU) y proporciona una capa de compresión encima de los datos de bufferView. Cada bufferView se comprime de forma independiente, lo que permite que el cargador descomprima los datos de manera más eficiente directamente en el almacenamiento de la GPU.

Además de optimizar la relación de compresión, el formato de compresión también tiene dos propiedades: decodificación muy rápida (usando WebAssembly SIMD, el decodificador funciona a aproximadamente 1 GB/segundo en hardware de escritorio moderno) y compresión compatible con bytes con almacenamiento universal. Es decir, en lugar de minimizar el tamaño de codificación, el flujo de bits se construye de tal manera que un compresor de uso general pueda comprimirlo aún más.

Esto es beneficioso para escenarios típicos de entrega web donde todos los archivos normalmente se comprimen usando gzip; el códec aquí no lo reemplaza por completo, pero lo mejora y al mismo tiempo reduce el tamaño (esto es útil para optimizaciones cuando la compresión gzip no está disponible, el tamaño de entrega es valioso) y también reduce el impacto en el rendimiento de la descompresión gzip, que normalmente es mucho más lenta que el decodificador propuesto aquí).

• EXT_textura_webp

La extensión EXT_texture_webp permite que los modelos glTF utilicen WebP como formato de imagen válido. Los clientes que no implementen esta extensión pueden ignorar las imágenes WebP proporcionadas y seguir confiando en las texturas PNG y JPG disponibles en la especificación base. Definir una textura alternativa es opcional. La sección Mejores prácticas describe los casos de uso previstos para esta extensión y el comportamiento esperado al usarla sin una textura de respaldo.

WebP es un formato de imagen desarrollado y mantenido por Google que proporciona una excelente compresión sin pérdida y con pérdida para imágenes en la web. Por lo general, es un 26 % más pequeño que PNG y entre un 25 y un 34 % más pequeño que las imágenes JPEG comparables (fuente).

5.2 Extensiones de múltiples proveedores para glTF 2.0

Cuando varios proveedores implementan una extensión, su nombre puede utilizar el prefijo EXT reservado. El marco IP de Khronos generalmente no cubre extensiones de múltiples proveedores, pero hay algunas excepciones notables (enumeradas anteriormente) que han pasado por el proceso de aprobación de Khronos después de ser ampliamente utilizadas bajo el prefijo EXT.

• EXT_luces_ies

La extensión EXT_lights_ies permite el uso de perfiles de luz IES como fuentes de luz dentro de una escena. El perfilado de luz de IES utiliza datos de medición reales de una fuente de luz para describir la distribución de la luz.

Muchas herramientas y motores 3D admiten perfiles de iluminación IES. Con esta extensión, las herramientas pueden exportar y los motores pueden importar escenas que contengan luces descritas por perfiles de luz IES.

Un nodo hace referencia a las configuraciones de luz y heredan la transformación de ese nodo. Describen fuentes puntuales de luz dentro de la escena. Estas fuentes de luz se definen como puntos infinitesimales parametrizados que emiten luz en todas direcciones con intensidad variable angularmente.

Una implementación consistente de esta extensión debe poder cargar los perfiles de luz definidos en los activos y renderizar los activos usando esas luces. Es necesario admitir los siguientes estándares de configuración óptica IES: IES LM-63-95, ANSI/IESNA LM-63-02 y ANSI/IES LM-63-19. La implementación deberá soportar perfiles de luz para fotometría Tipo B y Tipo C. El soporte para perfiles de luz para fotometría Tipo A es opcional. Consulte los detalles de implementación para obtener una lista de campos obligatorios y una descripción de las diferencias relevantes entre las versiones estándar anteriores.

• EXT_luces_imagen_basada

La extensión EXT_lights_image_based proporciona la capacidad de definir luces basadas en imágenes en escenas glTF. La iluminación basada en imágenes consiste en un mapa ambiental que representa el brillo especular de la escena, así como información de irradiancia.

Muchas herramientas y motores 3D admiten iluminación global basada en imágenes, pero las técnicas específicas y los formatos de datos utilizados varían. Con esta extensión, las herramientas pueden exportar y los motores pueden importar luces basadas en imágenes, y los resultados deberían ser muy consistentes.

Esta extensión especifica precisamente una forma de formatear y hacer referencia a los mapas ambientales que se utilizarán. El objetivo de hacer esto es doble. En primer lugar, facilita la implementación del soporte para esta extensión. En segundo lugar, garantiza que la representación de la iluminación basada en imágenes se mantenga constante en tiempo de ejecución.

Una implementación consistente de esta extensión debe poder cargar datos ambientales basados ​​en imágenes y renderizar materiales PBR con esta iluminación.

5.3 Extensiones de proveedores para glTF 2.0

La lista de prefijos de proveedores se mantiene en Prefixes.md. Cualquier proveedor (no sólo los miembros de Khronos) puede solicitar un prefijo de extensión enviando un problema en GitHub. La solicitud debe incluir:

• El nombre del prefijo.
• El nombre del proveedor que solicita el prefijo.
• URL del proveedor y/o información de contacto.

El marco de propiedad intelectual de Khronos no cubre extensiones de proveedores.

• ADOBE_materials_clearcoat_specular

La extensión ADOBE_materials_clearcoat_specular define un método para controlar el índice de refracción (IOR) y la F0 especular de la capa transparente proporcionada por la extensión KHR_materials_clearcoat. Esto anula el IOR predeterminado de la capa transparente (1,5) y también proporciona una manera de modular la reflectancia F0. Esta es exactamente la misma forma en que las extensiones KHR_materials_ior y KHR_materials_specular trabajan juntas para modificar la reflectancia F0.

• ADOBE_materials_thin_transparency

Muchos materiales ópticamente transparentes no se pueden representar de una manera físicamente razonable con materiales centrales glTF 2.0 PBR. Las superposiciones alfa (expuestas a través del canal alfa de baseColorTexture) son útiles para materiales transparentes que no reflejan, refractan, absorben ni dispersan la luz (como la gasa). Sin embargo, la mayoría de los materiales físicos no entran en esta categoría. El vidrio transparente y el plástico son buenos ejemplos. En el caso más sencillo, los reflejos especulares de la superficie del vidrio siguen siendo visibles sobre una malla completamente transparente. El uso de una cobertura Alfa del 0 % también hará que los reflejos sean invisibles.

La extensión ADOBE_materials_thin_transparency está diseñada para abordar el caso de uso más simple y común de la transparencia óptica: materiales delgados sin dispersión compleja (por ejemplo, dispersión dinámica) o dispersión. Trabajar específicamente con materiales "delgados" (es decir, materiales donde solo se considera la superficie y no el volumen) permite muchas simplificaciones en el cálculo de aspectos como la refracción y la absorción.

• AGI_uniones

La extensión AGI_articulations define los nombres y rangos de grados de libertad para todos los nodos móviles del modelo.

En glTF 2.0, el sistema de animación central apunta a patrones de uso típicos de la industria gráfica, donde el autor del modelo decide en el momento de la creación qué partes del modelo se moverán y la naturaleza exacta y el momento de esos movimientos. No permite casos en los que el autor designa partes del modelo como móviles, pero su movimiento exacto no se conoce hasta después de construir el modelo.

Consideremos, por ejemplo, el caso de una antena parabólica montada sobre un soporte motorizado. Al construir un modelo, el autor del modelo puede saber que el plato puede apuntar en ciertas direcciones, pero puede no saber (hasta que el plato se use activamente) hacia dónde apunta en un momento dado. El modelo glTF de este plato necesita indicar los nombres y límites de los movimientos disponibles, pero el modelo no contiene la secuencia real de movimientos a realizar, que puede no conocerse hasta el tiempo de ejecución o una simulación en tiempo real del plato en funcionamiento. .

En este caso, decimos que el modelo está articulado y necesitamos articulación para definir el nombre y el rango de movimientos permitidos (grados de libertad) para todos los nodos móviles del modelo. Aplicar uniones a un nodo no impide aplicar glTF Core Animation al mismo nodo, si se desea. Las implementaciones son libres de elegir cómo y cuándo aplicar las uniones disponibles, y se espera que esta información esté fuera del archivo glTF (de lo contrario, simplemente se puede codificar como una animación).

• AGI_stk_metadata

La extensión AGI_stk_metadata agrega metadatos adicionales a los modelos glTF. Estos metadatos están destinados a coincidir 1:1 con la funcionalidad existente del producto STK (System Tool Kit) producido por Analytical Graphics, Inc.

• CESIUM_primitivo_esquema

Los objetos 3D no fotorrealistas, como los edificios sin textura, suelen ser más atractivos visualmente cuando sus bordes están delineados. Una forma sencilla de agregar contornos a un modelo glTF es agregar primitivas adicionales de tipo LINES al modelo, dibujando líneas a lo largo de los bordes a los que se les dará contorno. Desafortunadamente, la calidad visual de este enfoque es bastante pobre porque la profundidad de la línea entra en conflicto con los triángulos. La rasterización de las líneas no coincide con la rasterización de los bordes del triángulo.

Conflicto de profundidad entre líneas y triángulos representados por separado

La forma tradicional de evitar conflictos tan profundos es utilizar glPolygonOffset o métodos similares. Sin embargo, glTF 2.0 no admite la especificación de desplazamientos de polígonos. Incluso si así fuera (o si se definiera una extensión para admitirlo), sería difícil obtener una representación de alta calidad utilizando este enfoque. Dependiendo del valor de desplazamiento del polígono seleccionado, las líneas en la parte posterior pueden "sangrarse" hacia el frente porque la desviación de profundidad es demasiado grande, o las líneas pueden adquirir una apariencia punteada porque la desviación de profundidad es demasiado pequeña. Incluso con un ajuste cuidadoso de los valores de desplazamiento del polígono, a menudo es posible detectar ambos problemas en una sola escena.

Incluso si estos artefactos se consideran tolerables, renderizar primitivas de líneas individuales aumenta el número de llamadas de dibujo necesarias para renderizar la escena. Además, en algunos hardware, dibujar líneas es mucho más lento que dibujar triángulos.

La extensión CESIUM_primitive_outline indica al motor de renderizado la lista de lados del triángulo que se deben delinear. Aunque no dicta cómo se debe realizar el renderizado, el hecho de que todas las líneas sean en realidad bordes de triángulos permite que el motor de renderizado utilice técnicas más rápidas y de mayor calidad para renderizar las líneas sin tener que inferir la aplicabilidad de dichas técnicas en tiempo de ejecución.

• FB_geometría_metadatos

La extensión FB_geometry_metadata anota objetos de escena glTF con un resumen de la complejidad geométrica acumulada del gráfico de escena asociado a la escena y la extensión del espacio de la escena. Cada malla a la que se hace referencia de forma recursiva se enumera para obtener el número total de vértices y primitivos, y cada vértice individual se transforma en un espacio de escena para obtener un cuadro delimitador perfectamente calculado.

Algunas aplicaciones prácticas comprobadas de esta información:

1. Cuando el espectador necesita tomar una decisión rápida y de alto nivel sobre qué escena mostrar. Quizás esto sea más significativo, por ejemplo, cuando la escena se utiliza para representar diferentes variaciones del modelo (como los niveles LoD).
2. Cuando el sistema del lado del servidor necesita tomar decisiones basadas en la complejidad geométrica y no quiere incluir su propio código matricial/vectorial complejo.

• MPEG_accessor_timed

Los descriptores de acceso en glTF definen el tipo y el diseño de los datos almacenados en el búfer vistos a través de bufferView. Al leer datos de temporización de un búfer, los datos del búfer pueden cambiar dinámicamente con el tiempo.

Las escenas que contienen medios y/o metadatos cronometrados deben utilizar la extensión de acceso temporizado MPEG_accessor_timed para describir el acceso a datos que cambian dinámicamente. MPEG_accessor_timed es una extensión del descriptor de acceso normal que indica que el búfer de datos subyacente es dinámico. Tenga en cuenta que el descriptor de acceso cronometrado tiene dos bufferViews, uno heredado del descriptor de acceso contenedor y el otro en la extensión MPEG_accessor_timed. El primero se utiliza para hacer referencia a datos de medios cronometrados. Este último se puede utilizar para apuntar a un encabezado de búfer dinámico, que puede estar presente o no. Cuando están presentes, ambos bufferViews deben apuntar al mismo búfer circular.

El campo accessor.bufferView en los descriptores de acceso con la extensión MPEG_accessor_timed y el campo de encabezado de información del descriptor de acceso temporizado se aplican a cada cuadro de datos en el búfer circular.

Las extensiones de acceso temporizadas se identifican mediante MPEG_accessor_timed.

• MPEG_animación_timing

La extensión MPEG_animation_timing admite la alineación entre la línea de tiempo de los medios y la línea de tiempo de la animación definida por glTF 2.0. Utilice extensiones para crear historias que usted cuente. Los metadatos de sincronización de animación pueden permitir pausar y otras operaciones en animaciones definidas en glTF 2.0 y medios simultáneamente.

• MPEG_audio_espacial

La extensión MPEG_audio_spatial agrega soporte para audio espacial, que puede incluirse en la parte superior o adjuntarse a cualquier nodo de la escena.

• MPEG_buffer_circular

Para admitir el acceso a datos temporizados, el elemento de búfer se amplía para proporcionar la funcionalidad de un búfer circular. La extensión MPEG_buffer_circular se puede incluir como parte del búfer. Los buffers que brindan acceso a datos de sincronización deben incluir la extensión MPEG_buffer_circular.

• MPEG_medios

MPEG_media proporciona una serie de elementos multimedia MPEG a los que hacen referencia otras extensiones en el documento glTF.

• MPEG_mesh_enlace

La extensión MPEG_mesh_linking brinda la posibilidad de vincular una malla a otra malla en un recurso glTF.

La malla sombreada corresponde a los datos de malla regular definidos por glTF 2.0, sin la extensión MPEG_mesh_linking. Las mallas dependientes se pueden transformar/animar basándose en mallas de sombra. La extensión MPEG_mesh_linking incluida en la malla esclava vincula la malla esclava y la malla de sombra y proporciona los datos y la información utilizados para implementar la capacidad de animar la malla esclava. Por lo tanto, existen mallas de sombra en los recursos glTF para facilitar la capacidad de aplicar transformaciones a las mallas esclavas.

• MPEG_escena_dinámica

Enlace de extensión MPEG_scene_dynamic.

• MPEG_textura_vídeo

La extensión MPEG_texture_video brinda la posibilidad de vincular objetos de textura definidos en glTF 2.0 a los medios y sus pistas correspondientes (enumeradas por MPEG_media). La extensión MPEG_texture_video también proporciona una referencia a un descriptor de acceso cronometrado, es decir, un descriptor de acceso con la extensión MPEG_accessor_timed, donde estarán disponibles texturas cronometradas decodificadas.

Cuando la extensión MPEG_texture_video no es compatible, el búfer de textura debe llenarse con datos descritos por un objeto fuente glTF estándar.

• MPEG_viewport_recomendado

La extensión MPEG_viewport_recommished proporciona un enlace desde el objeto de la cámara definido en glTF 2.0 a la información de la ventana gráfica recomendada haciendo referencia a un acceso cronometrado donde estará disponible una muestra de la información de la ventana gráfica recomendada.

La información de la ventana gráfica recomendada proporciona información que cambia dinámicamente, incluida la traslación y rotación del nodo que contiene el objeto de la cámara, así como los parámetros intrínsecos de la cámara del objeto de la cámara. El cliente representa la ventana gráfica basándose en información que cambia dinámicamente.

Nota: Otra forma de implementar la ventana gráfica recomendada es definir animaciones para los nodos con cámaras adjuntas. Sin embargo, este método no admite el cambio dinámico de la cámara interna y debe definirse durante la creación del objeto glTF.

• MSFT_lod

La extensión MSFT_lod agrega la capacidad de especificar varios niveles de detalle (LOD) para los recursos glTF. Las implementaciones de esta extensión pueden usar LOD para varios escenarios, como renderizar diferentes LOD según la distancia de los objetos o cargar recursos glTF de forma incremental comenzando desde el LOD más bajo.

Esta extensión permite definir LOD en el nodo de geometría o nivel de material. Los LOD de nodo pueden especificar diferentes geometrías y materiales en diferentes niveles, mientras que los LOD de material pueden especificar diferentes materiales para la misma geometría.

La extensión MSFT_lod se agrega al nivel LOD más alto. La extensión define un atributo ids, que es una matriz que contiene los índices de los niveles LOD inferiores. Cada valor de la matriz apunta a un nivel LOD con menor calidad que el nivel anterior. Por ejemplo, si las extensiones se definen a nivel de nodo, el objeto de nodo con la extensión es el nivel LOD más alto. Cada valor especificado en la matriz de identificadores expandida apunta a un índice en otro objeto de nodo que debe usarse como un nivel LOD inferior.

Las implementaciones de esta extensión pueden analizar la matriz de identificadores para crear una lista de niveles LOD que se pueden usar para el activo. Si un recurso que contiene esta extensión se carga en un cliente que no implementa la extensión, se cargará el nivel de LOD más alto y se ignorarán todos los LOD inferiores.

• MSFT_packing_normalRugosidadMetálico

La extensión MSFT_packing_normalRoughnessMetallic agrega compatibilidad con el empaquetado de texturas alternativo y está diseñada para usarse con Windows Mixed Reality Home y el iniciador 3D para Windows Mixed Reality.

Esta extensión define propiedades adicionales de normalRoughnessMetallicTexture. Esta propiedad especifica el índice de una textura con envoltura normal (RG), rugosidad (B), metálica (A). Este contenedor especializado está destinado a proporcionar una alternativa optimizada al contenedor especificado en la especificación principal glTF 2.0.

Esta extensión solo debe usarse al crear recursos glTF para motores que admitan este paquete y no es una extensión de paquete genérica. Cualquier cliente que no admita esta extensión puede ignorar con seguridad estas texturas empaquetadas adicionales y confiar en el empaquetado predeterminado en glTF 2.0. Esta extensión también se puede utilizar con otras extensiones como MSFT_texture_dds para almacenar texturas empaquetadas en archivos DDS.

• MSFT_packing_occlusionRugosidadMetálico

La extensión MSFT_packing_occlusionRoughnessMetallic agrega compatibilidad con el empaquetado de texturas alternativo y está diseñada para usarse con Windows Mixed Reality Home y el iniciador 3D para Windows Mixed Reality.

Esta extensión define tres propiedades adicionales:

1. occlusionRoughnessMetallicTexture: índice que especifica una textura con occlusion® empaquetada, rugosidad (G), metálica (B)
2. rugosidadMetallicOcclusionTexture: Índice que especifica una textura con rugosidad empaquetada®, Metálico(G), Oclusión(B)
3. normalTexture: especifica el índice de la textura que contiene el mapa normal de dos canales (RG).

Esta extensión solo debe usarse al crear recursos glTF para motores que admitan este paquete y no es una extensión de paquete genérica. Cualquier cliente que no admita esta extensión puede ignorar con seguridad estas texturas empaquetadas adicionales y confiar en el empaquetado predeterminado en glTF 2.0. Esta extensión también se puede utilizar con otras extensiones como MSFT_texture_dds para almacenar texturas empaquetadas en archivos DDS.

• MSFT_textura_dds

La extensión MSFT_texture_dds agrega la capacidad de especificar texturas utilizando el formato de archivo DirectDraw Surface (DDS). Las implementaciones de esta extensión pueden usar texturas proporcionadas en archivos DDS como alternativa a las texturas PNG o JPG disponibles en glTF 2.0.

Esta extensión se agrega al nodo de textura y especifica un atributo de origen que apunta al índice del nodo de imagen, que a su vez apunta al archivo de textura DDS. Los clientes que no comprendan esta extensión pueden ignorar el archivo DDS y seguir confiando en la textura PNG o JPG especificada.

• NV_materiales_mdl

La extensión NV_materials_mdl proporciona la capacidad de almacenar y transferir materiales en recursos glTF, que se definen en el lenguaje de definición de materiales (MDL) de NVIDIA, tal como se define en la especificación del lenguaje MDL. El propósito de esta extensión es proporcionar definiciones de materiales de alta calidad en glTF para aplicaciones y renderizadores compatibles con MDL, además del modelo estándar glTF 2.0 PBR.

Los materiales MDL se definen en módulos MDL, que se almacenan en archivos con una extensión de archivo .mdl. Las referencias a archivos .mdl se resuelven dentro del contexto de configuración de una implementación conforme, específicamente utilizando las rutas de búsqueda documentadas en el Apéndice F de la Especificación del lenguaje MDL. Como alternativa, los módulos MDL también se pueden integrar en los activos. Los materiales MDL pueden aceptar texturas y otros recursos como parámetros de entrada. Esta extensión utiliza texturas JPG y PNG para imágenes en el estándar central glTF 2.0. Además, si se utiliza esta extensión, los objetos de imagen pueden hacer referencia a recursos EXR y VDB utilizando los tipos de medios image/x-exr y application/x-vdb respectivamente. La extensión EXT_lights_ies es para perfiles de luz IES y los datos BSDF de medición isotrópica MBSDF definidos en el Apéndice B de la Especificación del lenguaje MDL son parte de esta extensión.

Una implementación conforme de esta extensión debe poder cargar módulos MDL referenciados, verificar que las llamadas a funciones referenciadas y los tipos definidos por el usuario tengan definiciones compatibles en esos módulos MDL y usar estas funciones en el enlace de material referenciado para representar la malla en consecuencia. El material reemplaza el material estándar glTF PBR. Las llamadas a funciones se validan con módulos MDL verificando si la llamada con parámetros de tipo encuentra una definición de función coincidente (incluida la resolución de sobrecarga como se define en la Sección 12.4 de la Especificación del lenguaje MDL). Valide los tipos definidos por el usuario con un módulo MDL verificando si todos los campos o valores de enumeración del tipo correspondiente existen en el módulo MDL.

Dado que el material MDL reemplaza el material glTF estándar, se recomienda encarecidamente que las aplicaciones de creación también proporcionen un material PBR glTF estándar muy similar junto con el material MDL, de modo que las implementaciones que no comprendan esta extensión aún puedan mostrar una representación representativa de este archivo glTF. . Sin embargo, definir el material de reserva es opcional. La sección de Mejores Prácticas proporciona más detalles sobre este tema.

Los materiales MDL se definen mediante funciones en el lenguaje que devuelven materiales de tipo integrado. Esta extensión opera en llamadas a funciones definidas en el módulo MDL al que se hace referencia. Estas llamadas a funciones se definen en el atributo de matriz functionCalls, que se define en el objeto de extensión NV_materials_mdl de nivel superior. Los módulos para llamadas a funciones y referencias de tipos se definen en la matriz de módulos. Finalmente, los recursos de medición de BSDF se definen en la matriz bsdfMeasurements.

5.4 Extensión de archivo para glTF 2.0

Las extensiones archivadas pueden ser útiles para leer archivos glTF más antiguos, pero ya no se recomienda su uso para crear archivos nuevos.

• KHR_materials_pbrBrillo Especular

La extensión KHR_materials_pbrSpecularGlossiness define el modelo de material de brillo especular para renderizado basado físicamente (PBR). Esta extensión permite que glTF admita este flujo de trabajo adicional.

• KHR_techniques_webgl

La extensión KHR_techniques_webgl permite a glTF definir instancias de técnicas de sombreado utilizando programas de sombreado externos y sus valores parametrizados. La tecnología de sombreado utiliza atributos JSON para describir los tipos de datos y la semántica de los programas de sombreado de fragmentos y vértices GLSL.

Esta especificación de extensión está dirigida a WebGL 1.0 y puede ser compatible con cualquier motor basado en WebGL 1.0 si el dispositivo admite las extensiones WebGL necesarias.

• KHR_xmp

La extensión KHR_xmp agrega soporte para metadatos XMP (Plataforma de metadatos extensible) (ISO 16684-1) a glTF. Los metadatos se utilizan para transferir información sobre los activos de glTF (como propiedad, licencia, fecha de creación). Los metadatos no tienen ningún impacto canónico en la apariencia y representación de los recursos glTF.

XMP es una tecnología para incrustar metadatos en documentos y ha sido un estándar ISO desde 2012. Un ejemplo del modelo de datos XMP se denomina paquetes XMP (ISO 16684-1$6.1). Los metadatos XMP están integrados en la extensión glTF de nivel superior como una matriz de paquetes de metadatos. Luego se puede hacer referencia al paquete de metadatos XMP desde objetos glTF de los siguientes tipos: activos, escenas, nodos, mallas, materiales, imágenes, animaciones. Los metadatos XMP a los que hacen referencia los activos de objetos de nivel superior glTF se aplican a todo el activo glTF. Los metadatos XMP están organizados por espacio de nombres (ISO 16684-1$6.2).

Esta extensión permite incrustar cualquier espacio de nombres de metadatos XMP en los activos glTF.

5.5 Khronos en curso y extensiones de múltiples proveedores para glTF 2.0

Khronos (KHR) El proyecto de prórroga aún no ha sido aprobado. Las extensiones de múltiples proveedores (EXT) no requieren aprobación, pero aún pueden cambiar antes de completarse.

Esta sección rastrea el estado de Khronos y las extensiones de múltiples proveedores que ya están en desarrollo o que creemos que muestran suficiente consenso para tener una alta probabilidad de ser utilizadas en un desarrollo futuro. Agradecemos sus comentarios sobre estas y todas las demás extensiones (consulte los problemas de GitHub). Esta lista tiene como objetivo proporcionar una visión general de las prioridades y direcciones actuales.

Para las funciones que no se enumeran aquí pero que pueden ser importantes para diferentes usos, animamos a la comunidad a comenzar con una extensión del proveedor (no se requiere revisión), buscar comentarios y colaboradores y, como forma de consenso, podemos considerar la mejor manera de llevar la Las extensiones de proveedor a proveedor introducen un ecosistema más amplio: a través de extensiones de múltiples proveedores, extensiones de Khronos o la inclusión en versiones futuras de la especificación glTF.

Expandir	estado
KHR_animation_pointer	Prepárese para la prueba
KHR_audio	Prepárese para la prueba
KHR_materiales_transmision_difusa	Prepárese para la prueba
KHR_materiales_sss	en desarrollo

---

Enlace original: La guía definitiva para la extensión GLTF: BimAnt