-
Notifications
You must be signed in to change notification settings - Fork 470
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
Comments
Discussed with @lilleyse offline. We're going to keep |
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:
The data is assumed to be tightly packed, so we are not using a Well known semantics that the client understands how to process like rgb, scale, and normal should be labelled as Every tile format will need to change to support the batch table binary section. |
+1 from me! |
Cesium implementation PR by @lilleyse - CesiumGS/cesium#4112 |
|
Spec updates: #125 |
#125 will be merged shortly. |
From #23:
batchTable
be renamed? Something likepropertyTable
,metadataTable
, etc.batchTable
work more like glTF buffer/bufferView/accessor to avoid arrays of numbers?The text was updated successfully, but these errors were encountered: