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.

Sign up for GitHub

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

Jump to bottom

EXT_mesh_gpu_instancing #1691

Merged
merged 27 commits into from
May 28, 2020
Merged

EXT_mesh_gpu_instancing #1691

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
27 commits
Select commit Hold shift + click to select a range
76587d9
instancing extension
ultrafishotoy Oct 23, 2019
de031ed
cleanup
ultrafishotoy Oct 23, 2019
5d2dac5
overview statement
ultrafishotoy Oct 23, 2019
ed5f6e6
tweak statements
ultrafishotoy Oct 23, 2019
a68dcf6
statement
ultrafishotoy Oct 23, 2019
82b3adb
description
ultrafishotoy Oct 23, 2019
1b4f9c3
typo
ultrafishotoy Oct 23, 2019
956b01d
simple example
ultrafishotoy Nov 6, 2019
62cf80a
syntax fix
ultrafishotoy Nov 6, 2019
2ed4903
teapots galore
ultrafishotoy Nov 6, 2019
a833742
oops
ultrafishotoy Nov 6, 2019
8b8e39a
example image
ultrafishotoy Nov 6, 2019
66fa030
fix path
ultrafishotoy Nov 6, 2019
332af44
update attribs to POSITION, ROTATION, and SCALE
ultrafishotoy Dec 2, 2019
133d28d
rename extension
ultrafishotoy Dec 2, 2019
3857fa7
updated POSITION attribute to TRANSLATION
ultrafishotoy Dec 31, 2019
d53d9c8
remove 'world space' language
ultrafishotoy Jan 5, 2020
b4854e9
new sample files
ultrafishotoy Feb 19, 2020
ea4c776
sample updated with rotation as a quaternion
ultrafishotoy Mar 5, 2020
c70f30e
latest sample files
ultrafishotoy Mar 26, 2020
615652a
oops
ultrafishotoy Mar 26, 2020
8d8f4a0
KHR_mesh_instancing -> EXT_mesh_gpu_instancing
Mar 28, 2020
eef3c13
Merge pull request #1 from donmccurdy/ultrafishotoy-EXT_mesh_gpu_inst…
ultrafishotoy Mar 30, 2020
900ac06
moved to Vendor folder and renamed
ultrafishotoy Mar 31, 2020
5984aa1
Merge branch 'KHR_instancing' of https://github.com/ultrafishotoy/glT…
ultrafishotoy Mar 31, 2020
dbd7b63
specify the types of the attributes
ultrafishotoy Apr 29, 2020
e0a458b
clean up readme.md
ultrafishotoy May 27, 2020
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
64 changes: 64 additions & 0 deletions ...ions/2.0/Khronos/KHR_instancing/extensions/2.0/Khronos/KHR_instancing/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,64 @@
# KHR\_instancing

## Khronos 3D Formats Working Group

* Alexey Knyazev
* Don McCurdy
* Ed Mackey
* Norbert Nopper, UX3D [@UX3DGpuSoftware](https://twitter.com/UX3DGpuSoftware)
* Romain Guy
* Tobias Haeussler
* John Cooke
ultrafishotoy marked this conversation as resolved.
Show resolved Hide resolved

## Acknowledgments

* TODO

## Status

Experimental

## Dependencies

Written against the glTF 2.0 spec.

## Overview

TODO
ultrafishotoy marked this conversation as resolved.
Show resolved Hide resolved

## Extending Nodes with per instance attributes

Instancing is defined by adding the `KHR_instancing` extension to any glTF mesh node. The attributes section contains accessor ids for new TRANSFORM4x3 and ID attribute buffers.
donmccurdy marked this conversation as resolved.
Show resolved Hide resolved
For example, the following defines some instancing attributes to a mesh node in the graph. Instancing only applies to mesh nodes. Applying to nodes rather than meshes allows the
same mesh to be attached as normal to nodes while also being instanced.

```json
{
"nodes": [
{
"mesh": 0,
Copy link
Contributor

Choose a reason for hiding this comment

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

One option we should consider is enabling the KHR_instancing extension to (optionally) override the node.mesh property. For example:

name: "teapot",
mesh: 0,
extensions: {
  KHR_instancing {
    mesh: 1,
    attributes: { ... }
  }
}

This simply provides exporters with some flexibility to control how/if fallback happens for viewers that don't recognize the extension:

  1. When the mesh override is omitted, clients that don't recognize the extension will render a single instance of the mesh with the node's transform.
  2. When the mesh override is provided, it should reference a single instance of the mesh. The fallback node.mesh value could then point to anything the exporter chooses – a merged mesh of all instances, a single point, or a textured plane saying "404 Not Found".
  3. When the KHR_instancing extension is marked as required, clients that don't recognize the extension are expected to fail fast without attempting to proceed.

"name": "teapot",
"extensions": {
"KHR_instancing": {
"attributes": {
"TRANSFORM4x3": 0,
Copy link
Member

Choose a reason for hiding this comment

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

The spec should mention in which coordinate space those transforms are defined. Reasonable options are

  • local, like a regular mesh (full chain: instanced transforms, local node's TRS, all parents to the scene root);
  • scene, like skinned mesh (all local and parent node transforms are ignored).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We're only using local space at otoy. Maybe that could be handled by alternate 'TRANSFORM' attributes that include the space? i.e. TRANSFORM_LOCAL, TRANSFORM_SCENE, with maybe TRANSFORM defaulting to LOCAL?

Copy link
Member

Choose a reason for hiding this comment

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

TRANSFORM_SCENE behavior can be achieved with a node positioned at the scene root. Supporting only local (with explicitly described interaction between JSON-stored local TRS and accessor-stored instanced TRS) seems enough to cover both cases from engine perspective.

"ID": 1
Copy link
Member

Choose a reason for hiding this comment

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

Are these IDs implementation-dependent, with no spec-defined usage? If so, they shouldn't be included here. glTF 2.0 has an established workflow for supporting app-specific attribute semantics - they just start with an underscore.

Otherwise, the spec should be more sound and include at least:

  • allowed datatypes (likely scalar uint8/16/32, uint32 is not available on WebGL 1.0);
  • uniqueness within a set of instances, within a scene, or within an asset (otherwise they should not be called IDs).

In shaders, GPU instances have built-in IDs. Should this attribute be somehow related to them?

},
}
donmccurdy marked this conversation as resolved.
Show resolved Hide resolved
}
}
]
}
```

## Appendix

TODO

## Reference

TODO

### Theory, Documentation and Implementations

TODO
19 changes: 19 additions & 0 deletions ...HR_instancing/extensions/2.0/Khronos/KHR_instancing/schema/glTF.KHR_instaning.schema.json
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,19 @@
{
"$schema": "http://json-schema.org/draft-04/schema",
"title": "KHR_instancing glTF extension",
"type": "object",
"description": "glTF extension defines per mesh instance attributes for a node mesh.",
"allOf": [ { "$ref": "glTFProperty.schema.json" } ],
"properties": {
"attributes": {
"type": "object",
"description": "A dictionary object, where each key corresponds to mesh attribute semantic and each value is the index of the accessor containing attribute's data (current valid attribs are TRANSFORM4x3, ID).",
"minProperties": 1,
"additionalProperties": {
"$ref": "glTFid.schema.json"
}
},
"extensions": { },
"extras": { }
}
}