Consider convenience functions to create instanced models

[javagl]

There currently is a glbToI3dm command that takes a GLB file and generates an I3DM from that. This I3DM contains a single instance. This is of somewhat limited use, considering that I3DM is now considered a 'legacy' format, and there is no longer any benefit of wrapping a GLB into such an I3DM.

We could consider to create utility functions for creating real instanced models.

(The output should preferably be GLBs with EXT_mesh_gpu_instancing extension, but we could also look at creating I3DM (maybe with URI as payload), if it's considered to be worth the effort)

In terms of implementing the functionality itself, this could be a pretty low-hanging fruit. The ExtInstanceFeaturesDemo.ts already shows that creating such a GLB from a bunch of translations is trivial.

The main degree of freedom is: Where does the instancing information come from?

A pragmatic (and generic) first shot could be to just use some JSON file with information like

{
    translations: [
        [1,2,3],
        [2,3,4],
    },
    rotations: [
        [0,0,0,1],
        [0,1,0,0],
    },
    scales: [
        [1,1,1],
        [2,2,2],
    }
}

Apparently, there are sources for data that could be relevant for creating such instanced models. For example, @bertt mentioned in the forum that opentrees.org could be a source for creating instanced tree models. Other sources of instancing information could be databases with the locations of wind power plants, for example. Maybe there could even be a thin convenience layer that takes longitude/latitude/height information and converts that into the low-level translation/rotation/scale information.

[bertt]

@qwork2010 one option https://github.com/Geodan/i3dm.export

[javagl]

@qwork2010 The required functionality has not (yet) been implemented as part of the 3D Tiles Tools. But you could give the tool that bertt linked to a try

[bertt]

@qwork2010 use option --use_gpu_instancing, rotation angles must be in columns roll, pitch, yaw

[bertt]

In I3dm.export you must have the model (glb not I3dm) and model positions and rotations (roll pitch, yaw) in the database table.

[mittermichal]

postgres is not running or maybe it is blocked by windows firewall

[mittermichal]

you should ask questions regarding i3dm.export in its issue tracker instead: https://github.com/Geodan/i3dm.export/issues

[javagl]

Apparently, some of the comments here have been deleted. Well. That's confusing 😕

---

However: I did have another look at the options here. And depending on the intended usage pattern for such a functionality, the overlap to #130 may be considerable (maybe even so large that it will eventually be a single function).

One difficulty is to decide where exactly which part of the "positioning" should be. And this basically boils down to the difference of someone who wants to define the positions/translations in some local coordinate system, and someone who wants to define them with cartographic positions.

The use-case that caused me to have another look at this was this forum thread, where the goal was to create tree instances based on cartographic positions. And assuming that the input is a glTF asset in its "canonical" representation (at the origin, y-up), then the translation and rotation for placing it at the given cartographic position could be represented in different ways:

• In theory, the transforms could be stored in EXT_mesh_gpu_instancing itself, but this is a no-go, due to the usual "jittering" that would result from that
• They could be stored in the glTF, as a transform of the root node. This would solve the problem and might even be OK for some use cases. But the resulting glTF would be pretty "unusual": It would be oriented awkwardly, and far away from the origin
• The transform could be stored in the transform of a tile in a 3D Tiles tileset

I think that the last solution is the most flexible one, for the reasons that I tried to illustrate in this forum thread: It would then be possible to place that "forest-GLB" at any place of earth, just by using the proper tile.transform.

However, as an intermediate step, I just did some experiments for the second solution that stores the transform in the glTF. The following is a snapshot of this experiment:

CreateMeshGpuInstancing 2024-12-07.zip

It contains some example data, and a _CreateMeshGpuInstancing.ts snippet. This snippet offers the functionality to...

• Read a GLB file
• Read a CSV file with (lonDeg,latDeg,heightM) rows (included)
• Create a GLB that uses EXT_mesh_gpu_instancing to create instances of the original GLB at these positions

Loading the resulting GLB in a Sandcastle (also included) will show the result:

But in a follow-up step, this might be generalized to optionally create a tileset that contains the proper transform. Maybe it's possible to address the goal of creating instanced models and #130 with a unified solution here.