Batch Table changes about 3d-tiles

[pjcozzi]

Throughout 3D Tiles, should batchTable be renamed?

Discussed with @lilleyse offline. We're going to keep batchTable.

[lilleyse]

Some ideas for adding a binary section to the batch table to store properties like colors, normals, scales, etc in a more space-efficient way:

Usually the batch table stores an array of values, like:

{
    "id" : ["unique id", "another unique id"],
    "displayName" : ["Building name", "Another building name"],
    "scale" : [1.0, 1.4]
}

But for numeric data like scale it is more efficient to store in a binary form. The property in the batch table can instead reference a chunk of binary data like:

{
    "id" : ["unique id", "another unique id"],
    "displayName" : ["Building name", "Another building name"],
    "scale" : {
        "byteOffset" : 0,
        "componentType" : "FLOAT",
        "type" : "SCALAR"
}

Where:

• byteOffset is the offset from the start of the batchTableBinary.
• componentType can be the following values: "BYTE", "UNSIGNED_BYTE", "SHORT", "UNSIGNED_SHORT", "INT", "UNSIGNED_INT", "FLOAT", and "DOUBLE"
• type can be "SCALAR", "VEC2", "VEC3", "VEC4", "MAT2", "MAT3", "MAT4"

The data is assumed to be tightly packed, so we are not using a byteStride variable for now.

Well known semantics that the client understands how to process like rgb, scale, and normal should be labelled as TILES3D_RGB, TILES3D_SCALE, TILES3D_NORMAL. For these properties the componentType and type are optional.

Every tile format will need to change to support the batch table binary section. batchTable will be broken into batchTableJson and batchTableBinary, and batchTableLength in the header will be replaced by two values batchTableJsonLength and batchTableBinaryLength. Like the batch table itself, batchTableBinary is optional.

[pjcozzi]

+1 from me!

[pjcozzi]

Cesium implementation PR by @lilleyse - CesiumGS/cesium#4112

[pjcozzi]

• We should do #103 as part of this.

[pjcozzi]

Spec updates: #125

[pjcozzi]

#125 will be merged shortly.