Upate to latest glTF

extensions/2.0/Khronos/KHR_materials_clearcoat/README.md

@@ -16,7 +16,7 @@ See [Appendix](#appendix-full-khronos-copyright-statement) for full Khronos Copy
 
 ## Status
 
-Draft
+Complete
 
 ## Dependencies
 
@@ -52,7 +52,7 @@ The PBR clearcoat materials are defined by adding the `KHR_materials_clearcoat`
 
 ### Clearcoat
 
-All implementations should use the same calculations for the BRDF inputs. Implementations of the BRDF itself can vary based on device performance and resource constraints. See [Appendix B](/specification/2.0/README.md#appendix-b-brdf-implementation) for more details on the BRDF calculations.
+The following parameters are contributed by the `KHR_materials_clearcoat` extension:
 
 |                                  | Type                                                                            | Description                            | Required             |
 |----------------------------------|---------------------------------------------------------------------------------|----------------------------------------|----------------------|
@@ -61,7 +61,19 @@ All implementations should use the same calculations for the BRDF inputs. Implem
 |**clearcoatRoughnessFactor**      | `number`                                                                        | The clearcoat layer roughness.         | No, default: `0.0`   |
 |**clearcoatRoughnessTexture**     | [`textureInfo`](/specification/2.0/README.md#reference-textureInfo)             | The clearcoat layer roughness texture. | No                   |
 |**clearcoatNormalTexture**        | [`normalTextureInfo`](/specification/2.0/README.md#reference-normaltextureinfo) | The clearcoat normal map texture.      | No                   |
-
+
+The clearcoat BRDF is layered on top of the glTF 2.0 Metallic-Roughness material, including emission and all extensions. The `clearcoatFactor` determines the view-independent intensity of the clearcoat BRDF. If `clearcoatFactor` (in the extension) is zero, the whole clearcoat layer is disabled. Implementations of the BRDF itself can vary based on device performance and resource constraints. As in the specular term of the glTF 2.0 Metallic-Roughness material, the roughness input is squared to make it perceptually linear, and the Fresnel term uses a fixed refractive index of 1.5, corresponding to a F0 of 0.04.
+
+The values for clearcoat layer intensity and clearcoat roughness can be defined using factors, textures, or both. If the `clearcoatTexture` or `clearcoatRoughnessTexture` is not given, respective texture components are assumed to have a value of 1.0. All clearcoat textures contain RGB components in linear space. If both factors and textures are present, the factor value acts as a linear multiplier for the corresponding texture values.
+
+If `clearcoatNormalTexture` is not given, no normal mapping is applied to the clear coat layer, even if normal mapping is applied to the base material.  Otherwise, `clearcoatNormalTexture` may be a reference to the same normal map used by the base material, or any other compatible normal map.
+
+## Implementation Notes
+
+*This section is non-normative.*
+
+All implementations should use the same calculations for the BRDF inputs. See [Appendix B](/specification/2.0/README.md#appendix-b-brdf-implementation) for more details on the BRDF calculations.
+
 The clearcoat formula `f_clearcoat` is computed using the specular term from the glTF 2.0 Metallic-Roughness material, defined in [Appendix B](/specification/2.0/README.md#appendix-b-brdf-implementation).  Use specular F0 equal `0.04`, base color black `0.0, 0.0, 0.0`, metallic value `0.0`, and the clearcoat roughness value defined in this extension as follows:
 
 ```
@@ -78,12 +90,6 @@ color = (f_emissive + f_diffuse + f_specular) * (1.0 - clearcoatBlendFactor * cl
         f_clearcoat * clearcoatBlendFactor
 ```
 
-If `clearcoatFactor` (in the extension) is zero, the whole clearcoat layer is disabled.
-
-The values for clearcoat layer intensity and clearcoat roughness can be defined using factors, textures, or both. If the `clearcoatTexture` or `clearcoatRoughnessTexture` is not given, respective texture components are assumed to have a value of 1.0. All clearcoat textures contain RGB components in linear space. If both factors and textures are present, the factor value acts as a linear multiplier for the corresponding texture values.
-
-If `clearcoatNormalTexture` is not given, no normal mapping is applied to the clear coat layer, even if normal mapping is applied to the base material.  Otherwise, `clearcoatNormalTexture` may be a reference to the same normal map used by the base material, or any other compatible normal map.
-
 ## Schema
 
 - [glTF.KHR_materials_clearcoat.schema.json](schema/glTF.KHR_materials_clearcoat.schema.json)
@@ -147,12 +153,11 @@ employees, agents or representatives be liable for any damages, whether direct,
 indirect, special or consequential damages for lost revenues, lost profits, or
 otherwise, arising from or in connection with these materials.
 
-Vulkan is a registered trademark and Khronos, OpenXR, SPIR, SPIR-V, SYCL, WebGL,
-WebCL, OpenVX, OpenVG, EGL, COLLADA, glTF, NNEF, OpenKODE, OpenKCAM, StreamInput,
-OpenWF, OpenSL ES, OpenMAX, OpenMAX AL, OpenMAX IL, OpenMAX DL, OpenML and DevU are
-trademarks of The Khronos Group Inc. ASTC is a trademark of ARM Holdings PLC,
-OpenCL is a trademark of Apple Inc. and OpenGL and OpenML are registered trademarks
-and the OpenGL ES and OpenGL SC logos are trademarks of Silicon Graphics
-International used under license by Khronos. All other product names, trademarks,
-and/or company names are used solely for identification and belong to their
-respective owners.
+Khronos® and Vulkan® are registered trademarks, and ANARI™, WebGL™, glTF™, NNEF™, OpenVX™,
+SPIR™, SPIR-V™, SYCL™, OpenVG™ and 3D Commerce™ are trademarks of The Khronos Group Inc.
+OpenXR™ is a trademark owned by The Khronos Group Inc. and is registered as a trademark in
+China, the European Union, Japan and the United Kingdom. OpenCL™ is a trademark of Apple Inc.
+and OpenGL® is a registered trademark and the OpenGL ES™ and OpenGL SC™ logos are trademarks
+of Hewlett Packard Enterprise used under license by Khronos. ASTC is a trademark of
+ARM Holdings PLC. All other product names, trademarks, and/or company names are used solely
+for identification and belong to their respective owners.

extensions/2.0/Khronos/KHR_mesh_quantization/README.md

@@ -10,7 +10,7 @@ See [Appendix](#appendix-full-khronos-copyright-statement) for full Khronos Copy
 
 ## Status
 
-Draft (not ratified yet)
+Complete
 
 ## Dependencies
 

extensions/2.0/Vendor/CESIUM_primitive_outline/README.md

@@ -0,0 +1,76 @@
+# CESIUM_primitive_outline
+
+<figure>
+<img src="./figures/with-extension.png"/>
+<figcaption><em>Edges rendered on solid buildings using this extension. The buildings are derived from OpenStreetMap data in New York.</em></figcaption>
+</figure>
+
+## Contributors
+
+- Kevin Ring, Cesium, [@kring](https://github.com/kring)
+- Sean Lilley, Cesium, [@lilleyse](https://github.com/lilleyse)
+
+## Status
+
+Cesium Vendor Extension - Currently supported in [CesiumJS](https://cesium.com/cesiumjs) and in some of Cesium's content generation tools.
+
+## Dependencies
+
+Written against the glTF 2.0 spec.
+
+## Overview
+
+Non-photorealistic 3D objects, such as untextured buildings, are often more visually compelling when their edges are outlined. A simple approach to adding outlines to a glTF model is to add an additional primitive of type `LINES` to the model, drawing lines along the edges to be outlined. Unfortunately, the visual quality of such an approach is quite poor, because the lines depth fight with the triangles. The rasterization of the lines does not match the rasterization of the edges of the triangles.
+
+<figure>
+<img src="./figures/depth-fighting.png"/>
+<figcaption><em>Stipling caused by depth fighting between separately-rendered lines and triangles.</em></figcaption>
+</figure>
+
+The traditional way to avoid this depth fighting is to use `glPolygonOffset` or similar. glTF 2.0, however, does not support specifying a polygon offset. Even if it did - or an extension were defined to support it - it's very difficult to get high quality rendering with this approach. Depending on the polygon offset values chosen, lines on the back-face may "bleed through" to the front because of too much depth bias, or lines may have a stipled look due to too little depth bias. Even with careful tuning of the polygon offset values, it's usually possible to detect both problems simultaneously in a single scene.
+
+Even if these artifacts are deemed tolerable, rendering separate line primitives increases the number of draw calls required to render the scene. Furthermore, on some hardware, drawing lines is significantly slower than drawing triangles.
+
+This extension indicates to a rendering engine that a list of triangle edges should be outlined. While it does not dictate how the rendering should be done, the fact that all of the lines are actually edges of triangles allows the rendering engine to use a higher quality - and faster - technique for rendering the lines, without needing to deduce the suitability of such a technique at runtime.
+
+## Extending Primitives
+
+Edge outlining is requested by adding the `CESIUM_primitive_outline` extension to a primitive rendered with `"mode": 4`, `TRIANGLES`.
+
+```json
+"meshes": [
+    {
+        "primitives": [
+            {
+                "attributes": {
+                    "POSITION": 0,
+                    "NORMAL": 1,
+                    "_BATCHID": 2
+                },
+                "indices": 3,
+                "material": 0,
+                "mode": 4,
+                "extensions": {
+                    "CESIUM_primitive_outline": {
+                        "indices": 4
+                    }
+                }
+            }
+        ]
+    }
+]
+```
+
+The `indices` property specifies the ID of an accessor with the locations of the edges. The accessor must contain an even number of elements of `componentType` `UNSIGNED_SHORT` (5123) or `UNSIGNED_INT` (5125) representing vertex indices on the primitive containing this extension. Each pair of indices specifies the endpoint vertices of an edge to be highlighted. These two vertices must also be two of the three vertices of one or more triangles; otherwise, the line will not be drawn at all.
+
+## Implementation Notes
+
+This extension does not dictate any specific rendering technique; it only requires that the outlines be drawn and that they avoid depth fighting with the solid geometry. However, most implementations will find it convenient to use a single-pass approach that renders the outlines as part of the triangles. For example, [Fast and versatile texture-based wireframe rendering](https://www.researchgate.net/publication/220067637_Fast_and_versatile_texture-based_wireframe_rendering) describes a technique that uses a mipmapped 1D texture and three sets of 1D texture coordinates to render high-quality, anti-aliased lines on the edges of triangles. This is the approach used in CesiumJS.
+
+A fully-functional, open-source implementation of this extension was added to CesiumJS in [this pull request](https://github.com/CesiumGS/cesium/pull/8776).
+
+## Justification
+
+Strictly speaking, this extension is not required. A rendering engine could inspect all LINES primitives to see if they share vertices with a TRIANGLES primitive and, if so, use a different rendering technique to render lines that are coincident with triangle edges. However, this would add a significant runtime cost to match lines to triangle edges, and the cost would be imposed on all models that use lines, even those that would not benefit from this rendering technique. Therefore, this extension is primarily an optimization, allowing models to opt-in to single-pass, non-photorealistic edge rendering.
+
+Using this extension also means that lines will not be drawn at all in rendering engines that do not support this extension. This is desirable because depth-fighting between lines and triangles looks very bad; we're probably better off not rendering the lines at all.

extensions/2.0/Vendor/CESIUM_primitive_outline/schema/primitive.CESIUM_primitive_outline.schema.json

@@ -0,0 +1,15 @@
+{
+    "$schema": "http://json-schema.org/draft-04/schema",
+    "title": "CESIUM_primitive_outline glTF primitive extension",
+    "type": "object",
+    "description": "glTF extension for indicating that some edges of a primitive's triangles should be outlined.",
+    "allOf": [ { "$ref": "glTFProperty.schema.json" } ],
+    "properties": {
+        "indices": {
+            "type": "integer",
+            "description": "The index of the accessor providing the list of highlighted lines at the edge of this primitive's triangles."
+        },
+        "extensions": { },
+        "extras": { }
+    }
+}

extensions/2.0/Vendor/EXT_mesh_gpu_instancing/README.md

@@ -0,0 +1,77 @@
+# EXT\_mesh\_gpu\_instancing
+
+## Contributors
+
+* John Cooke, OTOY, <mailto:[email protected]>
+* Don McCurdy
+* Arseny Kapoulkine, [@zeuxcg](https://twitter.com/zeuxcg)
+
+## Status
+
+Experimental
+
+## Dependencies
+
+Written against the glTF 2.0 spec.
+
+## Overview
+
+This extension is specfically designed to enable GPU instancing which renders many copies of a single mesh at once using a small number of draw calls.  It's useful for things 
+like trees, grass, road signs, etc.  The TRANSLATION, ROTATION, and SCALE attributes allows the mesh to be displayed at many different locations with different rotations and scales.  
+Custom attributes can use the underscore mechanism to achieve other effects (i.e. _ID, _COLOR, etc.).
+
+## Extending Nodes With Instance Attributes
+
+Instancing is defined by adding the `EXT_mesh_gpu_instancing` extension to any glTF node that has a mesh. Instancing only applies to mesh nodes, there is no defined behavior for a node 
+with this extension that doesn't also have a mesh. Applying to nodes rather than meshes allows the same mesh to be used by several nodes, instanced or otherwise. The attributes 
+section contains accessor ids for the TRANSLATION, ROTATION, and SCALE attribute buffers, all of which are optional. The attributes specify an object space transform that should be 
+multipled by the node's world transform in the shader to produce the final world transform for the instance. For example, the following defines some instancing attributes to a node with mesh.  
+
+```json
+{
+    "nodes": [
+        {
+            "mesh": 0,
+            "name": "teapot",
+            "extensions": {
+                "EXT_mesh_gpu_instancing": {
+                    "attributes": {
+                        "TRANSLATION": 0,
+                        "ROTATION": 1,
+                        "SCALE": 2,
+                        "_ID" : 3
+                    },
+                }
+            }
+        }
+    ]
+}
+```
+
+Valid accessor type and component type for each attribute semantic property are defined below.
+
+|Name|Accessor Type|Component Type(s)|Description|
+|----|----------------|-----------------|-----------|
+|`"TRANSLATION"`|`"VEC3"`|`5126`&nbsp;(FLOAT)|XYZ translation vector|
+|`"ROTATION"`|`"VEC4"`|`5126`&nbsp;(FLOAT)<br>`5120`&nbsp;(BYTE)&nbsp;normalized<br>`5122`&nbsp;(SHORT)&nbsp;normalized|XYZW rotation quaternion|
+|`"SCALE"`|`"VEC3"`|`5126`&nbsp;(FLOAT)|XYZ scale vector|
+
+All attribute accessors in a given node **must** have the same `count`.
+
+> **Implementation Note:** When instancing is used on the node, the non-instanced version of the mesh should not be rendered.
+
+## Transformation Order
+
+When using instancing, the instance transform matrix is constructed by multiplying translation (if present), rotation (if present), and scale in the same order as they are for nodes:
+
+    InstanceXform = Translation * Rotation * Scale
+
+The node's world transform matrix is constructed by multiplying the node's local transform matrix from the root of the tree up until (and including) the node itself:
+
+    NodeWorldXform = RootXform * ... * ParentLocalXform * NodeLocalXform
+
+The resulting transforms are applied to mesh positions/normals/etc., with instance transformation applied first:
+
+    WorldPosition = NodeWorldXform * InstanceXform * VertexPosition
+
+> Note: the construction above assumes column vectors; for row vectors, the matrix multiplication order should be reversed