[FEATURE SUGGESTION] A pre-formatted file format for fast loading into data textures

[xeolabs]

Currently

• The SceneModel class provides a set of builder methods, createGeometry, createMesh, createEntity etc.
• Internally, the SceneModel creates TrianglesDataTextureLayers, that pack the geometries, meshes and entities into data textures, which get rendered by our data texture shaders.

Idea

• Put this SceneModel and TrianglesDataTextureLayer logic into a NodeJS-based converter
• The converter would then convert glTF into a set of data arrays, saving those in the XKT file, or in a new file format, eg "DTX"
• The converter would also create a JSON structure within the XKT/DTX that describes all the entities in the model, their colors, AABBS, flags etc
• Then in the viewer, we could have SceneModel (or a new class, maybe DTXSceneModel) load that XKT/DTX and just transfer the data arrays straight into a set of data textures

Using this strategy, we offload things like geometry bucketing, array processing (all the concatenation of arrays etc) onto the converter.

The XKT/DTX would also have "layers" which split the data arrays into portions that will fit into data textures on the viewer's size. These layers could also fit with LoD/streaming somehow.

[xeolabs]

/ping @tmarti !

[xeolabs]

I had an idea (see ea86f96):

1. Add to SceneModel a new dtxLayer component:

mySceneModel.createDTXLayer({
    id: "myDTXLayer1",
    primitive: "triangles",
    origin,
    positionsCompressed,
    metallicRoughness,
    indices8Bits,
    indices16Bits,
    indices32Bits,
    edgeIndices8Bits,
    edgeIndices16Bits,
    edgeIndices32Bits,
    perEntityColors,
    perEntityPickColors,
    perEntitySolid,
    perEntityOffsets,
    perEntityPositionsDecodeMatrices,
    perEntityInstancePositioningMatrices,
    perEntityVertexBases,
    perEntityIndexBaseOffsets,
    perEntityEdgeIndexBaseOffsets,
    perTriangleNumberPortionId8Bits,
    perTriangleNumberPortionId16Bits,
    perTriangleNumberPortionId32Bits,
    perEdgeNumberPortionId8Bits,
    perEdgeNumberPortionId16Bits,
    perEdgeNumberPortionId32Bits
});

2. Extend SceneModel.createMesh to get its geometry, color etc from a portion within a given dtxLayer. This would override 'geometryId, color, 'positions etc.

mySceneModel.createMesh({
    id: "myMesh1",
    dtxLayerId: "myDTXLayer1",
    dtxLayerPortion: 3
});

3. SceneModel.createEntity is unchanged:

mySceneModel.createEntity({
   id: "myEntity1",
   meshIds: ["myMesh1"]
};

Each SceneModel.createDataLayer would simply internally create a TrianglesDataTextureLayer immediately, creating its data textures immediately from the given data arrays. Then createMesh would do very little and just have that portionIndex through which to access certain data textures (flags etc).

The meshes would still need to retain certain JavaScript flag values ('visible', `highlighted' etc), but may be able to extract them from the appropriate data texture arrays, perhaps on-demand on the first time they're queried with the getter methods, then caching them in JavaScript memory.

Or the createDTXLayer could also maybe provide an array of JSON records, one for each mesh, to indicate the flag and color values.

This would require the DTX layers to be created by the converter.

The benefit this approach would be:

• no array concatenations while building the data textures (ie. pushing elements to growing arrays as each mesh as created is expensive)
• pre-bucketed geometry in the data layer
• less logic while creating meshes
• no need to create a new type of SceneModel

Each mesh (or entity) would still need to know it's AABB though. That could be an extra array in the dtxLayer, that doesn't end up in the data texture.

These DTX layers could even be added to the XKT format, and the layer creation functions could be moved into convert2xkt fairly easily.