Odd texture sizes crash the compressor

[emackey]

Found by one of our internal artists. There was a model that had a bunch of 2048 x 2048 textures, but also had a handful of odd-size things like 349 x 150 or some such. The controls were set for 4x downsampling, and the compressor crashes with a message "width must be a positive integer." It was dividing the image dimensions by 4, not rounding the result, and throwing an exception on the resulting invalid image size.

Ideally, it should not crash in this situation, for example it could round off the smaller image size.

As a bonus, it would be great to have some option to only downsample the larger images that need downsampling, and ignore the smaller images. Deselecting them manually from the list is a tedious process for models with lots of textures, perhaps there could be a filter to select images of a certain size or minimum size.

[emackey]

Idea: Rather than cutting the dimension in half, perhaps it should look for the next-lower power of two!

So for example here, where the crash came from:

glTF-Compressor/app_web/src/main.js

Lines 820 to 824 in cd876c2

	const width = state.gltf.images[i].image.width;
	const height = state.gltf.images[i].image.height;
	const scaled_width = scale > 1? Math.max(width/scale, 1) : width;
	const scaled_height = scale > 1? Math.max(height/scale, 1) : height;

We could instead do something like:

let scaled_width = width;
let scaled_height = height;
if (scale > 1) {
    const factor = Math.log2(scale) - 0.9;
    scaled_width = Math.pow(2, Math.floor(Math.log2(width) - factor));
    scaled_height = Math.pow(2, Math.floor(Math.log2(height) - factor));
}

This would mean that an image dimension of 2001 pixels for example wouldn't cut in half to 1000.5 or even 1000, but would end up being 1024 becoming a power of two. This seems like it would benefit the output models.