docs: Start mesharrow document conventions

[ibgreen]

https://loaders.gl/docs/arrowjs/usage-guide/mesharrow

[donmccurdy]

@ibgreen if we might want to entertain the idea of Arrow becoming the core GPU memory layout for luma.gl ... should we consider supporting multi-draw indirect in this design? The mesharrow proposal currently in the PR seems close to optimal for a single mesh (perhaps with some uncertainty about the indices), but a list of such per-mesh tables won't scale up for complex AEC/BIM scenes, and I suspect that glTF scenes using EXT_mesh_features would benefit as well. Ideally, the number of buffers and draws would not have to scale up linearly with the number of objects in the scene.

Multi-draw could, for example, involve:

1. VertexTable - ArrowTable with a continuous vertex stream (attributes) for many meshes, each row represents one vertex, each column a vertex attribute
2. IndexTable - ArrowTable with a continuous stream of indices for many meshes. Only contains one column?
3. BatchTable - ArrowTable with a list of drawable primitives, each row represents a primitive, see MultiDrawElements, perhaps with additional attributes for color, transform matrix, visibility state, object name, etc.

A comparable concept in three.js is THREE.BatchedMesh, but it's newer, experimental, and very much "opt-in" today.

Totally understand if you prefer to focus on the mesh-per-table approach, it's just very interesting to consider APIs in which batching is foundational and on by default. :)

[ibgreen]

Totally understand if you prefer to focus on the mesh-per-table approach, it's just very interesting to consider APIs in which batching is foundational and on by default. :)

No, I am actually thinking about this primarily as "one-mesh-per-row" approach.

• The key realization is that aach row can have all its vertices in the POSITIONS column in a List<FixedSizeList<3, double>>.

The record batch structure can certainly be used to wrap each mesh in its own record batch, that way there is no need to concatenate all the array buffers from the different meshes being combined into a table.

As for multidraw, my understanding is that it is an optimized way to draw all the mesh primitives that share materials etc in a single lower overhead call.

If we store one mesh per row, we could just filter out all the Arrow Table rows that were using the same material, and get the start and end indices from the underlying arrow.Data offsets, and populate the multidraw parameter buffer.