logo资料库

glTF规范中文翻译.pdf

发布时间：2022-05-29 发布人：admin 分类：说明书 资料大小：0.78M 资料格式：pdf 举报 版权申诉
第1页 / 共47页
第2页 / 共47页
第3页 / 共47页
第4页 / 共47页
第5页 / 共47页
第6页 / 共47页
第7页 / 共47页
第8页 / 共47页
资料共47页，剩余部分请下载后查看
    glTF规范（中文）
    介绍(Introduction)
    动机（Motivation）
    glTF基础（glTF Basics）
    设计目标（Design Goals）
    版本控制
    文件扩展名和MIME类型（File Extensions and MIME Types）
    JSON编码（JSON Encoding）
    统一资源标识符（URIs）
    概念（Concepts）
    资产（Asset）
    索引和名称（Indices and Names）
    坐标系和单位（Coordinate System and Units）
    场景（Scenes）
    节点和层次（Nodes and Hierarchy）
    变换（Transformations）
    二进制数据存储（Binary Data Storage）
    缓冲区和缓冲区视图（Buffer and Buffer Views）
    GLB存储缓冲区（GLB-stored Buffer）
    访问器（Accessors）
    浮点数据（Floating-Point Data）
    访问器元素大小（Accessor Element Size）
    访问器界限（Accessor Bounds）
    稀疏存取器（Sparse Accessors）（？）
    数据对齐（Data Alignment）
    几何图形（Geometry）
    网格（Meshes）
    变形目标（Morph Targets）
    蒙皮（Skins）
    蒙皮网格属性（Skinned Mesh Attributes）
    关节层次结构（Joint Hierarchy）
    实例化（Instantiation）
    纹理数据（Texture Data）
    纹理（Textures）
    图片（Images）
    采样器（Samplers）
    材质（Materials）
    金属粗糙度材质（Metallic-Roughness Material）
    附加贴图（Additional Maps）
    Alpha覆盖（Alpha Coverage）
    双面（Double Sided）
    默认材质（Default Material）
    点和线材质（Point and Line Materials）
    相机（Cameras）
    投影矩阵(Projection Matrices)
    动画（Animations）
    指定扩展（Specifying Extensions）
    GIB文件格式规范（GLB File Format Specification）
    文件扩展名（File Extension）
    MIME类型（MIME Type）
    二进制glTF结构（Binary glTF Layout）
    头部（Header）
    数据块（Chunks）
    结构化JSON内容（Structured JSON Content）
    二进制缓冲区（Binary buffer）
    glTF 规范（中文） CSDN：https://blog.csdn.net/u010447508 Github: https://github.com/ComeformPC 介绍(Introduction) 动机（Motivation） 本节内容是非规范性的 传统的三维模型格式被设计成存储数据进行离线使用，主要是支持桌面 系统进行创出工作流程。工业标准的三维数据交换格式允许在不同建模工具 之间以及通常在内容流水线中共享资产。但是，这些类型的数据格式均未针 对下载速度和运行时快速加载进行优化。文件往往会变得很大，应用程序需 要做大量的处理才能加载这些资产到 GPU 加速的应用程序中。 寻求高性能的应用程序很少直接加载建模格式的数据；相反的，他们把 离线处理模型作为定制化内容流水线的一部分，将资产转换为针对其运行时 程序优化的专有格式。这导致大量分散的不兼容的专有运行时格式，并且在 内容创建流水线中重复工作。为一个应用程序导出的 3D 资产必须要还原成 原始建模，并且执行另一个专有导出才能在另一个程序中重用。 随着基础移动端和 web 端的 3D 计算的出现，新型应用程序急需一种快 速，动态加载的标准化 3D 资产。数字营销解决方案，电子商务产品可视化 以及在线模型共享网站只是使用 WebGL 或者 OpenGL ES 构建的连接 3D 应用 程序的一小部分。除了高效传输的需求外，许多这些在线应用程序可以受益 于标准的可互操作的格式，从而能够在用户之间，应用程序之间以及异构的 分布式内容流水线中共享和重用 3D 资产。 glTF 通过提供一种与供应商和运行时无关的格式来解决这些问题，该格 式可以以最少的处理量进行加载和渲染。glTF 将易于解析的 JSON 场景描述 与一个或多个表示几何，动画或者其他富文本数据的二进制文件结合在一 起。二进制数据的存储方式可以将其直接加载到 GPU 缓冲区中，而无需进 行额外解析或者其他操作。使用这种方法，glTF 如实地保留了包含节点、网 格、相机、材质和动画的完整分层场景，同时实现高效的传输和快速的加载。
    glTF 基础（glTF Basics） 本节内容是非规范性的。 glTF 资产是 JSON 文件，另外还支持外部数据。具体来说，一个 glTF 资 产表示为：  一个 JSON 格式的文件(.gltf)，包含完整的场景描述：节点层次结 构，材质，相机以及网格，动画和其他构造的描述符信息  二进制文件（.bin），包含几何和动画数据以及其他基于缓冲区 的数据  用于纹理的图像文件（.jpg，.png） 以其他格式定义的资产，例如图像，可以存储在通过 URL 引用的外部文件中， 并排存储在 GLB 容器中，或者使用 data URIs 直接嵌入到 JSON 中。 有效的 glTF 资产必须指定其版本。 设计目标（Design Goals） 本节内容是非规范性的 glTF 旨在满足以下目标：  压缩文件大小。尽管 Web 开发人员喜欢尽可能多地使用纯文本，但 是由于文件过大，纯文本编码对于传输 3D 数据根本不可行。glTF JSON 文件 本身是纯文本，但是它紧凑且能快速解析。所有的大数据，例如几何图形和 动画，都存储在二进制文件中，它比等效的文本表示形式小得多。
     快速加载。glTF 数据结构被设计成尽可能接近 GPU API 数据，无论是 JSON 还是二进制文件，目的就是为了减少加载时间。例如，二进制网格数据 可以被当作 JavaScript 数组查看，通过简单的复制就可以直接加载到 GPU 缓 冲区中，无需解析和进一步处理。  运行时无关。glTF 对目标应用程序或者 3D 引擎不做任何假设。除渲 染和动画外 glTF 没有指定任何运行时行为。  完整的3D 场景表示。从建模包中导出单个模型不足以用于许多应用 程序。通常，作者希望加载整个场景到他们的应用程序中，包括节点，变换， 变换层次结构，网格，材质，相机和动画。glTF 努力保留所有的这些信息， 以供下游应用程序使用。  可扩展性。尽管最初的基本规范支持丰富的功能集，但是仍然有许 多增长和改进的机会。glTF 定义了一种机制，该机制允许添加通用扩展和特 定于供应商的扩展。 glTF 的设计采用务实的方法。该格式尽可能接近地匹配 GPU API，但如果仅 这样做，就不会有建模工具和运行时系统通常存在的相机，动画或其他功能，并 且在转译时会失去很多语义信息。通过支持这些通用结构，glTF 内容不仅能加载 和渲染，还可以立即在更广泛的应用程序中使用，并且只需要在内容流水线中做 很少的工作。 以下不在最初设计 glTF 的范围内:  glTF 不是流格式。glTF 中的二进制数据本来就可以进行流式传输，并 且缓冲区设置允许以增量方式获取数据。但是格式中没有其他流传输构造， 并且对于实现流传输数据还是在渲染之前完整下载数据没有一致性要求。  glTF 并非人类可读。尽管以 JSON 表示，但它对开发人员友好。 尽 管 glTF 2.0 版 本 未 定 义 几 何 图 形 和 其 他 富 文 本 数 据 的 压 缩 ， 但 KHR_draco_mesh_compression 扩展提供了该选项。将来的扩展可能包括纹理和 动画数据的压缩方法。 版本控制 次要版本中对 glTF 所做的任何更新都将向后向前兼容。向后兼容将确保任 何支持加载 glTF 2.X 资产的客户端实现也能够加载 glTF 2.0 资产。向前兼容允许 仅支持 glTF 2.0 的客户端实现加载 glTF 2.X 资产，同时忽略它不了解的任何新功
    能。 次要版本更新可以引入新功能，但不会更改任何以前存在的行为。可以在次 要版本更新中弃用现有功能，但不会将其删除。 主要版本更新不应与以前的版本兼容。 文件扩展名和 MIME 类型（File Extensions and MIME Types） *.gltf 文件使用 model/gltf+json *.bin 文件使用 application/octet-stream 纹理文件使用基础特定图像格式的官方 image/* 类型。为了与现代浏 览器兼容，支持以下图像格式：image/jpeg,image/png JSON 编码（JSON Encoding） 为了简化客户端实现，glTF 对 JSON 格式和编码有额外的限制。 1、JSON 必须使用没有 BOM 的 UTF-8 编码。 实现说明：glTF 导出器不得在 JSON 文本的开头添加字节顺序标记。为了互 操作性，客户端实现可以忽略字节顺序标记的存在，而不是将其视为错误。更多 信息查看 RFC8259,第八节。 2、本规范中定义的所有字符串（属性名称，枚举）只能使用 ASCII 字符集， 并且必须以纯文本形式编写。 实现说明：这允许通用的 glTF 客户端实现不必具有完整的字符集支持。特 定于应用程序的字符串（例如，“名称”属性的值或 Extras 字段的内容）可以使 用任何符号。 3、JSON 对象中的名称（键）必须唯一，不允许重复的键。 统一资源标识符（URIs） glTF 使用 URIs 引用缓冲区和图像资源。客户端必须至少支持以下两种 URI 类型：  Data URIs，将资源嵌入 JSON 中。它们使用 RFC 2397 定义的语法。 实现说明：Data URIs 可以使用 JavaScript 进行解码，也可以由 Web 浏览器直 接以 HTML 标签使用。  相对 URI 路径或者 RFC 3986 节第 4.2 节定义的路径编码-不带方案， 权限或参数。保留字符必须按照 RFC 3986 第 2.2 节进行百分比编码。
    实现说明：客户端可以选择支持其他 URI 组件。例如 http://或 file://结构， 授权/主机名，绝对路径以及查询或片段参数。包含这些额外的 URL 组件的资产 的可移植性可能较差。 实现说明：这允许应用程序决定最佳的传输方式：如果不同的资产共享许多 相同的几何形状，动画或文件，则最好使用单独的文件以减少请求的数据总量。 使用单独的文件，应用程序可以逐步加载数据，而无需为不可见的模型部分加载 数据。如果应用程序更关心单文件部署，则嵌入数据可能是首选方法，即使由于 base64 编码而增加了文件大小并且不支持渐进式或按需加载。或者，资产可以 使用 GLB 容器将 JSON 和二进制文件存储到一个文件中，而无需使用 base64 编码。 有关详细内容，请参见 GLB 文件格式规范。 实施说明:尽管该规范并未明确禁止非标准化 URIs，但在某些平台上，可能 不支持使用它们或者导致不希望的副作用，例如安全警告或缓存泄露。 概念（Concepts） glTF 资产中的顶级结构 资产（Asset） 每个 glTF 资产都必须有 asset 属性。实际上，它是 JSON 成为有效的 glTF 唯
    一需要的顶级属性。资产对象必须包含 glTF 版本，该版本信息指定资产的目标 glTF 版本。此外，可选的 minVersion 属性可用于指定加载资产所需的最低 glTF 版本。minVersion 属性允许资产创建器指定客户端实现加载资产必须支持的最低 版本。这与 extensionsRequired 概念非常相似，只有客户端支持该指定的扩展时 才能加载资产。可以将其他元数据存储在可选属性中，例如生成器或版权信息。 例如： { "asset": { "version": "2.0", "generator": "collada2gltf@f356b99aef8868f74877c7ca545f2cd206b9d3b7", "copyright": "2017 (c) Khronos Group" } } 实现说明：客户端实现首先检查是否指定了 minVersion 属性并且保证主 要和次要版本都能够支持。如果没有指定 minVersion，客户端就应检查 version 属性并保证支持主要版本。客户端加载 GLB 格式同样需要检查 JSON 块中的 minVersion 和 version 属性，因为 GLB 头中指定的版本仅指 GLB 容器 版本。 索引和名称（Indices and Names） glTF 资产的实体由其在对应数据中的索引引用，例如，bufferView 通过指定 buffers 数组中的缓冲区的索引来引用缓冲区。例如： { "buffers": [ { } "byteLength": 1024, "uri": "path-to.bin" ], "bufferViews": [ "buffer": 0, "byteLength": 512, "byteOffset": 0 { } ]
    } 在此示例中，buffers 和 bufferViews 都只有一个元素。bufferView 通过使用 buffer 索引来引用 buffer：”buffer”:0。 索引用于 glTF 内部引用，names 则用于特定于应用程序的用途，例如显示。 为此，任何顶级 glTF 对象都可以具有 name 字符串属性。这些属性值不保证唯一， 因为他们旨在包含创作资产时创建的值。 对于属性名称，glTF 使用骆驼拼写法 likeThis。骆驼拼写法是 JSON 和 WebGL 中常见的命名约定。 坐标系和单位（Coordinate System and Units） glTF 使用右手坐标系统，即 X 轴正方向和 Y 轴正方向的叉积就是 Z 轴正方向。 glTF 定义 Y 轴正方向朝上。glTF 的前端面向 Z 轴正方向。 所有线性距离的单位均为米。 所有角度均为弧度。 旋转正方向为逆时针方向。 节点变换和动画通道路径是具有以下数据类型和语义的 3D 向量或四元数：  平移：包含沿 x,y,z 轴平移距离的 3D 向量  旋转：四元数（x,y,z,w），其中 w 是标量  缩放：包含沿 x,y,z 轴的缩放比例因子的 3D 向量
    RGB 颜色值使用 sRGB 颜色原色。 实施说明：颜色原色定义了颜色模型中每个颜色通道的解释，特别是在 RGB 颜色模型方面。在典型的显示器中，原色描述红色、绿色和蓝色磷光体或滤光片 的颜色。ITU-R BT.709 建议书中也定了相同的原色。由于绝大多数当前使用的显 示器都使用与默认设置相同的原色，因此客户端实现通常不需要转换颜色值。未 来的规范版本或扩展可能会允许其他颜色原色（例如 P3），甚至提供嵌入自定 义颜色配置文件。 场景（Scenes） glTF 资产包含零个或多个 scenes，即要渲染的一组视觉对象。场景定义在 scenes 数组中。scene(注意单数)是一个附加属性，用于标识在加载时要显示数组 中的哪个场景。 scene.nodes 数组中列出的所有节点都必须是根节点（有关详细信息，请参 见下一节）。 当 scene 未定义时，不需要运行时在加载时渲染任何内容。 实施说明：这允许应用程序将 glTF 资产用作单个实体（例如材质或网格） 的库。 以下示例定义了具有一个场景的 glTF 资产，其中还包含一个节点。 { "nodes": [ { } "name": "singleNode" ], "scenes": [ { } "name": "singleScene", "nodes": [ 0 ] ], "scene": 0 } 节点和层次（Nodes and Hierarchy） glTF 资产可以定义节点，即包含要渲染的场景的对象。 节点有一个可选的 name 属性。
    分享到：
    赞 收藏

    相关推荐

    资料库

    开发技术

    共收录19306份资料，累计14个分类，关注成员有19位，主要包括：Actionscript,Javascript,PHP,VB,Perl,Delphi,Python,C#,C,Java,C++,Web开发,硬件开发,其它

    热门标签

    Actionscript Javascript PHP VB Perl Delphi Python C# C Java C++ Web开发 硬件开发 其它

    最新资料