CLI "prune" operation results in significantly different file size from calling "prune()" transformation via JS before write

[gkjohnson]

Hello! I'm writing a series of scripts for simplifying gltf models using a combination of the javascript library and cli tools. One thing I have generally seen is that even when removing meshes and geometry from the document the file is still fairly bloated. I'm not sure if this is due to empty node structures or remaining buffer data in the file but I've found that calling gltf-transform prune ... fixes the issue. Sometimes from 100+mb down to a few hundred kb in extreme cases (like removing all but 1 mesh a large hierarchy, etc).

Rather than calling prune from the cli I'd prefer to call the prune() function using document.transform but the behavior seems to be significantly different. Here's what's happening:

• I process my model using the JS API
• I write the document to file like so, including the "prune" transformation:

const io = new WebIO();
await object.transform( prune() );
const outputBuffer = ( await io
  .setVertexLayout( VertexLayout.SEPARATE )
  .setLogger( new Logger( Logger.Verbosity.ERROR ) )
  .writeBinary( object ) ).buffer;

• When writing the above buffer to disk it is 108Mb
• I run the same file written to disk through the prune command via the cli:

gltf-transform prune ./output.glb ./pruned.glb

• The file processed by the above command comes out at ~50Kb:

info: prune: Removed types... TextureInfo (375), Material (75), Accessor (128781)
info: test.glb (108.67 MB) → pruned.glb (58.73 KB)

Is there something I'm doing wrong? Any settings the CLI is using that I'm not setting? I'd expect the two file sizes to be identical.

Thank you!

[donmccurdy]

Hm, there shouldn't be a difference, I'd expect the same result as well. Possible to share an example file? Does the input use any glTF extensions? The CLI is running the prune() transform, wrapped in a couple steps defined by the CLI Session, but I wouldn't expect that kind of difference vs. running a script.

Perhaps another possibility is some kind of dual package hazard, if two copies of the @gltf-transform/core package are loaded then instanceof checks can fail, and this might change the result of prune() in unexpected ways.

[gkjohnson]

Perhaps another possibility is some kind of dual package hazard,

Is there any way to check for this?

I've produced a repro with a README inside. It includes a simple script that deletes meshes and then runs "prune" before saving the file. Running "prune" on the output file again reduces the file size significantly. Let me know how this works for you:

prune-repro.zip

[donmccurdy]

Missing await on await document.transform( prune() ); :)

[gkjohnson]

Even with await I'm seeing the same size results (7.8Mb on the output file, 84Kb after cli prune). Are you seeing otherwise? Here's what I changed it to:

// ...

// dispose of the meshes
document
    .getRoot()
    .listMeshes()
    .forEach( mesh => mesh.dispose() );

await document.transform( prune() );

const result = await io
    .setVertexLayout( VertexLayout.SEPARATE )
    .setLogger( new Logger( Logger.Verbosity.ERROR ) )
    .writeBinary( document );
    
// ...

[donmccurdy]

Hm... no I'm not seeing that when running the script. I get:

• 7.8 MB input
• 134 byte output
• 134 byte output w/ CLI prune

Node.js v20.10.0

[gkjohnson]

Thanks - looks like it was related to some NPM / package weirdness (the await was correctly used in my actual project)... It works after removing the package lock & node_modules then reinstalling everything.

Thanks again!