拓冰网站定制 
图形学【免费下载链接】glTFglTF – Runtime 3D Asset Delivery项目地址https://gitcode.com/gh_mirrors/gl/glTF点击查看免费下载导读KHR_texture_basisu 是 Khronos Group 官方已批准Ratified的 glTF 2.0 扩展它允许 glTF 资产使用携带 Basis Universal 超压缩数据的 KTX v2 图像作为纹理来源从而显著降低资产传输体积与 GPU 内存占用并原生支持 mip 金字塔。读完本文你将掌握该扩展的完整 JSON 用法含回退与无回退两种模式、KTX v2 头部与 DFDData Format Descriptor字段的规范性要求、ETC1S 与 UASTC 两种通用纹理格式的选型策略以及 glTF 材质贴图的兼容性约束能够据此写出可直接被 three.js、Babylon、PlayCanvas 等运行时正确消费的纹理声明。扩展定位为运行时资产交付而生的纹理压缩方案该扩展的规范文本位于 extensions/2.0/Khronos/KHR_texture_basisu/README.md并在 extensions/README.md 的 Ratified Khronos Extensions 列表中正式登记状态为 Complete, Ratified by the Khronos Group依赖 glTF 2.0 规范。它解决的问题非常具体传输效率KTX v2 图像携带 Basis Universal 超压缩数据作为 PNG 或 JPEG 的可选替代品可明显减小网络传输字节数GPU 内存占用通用纹理格式可被运行时转码为平台支持的块压缩格式如 ASTC、BC7比解码为未压缩 RGBA 更省显存mip 金字塔KTX v2 容器天然支持多级 mip 数据这是 PNG/JPEG 单图像格式难以直接承载的能力。与同仓库中的KHR_meshopt_compression在 extensions/2.0/Khronos/KHR_meshopt_compression/README.md 中将其与超压缩纹理并列说明互补后者压缩 bufferView 中的几何/动画二进制数据而本扩展压缩的是图像纹理数据二者都假设底层数据面向 GPU 优化在其上再叠一层压缩。从运行机制上看扩展并不要求渲染器直接理解 Basis Universal 编码而是约定运行时引擎应将通用纹理格式转码为平台支持的块压缩纹理格式。也就是说KTX v2 文件是传输与存储形态最终上屏前由引擎完成转码这就是超压缩supercompression的语义。glTF Schema 更新与 JSON 用法KHR_texture_basisu扩展挂在 glTF 的textures对象上通过一个source属性指向某个image的索引该 image 引用一份携带 Basis Universal 超压缩的 KTX v2 图像。其官方 JSON Schema 位于 extensions/2.0/Khronos/KHR_texture_basisu/schema/texture.KHR_texture_basisu.schema.json整个扩展对象只声明一个属性属性类型说明sourceintegerglTF id最小值 0指向 KTX v2 资源带 Basis Universal 超压缩的 image 索引Schema 继承自glTFProperty.schema.json因此扩展对象同样允许可选的extensions与extras子属性符合 glTF 扩展机制参见 extensions/README.md 的 Extension Mechanics 一节。source索引的类型定义复用核心规范中的 specification/2.0/schema/glTFid.schema.json与核心texture.source完全一致。带回退的标准用法推荐核心texture.source保留 PNG/JPEG 回退图扩展source提供 KTX v2 主图。支持该扩展的客户端加载image.ktx2不支持的客户端自动回退到image.png{ asset: { version: 2.0 }, extensionsUsed: [ KHR_texture_basisu ], textures: [ { source: 0, extensions: { KHR_texture_basisu: { source: 1 } } } ], images: [ { uri: image.png }, { uri: image.ktx2 } ] }注意此模式下extensionsUsed中列出扩展即可不应将其写入extensionsRequired否则不支持扩展的加载器会判定资产不可加载回退机制便失去意义——这与 extensions/README.md 对required 扩展的界定一致仅当缺少该扩展导致资产无法加载时才必须声明为 required。GLB 二进制容器中的用法在 glTF BinaryGLB格式中图像通过 bufferView 内嵌存储此时引用 KTX v2 资源的 image 必须使用mimeType值为image/ktx2{ asset: { version: 2.0 }, extensionsUsed: [ KHR_texture_basisu ], textures: [ { source: 0, extensions: { KHR_texture_basisu: { source: 1 } } } ], images: [ { mimeType: image/png, bufferView: 1 }, { mimeType: image/ktx2, bufferView: 2 } ] }从 specification/2.0/schema/image.schema.json 的约束看核心mimeType只硬性限定image/jpeg与image/png但允许任意字符串扩展这正是image/ktx2得以作为扩展 MIME 类型合法存在的依据同时bufferView定义时mimeType必填、且bufferView与uri二者只能取其一oneOf约束。无回退的强制用法当 KTX v2 是唯一纹理来源时需同时将KHR_texture_basisu写入extensionsUsed与extensionsRequired核心texture.source必须省略依据核心 specification/2.0/schema/texture.schema.jsonsource未定义时须由扩展或其他机制提供替代纹理源否则行为未定义——本扩展正是其他机制{ asset: { version: 2.0 }, extensionsUsed: [ KHR_texture_basisu ], extensionsRequired: [ KHR_texture_basisu ], textures: [ { extensions: { KHR_texture_basisu: { source: 0 } } } ], images: [ { uri: image.ktx2 } ] }两种 Basis Universal 格式ETC1S 与 UASTC为了覆盖广泛的使用场景扩展允许两种 Basis Universal 格式格式超压缩方案supercompressionScheme典型用途ETC1S BasisLZ1BasisLZ尺寸优先适合颜色类贴图UASTC可选 Zstandard0None或2Zstandard质量优先适合法线、粗糙度-金属度等非颜色数据纹理类型的语义定义规范按通道使用情况定义了四种纹理类型并约束各自的 sRGB 编码能力RGB仅使用 R、G、B 通道Alpha 恒等于1.0255或运行时不被采样。可以使用 sRGB 传输函数。典型对应核心贴图baseColorTexture不透明场景、normalTexture、emissiveTexture、metallicRoughnessTexture与occlusionTexture合并时。RGBA四个通道全部使用。可以使用 sRGB 传输函数不作用于 Alpha。典型对应baseColorTexture非不透明场景。Red仅使用 R 通道其余通道不被采样。禁止使用 sRGB 传输函数。典型对应独立使用的occlusionTexture。Red-Green仅使用 R、G 通道B、A 不被采样。禁止使用 sRGB 传输函数。核心 glTF 2.0 规范中暂无此类贴图示例。ETC1S with BasisLZ 负载的 KTX 头部字段要求supercompressionScheme必须为1BasisLZDFDcolorModel必须为KHR_DF_MODEL_ETC1SDFD 通道按纹理类型对应纹理类型必需 DFD 通道RGB单个KHR_DF_CHANNEL_ETC1S_RGBRGBA两个KHR_DF_CHANNEL_ETC1S_RGBKHR_DF_CHANNEL_ETC1S_AAARed单个KHR_DF_CHANNEL_ETC1S_RRRRed-Green两个KHR_DF_CHANNEL_ETC1S_RRRKHR_DF_CHANNEL_ETC1S_GGGUASTC 负载的 KTX 头部字段要求supercompressionScheme必须为0None或2ZstandardDFDcolorModel必须为KHR_DF_MODEL_UASTCDFD 通道按纹理类型对应纹理类型必需 DFD 通道RGB单个KHR_DF_CHANNEL_UASTC_RGBRGBA单个KHR_DF_CHANNEL_UASTC_RGBARed单个KHR_DF_CHANNEL_UASTC_RRRRed-Green单个KHR_DF_CHANNEL_UASTC_RG附加兼容性要求无论何种格式为保证跨实现兼容以下限制对两种格式一律适用Swizzle 元数据KTXswizzle必须为rgba或省略方向元数据KTXorientation必须为rd或省略DFD 色彩空间信息必须与实际用途匹配颜色数据如 base color 贴图colorPrimaries必须为KHR_DF_PRIMARIES_BT709transferFunction必须为KHR_DF_TRANSFER_SRGB非颜色数据如法线贴图colorPrimaries必须为KHR_DF_PRIMARIES_UNSPECIFIEDtransferFunction必须为KHR_DF_TRANSFER_LINEAR。mip 金字塔当纹理引用的 sampler 使用 mipmap 缩小过滤参见 specification/2.0/schema/sampler.schema.json 中minFilter的 9984/9985/9986/9987 等 mipmap 模式或 sampler 未定义时KTX 图像应当包含完整 mip 金字塔。规范给出的实现说明指出若缺少完整 mip 链引擎可能需要在运行时解压纹理并现场生成缺失的 mip 级别。尺寸对齐pixelWidth和pixelHeight必须为 4 的倍数。实现说明建议导出器优先将尺寸设为 2 的幂配合完整 mip 链可达到最大兼容性。用于材质贴图时的附加规则当引用 KTX v2 超压缩图像的纹理用于 glTF 2.0 材质贴图无论颜色还是非颜色贴图时KTX v2 图像必须是 KTX v2 规范第 4.1 节定义的2D类型除非材质规范要求预乘 Alpha否则不得设置KHR_DF_FLAG_ALPHA_PREMULTIPLIED标志导出器应当依据贴图用途与内容选择最合适的通用纹理格式。规范给出的实现说明是一般性经验法则颜色数据贴图使用 ETC1S非颜色数据贴图如粗糙度-金属度、法线贴图使用 UASTC当运行时缺少高质量 GPU 格式ASTC 或 BC7时引擎应当将携带非颜色数据的 UASTC 纹理转码为未压缩 RGBA以避免质量伪影。已知实现规范文档列出的生态实现可帮助判断工具链兼容性名称保留自原文档不附外部链接作者/导出工具Authoringgltfpack来自 meshoptimizer 项目glTF-Transform CLIGestaltorRapidCompact查看/运行时ViewingBabylonPlayCanvasthree.js延伸资源KTX 文件格式规范 v2KTX File Format Specification, version 2由 Khronos 维护定义了 KTX v2 容器结构、DFD、supercompressionScheme 等本扩展依赖的底层字段KTX 参考软件KTX Reference Software / KTX-Software官方参考实现提供 KTX v2 编解码、Basis Universal 转码能力可用于验证导出的 KTX v2 文件是否符合本扩展的头部与 DFD 要求。附录Khronos 版权声明摘要本规范文档含 KHR_texture_basisu 扩展说明版权归 2020 The Khronos Group Inc. 所有。规范中部分内容为纯信息性描述标记为非规范性或Implementation Notes不构成合规性要求。规范受版权法保护未经 Khronos 书面许可不得以任何方式复制、再发布、分发、传输、展示、广播或利用其任何组成部分。Khronos 依据 Khronos 知识产权政策授予有条件版权许可允许为任何目的使用和复制未经修改的规范但不授予任何专利、商标或其他知识产权的许可希望实施规范并享受 Khronos 商标互惠专利许可保护的各方须成为 Adopter 并通过一致性确认流程。完整声明见 extensions/2.0/Khronos/KHR_texture_basisu/README.md 的 Appendix 部分许可证文本另见 LICENSES/LicenseRef-KhronosSpecCopyright.txt。赞分享图形学【免费下载链接】glTFglTF – Runtime 3D Asset Delivery项目地址https://gitcode.com/gh_mirrors/gl/glTF点击查看免费下载相关推荐three.js 中 Basis Universal GPU 纹理压缩与 KTX2 转码实战three.js 中 Basis Universal GPU 纹理压缩与 KTX2 转码实战 Basis Universal 是一套面向 GPU 纹理与纹理视频前端3D渲染图形学【亲测免费】 开源项目推荐Basis Universal超级压缩GPU纹理编码器开源项目推荐Basis Universal超级压缩GPU纹理编码器 在游戏开发和图形处理领域中纹理数据的管理和优化至关重要。今天要介绍的是一个极其强大的工具glTF 2.0 EXT_texture_webp 扩展实战指南用 WebP 压缩纹理、缩小传输体积并优雅降级glTF 2.0 EXT_texture_webp 扩展实战指南用 WebP 压缩纹理、缩小传输体积并优雅降级 本篇技术指南聚焦 glTF 官方扩展仓库gl图形学上一篇macOS 菜单栏整理神器 Ice 上手指南5 分钟把状态栏变成你想要的样子下一篇DLL报错刷屏的时代结束了Visual C 运行库一键安装VisualCppRedist AIO 使用全攻略创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 glTF 2.0 KHR_texture_basisu 扩展详解：用 KTX v2 + Basis Universal 超压缩纹理替代 PNG/JPEG
图形学【免费下载链接】glTFglTF – Runtime 3D Asset Delivery项目地址https://gitcode.com/gh_mirrors/gl/glTF点击查看免费下载导读KHR_texture_basisu 是 Khronos Group 官方已批准Ratified的 glTF 2.0 扩展它允许 glTF 资产使用携带 Basis Universal 超压缩数据的 KTX v2 图像作为纹理来源从而显著降低资产传输体积与 GPU 内存占用并原生支持 mip 金字塔。读完本文你将掌握该扩展的完整 JSON 用法含回退与无回退两种模式、KTX v2 头部与 DFDData Format Descriptor字段的规范性要求、ETC1S 与 UASTC 两种通用纹理格式的选型策略以及 glTF 材质贴图的兼容性约束能够据此写出可直接被 three.js、Babylon、PlayCanvas 等运行时正确消费的纹理声明。扩展定位为运行时资产交付而生的纹理压缩方案该扩展的规范文本位于 extensions/2.0/Khronos/KHR_texture_basisu/README.md并在 extensions/README.md 的 Ratified Khronos Extensions 列表中正式登记状态为 Complete, Ratified by the Khronos Group依赖 glTF 2.0 规范。它解决的问题非常具体传输效率KTX v2 图像携带 Basis Universal 超压缩数据作为 PNG 或 JPEG 的可选替代品可明显减小网络传输字节数GPU 内存占用通用纹理格式可被运行时转码为平台支持的块压缩格式如 ASTC、BC7比解码为未压缩 RGBA 更省显存mip 金字塔KTX v2 容器天然支持多级 mip 数据这是 PNG/JPEG 单图像格式难以直接承载的能力。与同仓库中的KHR_meshopt_compression在 extensions/2.0/Khronos/KHR_meshopt_compression/README.md 中将其与超压缩纹理并列说明互补后者压缩 bufferView 中的几何/动画二进制数据而本扩展压缩的是图像纹理数据二者都假设底层数据面向 GPU 优化在其上再叠一层压缩。从运行机制上看扩展并不要求渲染器直接理解 Basis Universal 编码而是约定运行时引擎应将通用纹理格式转码为平台支持的块压缩纹理格式。也就是说KTX v2 文件是传输与存储形态最终上屏前由引擎完成转码这就是超压缩supercompression的语义。glTF Schema 更新与 JSON 用法KHR_texture_basisu扩展挂在 glTF 的textures对象上通过一个source属性指向某个image的索引该 image 引用一份携带 Basis Universal 超压缩的 KTX v2 图像。其官方 JSON Schema 位于 extensions/2.0/Khronos/KHR_texture_basisu/schema/texture.KHR_texture_basisu.schema.json整个扩展对象只声明一个属性属性类型说明sourceintegerglTF id最小值 0指向 KTX v2 资源带 Basis Universal 超压缩的 image 索引Schema 继承自glTFProperty.schema.json因此扩展对象同样允许可选的extensions与extras子属性符合 glTF 扩展机制参见 extensions/README.md 的 Extension Mechanics 一节。source索引的类型定义复用核心规范中的 specification/2.0/schema/glTFid.schema.json与核心texture.source完全一致。带回退的标准用法推荐核心texture.source保留 PNG/JPEG 回退图扩展source提供 KTX v2 主图。支持该扩展的客户端加载image.ktx2不支持的客户端自动回退到image.png{ asset: { version: 2.0 }, extensionsUsed: [ KHR_texture_basisu ], textures: [ { source: 0, extensions: { KHR_texture_basisu: { source: 1 } } } ], images: [ { uri: image.png }, { uri: image.ktx2 } ] }注意此模式下extensionsUsed中列出扩展即可不应将其写入extensionsRequired否则不支持扩展的加载器会判定资产不可加载回退机制便失去意义——这与 extensions/README.md 对required 扩展的界定一致仅当缺少该扩展导致资产无法加载时才必须声明为 required。GLB 二进制容器中的用法在 glTF BinaryGLB格式中图像通过 bufferView 内嵌存储此时引用 KTX v2 资源的 image 必须使用mimeType值为image/ktx2{ asset: { version: 2.0 }, extensionsUsed: [ KHR_texture_basisu ], textures: [ { source: 0, extensions: { KHR_texture_basisu: { source: 1 } } } ], images: [ { mimeType: image/png, bufferView: 1 }, { mimeType: image/ktx2, bufferView: 2 } ] }从 specification/2.0/schema/image.schema.json 的约束看核心mimeType只硬性限定image/jpeg与image/png但允许任意字符串扩展这正是image/ktx2得以作为扩展 MIME 类型合法存在的依据同时bufferView定义时mimeType必填、且bufferView与uri二者只能取其一oneOf约束。无回退的强制用法当 KTX v2 是唯一纹理来源时需同时将KHR_texture_basisu写入extensionsUsed与extensionsRequired核心texture.source必须省略依据核心 specification/2.0/schema/texture.schema.jsonsource未定义时须由扩展或其他机制提供替代纹理源否则行为未定义——本扩展正是其他机制{ asset: { version: 2.0 }, extensionsUsed: [ KHR_texture_basisu ], extensionsRequired: [ KHR_texture_basisu ], textures: [ { extensions: { KHR_texture_basisu: { source: 0 } } } ], images: [ { uri: image.ktx2 } ] }两种 Basis Universal 格式ETC1S 与 UASTC为了覆盖广泛的使用场景扩展允许两种 Basis Universal 格式格式超压缩方案supercompressionScheme典型用途ETC1S BasisLZ1BasisLZ尺寸优先适合颜色类贴图UASTC可选 Zstandard0None或2Zstandard质量优先适合法线、粗糙度-金属度等非颜色数据纹理类型的语义定义规范按通道使用情况定义了四种纹理类型并约束各自的 sRGB 编码能力RGB仅使用 R、G、B 通道Alpha 恒等于1.0255或运行时不被采样。可以使用 sRGB 传输函数。典型对应核心贴图baseColorTexture不透明场景、normalTexture、emissiveTexture、metallicRoughnessTexture与occlusionTexture合并时。RGBA四个通道全部使用。可以使用 sRGB 传输函数不作用于 Alpha。典型对应baseColorTexture非不透明场景。Red仅使用 R 通道其余通道不被采样。禁止使用 sRGB 传输函数。典型对应独立使用的occlusionTexture。Red-Green仅使用 R、G 通道B、A 不被采样。禁止使用 sRGB 传输函数。核心 glTF 2.0 规范中暂无此类贴图示例。ETC1S with BasisLZ 负载的 KTX 头部字段要求supercompressionScheme必须为1BasisLZDFDcolorModel必须为KHR_DF_MODEL_ETC1SDFD 通道按纹理类型对应纹理类型必需 DFD 通道RGB单个KHR_DF_CHANNEL_ETC1S_RGBRGBA两个KHR_DF_CHANNEL_ETC1S_RGBKHR_DF_CHANNEL_ETC1S_AAARed单个KHR_DF_CHANNEL_ETC1S_RRRRed-Green两个KHR_DF_CHANNEL_ETC1S_RRRKHR_DF_CHANNEL_ETC1S_GGGUASTC 负载的 KTX 头部字段要求supercompressionScheme必须为0None或2ZstandardDFDcolorModel必须为KHR_DF_MODEL_UASTCDFD 通道按纹理类型对应纹理类型必需 DFD 通道RGB单个KHR_DF_CHANNEL_UASTC_RGBRGBA单个KHR_DF_CHANNEL_UASTC_RGBARed单个KHR_DF_CHANNEL_UASTC_RRRRed-Green单个KHR_DF_CHANNEL_UASTC_RG附加兼容性要求无论何种格式为保证跨实现兼容以下限制对两种格式一律适用Swizzle 元数据KTXswizzle必须为rgba或省略方向元数据KTXorientation必须为rd或省略DFD 色彩空间信息必须与实际用途匹配颜色数据如 base color 贴图colorPrimaries必须为KHR_DF_PRIMARIES_BT709transferFunction必须为KHR_DF_TRANSFER_SRGB非颜色数据如法线贴图colorPrimaries必须为KHR_DF_PRIMARIES_UNSPECIFIEDtransferFunction必须为KHR_DF_TRANSFER_LINEAR。mip 金字塔当纹理引用的 sampler 使用 mipmap 缩小过滤参见 specification/2.0/schema/sampler.schema.json 中minFilter的 9984/9985/9986/9987 等 mipmap 模式或 sampler 未定义时KTX 图像应当包含完整 mip 金字塔。规范给出的实现说明指出若缺少完整 mip 链引擎可能需要在运行时解压纹理并现场生成缺失的 mip 级别。尺寸对齐pixelWidth和pixelHeight必须为 4 的倍数。实现说明建议导出器优先将尺寸设为 2 的幂配合完整 mip 链可达到最大兼容性。用于材质贴图时的附加规则当引用 KTX v2 超压缩图像的纹理用于 glTF 2.0 材质贴图无论颜色还是非颜色贴图时KTX v2 图像必须是 KTX v2 规范第 4.1 节定义的2D类型除非材质规范要求预乘 Alpha否则不得设置KHR_DF_FLAG_ALPHA_PREMULTIPLIED标志导出器应当依据贴图用途与内容选择最合适的通用纹理格式。规范给出的实现说明是一般性经验法则颜色数据贴图使用 ETC1S非颜色数据贴图如粗糙度-金属度、法线贴图使用 UASTC当运行时缺少高质量 GPU 格式ASTC 或 BC7时引擎应当将携带非颜色数据的 UASTC 纹理转码为未压缩 RGBA以避免质量伪影。已知实现规范文档列出的生态实现可帮助判断工具链兼容性名称保留自原文档不附外部链接作者/导出工具Authoringgltfpack来自 meshoptimizer 项目glTF-Transform CLIGestaltorRapidCompact查看/运行时ViewingBabylonPlayCanvasthree.js延伸资源KTX 文件格式规范 v2KTX File Format Specification, version 2由 Khronos 维护定义了 KTX v2 容器结构、DFD、supercompressionScheme 等本扩展依赖的底层字段KTX 参考软件KTX Reference Software / KTX-Software官方参考实现提供 KTX v2 编解码、Basis Universal 转码能力可用于验证导出的 KTX v2 文件是否符合本扩展的头部与 DFD 要求。附录Khronos 版权声明摘要本规范文档含 KHR_texture_basisu 扩展说明版权归 2020 The Khronos Group Inc. 所有。规范中部分内容为纯信息性描述标记为非规范性或Implementation Notes不构成合规性要求。规范受版权法保护未经 Khronos 书面许可不得以任何方式复制、再发布、分发、传输、展示、广播或利用其任何组成部分。Khronos 依据 Khronos 知识产权政策授予有条件版权许可允许为任何目的使用和复制未经修改的规范但不授予任何专利、商标或其他知识产权的许可希望实施规范并享受 Khronos 商标互惠专利许可保护的各方须成为 Adopter 并通过一致性确认流程。完整声明见 extensions/2.0/Khronos/KHR_texture_basisu/README.md 的 Appendix 部分许可证文本另见 LICENSES/LicenseRef-KhronosSpecCopyright.txt。赞分享图形学【免费下载链接】glTFglTF – Runtime 3D Asset Delivery项目地址https://gitcode.com/gh_mirrors/gl/glTF点击查看免费下载相关推荐three.js 中 Basis Universal GPU 纹理压缩与 KTX2 转码实战three.js 中 Basis Universal GPU 纹理压缩与 KTX2 转码实战 Basis Universal 是一套面向 GPU 纹理与纹理视频前端3D渲染图形学【亲测免费】 开源项目推荐Basis Universal超级压缩GPU纹理编码器开源项目推荐Basis Universal超级压缩GPU纹理编码器 在游戏开发和图形处理领域中纹理数据的管理和优化至关重要。今天要介绍的是一个极其强大的工具glTF 2.0 EXT_texture_webp 扩展实战指南用 WebP 压缩纹理、缩小传输体积并优雅降级glTF 2.0 EXT_texture_webp 扩展实战指南用 WebP 压缩纹理、缩小传输体积并优雅降级 本篇技术指南聚焦 glTF 官方扩展仓库gl图形学上一篇macOS 菜单栏整理神器 Ice 上手指南5 分钟把状态栏变成你想要的样子下一篇DLL报错刷屏的时代结束了Visual C 运行库一键安装VisualCppRedist AIO 使用全攻略创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考