Three.js: BasisTextureLoader: Nächste Schritte

Ich habe den Code noch nicht im Detail untersucht, aber könnten wir synchron texture von load wie es andere Texturlader tun?

Ich finde es gut für die Konsistenz. Und wenn wir die Textur nicht synchron zurückgeben, muss der Benutzer material.needsUpdate = true im Callback aufrufen (wenn bereits eine Animationsschleife gestartet wurde).

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

Ich habe noch nicht überprüft, ob das mit THREE.CompressedTexture funktioniert, aber wenn ja, stimme ich zu, dass das am besten wäre. 👍

Andere Bereinigung: Die der Textur zugewiesenen Eigenschaften sind ein wenig willkürlich (überbleibt von der Basis-Demo), wie flipY=false . Und es gibt eine ungenutzte startTime Variable im Worker.

Wenn ich richtig liege, scheint Mipmaps nicht unterstützt zu werden. Transcoder unterstützt nicht? Oder hat der Loader noch nicht nur Mipmaps-Unterstützung implementiert?

Eine .basis Datei kann mehrere Mipmap-Ebenen enthalten, ja. Ich denke, der Transcoder unterstützt es bereits, aber ich habe das nicht getestet. BasisTextureLoader unterstützt es noch nicht.

Wir sollten auch auf die neue/kleinere Version des Transcoders aktualisieren: https://github.com/BinomialLLC/basis_universal/pull/7~~ Fertig.

Ja, der Transcoder sollte es unterstützen. Sie übergeben den Mip-Level als levelIndex an transcodeImage .
https://github.com/BinomialLLC/basis_universal/blob/master/webgl/transcoder/basis_wrappers.cpp#L197

Danke für deine Erklärungen.

Und wenn es noch andere Funktionen gibt, die der Loader noch nicht unterstützt, der Transcoder jedoch, die Ihnen bekannt sind, bitte zur TODO-Liste hinzufügen. Wir können bei der Umsetzung helfen.

Habe ein Beispiel gemacht. #16553 Es kann zu einfach sein, Sie können es später verbessern / ersetzen, wenn es zusammengeführt wird.

Auf andere Funktionen hat der Transcoder, aber THREE.BasisTextureLoader nicht. Ein wesentlicher Unterschied besteht darin, dass der Transcoder viele zusätzliche Formate ausgeben kann:

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

Ich weiß ehrlich gesagt nicht, wann ich all dies verwenden soll. Ich gehe davon aus, dass der Benutzer manchmal die Kontrolle darüber haben möchte, und in anderen Fällen wird ein Loader (zB GLTFLoader) die Entscheidung basierend auf dem Zweck der Textur treffen. Beispielsweise kann für material.map (Grundfarbe) ein anderes komprimiertes Format gewählt werden als für material.aoMap (Umgebungsokklusion).

Der offensichtlichste Weg, dies zu unterstützen, wäre, eine Alternative zu detectSupport( renderer ) hinzuzufügen:

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

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

Dies hat ein potenzielles Problem – wenn ich mehrere Texturen lade, möchten wir sie möglicherweise nicht alle in das gleiche Format transkodieren. Wir könnten mehrere Loader erstellen, aber dann ist es schwieriger, vorhandene Web Worker wiederzuverwenden (was wichtig ist). Wir könnten ein Format an die Methode load() , aber dann ist es nicht abwärtskompatibel mit TextureLoader. Ich denke, das Beste ist, wenn Sie dies tun ...

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

... wendet immer das richtige Format auf jede Textur an, auch wenn die Dekodierung asynchron ist.

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

Noch ein Hinweis, um dies irgendwo nachzuverfolgen: Der JS-Wrapper in examples/js/libs/basis enthält eine geringfügige Änderung gegenüber der Version im Basis-Repository. Die erste Deklaration ( var Module ) wird nur durch Module , um die in einem Web Worker verwendete verzögerte Initialisierung zu aktivieren. Dies kann wahrscheinlich anders erfolgen, entweder durch Kompilieren des Transcoders mit verschiedenen Flags oder über https://github.com/BinomialLLC/basis_universal/issues/21.

Sollte BasisTextureLoader mit glTF zusammenarbeiten? Ich habe versucht, Texturen manuell in das .basis-Format zu codieren und BasisTextureLoader wie folgt als Loader hinzuzufügen:

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

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

Aber die Texturen werden nicht richtig gerendert und die Konsole hat folgende Ausgabe:

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

gleiches Problem wie @zeux beschreibt

Ich habe dies debuggt und das passiert, weil:

1. Der glTF-Loader setzt normalerweise die Mag-Filterung auf LinearMipMapLinearFilter
2. BasisTextureLoader unterstützt keine Mipmaps
3. webGL erfordert vollständige Mip-Ketten :-/

@zeux Nicht offiziell unterstützt – die glTF-Kernspezifikation lässt nur JPEG- und PNG-Texturen zu. Aber eine Erweiterung für Basis (über den KTX2-Wrapper) ist der Mechanismus, mit dem wir planen, dem Format Unterstützung für komprimierte Texturen hinzuzufügen. Siehe https://github.com/KhronosGroup/glTF/pull/1612 für Erweiterungsentwürfe (hier sind nur die ersten beiden relevant) und füge gerne Feedback hinzu.

Das heißt, der Mangel an Mipmap-Unterstützung in BasisTextureLoader liegt nur daran, dass wir noch nicht dazu gekommen sind. Der Transcoder selbst sollte das meines Wissens unterstützen.

Eingereichte PR zur Behebung der Mipmap-Unterstützung - solange Sie Texturen mit der Option -mipmap konvertieren, funktioniert der glTF-Loader nur so lange, wie Sie den Loader wie oben aufgeführt hinzufügen, zumindest auf dem Desktop. Ich war nicht in der Lage, es auf dem Handy (iPhone oder Android) zum Laufen zu bringen, aber das Threejs.org-Beispiel mit dem sich drehenden Würfel funktioniert auch nicht auf dem iPhone, so dass dies möglicherweise ein separates Problem ist.

Ich konnte es nicht auf dem Handy (iPhone oder Android) ausführen.

Aus den Basis-Dokumenten –

Unter iOS können Sie beispielsweise für PVTC1 nur die Quadratpotenz von 2 Texturdimensionen verwenden, und es gibt nichts, was Basis heute für Sie tun kann, das diese Einschränkung umgeht. (Wir werden in Kürze die Möglichkeit unterstützen, kleinere Nicht-Pow2-Texturen in größere Power von 2 PVRTC1-Texturen umzuwandeln.)

Wir haben in dieser Demo eine 512x768-Textur verwendet und sollten sie wahrscheinlich durch etwas ersetzen, das dieser Einschränkung entspricht.

Okay - das macht Sinn. FWIW das Android-Handy, auf dem ich getestet habe, hat eine ganze Reihe von Problemen mit mehreren WebGL-Demos, nicht nur in Bezug auf die Basis-Textur - ein anderes Android-Handy läuft einwandfrei. Also ja, es ist wahrscheinlich nur die Zweierpotenz-Beschränkung, die bei iOS problematisch ist.

Verschiedene Updates für BasisTextureLoader kommen in https://github.com/mrdoob/three.js/pull/16675.

Wir sollten uns wahrscheinlich auch überlegen, wie wir Alpha unterstützen können ... die Basis-Dokumentation geht detailliert auf die Optionen ein (https://github.com/BinomialLLC/basis_universal/#how-to-use-the-system) aber für einige Bei Geräten umfasst dies mehrere Transcodierungsausgänge:

Nur ETC1-Geräte/APIs: Transkodieren Sie in zwei ETC1-Texturen und sampeln Sie sie in einem Shader. Sie können entweder eine doppelt so hohe ETC1-Textur oder zwei separate ETC1-Texturen verwenden.

Bisher stimmt die API mit TextureLoader überein, die geändert werden müsste (oder eine alternative API haben), um die Rückgabe mehrerer transkodierter Ausgaben von einer einzelnen .basis Textur zu unterstützen.

Der Wechsel zu einer quadratischen Power-of-Two-Textur in https://github.com/mrdoob/three.js/pull/16686 behebt die Demo auf iOS, aber Mipmaps funktionieren nicht:

INVALID_VALUE: CompressedTexImage2D: Länge von ArrayBufferView ist für Dimensionen nicht korrekt.

Müssen wir für Mipmaps mit PVRTC etwas Besonderes tun?

Geschieht das bei einem der letzten paar mips?

Ich habe nicht genau genug debuggt, um zu identifizieren, welche Mips, aber der Fehler wird dreimal gedruckt, und die letzten drei hatten alle die gleiche Puffergröße. 🤔

Ich vermute, dass Basis die Größe (in Bytes) der letzten paar Mips nicht richtig berechnet. Für PVTC1 4bpp werden die Abmessungen der Blöcke auf 8 gerundet, sodass 4x4, 2x2 und 1x1 dieselbe Größe wie 8x8 haben sollten. Ich denke, der Basis-Transcoder rundet auf 4x4. Alle Bilder der Größen 8x8, 4x4, 2x2, 1x1 müssen 32 Bytes belegen; Ich denke, für 4x4 und darunter geht die Basis davon aus, dass es nur 1 4x4-Block ist, der 8 Bytes umfasst und Ihnen 8 Bytes statt 32 gibt. @richgel999

Die Formel zur Berechnung der Bildgrößen lautet hier: 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

Diese Problemumgehung (im Worker kurz vor dem Aufrufen von Transcode) scheint für mich zu funktionieren. Dies muss natürlich im Transcoder behoben werden, aber es ist einfach, dies in JS zu validieren:

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

Vielen Dank! Ich werde das so schnell wie möglich beheben.

Der Fehler bei der Mipmap-Größe von PVTC1 sollte behoben werden. Wir haben den Transcoder so korrigiert, dass er die zusätzlichen Bytes bei kleinen (weniger als 8 Pixel breit/hohen) Mips löscht. Und wir haben den Wrapper repariert, um die richtigen Größen zurückzugeben. Bitte lassen Sie es mich wissen, wenn es irgendwelche Probleme gibt und ich werde sie so schnell wie möglich beheben.

@donmccurdy Könnten Sie " texture synchron load Methode Aufgabenliste hinzufügen? (wie oben von Takahirox vorgeschlagen)

@ Ben-Mack Hinzugefügt. Beachten Sie, dass wir eine andere API dafür benötigen, da Texturen mit einem Alphakanal in mehrere Texturen transkodieren können und wir das nicht synchron wissen.

@richgel999 Danke! Ich habe Probleme beim Wiederaufbau des WASM-Transcoders, da https://github.com/BinomialLLC/basis_universal/commit/ab722fa2e18536f9a1d5f33814f3088232446d52 nur webgl/transcoder/basis_wrappers.cpp aktualisiert hat. Kompilieren unter 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

Theoretisch sollten wir in der Lage sein, den Transcoder zu PavingStones.basis Textur durch diese zu ersetzen, die Mipmaps enthält:

Pflastersteine.basis.zip

BEARBEITEN: Ups, das könnte mit https://github.com/BinomialLLC/basis_universal/pull/27 zusammenhängen.

@donmccurdy Ich glaube, dafür muss https://github.com/BinomialLLC/basis_universal/pull/27 zusammengeführt werden, hoffentlich kann dies bald passieren. Auch Ihre emscripten-Version könnte älter als die Existenz von emmalloc sein, die Dateien, die derzeit Teil von three.js sind, wurden mit 1.38.31 erstellt, denke ich.

Dieser Fehler trat auf, während ich versuche, mehrere Basisdateien gleichzeitig zu laden:

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

Um zu reproduzieren, rufen Sie einfach die Methode load zweimal auf:

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

@Ben-Mack Es lohnt sich wahrscheinlich immer noch, ihn zu beheben, aber dieser Fehler liegt nur daran, dass Sie genau dieselbe Textur zweimal laden und der Loader einen ArrayBuffer wiederverwendet, der nicht gleichzeitig auf zwei Worker übertragen werden kann. Der folgende Code wird ausgeführt, auf Kosten der doppelten Arbeit:

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

@donmccurdy Für die Unterstützung von Alpha wie wäre es mit so etwas wie:

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

Eine Option zur Unterstützung von Alpha könnte auch dem Modell von Mipmap hinzugefügt werden:
loader.generateAlpha = true //default

@ Makio64 So ähnlich! Die meisten Threejs-Loader sind nicht zustandsbehaftet (ein einzelner Loader könnte parallel an mehreren Dingen arbeiten), also vielleicht:

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

^In beiden Fällen, aber besonders in Alpha, denke ich, dass es genügend verschiedene Möglichkeiten gibt, Dinge zu tun, die eine Konfiguration der Methode erfordern.

Oder wir könnten stattdessen einfach asynchron mit den neuen Methoden arbeiten:

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

Die asynchrone Lösung sieht einfacher mit dem Worker zu implementieren und mit den Loadern der anderen Threejs abzustimmen.

Ich kann nur Texturen mit der Auflösung 768 x 512 oder 384 x 256 usw. laden. Jede andere Auflösung kann mit Three.js und BasisTextureLoader nicht geladen werden mit Warnung:
"Textur, die an Textureinheit 0 gebunden ist, kann nicht gerendert werden. Sie hat möglicherweise keine Potenz von 2 und hat eine inkompatible Texturfilterung."

@mozg4D Bitte Basis-Dokumentation , insbesondere werden in iOS Texturen mit der Zweierpotenz benötigt. Wenn die Dokumentation nicht dem angezeigten Verhalten entspricht, melden Sie bitte einen neuen Fehler. Es ist auch möglich, dass die ausgewählte Texturfilterung inkompatibel ist, in diesem Fall benötigen wir immer noch eine Demo und ein neuer Fehler wäre hilfreich. Vielen Dank!

@donmccurdy Wird die Alpha-Unterstützung für Basis bald veröffentlicht?

Ich glaube, ich habe einen Fehler gefunden: Nur auf iOS gibt es einen seltsamen "Texture-Glowing"-Effekt über Textur-Geometrie-Kanten: #17597

Ist das noch jemandem begegnet?

Ich denke, auf iOS wird es wahrscheinlich PVRTC verwenden. Geschieht dies in einer früheren Version (r108)?
Vielleicht könnten Sie versuchen, ein Problem in https://github.com/BinomialLLC/basis_universal einzureichen

Geschieht dies in einer früheren Version (r108)?

Der Fehler, den ich eingereicht habe, ist für r108.

Vielleicht könnten Sie versuchen, ein Problem in https://github.com/BinomialLLC/basis_universal einzureichen

War gerade dabei: https://github.com/BinomialLLC/basis_universal/issues/78

Ich glaube, ich habe einen Fehler gefunden: Nur auf iOS gibt es einen seltsamen "Texture-Glowing"-Effekt über Textur-Geometrie-Kanten: #17597

Ich habe auf dem basis_universal Github geantwortet. Wir greifen die Textur und sehen, was passiert. Höchstwahrscheinlich handelt es sich um ein Artefakt, das damit zusammenhängt, dass das Wrap/Clamp-Adressierungs-Transcode-Flag nicht korrekt gesetzt wurde, oder um ein Artefakt, das von unserem Echtzeit-PVRTC1-Encoder verursacht wird. Wenn beides das Problem ist, gibt es normalerweise Problemumgehungen. Wir können auch die PVTC1-Qualität auf Kosten von mehr CPU-Zeit/Speicher für die Transcodierung erhöhen.

Ich habe ein Update auf https://github.com/BinomialLLC/basis_universal/issues/78#issuecomment -536159690 gepostet -- Screenshots sind dort enthalten.

Es zeigt das Umhüllungsproblem bei einem sich nicht drehenden Würfel.

Ich habe einen weiteren Fehler gefunden (der aber höchstwahrscheinlich nicht in Zusammenhang steht): https://github.com/mrdoob/three.js/pull/17546#commitcomment -35275564

Ich habe einen weiteren Fehler gefunden (aber höchstwahrscheinlich ohne Zusammenhang): #17546 (Kommentar)

Behoben in #17622.

Gibt es in Bezug auf Mipmaps eine Möglichkeit, Basistexturdateien (in einer .gltf-Datei referenziert) richtig zu laden, ohne die Mipmaps in die .basis-Datei einbetten zu müssen?

Ich kann es zum Laden von Proplery bringen, wenn ich die .basis-Datei mit -mipmap generiere, aber dies fügt der .basis-Datei eine Menge Dateigröße hinzu - aber wenn ich eine .basis-Datei ohne -mipmap generiere Option wird es im Browser mit Threejs einfach schwarz angezeigt.

Gibt es in Bezug auf Mipmaps eine Möglichkeit, Basistexturdateien (in einer .gltf-Datei referenziert) richtig zu laden, ohne die Mipmaps in die .basis-Datei einbetten zu müssen?

Ich kann es zum Laden von Proplery bringen, wenn ich die .basis-Datei mit -mipmap generiere, aber dies fügt der .basis-Datei eine Menge Dateigröße hinzu - aber wenn ich eine .basis-Datei ohne -mipmap generiere Option wird es im Browser mit Threejs einfach schwarz angezeigt.

Im Moment können Sie Mipmaps deaktivieren, damit die Textur angezeigt wird:
https://discourse.threejs.org/t/compressed-texture-workflow-gltf-basis/10039/12?u=johannesdeml
https://github.com/JohannesDeml/three.js/commit/909d9cc6dc9192f398df7455f52b7e71e3bf61e2

Das ist natürlich keine Unterstützung für Mipmaps, aber wenn Ihr Ziel darin besteht, nur Texturen anzuzeigen, könnte dies eine einfache Lösung für Sie sein.

Das scheint nicht mehr zu funktionieren und es sieht so aus, als ob der BasisTextureLoader jetzt auch einen ähnlichen Code hat (Einstellung des min/magFilter = LinearFilter), wenn nur 1 Mipmap erkannt wird (https://github.com/mrdoob/three.js /blob/e66e86901abd84ffc260fea9665170631a2b0493/examples/js/loaders/BasisTextureLoader.js#L170-L171) - was basisu ohne die Option -mipmap generiert. Allerdings ist es immer noch schwarz.

Kannst du die Datei teilen? Ich habe das erst letzte Woche gemacht, obwohl es Basis in einem .ktx2 Container war und nicht .basis ...

Und nur zur Bestätigung – Sie wissen, dass Sie diese Mipmaps nicht zur Laufzeit generieren können und mit den damit verbundenen Interpolationsbeschränkungen auskommen müssen?

Klar und danke fürs reinschauen!

body_green.basis.zip

Und nur zur Bestätigung – Sie wissen, dass Sie diese Mipmaps nicht zur Laufzeit generieren können und mit den damit verbundenen Interpolationsbeschränkungen auskommen müssen?

Ja, das habe ich auch herausgefunden, ein bisschen schade, da ein Großteil des Gewinns, den ich bei einer geringeren Dateigröße von .basis im Vergleich zu einem komprimierten JPG gesehen habe, dann verloren geht - ich weiß, dass der GPU-Speichergewinn immer noch da ist, aber ich war es hauptsächlich konzentriert sich auf die Download-/Transfergröße der Textur.

Und nur zur Bestätigung – Sie wissen, dass Sie diese Mipmaps nicht zur Laufzeit generieren können und mit den damit verbundenen Interpolationsbeschränkungen auskommen müssen?

Ist dies immer der Fall, wenn basis anstelle von jpg/png verwendet wird?

Wie wäre es mit einem Anwendungsfall, bei dem 6 Texturen als Facelist für eine Cube-Map in eine einzige Basisdatei gepackt werden, da das Format dies in der README unterstützt / erwähnt. Ist der PMREM-Generator hier nutzlos und die Basisdatei sollte Mipmaps für jede generierte Textur enthalten?

Wie wäre es mit der Bereitstellung dieser gepackten Texturdaten zur Verwendung als Cubemap in ThreeJS? Normalerweise würden Sie Argumente für jede einzelne Textur übergeben? (Ich habe mir diese Textur-Loader-Unterstützung noch nicht angesehen, um zu sehen, ob eine Basisdatei mit mehreren Texturen möglich ist) Eine Alternative ist vielleicht über KTX2, das möglicherweise besser geeignet ist, um eine mit Facelist gepackte Basisdatei bereitzustellen, die als Cubemap verwendet werden kann?

Eine letzte Frage zu dieser Verwendung, da Sie über den Umgang mit Alpha gesprochen haben, diese Texturen könnten als RGBE oder RGBM codiert werden (ThreeJS unterstützt M7 und M16). Ich habe nicht untersucht, wie gut diese mit Basis komprimieren, aber sie können ähnliche Probleme haben, wie es bei normalen Karten bekannt ist. Es ist ziemlich wichtig, dass die Alphakanaldaten dort unterstützt werden. Ich bin mir nicht sicher, in welches komprimierte Texturformat sie transkodiert werden. Einige können ziemlich schlechte Ergebnisse liefern, wie der unten verlinkte Artikel behandelt.

ARM hat beispielsweise einen Artikel über Probleme mit ASTC und RGBM geschrieben . Die Unity-Engine verwendet, wie im Artikel erwähnt, RGBM5, das in den meisten Fällen einen geeigneten HDR-Bereich abdecken sollte, der niedrigere Multiplikator würde vermutlich weniger Probleme mit der Komprimierungsqualität erzeugen als eine höhere Multiplikatorkonstante, wenn die Daten innerhalb der Bereichsgrenzen liegen.

Auf diese Fragen kenne ich leider keine Antwort. Bei den Basis Universal- oder KTX-GitHub-Repositorys haben Sie möglicherweise mehr Glück. Ich weiß, dass KTX2 entwickelt wurde, um Cubemaps mit Basis-Payloads zu unterstützen.

Ich habe sie hier angesprochen, da sie relevante Fälle für die Nutzung der ThreeJS-Unterstützung schienen, die hier diskutiert wurden.

Basis kann alle 6 Texturen für eine Cubemap in einer einzigen Basisdatei speichern. KTX2 mit Basis-Unterstützung kann Cubemaps mit mehreren Texturen, aber einer einzigen Datei afaik besser unterstützen.

Es ist unklar, ob ThreeJS in Zukunft damit umgehen kann. Eventuell müssen 6 verschiedene Basisdateien bereitgestellt werden oder KTX2 mit Basisloader-Unterstützung erhalten.

RGBM5 würde einen separaten PR benötigen, es wären nur RGBM7 oder RGBM16, die derzeit existieren, oder eine Variante, die eine Uniform benötigt, um den Multiplikatorwert anzupassen. Der wichtigste wichtige Teil dabei ist, dass Alpha richtig gehandhabt werden muss, um richtig zu komprimieren. Die Möglichkeit, etwas Kontrolle darüber zu haben, wie zuvor in dieser Ausgabe beschrieben, ist ein weiteres Beispiel dafür, wo dies nützlich wäre, ähnlich wie bei Normal Maps und ihren Linear/ Nicht-Farbkodierung, bei der das Format je nach Kompressionsunterstützung auch in zwei mögliche Texturen aufgeteilt werden kann (von einfarbigem RGB für X und Alpha für Y in der Basisdatei).

Three.js unterstützt derzeit Basis Universal. Vor wenigen Wochen wurde ein neues Basis-Format, UASTC, veröffentlicht. Ich glaube nicht, dass zuvor Cubemaps von Basis in einer einzigen Datei unterstützt wurden. Pull-Requests wären willkommen.

Ein KTX2-Loader ist in Bearbeitung, mit https://github.com/mrdoob/three.js/pull/18490.

In älteren Versionen der README für Basis (vor UASTC, aber immer noch in der aktuellen README vorhanden) wird die Funktion zum Packen mehrerer Texturen in eine einzelne Basisdatei erwähnt:

Basisdateien unterstützen ungleichmäßige Texturarrays, sodass Cubemaps, Volumentexturen, Texturarrays, Mipmap-Ebenen, Videosequenzen oder beliebige Textur-"Kacheln" in einer einzigen Datei gespeichert werden können. Der Kompressor ist in der Lage, Farb- und Musterkorrelationen über die gesamte Datei hinweg auszunutzen, sodass mehrere Bilder mit Mipmaps sehr effizient in einer einzigen Datei gespeichert werden können.

Pull-Requests wären willkommen.

Ich wüsste nicht, wo ich anfangen soll, noch habe ich zur Zeit die Freizeit. Sobald dieses Problem abgeschlossen ist und der KTX2-Loader bereit ist, könnte die Unterstützung für komprimierte/gepackte Cubemaps möglicherweise behoben werden. Wenn ich bis dahin Zeit habe, würde ich gerne versuchen, eine PR beizutragen :)

Hallo zusammen, ich habe ein zeitweiliges Problem mit iOS (aawww maaaan!)
Grundsätzlich lädt die Textur manchmal gut, manchmal erscheint sie nicht.
Kein Fehler in der Konsole, Ladefortschritt ist 100%, also definitiv kein Netzwerkproblem.
Getestet sowohl am offiziellen Beispiel (https://threejs.org/examples/?q=basis#webgl_loader_texture_basis) als auch an meinem eigenen Projekt. Auf meinem iPhone X, auf Safari, erscheint die Textur manchmal und manchmal nicht.
Auf dem iPhone 6, Safari, wird es nie angezeigt.
Alle anderen sehen gut aus.
Was könnte es sein?

[BEARBEITEN] habe gerade das gleiche Problem in Safari unter Mac OS, immer noch zeitweilig

@igghera Klingt so, als ob dies ein Fehler sein könnte, besonders wenn es im offiziellen Beispiel passiert. Macht es Ihnen etwas aus, dafür eine neue Ausgabe zu eröffnen? Vielen Dank!

Wie könnte man in BasisTextureLoader Unterstützung für 2D-Array-Texturen hinzufügen? Ich habe mir das ein wenig angesehen, bin mir aber nicht ganz sicher, wie ich vorgehen soll.

Das Ändern der transcode Funktion, um die Bilder aus der von basisFile.getNumImages() Anzahl zu

1. compressedTexImage3D existiert nicht in THREE.WebGLState und müsste eine Option für gl.TEXTURE_2D_ARRAY pro WebGLRenderingContext.compressedTexImage3D
2. Die API von Basis gibt einzelne Mipmaps pro Bildindex zurück, aber Sie benötigen einen einzigen großen Textur-Blob zum Binden für sampler2DArray ?
3. CompressedTexture bräuchte eine Möglichkeit, Mipmaps pro Bildindex zuzuordnen. Für ein 200 Deep-Array-Image und 6 Mipmap-Ebenen wären das 1200 Mipmap-Einträge, also wird mipmaps in CompressedTexture wahrscheinlich zu einem gestaffelten Array. Oder gibt es eine Möglichkeit, dass WebGL dieses Detail abstrahiert?

Dann bräuchte es für Videotexturen wahrscheinlich eine andere Implementierung. Anstatt auf einmal im Stapel zu transkodieren, würden Sie das Basisdatei-Handle geöffnet lassen und eine Möglichkeit haben, den nächsten Frame anzufordern.