GitLab

gltfpack: Stop supporting texture compression via external executables

Note the differences between native binaries and node.js

We no longer need unlink() and no longer need to use a horrible hack to
proxy system().

Now that we only have a single mode, we can centralize the Basis
encoding support a little more; we no longer need abstract push/wait
functions etc.

To simplify gltfpack maintenance, we no longer support using toktx or
basisu as command line executables. Instead, we use the builtin BasisU
library if gltfpack was built with it, which allows us to use optimally
threaded compression, or simply error.

For node.js builds we link the native builds instead.

gltfpack: Implement support for KHR_materials_iridescence

This will be upstreamed separately.

Fixes #405.

Added `MESHOPTIMIZER_ALLOC_CALLCONV` (fixes #403)

gltfpack: Update to Basis 1.16

This requires associated changes from zeux/basis_universal @ gltfpack.

gltfpack: Sort bone influences by weight, not by index

This slightly regresses the compression ratio but the delta is not very significant -
it seems to be <~0.1% on most meshes and goes up to ~0.3% on some.

We can probably recoup some of the losses by sorting the skin joints in the future
by making the neighboring joints more spatially proximal wrt rigging.

With this change renderers that discard lower weights and renormalize the rest will
not have to sort the weights for glTF files packed by gltfpack in the future, even
though there's no way to indicate that in the file for now.

gltfpack: Implement a new setting to limit texture dimensions

Add one more explicit int->float cast

When -tl is set, we rescale textures so that the maximum dimension is within the
specified limit; the scaling preserves aspect ratio, eg 1000x100 texture gets
rescaled to 128x18 with -tl 128.

Use ibuf variable name in decodeIndexBuffer example

Fixes #396.

This works around a codesign bug in macOS where cp overwrites the bits of the target executable
but doesn't fix up the codesign metadata so the executable can't be launched.

With this change -test should be usable even if textures are being compressed; we don't
write the resulting textures to files and simply embed them into the binary blob that
is discarded after packing.

gltfpack: Switch to token-based pool from basis_universal fork

This is technically unrelated to improved parallelism but might as well
refactor it here; with this change we also read images in parallel.

This change builds on top of https://github.com/zeux/basis_universal/commit/3c5d651357e75f854f60aa5a65acda4e79e45148
and merges two pools which results in much better scalability, before
this the CPU utilization of gltfpack on large scenes was ~80% during
texture compression and now it's ~100%.

Remove the mention of various executables since they are not always used now.

This is so that build/ and release/ artifacts don't get confused.

Update to WASI SDK 14

gltfpack: Add support for KHR_materials_emissive_strength

This also updates cgltf.h to latest to get support for this extension.

This is needed to get full support for SIMD...

This switches the builds to latest WASI SDK & LLVM. This required minor
tweaks in WASI stubs to compile.

As a result, the .js files unfortunately get ~10% larger. However, the
vertex decoder is ~10% faster as well, so I'm not very motivated to
chase down the precise source of the difference. The 10% size increase
for decoder translates into 600 extra bytes fetched (gzipped).

gltfpack: Compress textures in parallel

This is hard to tune, but seems correct and good enough for now.

Instead of encoding one image at a time and letting Basis do internal
threading we now encode images in parallel using two job pools, one for
actual encoding and another one for farming out Basis encoding jobs.

As a result the compression is much faster, eg jrat.gltf encodes in ~20
seconds before this change and in ~7.5 seconds after it on Ryzen 5900X.

Note that we use two pools but their use isn't very well balanced;
depending on the mode we aren't running as fast as we possibly could, eg
changing both pools to max out logical processor count gets us to 5.5
seconds on the same input. However this would mean that we'd overload
the system so for now we're going to stay conservative.

gltfpack: Cleanup Basis integration

We will need changes from this for parallelism

This allows us to implement pre-encoding