Add 3dtiles(extension)

The .b3dm data was converted from .3dml by TerraExplorer Pro7.2, and gltf was upgraded from 1.0 to 2.0 by tools such as gltf-pipeline, which loaded into ue4 without error, but no data was seen on the screen. I think it is possible that this expansion method is not supported by ue4, how can I fix it if this is the problem?
Or is it because of other reasons?

It’s indeed a bit surprising to see that this is a glTF 2.0 asset, but still requires the EXT_techniques_webgl extension. As far as I know, this should not be the case when the asset was converted with the 3d-tiles-validator tools.

Can you provide more information, for example:

  • The original tileset (with glTF 1.0)
  • The converted tileset (with glTF 2.0)
    • Both of course only if they can be shared, and if they are not too large - otherwise, a single B3DM might already help
  • How exactly did you do the conversion? Note that you should do the update with the specific branch at 3d-tiles-validator/tools at 2.0-tools · CesiumGS/3d-tiles-validator · GitHub
  • Are there any error messages? (See "Window” Menu → Developer Tools → Output Log)

data.rar (155.6 KB)
i upgraded the data by:b3dm → glb → gltf → gltf(2.0) → glb(2.0) → b3dm,because i upgraded this .b3dm directly but the tool did not recognize.
i don’t know whether my route itself is wrong or which link in the middle is wrong.

I started investigating this, but unfortunately, one of the root causes of the problem is already hard to solve: The B3DM files in the 1.0 folder of the attached archive indeed contain glTF 1.0. Now your goal was to update that glTF 1.0 file to glTF 2.0, but a deeper problem is that the input file is already invalid: The JSON part of that file contains

  "buffers" : {
    "KHR_binary_glTF" : {
      "byteLength" : 13308
    }
  },

but the ID of that buffer should not be KHR_binary_glTF, but just binary_glTF (as described in the old specification).

(I even tried to change that, for a single file, manually, with a HEX editor, but that’s difficult, and even if it was a step towards making the file valid, wouldn’t help you much…)


You mentioned that the original data was created with TerraExplorer Pro 7.2. I don’t know the technical details of that software - for example, I do not know if it exports B3DM with glTF 2.0 in the latest version. In any case, the fact that they apparently export invalid glTF 1.0 data in their B3DMs already is a problem. You might consider reaching out to them (or consider a different tool for converting the input data to 3D Tiles, if such a tool is available).

so if i want to solve this problem, i may move the focus forward to the source of the data production。。。

but i used the CesiumJS to test the b3dm(2.0 , which upgraded from 1.0), the data can be loaded,i can see the buildings on the terrain.So i think if the cesium for ue4 is upgraded to the level close to the cesiumJS,(such as upgrading the cesium extension), then some date will be loaded by cesium for ue4.

I don’t think that there are any plans for updating Cesium For Unreal to support the KHR_techniques_webgl extension. This extension was mainly one “migration step” from glTF 1.0 to 2.0. Ideally, new data sets should use glTF 2.0 directly. You might want to reach out to the TerraExplorer developers to see whether they have plans to use an up-to-date format for their output.