Internal "Document" Format?

[KooIaIa]

Does glTF-Transform have a 'format' for its "Document"? Internally, is the glTF object treated as JSON of all the deconstructed buffers or anything like that?

[donmccurdy]

The Document is a JS class instance with methods below:

https://gltf-transform.donmccurdy.com/classes/core.document.html

Its content is 1:1 analogous to the glTF JSON content, but is not stored internally as glTF JSON, but instead as a reference graph, to help manage references during editing.

EDIT: The reference graph is now published as a standalone package: https://github.com/donmccurdy/property-graph

[KooIaIa]

I think I may be looking for the "reference graph" format.

Is there anything on what the reference graph looks like - could it be stringified as a JSON object?

I may also just be misunderstanding, does the reference graph break apart the GLTF into human readable transformable data? Like for example, a human readable list of all vertices of a model after being extracted from a buffer?

[donmccurdy]

The reference graph is more of an internal implementation detail — it is meant to be a convenient JavaScript API but not an alternative data format. The "nodes" of the graph are class instances like "Texture" or "Accessor" and not JSON primitives, but I suppose it could be stringified if you write some code defining how to stringify the node types you're interested in. Buffers are unpacked into JavaScript types like Float32Array or Uint8Array, but to make a human-readable printout or UI you'd need to display those yourself.

A simple example to extract and display vertex positions:

const mesh = document.getRoot().listMeshes().pop();
const prim = mesh.listPrimitives().pop();

// debug Primitive properties.
console.log(prim);

// debug Primitive vertex position data.
const position = prim.getAttribute('POSITION'); // Accessor
const positionArray = Array.from(position.getArray()); // Float32Array → Array
console.log(positionArray);

^Run this script in https://gltf.report/ with a small glTF/GLB model for a quick test. The website is converting the result of getter methods like prim.getMaterial() and prim.getName() into the "material" and "name" properties shown in the logs.

[donmccurdy]

In the upcoming release (v2.0) I've refactored the internal graph into a separate package, which now provides a somewhat better answer to this question: https://github.com/donmccurdy/property-graph