javagl
commented
1 month ago These --options are intended for a very narrow use-case. (And maybe that could be made clearer in the description). They are only passed to the gltf-pipeline for the case where the glTF that is contained in B3DM- or I3DM files is supposed to be upgraded from glTF 1.0 to glTF 2.0. (This in itself is only possible for very few cases - basically, cases where ~"the GLSL shader code (that was still stored in glTF 1.0!) has a certain structure"). So when you have a veeery old tileset, where the B3DMs still contain glTF 1.0 data, then the upgrade (with --targetVersion 1.0, the default) will try to convert this glTF 1.0 into glTF 2.0. And for rare, special cases, it can be useful to pass in additional --options for the conversion.
Or more focussed on your question: There is no built-in mechanism for doing arbitrary invovations of gltf-pipeline (and consequently, no mechanism to pass --options to such an invocation).
But... in a more abstract form, this is a common use-case: "Perform operation X on every tile content". This can often be done with a few lines of custom code. And an approach for generalizing this was ... actually drafted even in one of the first versions of the 3D Tiles Tools. Namely, the concept of a "pipeline". Unfortunately, this was never really settled/solidified (even though it could be remarkably powerful). But fortunately, one of the "initial draft" functionalities that still does work could be helpful here:
Put this into some pipeline.json:
{
"input": "C:/data/glb/tileset.json",
"output": "C:/data/gltf/tileset.json",
"tilesetStages": [
{
"name": "ConvertGlbToGltf",
"contentStages": [
{
"name": "separateGltf"
}
]
}
]
}and run this with
npx 3d-tiles-tools pipeline -i .\pipeline.json
It will read the input, and convert each .glb into a .gltf+resources (updating the content.uris accordingly).
(The "magic" here is that "name": "separateGltf", which is sort of a "predefined command". Generalizing this properly, and defining a real "file format" for the pipelines, including a JSON schema and such, is ... a long-term-maybe 'TODO'...)
I'm still curious about how you intend to do the next step. I don't know how much tooling exists, in NodeJS or in general, for the required steps:
- Uncompress KTX2
- Sure, there is
ktx transcode --target rgba8 example.ktx2 output.rawto convert the KTX data into raw RGBA pixel values, but ... then you'd still have to convert raw RGBA pixel values into PNG. Yeah, it's doable (I just tried this out (in Java), and ... yeah, there are the usual quirks (with the image being flipped vertically and such)), but ... a bit of a hassle...
- Sure, there is
- Update the glTF files to now refer to these PNGs (even though that might be doable with some glTF-Transform trickery...)
- Convert the resulting
.gltffiles back into.glb(there is no "opposite" ofseparateGltfin the current state of that "pipeline" support 😬 )
The easiest approach would be - iff glTF-Transform supported decompressing KTX2 - to just use the following skeleton for "generic tile content processing". In that callback that currently contains the log message, you could ...
- create a glTF-Transform
Documentfrom thesourceEntry.value(GLB data) - twiddle with that document - i.e. apply the hypothetical
transform(ktxToPng()), if this existed... - write the resulting document into a buffer, and return this as the
targetEntry.value
import { TilesetEntry } from "./src/tilesets";
import { BasicTilesetProcessor } from "./src/tools";
async function example() {
const source = "./input/tileset.json";
const target = "./output/tileset.json";
const overwrite = true;
const tilesetProcessor = new BasicTilesetProcessor();
await tilesetProcessor.begin(source, target, overwrite);
// Process all entries that are tile content
await tilesetProcessor.processTileContentEntries(
(uri: string) => uri,
async (
sourceEntry: TilesetEntry,
type: string | undefined
): Promise<TilesetEntry> => {
console.log("In processTileContentEntries");
console.log(" name:" + sourceEntry.key);
console.log(" type: " + type);
const targetEntry : TilesetEntry = {
key: sourceEntry.key,
value: sourceEntry.value
}
return targetEntry;
}
);
await tilesetProcessor.end();
}
example();It might even be possible to come up with some hacky solution here, like an fs.writeFileSync(..."tempInput"), followed by a (CLI!) call to ktx transcode, and then some fs.readFileSync("tempOutput") to read the RGBA pixels, and do some sharp call to convert these pixels to PNG and sneak the result back into the glTF-Transform Texture - but this could only be remotely reasonable iff (if and only if) all this was supposed to be a one-shot operation for one specific tileset...
jo-chemla
Hi there,
I'm trying to parse through every glb tile of a large tileset, trying to decompress textures which are compressed with KTX2. Note KTX2 decompression is not yet available within gltf-pipeline - see probable blockers in this thread for gltf-transform, and linked root issue thread to enable support within
KhronosGroup/Basis-Universal-Transcoders- so I'll do this by myself, but would need to explode everyglbtile togltf + bin geometry + ktx2 texture.I've been trying several iterations of the
upgradecommand with the--optionsflag passed to either--separateTextures,--separateto explode geometry and textures, or--jsonto convert gltf to glb but they all resulted in glb tiles - with packed geometry and textures. By reading through the code, it seems that the targetVersion has to be 1.0 for thesegltfUpgradeOptionsto be passed, but I feel like I'm misunderstanding how to process every tile with gltf-pipeline.Here are some example commands I've tested. Any help would be appreciated! Best regards,