You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Header
------
magic // uchar[4], "vctr"
version // uint32, 1
byteLength // uint32, length, in bytes, of the entire tile. See #23
batchTableLength // uint32, length, in bytes, of the batch table. Can be zero.
Batch Table
-----------
// Same as Batched 3D Model. Optional.
Polygons
--------
polygonsLength // uint32, number of polygons in the tile
There are polygonsLength of these (each is variable length):
* batchId // uint32, index into batchTable, zero when Header.batchTableLength === 0
* minimumHeight // float, for shadow volume extrusion optimization
* maximumHeight // float, for shadow volume extrusion optimization
* positionsLength // uint32, number of vertex positions in this polygon
* x, y, z ... // doubles in WGS84 coordinates
* indicesLength // uint32, number of triangle indices
* i0, i1, i2, ... // uint16, every three indices form a triangle
This design assumes server-side triangulation and client-side subdivision and shadow volume extrusion. It includes metadata to optimize shadow volume rendering (which makes a huge difference).
Polygons with holes can be represented as multiple polygons (with or without the same batchId) or as one polygon with disconnected triangles.
The geometry is well behaved: there are no degenerate triangles nor are the duplicate vertex positions.
Cesium should render these tiles with RTC instead of GPU RTE.
Should indices be uint16 or uint32? When using uint16, a big polygon could be represented as several polygons with the same batchId.
minimumHeight and maximumHeight are for rendering optimization. Most likely, they should be a semantic in the Batch Table instead.
minimumHeight and maximumHeight just need to be conservative. Is uint16 more appropriate?
Less Easy Questions
Tight representation for vertex positions, e.g., RTC, EXT_quantized_attributes, delta encoding, Open3DGC SOA vs. AOS, cartographic, etc.
As we add more geometries, including geometries with optional fields, will a hybrid JSON/binary approach, like Binary glTF, be better?
As we add more geometries, do we need to introduce multiple Batch Tables - one per geometry type. Or do we break this into many tile formats and use a Composite (Instanced 3D Model and Composite Tile Formats #23) tile?
See the originial notes for Vector Data.
Considering only polygons and no styling:
This design assumes server-side triangulation and client-side subdivision and shadow volume extrusion. It includes metadata to optimize shadow volume rendering (which makes a huge difference).
Polygons with holes can be represented as multiple polygons (with or without the same
batchId
) or as one polygon with disconnected triangles.The geometry is well behaved: there are no degenerate triangles nor are the duplicate vertex positions.
Cesium should render these tiles with RTC instead of GPU RTE.
Easy Questions
batchId
is the first field here, but the last field in i3dm (Instanced 3D Model and Composite Tile Formats #23). Which do we prefer?uint16
oruint32
? When usinguint16
, a big polygon could be represented as several polygons with the samebatchId
.minimumHeight
andmaximumHeight
are for rendering optimization. Most likely, they should be a semantic in the Batch Table instead.minimumHeight
andmaximumHeight
just need to be conservative. Isuint16
more appropriate?Less Easy Questions
The text was updated successfully, but these errors were encountered: