won't load properly on 3DTilesRendererJS

[yoyomule]

Hello, I converted the bim model to 3dtile, which can be loaded normally in cesium. But it won't load properly on 3DTilesRendererJS. The error is as follows pic, it seems to be missing a file with root.b3dm I provided the test file in the attachment. bim3dtile.zip

[gkjohnson]

Hi @yoyomule! Thanks for the report.

I downloaded the zip you provided and I'm able to load the tileset without errors. Can you provide more information on your set up? Would you also be able to provide a screenshot of what you expect it to look like?

Please also keep in mind that there are still some unimplemented features such as CMPT file format that can't currently be loaded in this tileset, as well. See #15 for more details.

[gkjohnson]

Ping @yoyomule. Is this still an issue? I'm not seeing the problems you've reported.

[yoyomule]

Sorry, this question is here https://github.com/NASA-AMMOS/3DTilesRendererJS/issues/78#issuecomment-647668347

Garrett Johnson notifications@github.com 于2020年6月30日周二 下午12:11写道：

Ping @yoyomule https://github.com/yoyomule. Is this still an issue? I'm not seeing the problems you've reported.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/NASA-AMMOS/3DTilesRendererJS/issues/78#issuecomment-651519182, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACMJTMXPLACRYN5KCJJHVYDRZFQW7ANCNFSM4OELRVNQ .

[gkjohnson]

Sorry, this question is here

Yes and I've responded here: https://github.com/NASA-AMMOS/3DTilesRendererJS/issues/78#issuecomment-647668347.

I cannot reproduce your problem.

[yoyomule]

Hello, we loaded it, but it is not displayed correctly. I provided two pictures, one is loaded in cesium, and the other is loaded in 3DTilesRendererJS. As you can see, the situation in 3DTilesRendererJS is wrong, It seems to turn into a red object, not the shape of a house,and related error messages are also prompted. bim3dtile.zip

[gkjohnson]

@yoyomule

Great that looks more like what I was seeing.

I have tried loading the /0/2/b0.b3md file alone and scaled it down and saw this:

I saved out the GLB portion of the file and ran it through this GTLF Validator and it looks like there are a lot of validation errors on the file. One that sticks out is that a WEB3D_quantized_attributes extension is used but is not recognized. According to the GLTF Spec this extension is intended for use with GLTF 1.0 only, so it seems that the B3DM file is being incorrectly generated. There are other invalid fields in the GLTF, as well, which explains why the render does not look correct. It seems that Cesium is tolerant to these invalid files in a way that three.js is not.

Unfortunately without valid files I can't do a lot to help with this. How did you generate this 3D Tiles dataset? I recommend looking into why the generation process produced files with incorrect extensions.

Here is the converted GLB in case you want to run the file through the validator yourself to see the errors:

b0.zip

[yoyomule]

As far as we know, b3dm does not necessarily fully follow the gltf standard, it does a compatible treatment. This is the revit model we convert, which contains both the model and the property information corresponding to the model. In addition, we have enabled quantum compression (the bim model is more advantageous with quantum compression), so this compatibility(WEB3D_quantized_attributes) tip appears. At the same time, we provide another scenario transformation model without enabling quantum compression. bim3dtile2.zip

[gkjohnson]

@yoyomule

As far as we know, b3dm does not necessarily fully follow the gltf standard

The documentation for the B3DM file format very specifically states that the embedded mesh is of the GLTF 2.0 format. It's possible that Cesium implements a more flexible interpretation of the spec that supports both GLTF 1.0 and 2.0, which could be why it works there but it's outside the scope of what the spec says is valid. The B3DMLoader in this package depends on the GTLFLoader in the official three.js library so ultimately whatever they support is what will work here.

I've made a few changes to the renderer to handle some failure cases that weren't accounted for previously (and hacked in Draco decompression, see #28) and here's what I'm able to load now. It looks like some of the bounding box positions are off but we can track that down after the data set is working more completely -- thanks for the extra data to test with! It's helped with a couple unsupported cases so far.

I'm still getting errors on loading 4 of the GLTF blobs, though, one of which I'll attach below. Running it through this gltf viewer it looks like an embedded texture is failing to load. And running it through the validator it looks like there are quite a few other issues, as well.

Here's the glb that's failing embedded in the ./1/0/0.b3dm file:

failed-bim.zip

[gkjohnson]

Ping @yoyomule.

With #105 now merged the example now supports DRACO decompression and I've added instructions on how to add it here. It looks like the files you provided are using is using and image/crn format, as well, which seems to be from crunch but it's not supported by three.js' GLTFLoader. For that I recommend making an issue asking for support in the official three.js project or using another supported compressed image format like KTX2 or DDS.

I think I've done all I can for the moment. I think the GLTF validation errors need to be worked out before we can consider any of the other issues here a bug. Let me know if you get any of those figured out and I'm happy to try out a new tileset.

[yoyomule]

模型.3dtilezip https://drive.google.com/file/d/1B4P3D5awALhueatDz79aHanEL_jSKT4i/view?usp=drive_web Thank you for your reply. I re-uploaded a 3dtile file. The data of this file is larger. There are still many errors in our loading. I hope this file is useful for your development. PS. In cesium, this file is normal.

Garrett Johnson notifications@github.com 于2020年7月22日周三 上午11:53写道：

Ping @yoyomule https://github.com/yoyomule.

With #105 https://github.com/NASA-AMMOS/3DTilesRendererJS/pull/105 now merged the example now supports DRACO decompression and I've added instructions on how to add it here https://github.com/NASA-AMMOS/3DTilesRendererJS#adding-draco-decompression-support. It looks like the files you provided are using is using and image/crn format, as well, which seems to be from crunch https://github.com/BinomialLLC/crunch but it's not supported by three.js' GLTFLoader. For that I recommend making an issue asking for support in the official three.js project https://github.com/mrdoob/three.js or using another supported compressed image format like KTX2 or DDS.

I think I've done all I can for the moment. I think the GLTF validation errors need to be worked out before we can consider any of the other issues here a bug. Let me know if you get any of those figured out and I'm happy to try out a new tileset.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/NASA-AMMOS/3DTilesRendererJS/issues/78#issuecomment-662226309, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACMJTMSDRAEMG6UA6KG7MRTR4ZPE7ANCNFSM4OELRVNQ .

[gkjohnson]

Great thanks @yoyomule! Unfortunately I can't download the zip, though. Can you make it public or give access to <removed>?

[gkjohnson]

Thanks for the new data set @yoyomule! This tile set seems to have the same issues mentioned above (https://github.com/NASA-AMMOS/3DTilesRendererJS/issues/78#issuecomment-652186806) in that it contains GLTF blobs that do not adhere to the GLTF spec -- specifically it at least uses the WEB3D_quantized_attributes extension which is not a part of the GLTF 2.0 spec.

PS. In cesium, this file is normal.

Cesium seems to support functionality that is outside of the GLTF spec and their own B3DM and 3DTiles spec. Unfortunately including undocumented features is outside the scope of this project. If you want to use this project you'll have to generate valid B3DM files that adhere to the B3DM Spec and embed valid GLTF 2.0 data, which the ones you've provided do not.

[gkjohnson]

I'm gonna go ahead and close this -- if you have other thoughts on the issue or have a tileset you feel addresses the above comments do feel free to open a new one!

[gkjohnson]

I just fixed an issue that caused incorrect transformations in #151, which likely caused the incorrect transformations here. It doesn't address the quantized attributes but the positions of correctly loaded models should be correct, now. It's been released in v0.2.5.