USDZExporter: Add support for WebGPURenderer.

[Mugen87]

Related issue: #29295, #29156 (comment)

Description

The PR makes sure USDZExporter can be used without a dependency to WebGLRenderer by supporting the WebGPU version of TextureUtils. For that, the utils must be configurable.

@donmccurdy Do you think we can apply the same approach to GLTFExporter as well? And is the approach in general acceptable?

The exporters must call decompress() in an async fashion which unfortunately requires quite some refactoring in GLTFExporter.

[donmccurdy]

@Mugen87 I think so; opened #29509. Note that the renderer is an argument to TextureUtils.decompress, so we may need to refactor that a bit as well... maybe separate WebGLTextureUtils and WebGPUTextureUtils?

[mrdoob]

maybe separate WebGLTextureUtils and WebGPUTextureUtils?

That sounds nicer 👍

[Mugen87]

Okay, I have renamed both modules in this PR.

Note that the renderer is an argument to TextureUtils.decompress, so we may need to refactor that a bit as well

We could transform the utils to real classes and then apply the renderer in the ctor:

const utils = new WebGPUTextureUtils( renderer );
exporter.setTextureUtils( utils );

If we decide to do that, I would completely remove the internal renderer creation in the utils. Right now, if no renderer is provided to decompress(), the methods create renderers for each invocation which isn't ideal, tbh (even if they got properly disposed of). The above design would force the app to share the renderer which seems more appropriate to me.

[Mugen87]

I'll go ahead and merge since refactoring WebGLTextureUtils/WebGPUTextureUtils like suggested in #29507 (comment) would require to migrate GLTFExporter. So let's complete #29509 first so GLTFExporter can handle the decompress() call async.