missing BATCH_LENGTH property in b3dm files

[zeevMarkovitz]

I'm currently trying to upgrade tilesets I created using ContextCapture in 2018. The original .b3dm files don't have the BATCH_LENGTH property, and the upgrade tool doesn't add it during the upgrade process.

I'm currently receiving this error while running the 3d-tiles-validator:

for all .b3dm files in the tileset.

I added the upgraded tileset.json & example .b3dm

AKKO_247_TILES_cESIUM_ACT.zip

[javagl]

A first, quick response is that the upgrade will have to make some assumptions about the validity of the input. It cannot be exected to create "valid" output data from "invalid" input data.

There is a little bit of room for arguing about what "validity" means for "legacy" data, and I'll have a closer look at the data soon. Maybe it could be reasonable to assume that the BATCH_LENGTH is 1 when it is not given only for the upgrade step, but I'll have to confirm that.

[javagl]

There are some unknowns here, and would like to ask for confirmation:

• You used the upgrade command without specifying a targetVersion (i.e. defaulting to a target version of 1.0), is that correct?
• The B3DM file that you attached already is the output of the upgrade command, is that correct?

The point is that it's not clear for me whether the original B3DM files contained glTF 1.0 or glTF 2.0 data. (glTF 2.0 was published mid 2017, so these B3DM files might still contain glTF 1.0).

Could you attach one of the original B3DM files here, so that this can be analyzed further?

It's very likely that the upgrade could be done with a small, custom script if necessary. But I'd like to get a clearer idea about the input, and whether the upgrade command should be modified in any way, so that it automatically covers this sort of input.

[lilleyse]

Maybe it could be reasonable to assume that the BATCH_LENGTH is 1 when it is not given only for the upgrade step, but I'll have to confirm that.

I think BATCH_LENGTH: 0 would be a better assuming the b3dm doesn't have a batch table.

[zeevMarkovitz]

Hi

• I didn't specify a targetVersion. The documentation says it defaults to 1.0 in this condition
• Yes, it is the output of the upgrade. Attached is the sample b3dm file before upgrade

I assume the original b3dm contains glTF 1.0 as I see KHR_binary_glTF being removed from the file during upgrade

AKKO_247_TILES_cESIUM_ACT_og.zip

[javagl]

I had a short look at the B3DM, and it indeed contains glTF 1.0 data, and no feature/batch table.

Depending on your exact goal, there could be two options:

• We could try to fix the upgrade command for the (default) targetVersion=1.0, so that it basically ignores the missing batch/feature table information, and inserts "dummy" information in the output (with BATCH_LENGTH: 0, as Sean said)
• You could try specifying --targetVersion 1.1 as part of the upgrade command.

The latter will not try to upgrade the B3DM to create an "upgraded" B3DM. Instead, it will try to convert the B3DM directly into a GLB (with version 2.0, of course). There are some unknowns, and this is considered as a "preview feature", but from a quick test with the B3DM that you provided and a dummy "tileset.json" that refers to this B3DM, it seemed to work, so it should be worth a try.

(If the goal is to explicitly create B3DM (and not GLB) as the output, then we might have to look closer into that - there'll probably also be an easy solution, but maybe converting to GLB with --targetVersion 1.1 could already resolve this...)