iTwin / itwinjs-core

Monorepo for iTwin.js Library
https://www.itwinjs.org
MIT License
621 stars 210 forks source link

Reality model loading issue #2035

Closed dontbmh closed 2 years ago

dontbmh commented 3 years ago

Hi,

we got a reality model dataset exported through a third-party tool in 3D tileset format. Then the tilesets are loaded via displayStyle.attachRealityModel but there is nothing present. After inspecting the network panel from browser devtools, it can be seen that the tilesets(b3dm) and their corresponding images(blob, image/jpeg) are requested successfully while locating to the area with the reality model attached and there is no logs/errors from imodeljs.

Is imodeljs fully compatible with 3D tilesets? If not, are there any specs/settings that need to be taken care of when generating the 3D tilesets?

For the test purpose, these are two temporary URLs given for Cesium viewer and reality model 3D Tileset, respectively. http://20.48.110.217/reality/cesium1.html http://20.48.110.217/reality/tilesetjson/tileset.json

AlainRobertAtBentley commented 3 years ago

@dontbmh Just answered something concerning elevation on the issue you just closed. The team in charge of Reality Data and geolocation just happens to be the same. As I indicated it would probably be easier for you to open a Service Request for MicroStation. One of the service technician will be assigned and he will keep you updated more effectively than we can here. We did notice that horizontal positioning appeared correct but could not detemine the source of the 15 meter elevation shift. We will keep you updated in any case.

rbois-bentley commented 3 years ago

@dontbmh You could try to disable Draco compression and if that still doesn't work you could try exporting to 3DTiles using GLTF version 1.0 if you can. Not sure if Draco + GLTF 2.0 are supported yet in iModeljs.

pmconne commented 3 years ago

glTF 2.0 is supported. We have an implementation of Draco mesh decoding but it is not fully hooked up. @RBBentley any reason not to add the Draco package dependency and enable decoding?

RBBentley commented 3 years ago

Yes -- This tileset uses Draco3D which as @pmconne points out is currently disabled.

@dontbmh Was this tileset created with the Cesium pipeline? -- Can you retest with Draco compression disabled?

dontbmh commented 3 years ago

@RBBentley Actually, we are using a third-party tool to export the tilesets with glTF 2.0 and Draco compression disabled for sure. After an initial investigation, it can be confirmed that this tool is developed based on Ceisum things but the versions of those are still unspecified yet. Moreover, the lack of error/logging outputs makes the debug more complicated but we are continuously trying.

pmconne commented 2 years ago

The tileset definitely uses Draco compression as revealed in debugger. GltfReader.readMeshPrimitive returns undefined here:

    if (primitive.extensions?.KHR_draco_mesh_compression) {
      return undefined; // Defer Draco decompression until web workers implementation.

image

pmconne commented 2 years ago

@dontbmh I have implemented support for draco mesh decoding in #3106. If you want me to test it against your reality model, please supply a working version. The one previously supplied produces URLs that go outside the root directory - e.g., "http://localhost:8080/dontbmh/../Tile_0003_0020/Tile_0003_0020.b3dm". Otherwise, I will close this issue after the PR merges.