Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Batch Table changes #32

Closed
2 tasks done
pjcozzi opened this issue Nov 6, 2015 · 7 comments
Closed
2 tasks done

Batch Table changes #32

pjcozzi opened this issue Nov 6, 2015 · 7 comments

Comments

@pjcozzi
Copy link
Contributor

pjcozzi commented Nov 6, 2015

From #23:

  • Throughout 3D Tiles, should batchTable be renamed? Something like propertyTable, metadataTable, etc.
  • Throughout 3D Tiles, should the batchTable work more like glTF buffer/bufferView/accessor to avoid arrays of numbers?
@pjcozzi
Copy link
Contributor Author

pjcozzi commented Jan 26, 2016

Throughout 3D Tiles, should batchTable be renamed?

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

@lilleyse
Copy link
Contributor

lilleyse commented Jul 12, 2016

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
Copy link
Contributor Author

pjcozzi commented Jul 12, 2016

+1 from me!

@pjcozzi
Copy link
Contributor Author

pjcozzi commented Jul 13, 2016

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

@pjcozzi
Copy link
Contributor Author

pjcozzi commented Jul 14, 2016

@pjcozzi
Copy link
Contributor Author

pjcozzi commented Sep 1, 2016

Spec updates: #125

@pjcozzi
Copy link
Contributor Author

pjcozzi commented Sep 2, 2016

#125 will be merged shortly.

@pjcozzi pjcozzi closed this as completed Sep 2, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants