Open xeolabs opened 10 months ago
/ping @tmarti !
I had an idea (see https://github.com/xeokit/xeokit-sdk/commit/ea86f96c3cd677589cbce67bf899fc547bcf7137):
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
});
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
});
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:
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.
Currently
SceneModel
class provides a set of builder methods,createGeometry
,createMesh
,createEntity
etc.SceneModel
createsTrianglesDataTextureLayers
, that pack the geometries, meshes and entities into data textures, which get rendered by our data texture shaders.Idea
SceneModel
andTrianglesDataTextureLayer
logic into a NodeJS-based converterSceneModel
(or a new class, maybeDTXSceneModel
) load that XKT/DTX and just transfer the data arrays straight into a set of data texturesUsing 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.