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

KHR_draco_mesh_compression #874

Merged
merged 50 commits into from
Feb 14, 2018
Merged
Show file tree
Hide file tree
Changes from 41 commits
Commits
Show all changes
50 commits
Select commit Hold shift + click to select a range
acfd558
Initial commit
fanzhanggoogle Mar 10, 2017
6472e25
Finished most of the Readme
fanzhanggoogle Mar 10, 2017
41432dc
Added json schema file
Mar 10, 2017
66dfde1
Finished the first version
Mar 10, 2017
eae186d
Fix style issue
Mar 10, 2017
3dff72b
Changed extension name
fanzhanggoogle Mar 13, 2017
54db399
Removed support for multiple compression libraries
fanzhanggoogle Mar 13, 2017
65e79d3
Added support for point cloud in the spec
fanzhanggoogle Mar 13, 2017
b132fa0
Fix
fanzhanggoogle Mar 13, 2017
7c48fb7
Refined alternative option
fanzhanggoogle Mar 13, 2017
007e570
Removed unused file
fanzhanggoogle Mar 13, 2017
7e7ff5d
Changes on lexaknyazev's comment
fanzhanggoogle Mar 14, 2017
ca7c8ee
Fixes
fanzhanggoogle Mar 14, 2017
ddf534f
Renaming
fanzhanggoogle Mar 14, 2017
1d4ab96
Fix
fanzhanggoogle Mar 14, 2017
251452d
Address Patrick's comments
fanzhanggoogle Mar 14, 2017
260534e
Added version property and description
fanzhanggoogle Mar 14, 2017
ea273be
Changed indicesCount to indexCount
fanzhanggoogle Mar 15, 2017
198792f
grammar fix
fanzhanggoogle Mar 15, 2017
5956b53
minor fix
fanzhanggoogle Mar 19, 2017
f60ff63
Removed indexCount and vertexCount
fanzhanggoogle Apr 19, 2017
61bd686
Removed attributes in the extension
fanzhanggoogle Apr 20, 2017
2c3a051
Define order of attributes
fanzhanggoogle Apr 24, 2017
3c14401
Fix
fanzhanggoogle Apr 24, 2017
a502855
minor fix
fanzhanggoogle Apr 24, 2017
fba95f4
Merge branch 'master' into KHR_mesh_compression
fanzhanggoogle Jul 27, 2017
c765c2f
Added draco extension to extension README
fanzhanggoogle Jul 27, 2017
0cd8f60
Fix for comments
fanzhanggoogle Aug 8, 2017
6102695
Add fallback for loaders not support the extension.
fanzhanggoogle Aug 9, 2017
63f07ee
Changed last paragraph about the fallback
fanzhanggoogle Aug 9, 2017
a8f4e06
Added support for gltf attribute types that are not defined in Draco
fanzhanggoogle Aug 10, 2017
d0d5fa8
Fixed comma
fanzhanggoogle Aug 10, 2017
1da7ae2
Fix duplicate description
fanzhanggoogle Aug 10, 2017
85673d4
fix nit and added 1) attributes in extension must be subset of attrib…
fanzhanggoogle Aug 10, 2017
99b131c
Removed version property, specify draco bitstream version for the ext…
fanzhanggoogle Aug 10, 2017
306e5bc
Refine conformance
fanzhanggoogle Aug 10, 2017
ae9c8d6
removed version in schema; removed alternative approach
fanzhanggoogle Aug 16, 2017
9039f52
Force to consistently use attribute id to get data
fanzhanggoogle Aug 16, 2017
0cdbd3c
Fix example
fanzhanggoogle Aug 29, 2017
d643d96
minor fix
fanzhanggoogle Sep 12, 2017
ae30e83
Removed point cloud.
fanzhanggoogle Oct 4, 2017
2cba5c2
typo
fanzhanggoogle Oct 9, 2017
e71f0d8
Removed unused image
fanzhanggoogle Oct 9, 2017
e3cce40
Wording fix
fanzhanggoogle Nov 1, 2017
66bfc6d
more wording fixes
fanzhanggoogle Nov 1, 2017
734b3cb
more fixes
fanzhanggoogle Nov 1, 2017
e42d251
Change Draft to Complete
fanzhanggoogle Nov 1, 2017
8e9a344
Change Conformance to Recommended Loader Process; change normative
fanzhanggoogle Nov 2, 2017
1eba79a
Make conformance normative
fanzhanggoogle Nov 2, 2017
cb478d9
Merge branch 'master' into KHR_mesh_compression
pjcozzi Feb 8, 2018
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
138 changes: 138 additions & 0 deletions extensions/Khronos/KHR_draco_mesh_compression/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,138 @@
# KHR_draco_mesh_compression

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As the Draco extension is referring to significant external documents – namely the Bitstream specification we should also include, and be consistent with the additional header wording for normative clarity:
https://www.khronos.org/members/login/groups/Agreements%20and%20Licenses/Open%20Source%20Repository%20Resources/Khronos%20Copyright%20License%20Header%20Addition%20for%20NORMATIVE%20CLARITY%20Oct17.txt Note - this has some boiler plate that needs to be tweaked to fit the spec.

The key text in the header is:

Some parts of this Specification are purely informative and do not define requirements
necessary for compliance and so are outside the Scope of this Specification. These
parts of the Specification are marked by the "Note" icon or designated "Informative"
<replace/insert specific conventions for the specification here>.

And

Where this Specification includes normative references to external documents, only the
specifically identified sections and functionality of those external documents are in
Scope. Requirements defined by external documents not created by Khronos may contain
contributions from non-members of Khronos not covered by the Khronos Intellectual
Property Rights Policy.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

## Contributors

* Fan Zhang, Google, <mailto:zhafang@google.com>
* Ondrej Stava, Google, <mailto:ostava@google.com>
* Frank Galligan, Google, <mailto:fgalligan@google.com>
* Kai Ninomiya, Google, <mailto:kainino@google.com>
* Patrick Cozzi, Cesium, [@pjcozzi](https://twitter.com/pjcozzi)

## Status

Draft

## Dependencies

Written against the glTF 2.0 spec.

## Overview

This extension defines a schema to use [Draco geometry compression](https://github.com/google/draco) libraries in glTF format. This allows glTF to support streaming compressed geometry data instead of the raw data. This extension specification is based on [Draco bitestream version 2.0](https://google.github.io/draco/spec/).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Draco bitestream version 2.2

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done


The [conformance](#conformance) section specifies what an implementation must do when encountering this extension, and how the extension interacts with the attributes defined in the base specification.

## glTF Schema Updates

Draco geometry compression library could be used for `primitive` by adding an `extension` property to a primitive, and defining its `KHR_draco_mesh_compression` property.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If a primitive contains an extension property and the extension property defines it's KHR_draco_mesh_compression property, then the Draco geometry compression must be used.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unless the loader doesn't support Draco and use the fallback uncompressed data?


The following picture shows the structure of the schema update.

**Figure 1**: Structure of geometry compression extension.
![](figures/structure.png)

In general, we will use the extension to point to the buffer that contains the compressed data. One of the requirements is that a loader/engine should be able to load the glTF assets no matter it supports the extension or not. To achieve that, all the existing components of the glTF specification stays the same when the extension exists, so that a loader doesn't support decoding compressed assets could just ignore the extension.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Draco extension points to the buffer that contains the compressed data.

If the uncompressed version of the asset is not provided, then KHR_draco_mesh_compression must be added to extensionsRequired.

 "extensionsRequired" : [
     "KHR_draco_mesh_compression"
 ]
 

If KHR_draco_mesh_compression is set in the extensionsRequired property then the primitive should only contain the Draco compressed data.

If a Draco compressed version of the asset is provided then KHR_draco_mesh_compression must be added to extensionsUsed.

 "extensionsUsed" : [
     "KHR_draco_mesh_compression"
 ]
 

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.


Usage of the extension must be listed in the `extensionUsed`.

```javascript
"extensionsUsed" : [
"KHR_draco_mesh_compression"
]

```

The extension then could be used like the following, note that all other nodes stay the same
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Below is an example of what a part of a glTF file may look like if the Draco extension is set. Note that all other nodes stay the same except primitives:

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

except `primitives`:

```javascript

"mesh" : {
"primitives" : [
{
"attributes" : {
"POSITION" : 11,
"NORMAL" : 12,
"TEXCOORD_0" : 13,
"WEIGHTS_0" : 14,
"JOINTS_0" : 15,
},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The attributes above are ignored when the extension is present, correct? Or do these accessors have some special meaning to the Draco extension?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In practical, for an implementation of loader like ThreeJS, it might be OK to ignore the attributes. But it is preferred not to ignore accessors since there are other properties. For example, WebGL might require these properties to render the assets correctly.
Another reason we don't explicitly omit the attributes is that we want to minimize the change in the spec when Draco extension is presented. In our design, the accessors of attributes could even have other extensions as long as they use the decompressed data instead of from bufferView.

Copy link
Contributor

@donmccurdy donmccurdy Aug 7, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I assume you mean that the primitive might list additional attributes here, beyond those encoded in the Draco buffer? If so, then let's clarify this example by changing attributes to avoid duplication:

"attributes" : {
    "TEXCOORD_1" : 11
}

... in which case, a loader would be expected to load POSITION, NORMAL, and TEXCOORD_0 from the Draco buffer, and then to add TEXCOORD_1 from a traditional accessor.

Alternatively, do we consider it valid to include POSITION in attributes, even if it's already in the Draco buffer? This would enable loaders to treat the Draco extension as optional, and to either load the compressed Draco data, or uncompressed data from another buffer, depending on runtime needs/capabilities. Or we could disallow this case, to keep things simple for the initial version, and say that attributes must be omitted when the Draco extension is used.

In previous comments, attributes was removed, and later re-added to specify Draco attribute order. With the observance that object properties aren't ordered, we then added attributeOrder as well. I'm not sure that we need both. Perhaps we don't need either one?

"indices" : 10,
"mode" : 4
"extensions" : {
"KHR_draco_mesh_compression" : {
"bufferView" : 5,
"attributes" : {
"POSITION" : 0,
"NORMAL" : 1,
"TEXCOORD_0" : 2,
"WEIGHTS_0" : 3,
"JOINTS_0" : 4
},
}
}
},
]
}

"bufferViews" : [
// ...
// bufferView of Id 5
{
"buffer" : 10,
"byteOffset" : 1024,
"byteLength" : 10000
}
// ...
}

```
We will explain each of the property in the following sections.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

properties

Should we just remove this line?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed.

#### bufferView
The `bufferView` property points to the buffer containing compressed data. The data should be passed to a mesh decoder and decompressed to a
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The bufferView property points to the buffer containing compressed data. The data must be passed to a Draco decoder and decompressed to a mesh.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

mesh.

### attributes
`attributes` defines the attributes stored in the decompressed geometry. E.g, in the example above, `POSITION`, `NORMAL`, `TEXCOORD_0`, `WEIGHTS_0` and `JOINTS_0`. Each attribute is associated with an attribute id which is its unique id in the compressed data. The `attributes` defined in the extension must be a subset of the attributes of the primitive. To request an attribute, loaders should be able to use the correspondent attribute id specified in the `attributes` to get the attribute from the compressed data.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should -> must

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done


#### Restrictions on geometry type
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When using this extension, the mode of primitive must be either TRIANGLES or TRIANGLE_STRIP and the mesh data will be decoded accordingly.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

When using this extension, the `mode` of `primitive` could only be one of `TRIANGLES` and `TRIANGLE_STRIP` and the mesh data will be decoded accordingly.

### JSON Schema

For full details on the `KHR_draco_mesh_compression` extension properties, see the schema:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It could be cool to try the latest wetzel (CesiumGS/wetzel#4) to generate reference doc to paste in here like the glTF spec has.


* [extension property](schema/node.KHR_draco_mesh_compression.schema.json) `KHR_draco_mesh_compression` extensions object.

## Conformance

To process this extension, there are some changes need to be made in loading a glTF asset.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Below is the process when a loader encounters a glTF asset with the Draco extension set:

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

* If `KHR_draco_mesh_compression` is in `extensionsRequired` then the loader must support the extension or it will fail loading the assets.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If KHR_draco_mesh_compression is in extensionsRequired and the loader does not support the Draco extension, then the loader must fail loading the asset.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

* If `KHR_draco_mesh_compression` is in `extensionsUsed` but not `extensionsRequired`:
* Check if the loader supports the extension. If not, then load the glTF asset ignoring the compression extension in `primitive`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the loader does not support the Draco extension, then load the glTF asset ignoring KHR_draco_mesh_compression in primitive.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

* If the loader supports the extension, then process the extension and ignore the attributes and indices of the primitive that are contained in the extension.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

* If the loader does support the Draco extension, but will not process `KHR_draco_mesh_compression`, then the loader must load the glTF asset ignoring `KHR_draco_mesh_compression` in `primitive`.
* If the loader does support the Draco extension, and will process `KHR_draco_mesh_compression`, then:
  * The loader must process `KHR_draco_mesh_compression` first. The loader must get the data from `KHR_draco_mesh_compression`'s `bufferView` property and decompress the data using a Draco decoder to a Draco geometry.
  * Then the loader must process `attributes` and `indices` properties of the `primitive`. When loading each `accessor`, go to the previously Draco decoded geometry in the `primitive` to get indices and attributes data. A loader must use the decompressed data to overwrite `accessors` or render the decompressed geometry directly (e.g. ThreeJS).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

* When encountering a `primitive` with the extension the first time, you must process the extension first. Get the data from the pointed `bufferView` in the extension and decompress the data to a geometry of a specific format, e.g. Draco geometry.
* Then, process `attributes` and `indices` properties of the `primitive`. When loading each `accessor`, go to the previously decoded geometry in the `primitive` to get indices and attributes data. A loader could use the decompressed data to overwrite `accessors` or render the decompressed geometry directly (e.g. ThreeJS).

It is pretty straightforward for top-down loading of a glTF asset, e.g. only
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove this section

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

decompress the geometry data when a `primitive` is met for the first time. However, for
bottom-up loading, loading `accessor` before `primitive` will not get the data. It could only be handled when processing its parent `primitive`. This is based on the consideration that it will rarely happen that
loading an `accessor` without knowing its parent `primitive`. And it should be
easy enough to change the loader to ignore `accessor` without `bufferView` in glTF 2.0. But we are
definitely open to change this if there actually are some use cases that require
loading `accessor` independently.
Copy link
Contributor

@donmccurdy donmccurdy Aug 7, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Per comment above, could I suggest that the attributes list be omitted, or that we clarify how it must be used in conjunction with Draco?


The extension provides compressed alternatives to one or more of a primitive's uncompressed attributes. A loader may choose to use the uncompressed attributes instead — when the extension is not supported, or for other reasons. When using compressed Draco data, the corresponding uncompressed attributes defined by the primitive should be ignored. If additional uncompressed attributes are defined by the primitive, but are not provided by the Draco extension, the loader must proceed to use these additional attributes as usual.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can remove this section as well and replace it with this (which will be part of the list above.

  * If  additional attributes are defined in `primitive`'s `attributes`, but not defined in `KHR_draco_mesh_compression `'s `attributes`, then the loader must process the additional attributes as usual.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done


* Implementation note: To prevent transmission of redundant data, exporters should generally write compressed Draco data into a separate buffer from the uncompressed fallback, and shared data into a third buffer. Loaders may then optimize to request only the necessary buffers.

If the uncompressed version of asset is not provided for the fallback described above, then the extension must be added to `extenionRequired` so that the loaders/engines don't support the extension could report failure.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

extenionRequired -> extensionsRequired

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. Thanks.


## Resources

* [Draco Open Source Library](https://github.com/google/draco)
* [ThreeJS
Loader](https://github.com/mrdoob/three.js/blob/dev/examples/js/loaders/DRACOLoader.js)
and
[example](https://github.com/mrdoob/three.js/blob/dev/examples/webgl_loader_draco.html)

Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
{
"$schema": "http://json-schema.org/draft-04/schema",
"title": "KHR_draco_mesh_compression extension",
"type": "object",
"properties": {
"bufferView": {
"allOf": [ { "$ref" : "glTFid.schema.json" } ],
"description": "The index of the bufferView."
},
"attributes": {
"type": "object",
"minProperties": 1,
"additionalProperties": {
"$ref": "glTFid.schema.json"
},
"description": "A dictionary object, where each key corresponds to an attribute and its unique attribute id stored in the compressed geometry."
}
},
"additionalProperties": false,
"required": [ "bufferView", "attributes" ]
}
1 change: 1 addition & 0 deletions extensions/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,6 +7,7 @@

#### Draft Khronos extensions
_Draft Khronos extensions are not ratified yet._
* [KHR_draco_mesh_compression](Khronos/KHR_draco_mesh_compression/README.md)
* [KHR_materials_common](Khronos/KHR_materials_common/README.md)
* [KHR_technique_webgl](Khronos/KHR_technique_webgl/README.md)

Expand Down