Three.js: BasisTextureLoader : prochaines étapes

Je n'ai pas encore examiné le code en détail, mais pourrions-nous retourner de manière synchrone texture partir de load comme le font les autres chargeurs de texture ?

Je pense que c'est bon pour la régularité. Et si nous ne retournons pas de manière synchrone la texture, l'utilisateur doit appeler material.needsUpdate = true en rappel (si la boucle d'animation a déjà commencé).

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;
});

Je n'ai pas encore vérifié pour confirmer que cela fonctionne avec THREE.CompressedTexture , mais si c'est le cas, je suis d'accord, ce serait mieux. ??

Autre nettoyage : les propriétés attribuées à la texture sont un peu arbitraires (restées de la démo de Basis), comme flipY=false . Et il y a une variable startTime inutilisée dans le worker.

Si j'ai raison, les mipmaps ne semblent pas être pris en charge. Le transcodeur ne prend pas en charge ? Ou le chargeur n'a pas encore implémenté la prise en charge des mipmaps ?

Un fichier .basis peut contenir plusieurs niveaux de mipmap, oui. Je pense que le transcodeur le prend déjà en charge, mais je ne l'ai pas testé. BasisTextureLoader ne le supporte pas encore.

Nous devrions également mettre à jour vers la nouvelle/plus petite version du transcodeur : https://github.com/BinomialLLC/basis_universal/pull/7~~ Terminé.

Oui, le transcodeur devrait le prendre en charge. Vous passez le niveau mip en tant que levelIndex à transcodeImage .
https://github.com/BinomialLLC/basis_universal/blob/master/webgl/transcoder/basis_wrappers.cpp#L197

Merci pour vos explications.

Et s'il existe d'autres fonctionnalités que le chargeur n'a pas encore prises en charge, mais que le transcodeur le fait, vous êtes au courant, veuillez les ajouter à la liste TODO. Nous pouvons aider à la mise en œuvre.

Fait un exemple. #16553 C'est peut-être trop simple, n'hésitez pas à l'améliorer/remplacer plus tard s'il est fusionné.

Sur d'autres fonctionnalités que le transcodeur a mais THREE.BasisTextureLoader n'en a pas, une différence clé est que le transcodeur peut sortir de nombreux formats supplémentaires :

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

Honnêtement, je ne sais pas quand utiliser tout cela. Je m'attends à ce que l'utilisateur veuille parfois contrôler cela, et dans d'autres cas, un chargeur (par exemple GLTLFoader) prendra la décision en fonction de l'objectif de la texture. Par exemple, il peut choisir un format compressé différent pour material.map (couleur de base) que pour material.aoMap (occlusion ambiante).

Le moyen le plus évident de supporter cela serait d'ajouter une alternative à detectSupport( renderer ) :

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

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

Cela a un problème potentiel - si je charge plusieurs textures, nous ne voudrons peut-être pas toutes les transcoder dans le même format. Nous pourrions créer plusieurs chargeurs, mais il est alors plus difficile de réutiliser les Web Workers existants (ce qui est important). Nous pourrions passer un format dans la méthode load() , mais ce n'est pas rétrocompatible avec TextureLoader. Je suppose que la meilleure chose pourrait être de s'assurer que faire cela...

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' );

... appliquera toujours le bon format à chaque texture, même si le décodage est asynchrone.

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

Une autre note, juste pour garder cela quelque part : le wrapper JS dans examples/js/libs/basis contient un changement mineur par rapport à la version dans le référentiel Basis. La première déclaration ( var Module ) est remplacée par seulement Module pour activer l'initialisation paresseuse utilisée dans un Web Worker. Cela peut probablement être fait différemment, soit en compilant le transcodeur avec différents drapeaux, soit via https://github.com/BinomialLLC/basis_universal/issues/21.

BasisTextureLoader devrait-il fonctionner en tandem avec glTF ? J'ai essayé d'encoder manuellement les textures au format .basis et d'ajouter BasisTextureLoader en tant que chargeur comme celui-ci :

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

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

Mais les textures ne sont pas rendues correctement et la console a la sortie suivante :

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

même problème que @zeux décrit

J'ai débogué ceci et cela se produit parce que :

1. Le chargeur glTF définit généralement le filtrage magnétique sur LinearMipMapLinearFilter
2. BasisTextureLoader ne prend pas en charge les mipmaps
3. webGL nécessite que les chaînes mip soient complètes :-/

@zeux Non officiellement pris en charge - la spécification glTF de base n'autorise que les textures JPEG et PNG. Mais une extension pour Basis (via le wrapper KTX2) est le mécanisme par lequel nous prévoyons d'ajouter la prise en charge des textures compressées au format. Voir https://github.com/KhronosGroup/glTF/pull/1612 pour les extensions de brouillon (seules les deux premières sont pertinentes ici) et n'hésitez pas à ajouter des commentaires.

Cela dit, le manque de prise en charge des mipmaps dans BasisTextureLoader est purement dû au fait que nous n'y sommes pas encore parvenus. Le transcodeur lui-même devrait prendre en charge cela pour autant que je sache.

PR soumis pour corriger la prise en charge de mipmap - tant que vous convertissez les textures avec l'option -mipmap , le chargeur glTF fonctionne aussi longtemps que vous ajoutez le chargeur comme indiqué ci-dessus, au moins sur le bureau. Je n'ai pas réussi à le faire fonctionner sur un mobile (iPhone ou Android), mais l'exemple de threejs.org avec le cube rotatif ne fonctionne pas non plus sur iPhone, ce qui pourrait être un problème distinct.

Je n'ai pas réussi à le faire fonctionner sur mobile (iPhone ou Android)

À partir des documents de base –

Par exemple, sur iOS, vous ne pouvez utiliser que la puissance carrée de 2 dimensions de texture pour PVRTC1, et il n'y a rien que Basis puisse faire pour vous aujourd'hui qui contourne cette limitation. (Nous prendrons bientôt en charge la possibilité de transcoder des textures non-pow2 plus petites en une puissance plus importante de 2 textures PVRTC1.)

Nous avons utilisé une texture 512x768 dans cette démo, et devrions probablement la remplacer par quelque chose qui correspond à cette contrainte.

Ok - c'est logique. FWIW, le téléphone Android sur lequel j'ai testé présente une multitude de problèmes avec plusieurs démos WebGL, pas seulement liés à la texture de base - un autre téléphone Android fonctionne très bien. Alors oui, c'est probablement juste la restriction de puissance de deux qui pose problème sur iOS.

Diverses mises à jour de BasisTextureLoader à venir sur https://github.com/mrdoob/three.js/pull/16675.

Nous devrions probablement aussi réfléchir à la façon de prendre en charge l'alpha... la documentation de Basis détaille les options (https://github.com/BinomialLLC/basis_universal/#how-to-use-the-system) mais pour certains appareils, cela implique plusieurs sorties de transcodage :

Appareils/API ETC1 uniquement : transcodez en deux textures ETC1 et échantillonnez-les dans un shader. Vous pouvez soit utiliser une texture ETC1 deux fois plus élevée, soit deux textures ETC1 distinctes.

Jusqu'à présent, l'API correspond à TextureLoader , qui devrait changer (ou avoir une API alternative) pour prendre en charge le retour de plusieurs sorties transcodées à partir d'une seule texture .basis .

Le passage à une texture carrée puissance-de-deux dans https://github.com/mrdoob/three.js/pull/16686 corrige la démo sur iOS, mais les mipmaps ne fonctionnent pas :

INVALID_VALUE : compresséTexImage2D : la longueur de ArrayBufferView n'est pas correcte pour les dimensions.

Avons-nous besoin de faire quelque chose de particulier pour les mipmaps avec PVRTC ?

Est-ce que cela se produit pour l'un des derniers mips?

Je n'ai pas débogué d'assez près pour identifier quels mips, mais l'erreur est imprimée trois fois, et les trois derniers avaient tous la même taille de tampon. ??

Je soupçonne que Basis ne calcule pas correctement la taille (en octets) des derniers mips. Pour PVRTC1 4bpp, les dimensions des blocs sont arrondies à 8, donc 4x4, 2x2 et 1x1 doivent être de la même taille que 8x8. Je pense que le transcodeur Basis passe au 4x4. Toutes les images de tailles 8x8, 4x4, 2x2, 1x1 doivent prendre 32 octets ; Je pense que pour 4x4 et ci-dessous, Basis suppose qu'il ne s'agit que d'un bloc 4x4 de 8 octets et vous donne 8 octets au lieu de 32. @richgel999

La formule pour calculer la taille des images est ici : 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

Cette solution de contournement (dans le worker juste avant d'appeler transcode) semble fonctionner pour moi. Cela doit être corrigé dans le transcodeur bien sûr, mais il est facile de le valider en 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 );

Merci! Je vais réparer ça au plus vite.

Le bogue de taille de mipmap PVRTC1 devrait être corrigé. Nous avons corrigé le transcodeur afin qu'il efface les octets supplémentaires sur les petits mips (moins de 8 pixels de large/haut). Et nous avons réparé l'emballage pour retourner les tailles correctes. S'il vous plaît laissez-moi savoir s'il y a des problèmes et je vais les résoudre dès que possible.

@donmccurdy Pourriez-vous ajouter " texture de la méthode load " à la liste des tâches ? (comme takahirox suggéré ci-dessus)

@Ben-Mack ajouté. Notez que parce que les textures avec un canal alpha peuvent transcoder en plusieurs textures, et nous ne le saurons pas de manière synchrone, nous aurons besoin d'une API différente pour cela.

@richgel999 Merci ! J'ai du mal à reconstruire le transcodeur WASM, car https://github.com/BinomialLLC/basis_universal/commit/ab722fa2e18536f9a1d5f33814f3088232446d52 n'a mis webgl/transcoder/basis_wrappers.cpp jour que

$ 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

En théorie, nous devrions pouvoir mettre à PavingStones.basis par celle-ci, qui inclut les mipmaps :

PavingStones.basis.zip

EDIT : Oups, cela pourrait être lié à https://github.com/BinomialLLC/basis_universal/pull/27.

@donmccurdy Je pense que cela nécessite la fusion de https://github.com/BinomialLLC/basis_universal/pull/27 , j'espère que cela pourra arriver bientôt. De plus, votre version d'emscripten peut être antérieure à l'existence d'emmalloc, les fichiers qui font actuellement partie de three.js ont été construits avec 1.38.31, je pense.

Cette erreur s'est produite alors que j'essaie de charger plusieurs fichiers de base en même temps :

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

Pour reproduire, appelez simplement la méthode load 2 fois comme :

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

@Ben-Mack Cela vaut probablement encore la peine d'être corrigé, mais cette erreur est uniquement due au fait que vous chargez exactement la même texture deux fois et que le chargeur réutilise un ArrayBuffer qui ne peut pas être transféré à deux travailleurs en même temps. Le code ci-dessous s'exécute, au prix d'un double travail :

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

@donmccurdy Pour le support d'alpha, qu'en est-il de quelque chose comme :

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

Une option pour prendre en charge l'alpha pourrait également être ajoutée sur le modèle de mipmap :
loader.generateAlpha = true //default

@Makio64 Quelque chose comme ça ! La plupart des chargeurs threejs ne sont pas avec état (un seul chargeur peut travailler sur plusieurs choses en parallèle), alors peut-être :

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

^ Dans les deux cas, mais surtout alpha, je pense qu'il peut y avoir suffisamment de façons différentes de faire les choses pour nécessiter une certaine configuration sur la méthode.

Ou nous pourrions simplement utiliser les nouvelles méthodes de manière asynchrone :

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

La solution asynchrone semble plus facile à mettre en œuvre avec le travailleur et à s'aligner sur les autres chargeurs de threejs.

Je ne peux charger que des textures avec une résolution de 768 sur 512 ou 384 sur 256, etc. toute autre résolution ne parvient pas à se charger avec Three.js et BasisTextureLoader avec avertissement :
"la texture liée à l'unité de texture 0 n'est pas restituable. Elle n'est peut-être pas à la puissance 2 et a un filtrage de texture incompatible."

@mozg4D, veuillez consulter la documentation de base , en particulier les textures au pouvoir de deux sont requises dans iOS. Si la documentation ne correspond pas au comportement que vous voyez, veuillez signaler un nouveau bogue. Il est également possible que le filtrage de texture sélectionné soit incompatible, auquel cas nous aurions encore besoin d'une démo et un nouveau bug serait utile. Merci!

@donmccurdy Le support alpha de Basis sera-t-il bientôt disponible ?

Je pense avoir trouvé un bug : sur iOS uniquement, il y a un effet étrange de "texture glowing" sur les bords de la géométrie de la texture : #17597

Quelqu'un d'autre a-t-il rencontré cela ?

Je pense que sur iOS, il utilisera probablement PVRTC. Cela se produit-il dans une version antérieure (r108) ?
Peut-être pourriez-vous essayer de signaler un problème sur https://github.com/BinomialLLC/basis_universal ?

Cela se produit-il dans une version antérieure (r108) ?

Le bogue que j'ai signalé concerne la r108.

Peut-être pourriez-vous essayer de signaler un problème sur https://github.com/BinomialLLC/basis_universal ?

Était juste en train de le faire : https://github.com/BinomialLLC/basis_universal/issues/78

Je pense avoir trouvé un bug : sur iOS uniquement, il y a un effet étrange de "texture glowing" sur les bords de la géométrie de la texture : #17597

J'ai répondu sur le github de base_universal. Nous allons saisir la texture et voir ce qui se passe. Très probablement, il s'agit d'un artefact lié au fait de ne pas définir correctement l'indicateur de transcodage d'adressage wrap/clamp, ou d'un artefact causé par notre encodeur PVRTC1 en temps réel. Si l'un ou l'autre est le problème, il existe généralement des solutions de contournement. Nous pouvons également augmenter la qualité de PVRTC1, au prix de plus de temps CPU/mémoire de transcodage.

J'ai publié une mise à jour sur https://github.com/BinomialLLC/basis_universal/issues/78#issuecomment -536159690 -- captures d'écran incluses ici.

Il montre le problème de bouclage avec un cube qui ne tourne pas.

J'ai trouvé un autre bug (mais très probablement sans rapport): https://github.com/mrdoob/three.js/pull/17546#commitcomment -35275564

J'ai trouvé un autre bug (mais probablement sans rapport) : #17546 (commentaire)

Corrigé dans #17622.

En termes de mipmaps, existe-t-il un moyen de charger correctement les fichiers de texture de base (référencés dans un fichier .gltf) sans avoir à intégrer les mipmaps dans le fichier .basis ?

Je peux lui faire charger la propriété lorsque je génère le fichier .basis avec -mipmap , mais cela ajoute beaucoup de taille de fichier au fichier .basis - mais lorsque je génère un fichier .basis sans -mipmap option, il apparaît simplement en noir dans le navigateur avec threejs.

En termes de mipmaps, existe-t-il un moyen de charger correctement les fichiers de texture de base (référencés dans un fichier .gltf) sans avoir à intégrer les mipmaps dans le fichier .basis ?

Je peux lui faire charger la propriété lorsque je génère le fichier .basis avec -mipmap , mais cela ajoute beaucoup de taille de fichier au fichier .basis - mais lorsque je génère un fichier .basis sans -mipmap option, il apparaît simplement en noir dans le navigateur avec threejs.

Pour l'instant, vous pouvez désactiver les mipmaps pour afficher la texture :
https://discourse.threejs.org/t/compressed-texture-workflow-gltf-basis/10039/12?u=johannesdeml
https://github.com/JohannesDeml/three.js/commit/909d9cc6dc9192f398df7455f52b7e71e3bf61e2

Bien sûr, cela ne prend pas en charge les mipmaps, mais si votre objectif est de simplement afficher des textures, cela pourrait être une solution simple pour vous.

Cela ne semble plus fonctionner, et il semble que BasisTextureLoader ait maintenant également un code similaire (définir le min/magFilter = LinearFilter) lorsqu'un seul mipmap est détecté (https://github.com/mrdoob/three.js /blob/e66e86901abd84ffc260fea9665170631a2b0493/examples/js/loaders/BasisTextureLoader.js#L170-L171) - c'est ce que génère basisu sans l'option -mipmap . Cependant il est toujours noir.

Pouvez-vous partager le fichier ? Je le faisais pas plus tard que la semaine dernière, même si c'était Basis dans un conteneur .ktx2 plutôt que .basis ...

Et juste pour confirmer – vous savez que vous ne pouvez pas générer ces mipmaps au moment de l'exécution et que vous devrez vous contenter des contraintes d'interpolation impliquées ?

Bien sûr, et merci d'avoir jeté un coup d'œil !

body_green.basis.zip

Et juste pour confirmer – vous savez que vous ne pouvez pas générer ces mipmaps au moment de l'exécution et que vous devrez vous contenter des contraintes d'interpolation impliquées ?

Oui, j'ai compris cela aussi, un peu dommage car une grande partie du gain que j'ai vu dans la taille de fichier inférieure de .basis par rapport à un jpg compressé est alors perdue - je sais que le gain de mémoire GPU est toujours là, mais j'étais surtout axé sur la taille de téléchargement/transfert de la texture.

Et juste pour confirmer – vous savez que vous ne pouvez pas générer ces mipmaps au moment de l'exécution et que vous devrez vous contenter des contraintes d'interpolation impliquées ?

Est-ce toujours le cas lors de l'utilisation de base au lieu de jpg/png ?

Qu'en est-il d'un cas d'utilisation consistant à regrouper 6 textures en tant que liste de visages pour une carte de cube dans un seul fichier de base, car le format prend en charge/mentionne cela sur le README. Le générateur PMREM est-il inutile ici et le fichier de base devrait avoir des mipmaps pour chaque texture générée ?

Que diriez-vous de fournir ces données de texture compressées à utiliser comme cubemap dans ThreeJS ? Normalement, vous passeriez des arguments pour chaque texture individuelle ? (Je n'ai pas encore examiné ce support de chargeur de texture pour voir si un fichier de base avec plusieurs textures est possible) Une alternative est peut-être via KTX2 qui pourrait être plus approprié pour fournir un fichier de base emballé par liste de visages à utiliser comme cubemap?

Une dernière question sur cette utilisation alors que vous discutiez de la gestion de l'alpha, ces textures pourraient être encodées en RGBE ou RGBM (ThreeJS prend en charge M7 et M16). Je n'ai pas étudié dans quelle mesure ceux-ci compressent avec la base, mais ils peuvent avoir des problèmes similaires à ceux des cartes normales. Les données du canal alpha sont assez importantes pour être prises en charge là-bas, je ne sais pas dans quel format de texture compressée elles seront transcodées, certaines peuvent produire des résultats assez médiocres comme l'article lié ci-dessous l'adresse.

ARM a écrit un article sur les problèmes avec ASTC et RGBM par exemple . Le moteur Unity, comme le mentionne l'article, utilise RGBM5, qui devrait dans la plupart des cas couvrir une plage HDR appropriée, le multiplicateur inférieur produira probablement moins de problèmes de qualité de compression qu'une constante de multiplicateur plus élevée si les données entrent dans les limites de la plage.

Désolé, je ne connais pas la réponse à ces questions. Vous aurez peut-être plus de chance sur les référentiels Basis Universal ou KTX GitHub. Je sais que KTX2 est conçu pour prendre en charge les cubemaps avec des charges utiles de base.

Je les ai soulevés ici, car ils semblaient des cas pertinents pour l'utilisation du support ThreeJS et discutés ici.

Basis peut stocker les 6 textures d'un cubemap dans un seul fichier de base. KTX2 avec prise en charge de Basis peut mieux prendre en charge les cubemaps avec plusieurs textures mais un seul fichier à ma connaissance.

La capacité de ThreeJS à le gérer à l'avenir n'est pas claire. Peut-être que 6 fichiers de base différents doivent être fournis, ou gagner KTX2 avec la prise en charge du chargeur de base.

RGBM5 aurait besoin d'un PR séparé, ce serait juste RGBM7 ou RGBM16 qui existent actuellement, ou une variante qui prend un uniforme pour ajuster la valeur du multiplicateur. La partie la plus importante est que l'alpha doit être géré de manière appropriée pour compresser correctement, donc être en mesure d'avoir un certain contrôle sur cela, comme discuté plus tôt dans ce numéro, est un autre exemple de cas où cela serait utile, similaire aux cartes normales et à leur linéaire/ encodage sans couleur, qui peut également avoir le format divisé en deux textures possibles (de RVB monocolore pour X et alpha pour Y dans le fichier de base) en fonction de la prise en charge de la compression.

Three.js prend actuellement en charge Basis Universal. Un nouveau format de base, UASTC, est sorti il ​​y a quelques semaines à peine. Je ne pense pas que Basis ait pris en charge les cubemaps dans un seul fichier avant cela. Les demandes de tirage seraient les bienvenues.

Un chargeur KTX2 est en cours, avec https://github.com/mrdoob/three.js/pull/18490.

Les versions plus anciennes du README for Basis (antérieures à l'UASTC, mais toujours présentes dans le README actuel) mentionnent le regroupement de plusieurs textures dans la fonctionnalité de fichier de base unique :

Les fichiers de base prennent en charge les tableaux de textures non uniformes, de sorte que les cubemaps, les textures de volume, les tableaux de textures, les niveaux de mipmap, les séquences vidéo ou les « tuiles » de texture arbitraires peuvent être stockés dans un seul fichier. Le compresseur est capable d'exploiter les corrélations de couleurs et de motifs sur l'ensemble du fichier, de sorte que plusieurs images avec des mipmaps peuvent être stockées très efficacement dans un seul fichier.

Les demandes de tirage seraient les bienvenues.

Je ne saurais pas par où commencer et je n'ai pas de temps libre pour le moment. Peut-être qu'une fois que ce problème aura été résolu et que le chargeur KTX2 sera prêt, la prise en charge de la cubemap compressée/packée pourra être résolue. Si j'ai du temps libre d'ici là, je serais heureux d'essayer de contribuer à un PR :)

Salut à tous, j'ai un problème intermittent sur iOS (aawww maaaan !)
Fondamentalement, la texture se charge parfois bien, parfois elle n'apparaît pas.
Aucune erreur dans la console, la progression du chargement est de 100%, donc certainement pas un problème de réseau.
Testé à la fois sur l'exemple officiel (https://threejs.org/examples/?q=basis#webgl_loader_texture_basis) et sur mon propre projet. Sur mon iPhone X, sur Safari, la texture apparaît parfois et parfois non.
Sur iPhone 6, Safari, il n'apparaît jamais.
Tous les autres ont l'air bien.
Qu'est ce que ça pourrait être?

[EDIT] vient d'avoir le même problème sur Safari sur Mac OS, toujours intermittent

@igghera On dirait que cela peut être un bogue, surtout si cela se produit sur l'exemple officiel. Cela vous dérange-t-il d'ouvrir un nouveau numéro pour cela? Merci!

Comment pourrait-on ajouter le support des textures de tableau 2D dans BasisTextureLoader ? J'ai un peu regardé mais je ne sais pas trop comment procéder.

Changer la fonction transcode pour parcourir les images à partir du nombre renvoyé par basisFile.getNumImages() semble simple, mais il semble qu'il y ait trois choses à régler après cela :

1. compressedTexImage3D n'existe pas dans THREE.WebGLState et devrait passer une option pour gl.TEXTURE_2D_ARRAY par WebGLRenderingContext.compressedTexImage3D
2. L'API de Basis renvoie des mipmaps individuels par index d'image, mais vous avez besoin d'un seul gros blob de texture à lier pour sampler2DArray ?
3. CompressedTexture aurait besoin d'un moyen d'associer des mipmaps par index d'image. Pour une image de tableau profond de 200 et 6 niveaux de mipmap, cela ferait 1200 entrées de mipmap, donc probablement mipmaps dans CompressedTexture devient un tableau strié. Ou existe-t-il un moyen pour WebGL d'abstraire ce détail ?

Ensuite, pour les textures vidéo, il faudrait probablement une implémentation différente. Plutôt que de transcoder par lots à la fois, vous garderiez le descripteur de fichier de base ouvert et vous auriez un moyen de demander la prochaine image.