Ohhh … OK, that’s something else, and indeed something that could be emphasized when trying to convert between I3DM and GLB+Instancing. It is a somewhat low level aspect, but might be important for people who want to create such data.
In an I3DM, the translations are indeed given in meters. When there is a GLB that is contained in an I3DM, and the I3DM defines translations like (1,0,0) and (2,0,0), then the distance between the instances should be 1 meter.
However, in the GLB+Instancing case, the instancing extension is not applied to the whole glTF, but only to the mesh that is contained in a node. This means that the "TRANSLATION" that is put into the instancing extension will still be affected by the transform of the node. For the given tree.glb, the node that contains the mesh is
"nodes" : [
{
"name" : "tree-beech",
"matrix" : [
0.43513906,
0.0,
0.0,
0.0,
0.0,
0.43513906,
0.0,
0.0,
0.0,
0.0,
0.43513906,
0.0,
-13.904818,
0.1899376,
17.165821,
1.0
],
"mesh" : 0
}
],
which contains some scaling and translation components. This means that the translations that I used in the CreateInstancedTrees.ts, which are
const translations = [
0.0, 0.0, 0.0,
10.0, 0.0, 0.0,
0.0, 0.0, 10.0,
10.0, 0.0, 10.0,
];
will eventually translate the trees by 10 * 0.43513906 meters along the axes.
(Admittedly, I just threw some random numbers into this array, without thinking about the exact units…)
If the "TRANSLATION" in the instancing extension should really be meters, then this would require the (global) transform of that node to be the identity matrix.
Fortunately, glTF-Transform offers some helpful functionality here: The clearNodeTransform and clearNodeParent functions will allow you to easily “bake” any transforms into the meshes. Depending on the exact layout/structure of the input GLB, one might want to update the translation before baking it,so that the object is centered on top of the origin, by calling the center transform to the model before “baking” it.
I updated the code snippet and the resulting GLB here:
27549c.zip (140.6 KB)
And the result will be instances that should indeed be 10 meters apart:

EDIT:
eastNorthUpToFixedFrame should be involved
this should, very roughly speaking, only be necessary for translations that are large enough to be affected by the curvature of the earth. At this point, the question of what the translations (and rotations!) should be, exactly, will become more difficult (but equally so for the I3DM and the GLB case…)