A question about Cell IDs in 3DTILES_bounding_volume_S2's description

[onsummer]

The example in 3DTILES_bounding_volume_S2 #cell-ids is:

0011000000000...000   Root cell 2
0010110000000...000   2nd child of root cell 2
0010111100000...000   4th child of 2nd child of root cell 2
0010111001000...000   1st child of 4th child of 2nd child of root cell 2 

The first one, 001 10 ... 000, Root cell 2, is it means "The 2nd cell of root face cell"?

If not, that is to say "Root cell 2" is "The 3rd cell of root face cell" (root cell's id is indexed started from 0 but not 1), why the first three bits of Cell ID "001 10 ... 000" is "001" but not "010"?

I have read the S2 libary's document about how S2 cell id is numbering (S2 Cell ID Numbering Again), in that document there is a similar S2 Cell ID,

010 10000...0         Face cell 2.

...

and the rules of how S2 cell id is constructed in that document is:

where “face” is a 3-bit number (range 0..5) that selects a cube face, and each of the k “child” values is a 2-bit number that selects one of the 4 children during the subdivision process. The bit that follows the last child is always 1, and all other bits are zero.

So, my question is, in 3DTILES_bounding_volume_S2's document, the first three bits of 2nd cell's id, is "001" or "010"?

By the way, The remaining bits's rules I have already known, thanks for Cesium team's contributing about next genaration 3D Tiles.

[sanjeetsuhag]

Thanks for opening this issue @onsummer. You correctly point out that the spec is inconsistent in its indexing here. I suppose the confusion arose because in the subsequent children illustrations we're using 1-indexed values (example "2nd child"), whereas in the top row, we're using 0-indexed values because it's being described as a cell on its own, and not as a relative child of a parent.

I have opened #613 to correct this.

[onsummer]

thank u @sanjeetsuhag

How to contribute to 3D Tiles Next? I am interested for it for a long time since last year early, but my graphic skill and compute geometry skill is a little poor, so I try to read and understand, translate the 3D Tiles Next extensions' docs to learn something.

Can I PR some translated docs link to the 3D Tiles Next extensions' docs?

[sanjeetsuhag]

Glad to hear that you're interested in contributing to 3D Tiles Next. Reading the specifications and creating issues for discussions regarding any fixes/changes is a great starting point. Beyond specifications, if you were to implement any of the new specs into a project of yours, we'd be happy to showcase it. Do you have any plans or ideas for how you would want to use 3D Tiles Next?

[onsummer]

No, I am still reading and learning the specification, but it's over soon:

• 3DTILES_content_gltf
• 3DTILES_metadata
• 3DTILES_implicit_tiling
• 3DTILES_multiple_content
• 3DTILES_bounding_volume_S2
• EXT_mesh_features
• 3D Metadata Specification

Or can I share my translation as a out link (still writing)?

Next step is to find the implements in CesiumJS source code, and try to write some simple geojson-to-3dtiles-next generator in nodejs to test and verify my understanding.

Future, I might look into some compression optimization techniques for geometry and texture resources, and how to optimistic the json resources, because embbed long json in tileset.json or .subtree files may require long request time.