Three.js: BasisTextureLoader: Próximas etapas

Eu não examinei o código em detalhes ainda, mas poderíamos retornar de forma síncrona texture de load como outros carregadores de textura fazem?

Acho que é bom para a consistência. E se não retornarmos a textura de forma síncrona, o usuário precisará chamar material.needsUpdate = true no retorno de chamada (se o loop de animação já tiver sido iniciado).

var material = new XXXMaterial();
textureLoader.load(..., function (texture) {
  material.map = texture;
   // .map is from null to non-null.
   // User needs to call material.needsUpdate = true here if already started animation loop
   // because whether material.map is null or not affects the final shader code.
  material.needsUpdate = true;
});

Ainda não verifiquei se funciona com THREE.CompressedTexture , mas se for assim, concordo que seria o melhor. 👍

Outra limpeza: as propriedades atribuídas à textura são um pouco arbitrárias (sobras da demonstração do Basis), como flipY=false . E há uma variável startTime não utilizada no trabalhador.

Se eu estiver certo, mipmaps não parece ser compatível. O transcodificador não é compatível? Ou o loader ainda não implementou o suporte a mipmaps?

Um arquivo .basis pode conter vários níveis de mipmap, sim. Acho que o transcodificador já é compatível, mas não testei isso. BasisTextureLoader ainda não oferece suporte.

Devemos atualizar para a versão nova / menor do transcodificador também: https://github.com/BinomialLLC/basis_universal/pull/7~~ Feito.

Sim, o transcodificador deve suportá-lo. Você passa o nível mip de levelIndex para transcodeImage .
https://github.com/BinomialLLC/basis_universal/blob/master/webgl/transcoder/basis_wrappers.cpp#L197

Obrigado por suas explicações.

E se houver qualquer outra funcionalidade que o carregador ainda não tenha suportado, mas o transcodificador sim, você sabe, adicione à lista TODO. Podemos ajudar na implementação.

Fiz um exemplo. # 16553 Pode ser muito simples, sinta-se à vontade para aprimorá-lo / substituí-lo mais tarde se estiver mesclado.

Em outros recursos, o transcodificador tem, mas THREE.BasisTextureLoader não, uma diferença importante é que o transcodificador pode gerar muitos formatos adicionais:

https://github.com/mrdoob/three.js/blob/dev/examples/js/loaders/BasisTextureLoader.js#L264 -L273

Sinceramente, não sei quando usar tudo isso. Espero que o usuário às vezes deseje controlar isso e, em outros casos, um carregador (por exemplo, GLTFLoader) tomará a decisão com base no propósito da textura. Por exemplo, ele pode escolher um formato de compactação diferente para material.map (cor de base) e para material.aoMap (oclusão de ambiente).

A maneira mais óbvia de apoiar isso seria adicionar uma alternativa a detectSupport( renderer ) :

// Let loader decide, based on device capabilities:
loader.detectSupport( renderer );

// Or, choose a particular format:
loader.setFormat( THREE.BasisTextureLoader.BASIS_FORMAT.cTFBC4 );

Isso tem um problema potencial - se estou carregando várias texturas, podemos não querer transcodificá-las todas para o mesmo formato. Poderíamos criar vários carregadores, mas é mais difícil reutilizar os Web Workers existentes (o que é importante). Poderíamos passar um formato para o método load() , mas ele não é compatível com as versões anteriores de TextureLoader. Acho que a melhor coisa pode ser garantir que fazendo isso ...

loader.setFormat( THREE.BasisTextureLoader.BASIS_FORMAT.cTFBC4 );
var fooTex = loader.load( 'foo.basis' );

loader.setFormat( THREE.BasisTextureLoader.BASIS_FORMAT.cTFBC1 );
var barTex = loader.load( 'bar.basis' );

... sempre aplicará o formato correto a cada textura, mesmo que a decodificação seja assíncrona.

Relevante: http://www.reedbeta.com/blog/understanding-bcn-texture-compression-formats/#comparison -table

Outra nota, apenas para manter isso rastreado em algum lugar: o wrapper JS em examples/js/libs/basis contém uma pequena alteração da versão no repositório Basis. A primeira declaração ( var Module ) é substituída por apenas Module para habilitar a inicialização lenta usada em um Web Worker. Provavelmente, isso pode ser feito de forma diferente, compilando o transcodificador com sinalizadores diferentes ou por meio de https://github.com/BinomialLLC/basis_universal/issues/21.

O BasisTextureLoader deve funcionar em conjunto com o glTF? Tentei codificar manualmente as texturas para o formato .basis e adicionar BasisTextureLoader como um carregador como este:

var basisLoader = new THREE.BasisTextureLoader();
basisLoader.setTranscoderPath( 'basis/' );
basisLoader.detectSupport( renderer );

THREE.Loader.Handlers.add( /\.basis$/i, basisLoader );

Mas as texturas não são renderizadas corretamente, e o console tem a seguinte saída:

[.WebGL-000002B68031CEF0]RENDER WARNING: texture bound to texture unit 1 is not renderable. It maybe non-power-of-2 and have incompatible texture filtering.

mesmo problema que @zeux descreve

Eu depurei isso e isso acontece porque:

1. O carregador glTF geralmente define a filtragem magnética para LinearMipMapLinearFilter
2. BasisTextureLoader não suporta mipmaps
3. webGL requer que as cadeias mip sejam completas: - /

@zeux Não oficialmente suportado - a especificação principal do glTF permite apenas texturas JPEG e PNG. Mas uma extensão para o Basis (via wrapper KTX2) é o mecanismo pelo qual planejamos adicionar suporte de textura compactada ao formato. Consulte https://github.com/KhronosGroup/glTF/pull/1612 para extensões de rascunho (apenas os dois primeiros são relevantes aqui) e sinta-se à vontade para adicionar comentários.

Dito isso, a falta de suporte a mipmap em BasisTextureLoader é puramente porque ainda não chegamos a ele. O próprio transcodificador deve suportar isso, pelo que eu sei.

PR enviado para consertar o suporte a mipmap - contanto que você converta texturas com a opção -mipmap , o carregador glTF funciona contanto que você adicione o carregador conforme listado acima, pelo menos no desktop. Não consegui fazer com que ele rodasse no celular (iPhone ou Android), mas o exemplo do threejs.org com o cubo giratório também não funciona no iPhone, então isso pode ser um problema separado.

Não consegui fazê-lo funcionar no celular (iPhone ou Android)

Dos documentos básicos -

Por exemplo, no iOS, você só pode usar a potência quadrada de 2 dimensões de textura para PVRTC1, e não há nada que o Basis possa fazer por você hoje que contorne essa limitação. (Estaremos oferecendo suporte à capacidade de trancodificar texturas menores não-pow2 em uma potência maior de 2 texturas PVRTC1 em breve.)

Usamos uma textura de 512x768 nesta demonstração e provavelmente devemos substituí-la por algo que se encaixe nessa restrição.

Ok - isso faz sentido. FWIW, o telefone Android que eu estava testando tem uma série de problemas com várias demos WebGL, não apenas relacionadas à textura do Basis - um telefone Android diferente funciona perfeitamente. Então, sim, provavelmente é apenas a restrição do poder de dois que é problemática no iOS.

Várias atualizações para BasisTextureLoader chegando em https://github.com/mrdoob/three.js/pull/16675.

Provavelmente também devemos pensar em como oferecer suporte a alfa ... a documentação do Basis entra em alguns detalhes sobre as opções (https://github.com/BinomialLLC/basis_universal/#how-to-use-the-system), mas para alguns dispositivos, isso envolve várias saídas de transcodificação:

Dispositivos / APIs somente ETC1: transcodifique para duas texturas ETC1 e faça uma amostra delas em um sombreador. Você pode usar uma textura ETC1 duas vezes mais alta ou duas texturas ETC1 separadas.

Até agora, a API corresponde a TextureLoader , que precisaria ser alterada (ou ter uma API alternativa) para suportar o retorno de várias saídas transcodificadas de uma única textura .basis .

Alterar para uma textura quadrada de potência de dois em https://github.com/mrdoob/three.js/pull/16686 corrige a demonstração no iOS, mas os mipmaps não estão funcionando:

INVALID_VALUE: compressedTexImage2D: o comprimento de ArrayBufferView não está correto para as dimensões.

Precisamos fazer algo específico para mipmaps com PVRTC?

Isso está acontecendo para um dos últimos poucos mips?

Não depurei de perto o suficiente para identificar quais mips, mas o erro é impresso três vezes e os três últimos tinham o mesmo tamanho de buffer. 🤔

Suspeito que o Basis não calcula o tamanho (em bytes) dos últimos mips corretamente. Para PVRTC1 4bpp, as dimensões dos blocos são arredondadas para 8, portanto, 4x4, 2x2 e 1x1 devem ter o mesmo tamanho que 8x8. Acho que o transcodificador Basis é arredondado para 4x4. Todas as imagens de tamanhos 8x8, 4x4, 2x2, 1x1 devem ter 32 bytes; Acho que para 4x4 e abaixo a base assume que é apenas 1 bloco 4x4 com 8 bytes e fornece 8 bytes em vez de 32. @ richgel999

A fórmula para calcular os tamanhos das imagens está aqui: https://www.khronos.org/registry/OpenGL/extensions/IMG/IMG_texture_compression_pvrtc.txt :

   For PVRTC 4BPP formats the imageSize is calculated as:
     ( max(width, 8) * max(height, 8) * 4 + 7) / 8

Esta solução alternativa (no trabalhador antes de chamar o transcode) parece funcionar para mim. Isso precisa ser corrigido no transcodificador, é claro, mas é fácil validar isso em JS:

var mipWidth = basisFile.getImageWidth( 0, mip );
var mipHeight = basisFile.getImageHeight( 0, mip );
var mipSize = basisFile.getImageTranscodedSizeInBytes( 0, mip, config.format );

if ( config.pvrtcSupported ) {

    // Basis incorrectly computes mip sizes for PVRTC, let's fix them up using the spec:
    // https://www.khronos.org/registry/OpenGL/extensions/IMG/IMG_texture_compression_pvrtc.txt
    mipSize = Math.floor((Math.max(mipWidth, 8) * Math.max(mipHeight, 8) * 4 + 7) / 8);

}

var dst = new Uint8Array( mipSize );

Obrigado! Vou consertar isso o mais rápido possível.

O bug de tamanho do mipmap PVRTC1 deve ser corrigido. Corrigimos o transcodificador para limpar os bytes extras em mips pequenos (menos de 8 pixels de largura / altura). E corrigimos o invólucro para retornar os tamanhos corretos. Informe se houver algum problema e eu irei corrigi-lo o mais rápido possível.

@donmccurdy Você poderia adicionar "Synchronously return texture from load method" à lista de afazeres? (como takahirox sugerido acima)

@ Ben-Mack adicionado. Observe que, como as texturas com um canal alfa podem transcodificar em várias texturas, e não saberemos disso de forma síncrona, precisaremos de uma API diferente para isso.

@ richgel999 Obrigado! Estou tendo problemas para reconstruir o transcodificador WASM, pois https://github.com/BinomialLLC/basis_universal/commit/ab722fa2e18536f9a1d5f33814f3088232446d52 atualizado apenas webgl/transcoder/basis_wrappers.cpp . Compilando no macOS:

$ emcmake cmake ../
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/donmccurdy/Documents/Projects/basis_universal/webgl/transcoder/build

$ make
[ 33%] Linking CXX executable basis_transcoder.js
Traceback (most recent call last):
  File "/Users/donmccurdy/Documents/Projects/emsdk/emscripten/1.37.22/em++", line 16, in <module>
    emcc.run()
  File "/Users/donmccurdy/Documents/Projects/emsdk/emscripten/1.37.22/emcc.py", line 882, in run
    exec 'shared.Settings.' + key + ' = ' + value in globals(), locals()
  File "<string>", line 1, in <module>
NameError: name 'emmalloc' is not defined
make[2]: *** [basis_transcoder.js] Error 1
make[1]: *** [CMakeFiles/basis_transcoder.js.dir/all] Error 2
make: *** [all] Error 2

Em teoria, devemos ser capazes de atualizar o transcodificador e substituir a textura PavingStones.basis atual por esta, que inclui mipmaps:

PavingStones.basis.zip

EDIT: Ops, isso pode estar relacionado a https://github.com/BinomialLLC/basis_universal/pull/27.

@donmccurdy Eu acredito que isso requer https://github.com/BinomialLLC/basis_universal/pull/27 para ser mesclado, espero que isso possa acontecer em breve. Além disso, sua versão emscripten pode ser anterior à existência de emmalloc, os arquivos que atualmente fazem parte de three.js foram construídos com 1.38.31, eu acho.

Este erro ocorreu enquanto tento carregar vários arquivos básicos ao mesmo tempo:

Uncaught (in promise) DOMException: Failed to execute 'postMessage' on 'Worker': ArrayBuffer at index 0 is already neutered.

Para reproduzir, basta chamar load method 2 vezes como:

loader.load( 'textures/compressed/PavingStones.basis');
loader.load( 'textures/compressed/PavingStones.basis');

@ Ben-Mack Provavelmente ainda vale a pena consertar, mas esse erro ocorre apenas porque você está carregando exatamente a mesma textura duas vezes e o carregador reutiliza um ArrayBuffer que não pode ser transferido para dois trabalhadores ao mesmo tempo. O código abaixo é executado, ao custo de fazer o dobro do trabalho:

loader.load( 'textures/compressed/PavingStones.basis?v=1' );
loader.load( 'textures/compressed/PavingStones.basis?v=2' );

@donmccurdy Para o suporte de alpha que tal algo como:

load(...) // as usual
//then :  
loader.getRGBTexture() //return by the load function as usual
loader.getAlphaTexture() //can be use as alphaMap

Uma opção de suporte a alfa também pode ser adicionada ao modelo de mipmap:
loader.generateAlpha = true //default

@ Makio64 Algo assim! A maioria dos carregadores do threejs não tem estado (um único carregador pode estar trabalhando em várias coisas em paralelo), então talvez:

const [ map ]           = loader.loadRGB( 'foo.basis', { ...options } );
const [ map, alphaMap ] = loader.loadRGBA( 'bar.basis', { ...options } );

^ Em ambos os casos, mas especialmente alfa, acho que pode haver maneiras diferentes o suficiente de fazer as coisas para exigir alguma configuração no método.

Ou podemos apenas ir assíncronos nos novos métodos, em vez disso:

loader.loadRGBA( 'bar.basis', { ...options }, ( map, alphaMap ) => {
  // ...
} );

A solução assíncrona parece mais fácil de implementar com o trabalhador e alinhar com os outros carregadores de três js.

Só consigo carregar texturas com resolução de 768 por 512 ou 384 por 256 etc. qualquer outra resolução falha ao carregar com Three.js e BasisTextureLoader com aviso:
"a textura vinculada à unidade de textura 0 não é renderizável. Talvez não seja potência de 2 e tenha filtragem de textura incompatível."

@ mozg4D consulte a documentação do

@donmccurdy O suporte alfa do Basis será lançado em breve?

Acho que encontrei um bug: apenas no iOS, há um efeito estranho de "textura brilhante" nas bordas da geometria da textura: # 17597

Alguém mais encontrou isso?

Acho que provavelmente usará PVRTC no iOS. Isso acontece em uma versão anterior (r108)?
Talvez você possa tentar registrar um problema em https://github.com/BinomialLLC/basis_universal?

Isso acontece em uma versão anterior (r108)?

O bug que preenchi é para o r108.

Talvez você possa tentar registrar um problema em https://github.com/BinomialLLC/basis_universal?

Estava apenas em processo de fazer isso: https://github.com/BinomialLLC/basis_universal/issues/78

Acho que encontrei um bug: apenas no iOS, há um efeito estranho de "textura brilhante" nas bordas da geometria da textura: # 17597

Eu respondi no github basis_universal. Vamos pegar a textura e ver o que está acontecendo. Provavelmente, é um artefato relacionado ao não ajuste correto do sinalizador de transcodificação de endereçamento wrap / clamp ou um artefato causado por nosso codificador PVRTC1 em tempo real. Se algum deles for o problema, geralmente há soluções alternativas. Também podemos aumentar a qualidade do PVRTC1, ao custo de mais tempo / memória da CPU para transcodificação.

Publiquei uma atualização em https://github.com/BinomialLLC/basis_universal/issues/78#issuecomment -536159690 - capturas de tela incluídas.

Mostra o problema de envolvimento com um cubo não giratório.

Encontrei outro bug (mas provavelmente não relacionado): https://github.com/mrdoob/three.js/pull/17546#commitcomment -35275564

Encontrei outro bug (mas provavelmente não relacionado): # 17546 (comentário)

Fixo em # 17622.

Em termos de mipmaps, existe uma maneira de carregar corretamente os arquivos de textura de base (referenciados dentro de um arquivo .gltf) sem ter que incorporar os mipmaps no arquivo .basis?

Posso fazer com que ele carregue o proplery ao gerar o arquivo .basis com -mipmap , no entanto, isso adiciona muito tamanho de arquivo ao arquivo .basis - mas quando gero um arquivo .basis sem -mipmap opção, ele simplesmente aparece como preto no navegador com threejs.

Em termos de mipmaps, existe uma maneira de carregar corretamente os arquivos de textura de base (referenciados dentro de um arquivo .gltf) sem ter que incorporar os mipmaps no arquivo .basis?

Posso fazer com que ele carregue o proplery ao gerar o arquivo .basis com -mipmap , no entanto, isso adiciona muito tamanho de arquivo ao arquivo .basis - mas quando gero um arquivo .basis sem -mipmap opção, ele simplesmente aparece como preto no navegador com threejs.

Por enquanto, você pode desativar mipmaps para mostrar a textura:
https://discourse.threejs.org/t/compressed-texture-workflow-gltf-basis/10039/12?u=johannesdeml
https://github.com/JohannesDeml/three.js/commit/909d9cc6dc9192f398df7455f52b7e71e3bf61e2

Claro que isso não é suporte para mipmaps, mas se seu objetivo é apenas mostrar texturas, essa pode ser uma solução fácil para você.

Isso parece não estar mais funcionando e parece que o BasisTextureLoader agora também tem um código semelhante (definindo o min / magFilter = LinearFilter) quando apenas 1 mipmap é detectado (https://github.com/mrdoob/three.js /blob/e66e86901abd84ffc260fea9665170631a2b0493/examples/js/loaders/BasisTextureLoader.js#L170-L171) - que é o que basisu sem a opção -mipmap gera. No entanto, ainda está preto.

Você pode compartilhar o arquivo? Eu estava fazendo isso recentemente, na semana passada, embora fosse a base em um contêiner .ktx2 vez de .basis ...

E só para confirmar - você está ciente de que não pode gerar esses mipmaps em tempo de execução e teria que se contentar com as restrições de interpolação envolvidas?

Claro, e obrigado por dar uma olhada!

body_green.basis.zip

E só para confirmar - você está ciente de que não pode gerar esses mipmaps em tempo de execução e teria que se contentar com as restrições de interpolação envolvidas?

Sim, eu percebi isso também, uma pena, já que muito do ganho que eu vi em um tamanho de arquivo inferior de .basis em comparação com um jpg compactado é perdido - eu sei que o ganho de memória da GPU ainda está lá, mas eu estava principalmente focado no tamanho de download / transferência da textura.

E só para confirmar - você está ciente de que não pode gerar esses mipmaps em tempo de execução e teria que se contentar com as restrições de interpolação envolvidas?

É sempre esse o caso ao usar o basis em vez de jpg / png?

Que tal um caso de uso de empacotar 6 texturas como facelist para um mapa de cubo em um único arquivo de base, já que o formato suporta / menciona isso no README. O gerador PMREM é inútil aqui e o arquivo base deve ter mipmaps para cada textura gerada?

Que tal fornecer esses dados de textura compactados para uso como um mapa de cubo no ThreeJS? Normalmente você passaria args para cada textura individual? (Eu não olhei para este suporte de carregador de textura para ver se um arquivo de base com várias texturas é possível) Uma alternativa talvez seja via KTX2, que pode ser mais adequado para fornecer um arquivo de base empacotado de facelist para ser usado como um mapa de cubo.

Uma pergunta final sobre esse uso, já que você estava discutindo como lidar com alpha, essas texturas poderiam ser codificadas como RGBE ou RGBM (ThreeJS tem suporte para M7 e M16). Eu não investiguei o quão bem eles são compactados com base, mas eles podem ter problemas semelhantes aos dos mapas normais. Os dados do canal alfa são bastante importantes para ter suporte lá, não tenho certeza para qual formato de textura compactada eles serão transcodificados, alguns podem produzir resultados muito ruins, como o artigo vinculado abaixo aborda.

ARM escreveu um artigo sobre problemas com ASTC e RGBM, por exemplo . O mecanismo Unity, como o artigo menciona, usa RGBM5, que deve, na maioria dos casos, cobrir uma faixa de HDR adequada, o multiplicador mais baixo provavelmente produziria menos problemas de qualidade de compressão do que uma constante de multiplicador mais alta se os dados se encaixassem nos limites da faixa.

Desculpe, não sei a resposta para essas perguntas. Você pode ter mais sorte nos repositórios Basis Universal ou KTX GitHub. Eu sei que o KTX2 foi projetado para oferecer suporte a mapas de cubos com payloads Basis.

Eu os levantei aqui porque pareciam casos relevantes para usar o suporte do ThreeJS sendo discutidos aqui.

O Basis pode armazenar todas as 6 texturas para um mapa de cubo em um único arquivo de base. KTX2 com suporte básico pode fornecer um melhor suporte a mapas de cubo com várias texturas, mas um único arquivo afaik.

O fato de ThreeJS ser capaz de lidar com isso no futuro não está claro. Talvez 6 arquivos de base diferentes precisem ser fornecidos, ou ganhe KTX2 com suporte de carregador de base.

RGBM5 precisaria de um PR separado, seria apenas RGBM7 ou RGBM16 que existe atualmente, ou uma variante que leva um uniforme para ajustar o valor do multiplicador. A parte principal e importante lá é que o alfa precisa ser tratado de forma adequada para compactar corretamente, então ser capaz de ter algum controle sobre isso, conforme discutido anteriormente nesta edição, é outro exemplo de onde isso seria útil, semelhante aos Mapas normais e seus Linear / codificação sem cor, que também pode ter o formato dividido em duas texturas possíveis (de RGB de cor única para X e alfa para Y no arquivo base), dependendo do suporte à compressão.

Three.js atualmente oferece suporte a Basis Universal. Um novo formato de base, UASTC, foi lançado apenas algumas semanas atrás. Eu não acho que o Basis suportava mapas de cubo em um único arquivo antes disso. Solicitações pull seriam bem-vindas.

Um carregador KTX2 está em andamento, com https://github.com/mrdoob/three.js/pull/18490.

Versões mais antigas do README for Basis (antes do UASTC, mas ainda presente no README atual) mostram a menção do empacotamento de várias texturas em um recurso de arquivo de base único:

Os arquivos de base oferecem suporte a matrizes de textura não uniformes, de modo que mapas de cubos, texturas de volume, matrizes de textura, níveis de mipmap, sequências de vídeo ou "blocos" de textura arbitrária podem ser armazenados em um único arquivo. O compressor é capaz de explorar as correlações de cores e padrões em todo o arquivo, de modo que várias imagens com mipmaps podem ser armazenadas de maneira muito eficiente em um único arquivo.

Solicitações pull seriam bem-vindas.

Não saberia por onde começar, nem tenho tempo livre no momento. Talvez assim que este problema progrida para a conclusão e o carregador KTX2 esteja pronto, o suporte ao cubo-mapa compactado / empacotado possa ser resolvido. Se eu tiver tempo livre até lá, ficarei feliz em tentar contribuir com um PR :)

Olá a todos, estou com um problema intermitente no iOS (aawww maaaan!)
Basicamente, a textura às vezes carrega bem, às vezes não aparece.
Nenhum erro no console, o progresso do carregamento é 100%, então definitivamente não é um problema de rede.
Testado no exemplo oficial (https://threejs.org/examples/?q=basis#webgl_loader_texture_basis) e no meu próprio projeto. No meu iPhone X, no Safari, a textura às vezes aparece e às vezes não.
No iPhone 6, Safari, isso nunca aparece.
Todos os outros parecem bem.
O que poderia ser?

[EDIT] acabou de ter o mesmo problema no Safari no Mac OS, ainda intermitente

@igghera Parece que isso pode ser um bug, especialmente se estiver acontecendo no exemplo oficial. Você se importa em abrir uma nova edição para isso? Obrigado!

Como alguém poderia adicionar suporte para texturas de array 2D em BasisTextureLoader ? Eu examinei isso um pouco, mas não tenho certeza de como proceder.

Alterar a função transcode para percorrer as imagens a partir da contagem retornada por basisFile.getNumImages() parece simples, mas parece que há três coisas a serem abordadas a seguir:

1. compressedTexImage3D não existe em THREE.WebGLState e precisaria passar uma opção para gl.TEXTURE_2D_ARRAY por WebGLRenderingContext.compressedTexImage3D
2. A API do Basis retorna mipmaps individuais por índice de imagem, mas você precisa de um único blob de textura grande para vincular sampler2DArray ?
3. CompressedTexture precisaria de uma forma de associar mipmaps por índice de imagem. Para uma imagem de matriz de 200 profundidade e 6 níveis de mipmap, seriam 1200 entradas de mipmap, então provavelmente mipmaps em CompressedTexture torna-se uma matriz strided. Ou existe uma maneira de o WebGL abstrair esses detalhes?

Então, para texturas de vídeo, provavelmente seria necessária uma implementação diferente. Em vez de transcodificar em lote de uma vez, você manteria o identificador de arquivo básico aberto e teria alguma forma de solicitar o próximo quadro.