Open sanjeetsuhag opened 3 years ago
I pushed some updates to the README https://github.com/CesiumGS/cdb-to-3dtiles/pull/58/commits/a20d929477b4c1dfe3b691968edb895af179376b. Are there any datasets that can't be outputted as 3D Tiles Next? It seemed like they all worked. Originally GTModels was not included in the list.
Consider adding support for 3DTILES_metadata
so that the schema is accessible in tileset.json
. This is useful so that applications know what metadata exists without having to load any content.
I noticed that tileAvailability
and contentAvailability
point to different buffer views but I expect the data to be the same. Can they point to the same one?
{
"bufferViews": [
{
"buffer": 0,
"byteLength": 683,
"byteOffset": 0
},
{
"buffer": 1,
"byteLength": 683,
"byteOffset": 0
}
],
"buffers": [
{
"byteLength": 688
},
{
"byteLength": 688,
"uri": "../availability/0_0_0.bin"
}
],
"childSubtreeAvailability": {
"constant": 0
},
"contentAvailability": {
"bufferView": 1
},
"tileAvailability": {
"bufferView": 0
}
}
Why is content availability stored in a separate binary file instead of embedded in the subtree?
I see there were some code changes to get a more accurate min/max height. How easy would it be to fix https://github.com/CesiumGS/cdb-to-3dtiles/issues/39?
Are there any datasets that can't be outputted as 3D Tiles Next?
I opened https://github.com/CesiumGS/cdb-to-3dtiles/issues/59 noting that we don't currently support reading the Surface Substrate
and Secondary Substrate(s)
from the Composite Material Tables.
Good to see that negative levels are supported :+1:
"children": [
{
"boundingVolume": {
"region": [-2.0594885173533086,0.5585053606381855,-2.0420352248333655,0.5759586531581288,0.0,0.0]
},
"children": [
{
"boundingVolume": {
"region": [-2.0594885173533086,0.5585053606381855,-2.0420352248333655,0.5759586531581288,0.0,0.0]
},
"content": {
"uri": "N32W118_D300_S001_T001_L{level}_U{y}_R{x}.glb"
},
"extensions": {
"3DTILES_implicit_tiling": {
"maximumLevel": 2,
"subdivisionScheme": "QUADTREE",
"subtreeLevels": 7,
"subtrees": {
"uri": "subtrees/{level}_{x}_{y}.subtree"
}
}
},
"geometricError": 292.96875
}
],
"content": {
"uri": "N32W118_D300_S001_T001_LC1_U0_R0.glb"
},
"geometricError": 585.9375
}
],
The feature table property elementCount
can be removed. It has since been removed from EXT_feature_metadata.
GTModels have a _FEATURE_ID_0
attribute on each primitive but it's not linked to a feature table. I assume it can be removed because the instancing extension is what links to the feature table.
For San Diego - what is the GTModels/1_1/Gltf
folder for? It has D500_S001_T001_AL015_000_coronado_bridge.glb
but N32W118_D101_S001_T001.json
doesn't seem to reference it.
HydrographyNetwork/N32W118_D204_S002_T005_LC6_U0_R0.glb
doesn't pass the validator. (That's the only one I checked, but I assume something is wrong with vector datasets)
The UI in the linked sandcastle does something weird when the info button is clicked:
@sanjeetsuhag I forget, are we able to post a sandcastle demo for Yemen? It would be great to show off the feature id textures
@sanjeetsuhag @ErixenCruz that's my first pass over the CLI, README, and inspecting the tileset output. I'll probably do a quick code pass later. So far seems pretty good!
For #39 I think it would not be too much work. We already have that branch that is mentioned in the issue that has most of the changes needed to calculate the tighter bounding region. For implicit, only the non positive levels would be affected.
Why is content availability stored in a separate binary file instead of embedded in the subtree?
I believe originally for multicontent, we were going to need per-content availability, and we thought it made more sense to store availability binaries within their respective content folder instead of smashing them all on the end of the subtree file. Multicontent was abandoned, but that decision was not revisited
@sanjeetsuhag I forget, are we able to post a sandcastle demo for Yemen? It would be great to show off the feature id textures
Yes. the Sandcastle can be found here.
An optimization for creating bounding volumes for instanced models would be to add the min and max of the TRANSLATION
values to the accessor.
I pushed a commit that fixes the 3D Tiles Next links. See https://github.com/CesiumGS/3d-tiles/pull/478
@sanjeetsuhag is there any top-level metadata (provenance information like author, date, etc) that should get carried over into tileset metadata? And more generally is there any other CDB metadata that's not getting carried through into the tileset?
CC @bradyjmoore
@lilleyse From what I recall, the problem here is that the CDB datasets we have kinda follow rules of their own in terms of what they put in the top level Metadata folders. I remember the LA CDB had a completely different set of namespaces in its Metadata.XML compared to the San Diego one. That being said, I don't think we've looked at the CDB spec either about what the typical way of doing this is.
Before this is merged, we should implement support for propagating feature ID textures to higher LODs where the RMTexture
dataset does not extend, but the Imagery
does.
3D Tiles Next is a set of capabilities for the future of 3D Tiles. Read the overview document for more details.
This PR adds support for the following extensions:
This PR also adds support for the RMTexture and RMDescriptor datasets.