Can I increase pixel limit for an input file?

[Patryk0494]

Hi, I'm traying to optimize my glb file by CLI, but there is an error when textures are compressed: textureCompress: Input image exceeds pixel limit. Is there a way to increase this limit or I have to omit this process?

[donmccurdy]

The limit is coming from lovell/sharp#2373, and is meant to avoid crashing. A limit of 268,402,689 pixels is equivalent to a 16K x 16K image, which costs about 1.5 GB in memory in a 3D viewer, and will certainly be too much for many 3D viewers.

Adding --no-texture-compress will skip the texture processing, as one possible workaround.

I'm not certain how far Sharp can scale for image processing beyond the limit... if using smaller images under 16K x 16K is at all an option for you, I'd recommend that. You may also need to run Node.js with a higher memory limit than the CLI has access to by default, so just adding a new CLI flag to remove the limit might not be enough.

I'm open to other ideas if you'd like to do some further investigation and testing here.

[Patryk0494]

3 of 6 images have size of 16384 x 16384 (1px over 16K), for now I add --no-texture-compress flag, thanks.

There is indeed problem with renedring on scene. Currently i'm traying do load model in giro3d and i failing , thats why I try optimize my file. There is an error in texture loading: THREE.GLTFLoader: Couldn't load texture blob:[URL]. Locally and in (Your) online viewer, but in viewer it's anyway render a model. After otpimazing without texture compress still the same, and the performance is terrible despite optimization decrease number of vertices from 356k to 294k and triangles from 500k to 385k - good reults, over 20%.

I consider to add flag for the sharp limitInputPixels configuration. Mesh is generated from pointcloud and AFAIK, don't have option to config texture size.

[donmccurdy]

Common advice for the web is to keep textures under 2K, or 4K at the most. Since glTF Transform is one of the tools people use to optimize models toward those targets, I'd certainly like for glTF Transform to handle more complex models as input.

I'm nervous to put a "use unlimited memory" flag into the CLI though, without some idea of what it's going to do with 1.5 GB textures and limited actual memory. It might simply crash. Or it might be able to resize the texture to 2-4k, but you'll find the quality isn't acceptable without also reworking the UVs, baking vertex colors, etc.

I don't currently have time to investigate more and come up with those answers, but please feel welcome to do so and share your results. If you'd like to try running texture compression in a Node.js script without the cap, I believe you could work around it like this:

import { NodeIO } from '@gltf-transform/core';
import { ALL_EXTENSIONS } from '@gltf-transform/extensions';
import { textureCompress } from '@gltf-transform/functions';
import _sharp from 'sharp';

function sharp(image) {
  return _sharp(image, { limitInputPixels: false });
}

const io = new NodeIO().registerExtensions(ALL_EXTENSIONS);
const document = await io.read('path/to/input.glb');

await document.transform(
  textureCompress({ encoder: sharp, targetFormat: 'webp', resize: [1024, 1024] })
);

await io.write('path/to/output.glb', document);

You can find the rest of the optimize command's functions in cli.ts, and refer to the draco compression documentation if you're using that.

[donmccurdy]

The option is now available experimentally on the v4 alpha release:

npm install --global @gltf-transform/cli@next

gltf-transform webp in.glb out.glb --no-limit-input-pixels