CesiumGS / cdb-to-3dtiles

Convert CDB to 3D Tiles
Apache License 2.0
76 stars 28 forks source link

This PR adds support for 3D Tiles Next #58

Open sanjeetsuhag opened 3 years ago

sanjeetsuhag commented 3 years ago

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.

lilleyse commented 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.

lilleyse commented 3 years ago

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.

lilleyse commented 3 years ago

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
  }
}
lilleyse commented 3 years ago

Why is content availability stored in a separate binary file instead of embedded in the subtree?

lilleyse commented 3 years ago

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?

sanjeetsuhag commented 3 years ago

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.

lilleyse commented 3 years ago

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
  }
],
lilleyse commented 3 years ago

The feature table property elementCount can be removed. It has since been removed from EXT_feature_metadata.

lilleyse commented 3 years ago

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.

lilleyse commented 3 years ago

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.

lilleyse commented 3 years ago

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)

lilleyse commented 3 years ago

The UI in the linked sandcastle does something weird when the info button is clicked:

Peek 2021-07-12 20-27

lilleyse commented 3 years ago

@sanjeetsuhag I forget, are we able to post a sandcastle demo for Yemen? It would be great to show off the feature id textures

lilleyse commented 3 years ago

@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!

ErixenCruz commented 3 years ago

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.

ErixenCruz commented 3 years ago

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 commented 3 years ago

@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.

sanjeetsuhag commented 3 years ago

An optimization for creating bounding volumes for instanced models would be to add the min and max of the TRANSLATION values to the accessor.

lilleyse commented 3 years ago

I pushed a commit that fixes the 3D Tiles Next links. See https://github.com/CesiumGS/3d-tiles/pull/478

lilleyse commented 2 years ago

@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

sanjeetsuhag commented 2 years ago

@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.

sanjeetsuhag commented 2 years ago

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.