Asset not visible [ mesh 0 primitive 0: Invalid position buffer ]

Cesium for Unreal
1

KakaoTalk_20220627_133608707
KakaoTalk_20220627_133608707817Ă—75 3.61 KB

After combining several files into 3D tiles, you can see them well when you upload them to ION, but they are not visible in Cesium for Unreal.

2

Would you mind privately sharing with me the asset ID and a token I can use to access it? I’m not sure what’s going wrong there, but I can take a look.

Thanks,
Kevin

3

I sent you a message.
Thank you!

4

Thanks for sending me the details of your tileset. I took a look, and the immediate problem is that your tileset uses two required extensions that are not yet supported by Cesium for Unreal: KHR_techniques_webgl and WEB3D_quantized_attributes.

KHR_techniques_webgl is unlikely to be supported anytime soon as it was never official ratified by Khronos and is likely to be challenging to implement in Unreal because Unreal does not use WebGL.

WEB3D_quantized_attributes is a glTF 1.0 extension, so it’s surprising to see it used here with glTF 2.0. It’s probably nearly accidental that this works in CesiumJS. The preferred modern equivalents would be either KHR_draco_mesh_compression or EXT_meshopt_compression. Draco is currently supported by Cesium for Unreal, and meshopt likely will be in the future.

Kevin

2 Likes
5

Hi @Kevin_Ring,
I have massive tilesets that were shared to me by a partner, produced via Bentley ContextCapture and exported as 3d-tiles. Most of them were glTF version 1.0 and therefore could not be loaded on unreal with error message

LogCesium: Error: [2023-07-04 17:53:59.689] [error] [ErrorList.h:72] Failed to load https://.../tileset_1/p_0.b3dm: - Only binary glTF version 2 is supported, found version 1

So I did upgrade them via npx 3d-tiles-tools upgrade -i "./tileset_1/n_0.json" -o ./_upgraded/tileset_1, but then I’ve got another error when loading them:

LogCesium: Warning: file:///Z:/path_to_/tileset_1/p_0.b3dm mesh 0 primitive 0: Invalid position buffer

Would you mind taking a look to see if this can somehow be fixed via 3D-tiles-tools or another procedure?
Thanks a lot for your time!

6

I’d suggest trying the upgraded tileset in CesiumJS, first.

If it works there but not in Cesium for Unreal, please share your tileset (or one with the same problem) with me so I can see where it’s going wrong.

If it doesn’t work in CesiumJS, either, then you should report an issue in the 3d-tiles-tools repo so that the maintainers of that tool can investigate.

7

Sharing the original version of the file that causes the error (p_0.b3dm) could also be helpful for first tests.

8

Hi again, thanks for getting back.

  • Both the original and upgraded tilesets load great in CesiumJS - urls sent in DM as well as tileset.json and a few b3dm mesh tiles - but lead to this error with the Cesium for Unreal plugin (UE v5.2.1 and latest plugin cesium v1.28.0). So it looks more like a cesium plugin related issue.
  • It seems like the hierarchical structure loads correctly though, as when my viewport is located around where the tileset should be and I decrease Maximum Screen Space Error, higher resolution b3dm mesh tiles also try to load, but again result in the same Invalid position buffer error.
    LogCesium: Warning: http://localhost:8080/_upgraded/tileset_1/p_467.b3dm mesh 0 primitive 0: Invalid position buffer

Sending a follow-up DM, thanks again for looking into that issue!

9

Are you saying you sent me a DM? I don’t think I received it.

10

Sorry I just had time now to send you the sample. Please don’t hesitate if you need anything else!

11

Thanks for sending through your tilesets. I took a look at one of the upgraded ones, and the problem with it is that it is using the WEB3D_quantized_attributes extension. This is a glTF 1.0 extension, so it’s weird to have it in a glTF 2.0 model like this. And in any case, it’s not supported by Cesium for Unreal. We’re currently adding support for KHR_mesh_quantization, which is a similar extension intended for use with glTF 2.0 models.

2 Likes
12

Hi Kevin, thanks for replying so quickly. Indeed weird that the WEB3D_quantized_attributes extension was ported during the 3d-tiles-tools update if it is not glTF 2.0 compatible. Is it possible to drop this extension somehow (“uncompress” the tile payload) by applying a specific glTF update pipeline - or to migrate from WEB3D_quantized_attributes to KHR_mesh_quantization?

Could not find that in the 3d-tiles-tools doc but there are some discussions about these extensions vs draco in this CesiumGS/gltf-pipeline discussion - for example integrated in glTF-transform. Would it be possible to apply via 3d-tiles-tools a pipeline from CesiumGS/gltf-pipeline or donmccurdy/glTF-Transform to do this uncompress step?

Note a Cesium_RTC field is also present in each glb tile that was converted via b3dmToGlb pipeline applied on the upgraded tileset, probably because the check in this condition thought tiles were gltf 2.0.

1 Like
13

I hope it’s OK to chime in here: The 3d-tiles-tools should not insert the WEB3D_quantized_attributes extension. But the upgrade from glTF 1.0 to glTF 2.0 is done with the gltf-pipeline, and it might be that the gltf-pipeline does not remove this extension when it is present in the input. (Most likely because it’s not entirely trivial to remove it…)

And regarding the CESIUM_RTC extension: The line that you linked to is not part of the current release of 3d-tiles-tools. And in fact, this line should cause the CESIUM_RTC extension to be removed if it was present (basically by writing the translation from the extension into a root node of the glTF).

If you could provide the original p_0.b3dm (either by attaching it here, or also via PM), then I could also run some tests on that.

1 Like
14

CESIUM_RTC is supported by Cesium for Unreal, despite technically being a v1.0 extension as well. But yeah, WEB3D_quantized_attributes is a problem and needs to be removed, somehow. Or else support for it needs to be added to cesium-native / Cesium for Unreal. I’m not opposed to the latter, but it’s unlikely to be a priority for the Cesium team, so we’d be looking for a community contribution on it.

You mentioned the tilesets were produced by ContextCapture. Is it possible to recreate them using that tool? I don’t think recent versions of ContextCapture would create tilesets with these very old extensions. Alternatively, you could take an OBJ or whatever single model produced by ContextCapture and let Cesium ion tile into to create 3D Tiles.

2 Likes
15

Hi, thanks again for your replies.

  • I’ll try reworking that tileset to hopefully get rid of the WEB3D_quantized_attributes extension if gltf-pipeline is indeed meant to remove it. Indeed, if cesium-native does not support it but instead supports KHR_mesh_quantization, that extension will probably not be added anytime soon.
  • I will also try to perform an update with dev release (from main) of 3d-tiles-tools regarding the CESIUM_RTC (which is not supported by blender).
  • And finally, I’m hoping I can rework these tilesets without relying on ContextCapture but only OSS tools. They were built on an open-standard, meant to stand the test of time, and I see the 3D-tiles-tools suite as a way to stay up-to-date with the standard spec version/iteration. Is there any other way to upgrade the tileset and get rid of that WEB3D_quantized_attributes extension - either via tooling from the cesium ecosystem or outside?

Thanks again for your time, the discussion is really helpful.