Legacy 3DTiles version

We have encountered a compatibility issue while loading some of the legacy 3dtiles models.

The error message indicates that their data version is not supported by the cesium-unity package (‘Only binary glTF version 2 is supported, found version 1’)

  1. Is there any plan to support older 3dtiles/b3dm versions
  2. Alternatively, is there any tool/flow for converting data from older 3dtile versions to the supported version (we do not have access to the raw data that was used to generate the original 3dtiles)


I cannot speak directly on behalf of the people responsible for Cesium For Unity, but can say with some certainty that glTF 1.0 will very likely not be supported in cesium-native, which is the underlying library of Cesium For Unity.

That being said:

There 3d-tiles-tools project contains some functions that can update tilesets that use glTF 1.0, under certain conditions. (There may be glTF 1.0 assets that can not be updated to glTF 2.0!). Specifically, in the 2.0-tools branch of that project, there is an upgrade function. You could try to apply this to your tileset.

The 3d-tiles-tools in the given form are currently not actively maitained, and setting them up and running them may require some manual steps. But there are efforts for an update/rewrite of the tools that should also include the upgrade function, so that using the upgrade functionality should be easier in the near future.

(If you have a “small” (<10MB) tileset that shows the issue and that can be shared publicly, you could attach it here as a ZIP, and I could give the upgrade function a try…)

Thank Marco,

We will try the upgrade utility.

BTW. Cesium for unity provides error/warning messages in the editor console when encountering issues in the tileset data (unsupported version, corrupted json etc.)
As we change tilesets in runtime we cannot use thess messages and we need better visibility for such issues through api, exceptions or method return code.

for example: currently there is no indication when setting CesiumGeoreference.url to a wrong address or corrupted json during run time.

Thanks again

You’re right, @Liem. I’ve just written an issue to address this.