Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sectioned hanging text #1917

Merged
merged 2 commits into from
Dec 3, 2020
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
53 changes: 53 additions & 0 deletions specification/2.0/Specification.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -66,6 +66,9 @@ Copyright 2013-2020 The Khronos Group Inc. All Rights Reserved. glTF is a tradem
[[introduction]]
= Introduction

[[introduction-general]]
== General

The GL Transmission Format (glTF) is an API-neutral runtime asset delivery format. glTF bridges the gap between 3D content creation tools and modern graphics applications by providing an efficient, extensible, interoperable format for the transmission and loading of 3D content.


Expand Down Expand Up @@ -212,6 +215,9 @@ While the spec does not explicitly disallow non-normalized URIs, their use may b
[[concepts]]
= Concepts

[[concepts-general]]
== General

image:figures/dictionary-objects.png[pdfwidth=4in,align=left]

The top-level arrays in a glTF asset. See the <<properties-reference, Properties Reference>>.
Expand Down Expand Up @@ -303,6 +309,10 @@ Color primaries define the interpretation of each color channel of the color mod
[[scenes]]
== Scenes


[[scenes-overview]]
=== Overview

The glTF asset contains zero or more *scenes*, the set of visual objects to render. Scenes are defined in a `scenes` array. An additional property, `scene` (note singular), identifies which of the scenes in the array is to be displayed at load time.

All nodes listed in `scene.nodes` array must be root nodes (see the next section for details).
Expand Down Expand Up @@ -475,6 +485,10 @@ The next example defines the transformation for a node with attached camera usin
[[buffers-and-buffer-views]]
=== Buffers and Buffer Views


[[buffers-and-buffer-views-overview]]
==== Overview

A *buffer* is data stored as a binary blob. The buffer can contain a combination of geometry, animation, and skins.

Binary blobs allow efficient creation of GPU buffers and textures since they require no additional parsing, except perhaps decompression. An asset can have any number of buffer files for flexibility for a wide array of applications.
Expand Down Expand Up @@ -575,6 +589,9 @@ See <<glb-file-format-specification,GLB File Format Specification>> for details
[[accessors]]
=== Accessors

[[accessors-overview]]
==== Overview

All large data for meshes, skins, and animations is stored in buffers and retrieved via accessors.

An *accessor* defines a method for retrieving data as typed arrays from within a `bufferView`. The accessor specifies a component type (e.g. `5126 (FLOAT)`) and a data type (e.g. `VEC3`), which when combined define the complete data type for each array element. The accessor also specifies the location and size of the data within the `bufferView` using the properties `byteOffset` and `count`. The latter specifies the number of elements within the `bufferView`, *not* the number of bytes. Elements could be, e.g., vertex indices, vertex attributes, animation keyframes, etc.
Expand Down Expand Up @@ -836,12 +853,18 @@ The size of the accessor component type is two bytes (the `componentType` is uns
[[geometry]]
== Geometry

[[geometry-overview]]
=== Overview

Any node can contain one mesh, defined in its `mesh` property. Mesh can be skinned using a information provided in referenced `skin` object. Mesh can have morph targets.


[[meshes]]
=== Meshes

[[meshes-overview]]
==== Overview

In glTF, meshes are defined as arrays of *primitives*. Primitives correspond to the data required for GPU draw calls. Primitives specify one or more `attributes`, corresponding to the vertex attributes used in the draw calls. Indexed primitives also define an `indices` property. Attributes and indices are defined as references to accessors containing corresponding data. Each primitive also specifies a material and a primitive type that corresponds to the GPU primitive type (e.g., triangle set).

[NOTE]
Expand Down Expand Up @@ -1039,6 +1062,9 @@ A significant number of authoring and client implementations associate names wit
[[skins]]
=== Skins

[[skins-overview]]
==== Overview

All skins are stored in the `skins` array of the asset. Each skin is defined by the `inverseBindMatrices` property (which points to an accessor with IBM data), used to bring coordinates being skinned into the same space as each joint; and a `joints` array property that lists the nodes indices used as joints to animate the skin. The order of joints is defined in the `skin.joints` array and it must match the order of `inverseBindMatrices` data. The `skeleton` property (if present) points to the node that is the common root of a joints hierarchy or to a direct or indirect parent node of the common root.

[NOTE]
Expand Down Expand Up @@ -1261,6 +1287,9 @@ A skin is instanced within a node using a combination of the node's `mesh` and `
[[texture-data]]
== Texture Data

[[texture-data-overview]]
=== Overview

glTF separates texture access into three distinct types of objects: Textures, Images, and Samplers.


Expand Down Expand Up @@ -1381,6 +1410,9 @@ glTF does not guarantee that a texture's dimensions are a power-of-two. At runt
[[materials]]
== Materials

[[materials-overvew]]
=== Overview

glTF defines materials using a common set of parameters that are based on widely used material representations from Physically-Based Rendering (PBR). Specifically, glTF uses the metallic-roughness material model. Using this declarative representation of materials enables a glTF file to be rendered consistently across platforms.

image:figures/materials.png[pdfwidth=4in,align=left]
Expand Down Expand Up @@ -1539,6 +1571,9 @@ This specification does not define size and style of non-triangular primitives (
[[cameras]]
== Cameras

[[cameras-overview]]
=== Overview

A camera defines the projection matrix that transforms from view to clip coordinates. The projection can be perspective or orthographic. Cameras are contained in nodes and thus can be transformed. Their world-space transformation matrix is used for calculating view-space transformation. The camera is defined such that the local +X axis is to the right, the lens looks towards the local -Z axis, and the top of the camera is aligned with the local +Y axis. If no transformation is specified, the location of the camera is at the origin.

Cameras are stored in the asset's `cameras` array. Each camera defines a `type` property that designates the type of projection (perspective or orthographic), and either a `perspective` or `orthographic` property that defines the details.
Expand Down Expand Up @@ -1578,6 +1613,9 @@ The following example defines two perspective cameras with supplied values for Y
[[projection-matrices]]
=== Projection Matrices

[[projection-matrices-overview]]
==== Overview

Runtimes are expected to use the following projection matrices.


Expand Down Expand Up @@ -1916,6 +1954,9 @@ For more information on glTF extensions, consult the https://github.com/KhronosG
[[glb-file-format-specification]]
= GLB File Format Specification

[[glb-file-format-specification-general]]
== General

glTF provides two delivery options that can also be used together:

* glTF JSON points to external binary data (geometry, key frames, skins), and images.
Expand Down Expand Up @@ -1950,6 +1991,9 @@ Use `model/gltf-binary`.
[[binary-gltf-layout]]
== Binary glTF Layout

[[binary-gltf-layout-overview]]
=== Overview

Binary glTF is little endian. Figure 1 shows an example of a Binary glTF asset.

*Figure 1*: Binary glTF layout.
Expand Down Expand Up @@ -1985,6 +2029,9 @@ Client implementations that load GLB format should also check for the <<asset,as
[[chunks]]
=== Chunks

[[chunks-overview]]
==== Overview

Each chunk has the following structure:

[source,c]
Expand Down Expand Up @@ -2082,6 +2129,9 @@ include::JsonSchemaReference.adoc[]
[[appendix-b-brdf-implementation]]
= BRDF Implementation

[[appendix-b-brdf-implementation-general]]
== General

In this chapter we present the bidirectional scattering distribution function (BRDF) of the glTF 2.0 metallic-roughness material. The BRDF describes the reflective properties of the surface of a physically-based material. For a pair of directions, the BRDF returns how much light from the incoming direction is scattered from the surface in the outgoing direction. See <<Pharr2016,Pharr et al. (2016), Chapter 5.6 "Surface Reflection">>, for an introduction to radiometry and the BRDF.

The BRDF of the metallic-roughness material is a linear interpolation of a metallic BRDF and a dielectric BRDF. The BRDFs share the parameters for roughness and base color. The blending factor `metallic` describes the metalness of the material.
Expand Down Expand Up @@ -2166,6 +2216,9 @@ The unbiased light simulation with physically realistic BRDFs will be the ground
[[implementation]]
== Implementation

[[implementation-overview]]
=== Overview

*This section is non-normative.*

An implementation sample is available at https://github.com/KhronosGroup/glTF-Sample-Viewer/ and provides an example of a WebGL implementation of a standard BRDF based on the glTF material parameters. In order to achieve high performance in real-time applications, this implementation takes some short-cuts and uses non-physical simplifications that break energy-conservation and reciprocity.
Expand Down