Three.js: BasisTextureLoader: Langkah selanjutnya

Saya belum melihat kode secara detail, tetapi bisakah kita mengembalikan texture bersamaan dari load seperti yang dilakukan oleh pemuat tekstur lainnya?

Saya pikir itu bagus untuk konsistensi. Dan jika kita tidak mengembalikan tekstur secara sinkron, pengguna perlu memanggil material.needsUpdate = true dalam panggilan balik (jika sudah memulai loop animasi).

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

Saya belum memeriksa untuk mengonfirmasi bahwa itu berfungsi dengan THREE.CompressedTexture , tetapi jika demikian saya setuju itu yang terbaik. 👍

Pembersihan lainnya: properti yang ditetapkan untuk tekstur sedikit berubah-ubah (sisa dari demo Basis), seperti flipY=false . Dan ada variabel startTime digunakan di pekerja.

Jika saya benar, mipmaps sepertinya tidak didukung. Transcoder tidak mendukung? Atau loader belum mengimplementasikan dukungan mipmaps?

File .basis dapat berisi beberapa level mipmap, ya. Saya pikir transcoder sudah mendukungnya, tetapi saya belum mengujinya. BasisTextureLoader belum mendukungnya.

Kita juga harus memperbarui ke versi baru/lebih kecil dari transcoder: https://github.com/BinomialLLC/basis_universal/pull/7~~ Selesai.

Yup, transcoder harus mendukungnya. Anda melewati level mip sebagai levelIndex ke transcodeImage .
https://github.com/BinomialLLC/basis_universal/blob/master/webgl/transcoder/basis_wrappers.cpp#L197

Terima kasih atas penjelasan Anda.

Dan jika ada fungsi lain yang belum didukung oleh pemuat, tetapi transcoder melakukannya, Anda tahu, silakan tambahkan ke daftar TODO. Kami dapat membantu pelaksanaannya.

Dijadikan contoh. #16553 Mungkin terlalu sederhana, silakan tingkatkan/ganti nanti jika digabungkan.

Pada fitur lain yang dimiliki transcoder tetapi THREE.BasisTextureLoader tidak, perbedaan utamanya adalah transcoder dapat menampilkan banyak format tambahan:

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

Sejujurnya saya tidak tahu kapan harus menggunakan semua ini. Saya berharap bahwa pengguna kadang-kadang menginginkan kontrol itu, dan dalam kasus lain loader (misalnya GLTFLoader) akan membuat keputusan berdasarkan tujuan tekstur. Misalnya, mungkin memilih format terkompresi yang berbeda untuk material.map (warna dasar) daripada untuk material.aoMap (oklusi ambien).

Cara paling jelas untuk mendukung ini adalah dengan menambahkan alternatif ke detectSupport( renderer ) :

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

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

Ini memiliki potensi masalah – jika saya memuat banyak tekstur, kami mungkin tidak ingin mentranskode semuanya ke format yang sama. Kami dapat membuat banyak pemuat, tetapi kemudian lebih sulit untuk menggunakan kembali Pekerja Web yang ada (yang penting). Kita dapat meneruskan format ke dalam metode load() , tetapi format tersebut tidak kompatibel dengan TextureLoader. Saya kira hal terbaik adalah memastikan bahwa melakukan ini ...

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

... akan selalu menerapkan format yang tepat untuk setiap tekstur, meskipun decoding tidak sinkron.

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

Catatan lain, hanya untuk melacak ini di suatu tempat: pembungkus JS di examples/js/libs/basis berisi perubahan kecil dari versi di repositori Basis. Deklarasi pertama ( var Module ) diganti dengan hanya Module untuk mengaktifkan inisialisasi lambat yang digunakan di Web Worker. Ini mungkin dapat dilakukan secara berbeda, baik dengan mengkompilasi transcoder dengan flag yang berbeda atau melalui https://github.com/BinomialLLC/basis_universal/issues/21.

Haruskah BasisTextureLoader bekerja bersama-sama dengan glTF? Saya telah mencoba menyandikan tekstur secara manual ke format .basis dan menambahkan BasisTextureLoader sebagai pemuat seperti ini:

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

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

Tetapi teksturnya tidak ditampilkan dengan benar, dan konsol memiliki output berikut:

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

Masalah yang sama seperti yang dijelaskan @zeux

Saya men-debug ini dan ini terjadi karena:

1. glTF loader biasanya menyetel pemfilteran mag ke LinearMipMapLinearFilter
2. BasisTextureLoader tidak mendukung mipmaps
3. webGL membutuhkan rantai mip untuk diselesaikan :-/

@zeux Tidak didukung secara resmi – spesifikasi inti glTF hanya mengizinkan tekstur JPEG dan PNG. Tetapi ekstensi untuk Basis (melalui pembungkus KTX2) adalah mekanisme yang kami rencanakan untuk menambahkan dukungan tekstur terkompresi ke format. Lihat https://github.com/KhronosGroup/glTF/pull/1612 untuk ekstensi draf (hanya dua yang pertama yang relevan di sini) dan jangan ragu untuk menambahkan umpan balik.

Meskipun demikian, kurangnya dukungan mipmap di BasisTextureLoader murni karena kami belum mencapainya. Transcoder itu sendiri harus mendukung itu sejauh yang saya tahu.

Mengirimkan PR untuk memperbaiki dukungan mipmap - dengan ini selama Anda mengonversi tekstur dengan opsi -mipmap , pemuat glTF hanya berfungsi selama Anda menambahkan pemuat seperti yang tercantum di atas, setidaknya di desktop. Saya tidak dapat menjalankannya di ponsel (iPhone atau Android), tetapi contoh threejs.org dengan kubus pemintalan juga tidak berfungsi di iPhone sehingga mungkin menjadi masalah tersendiri.

Saya tidak dapat menjalankannya di ponsel (iPhone atau Android)

Dari dokumen Dasar –

Misalnya, di iOS, Anda hanya dapat menggunakan kekuatan kuadrat dari 2 dimensi tekstur untuk PVRTC1, dan tidak ada yang dapat dilakukan Basis untuk Anda hari ini yang mengatasi batasan ini. (Kami akan mendukung kemampuan untuk mentranskode tekstur non-pow2 yang lebih kecil menjadi kekuatan yang lebih besar dari 2 tekstur PVRTC1 segera.)

Kami telah menggunakan tekstur 512x768 dalam demo ini, dan mungkin harus menggantinya dengan sesuatu yang sesuai dengan batasan itu.

Oke - itu masuk akal. FWIW ponsel Android yang saya uji memiliki banyak masalah dengan beberapa demo WebGL, bukan hanya terkait tekstur Basis - ponsel Android yang berbeda berjalan dengan baik. Jadi ya itu mungkin hanya pembatasan kekuatan dua yang bermasalah di iOS.

Berbagai pembaruan untuk BasisTextureLoader masuk https://github.com/mrdoob/three.js/pull/16675.

Kita mungkin juga harus memikirkan cara mendukung alpha... dokumentasi Basis membahas beberapa detail tentang opsi (https://github.com/BinomialLLC/basis_universal/#how-to-use-the-system) tetapi untuk beberapa perangkat ini melibatkan beberapa keluaran transcoding:

Hanya perangkat/API ETC1: Transcode ke dua tekstur ETC1 dan ambil sampelnya dalam shader. Anda dapat menggunakan satu tekstur ETC1 yang dua kali lebih tinggi, atau dua tekstur ETC1 terpisah.

Sejauh ini API cocok dengan TextureLoader , yang perlu diubah (atau memiliki API alternatif) untuk mendukung pengembalian beberapa keluaran transkode dari satu tekstur .basis .

Mengubah ke tekstur kekuatan dua persegi di https://github.com/mrdoob/three.js/pull/16686 memperbaiki demo di iOS, tetapi mipmaps tidak berfungsi:

INVALID_VALUE: compressTexImage2D: panjang ArrayBufferView tidak benar untuk dimensi.

Apakah kita perlu melakukan sesuatu yang khusus untuk mipmaps dengan PVRTC?

Apakah itu terjadi untuk salah satu dari beberapa mips terakhir?

Saya tidak melakukan debug cukup dekat untuk mengidentifikasi mips mana, tetapi kesalahan dicetak tiga kali, dan tiga yang terakhir semuanya memiliki ukuran buffer yang sama. 🤔

Saya menduga bahwa Basis tidak menghitung ukuran (dalam byte) dari beberapa mips terakhir dengan benar. Untuk PVRTC1 4bpp, dimensi balok dibulatkan menjadi 8, jadi 4x4, 2x2, dan 1x1 harus berukuran sama dengan 8x8. Saya pikir pembulatan basis transcoder menjadi 4x4. Semua gambar berukuran 8x8, 4x4, 2x2, 1x1 harus berukuran 32 byte; Saya pikir untuk 4x4 dan di bawah Basis mengasumsikan itu hanya 1 4x4 blok yang 8 byte dan memberi Anda 8 byte, bukan 32. @richgel999

Rumus untuk menghitung ukuran gambar ada di sini: 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

Solusi ini (di pekerja sebelum memanggil transcode) tampaknya berhasil untuk saya. Ini perlu diperbaiki di transcoder tentu saja, tetapi mudah untuk memvalidasi ini di 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 );

Terima kasih! Saya akan memperbaiki ini secepatnya.

Bug ukuran mipmap PVRTC1 harus diperbaiki. Kami memperbaiki transcoder sehingga akan menghapus byte ekstra pada mips kecil (lebar/tinggi kurang dari 8 piksel). Dan kami memperbaiki bungkusnya untuk mengembalikan ukuran yang benar. Tolong beri tahu saya jika ada masalah dan saya akan memperbaikinya secepatnya.

@donmccurdy Bisakah Anda menambahkan "Secara sinkron mengembalikan texture dari load metode" ke daftar tugas? (seperti yang disarankan takahirox di atas)

@Ben-Mack Ditambahkan. Perhatikan bahwa karena tekstur dengan saluran alfa dapat mentranskode ke beberapa tekstur, dan kita tidak akan mengetahuinya secara sinkron, kita memerlukan API yang berbeda untuk itu.

@richgel999 Terima kasih! Saya mengalami masalah saat membangun kembali transcoder WASM, karena https://github.com/BinomialLLC/basis_universal/commit/ab722fa2e18536f9a1d5f33814f3088232446d52 hanya memperbarui webgl/transcoder/basis_wrappers.cpp . Kompilasi di 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

Secara teori kita harus dapat memperbarui transcoder dan mengganti tekstur PavingStones.basis ini dengan yang ini, yang mencakup mipmaps:

PavingStones.basis.zip

EDIT: Ups, ini mungkin terkait dengan https://github.com/BinomialLLC/basis_universal/pull/27.

@donmccurdy Saya percaya ini membutuhkan https://github.com/BinomialLLC/basis_universal/pull/27 untuk digabungkan, semoga ini bisa segera terjadi. Juga versi emscripten Anda mungkin mendahului keberadaan emmalloc, file yang saat ini merupakan bagian dari three.js dibangun dengan 1.38.31 saya pikir.

Kesalahan ini terjadi ketika saya mencoba memuat beberapa file basis secara bersamaan:

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

Untuk mereproduksi, cukup panggil metode load 2 kali seperti:

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

@Ben-Mack Mungkin masih layak untuk diperbaiki, tetapi kesalahan itu hanya karena Anda memuat tekstur yang sama persis dua kali, dan pemuat menggunakan kembali ArrayBuffer yang tidak dapat ditransfer ke dua pekerja pada saat yang bersamaan. Kode di bawah ini berjalan, dengan mengorbankan melakukan dua kali pekerjaan:

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

@donmccurdy Untuk dukungan alpha bagaimana dengan sesuatu seperti:

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

Opsi untuk mendukung alpha mungkin juga ditambahkan pada model mipmap:
loader.generateAlpha = true //default

@ Makio64 Sesuatu seperti itu! Sebagian besar pemuat threejs tidak stateful (pemuat tunggal dapat mengerjakan banyak hal secara paralel) jadi mungkin:

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

^Dalam kedua kasus, tetapi terutama alfa, saya pikir mungkin ada cukup banyak cara berbeda untuk melakukan sesuatu yang memerlukan beberapa konfigurasi pada metode tersebut.

Atau kita bisa melakukan asinkron pada metode baru, sebagai gantinya:

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

Solusi asinkron terlihat lebih mudah diterapkan dengan pekerja dan disejajarkan dengan pemuat threejs lainnya.

Saya hanya dapat memuat tekstur dengan resolusi 768 x 512 atau 384 x 256 dll. resolusi lain gagal dimuat dengan Three.js dan BasisTextureLoader dengan peringatan:
"tekstur terikat ke unit tekstur 0 tidak dapat dirender. Mungkin non-kekuatan-2 dan memiliki pemfilteran tekstur yang tidak kompatibel."

@mozg4D silakan lihat dokumentasi Basis , khususnya tekstur kekuatan-dua diperlukan di iOS. Jika dokumentasi tidak sesuai dengan perilaku yang Anda lihat, harap laporkan bug baru. Mungkin juga pemfilteran tekstur yang dipilih tidak kompatibel, dalam hal ini kami masih memerlukan demo dan bug baru akan membantu. Terima kasih!

@donmccurdy Apakah dukungan Basis alpha akan segera dirilis?

Saya pikir saya menemukan bug: Hanya di iOS, ada efek "tekstur bercahaya" yang aneh di tepi tekstur-geometri: #17597

Apakah ada orang lain yang mengalami ini?

Saya pikir di iOS kemungkinan akan menggunakan PVRTC. Apakah ini terjadi di versi sebelumnya (r108)?
Mungkin Anda bisa mencoba mengajukan masalah di https://github.com/BinomialLLC/basis_universal?

Apakah ini terjadi di versi sebelumnya (r108)?

Bug yang saya ajukan adalah untuk r108.

Mungkin Anda bisa mencoba mengajukan masalah di https://github.com/BinomialLLC/basis_universal?

Baru saja dalam proses melakukannya: https://github.com/BinomialLLC/basis_universal/issues/78

Saya pikir saya menemukan bug: Hanya di iOS, ada efek "tekstur bercahaya" yang aneh di tepi tekstur-geometri: #17597

Saya menjawab di basis_universal github. Kami akan mengambil tekstur dan melihat apa yang terjadi. Kemungkinan besar, ini adalah artefak yang terkait dengan tidak menyetel flag transcode pengalamatan wrap/clamp dengan benar, atau artefak yang disebabkan oleh encoder PVRTC1 real-time kami. Jika salah satunya adalah masalahnya, biasanya ada solusi. Kami juga dapat meningkatkan kualitas PVRTC1, dengan mengorbankan lebih banyak waktu/memori CPU transkode.

Saya telah memposting pembaruan di https://github.com/BinomialLLC/basis_universal/issues/78#issuecomment -536159690 -- tangkapan layar disertakan di sana.

Ini menunjukkan masalah pembungkus dengan kubus yang tidak berputar.

Saya menemukan bug lain (tetapi kemungkinan besar tidak terkait): https://github.com/mrdoob/three.js/pull/17546#commitcomment -35275564

Saya menemukan bug lain (tetapi kemungkinan besar tidak terkait): #17546 (komentar)

Diperbaiki di #17622.

Dalam hal mipmaps, apakah ada cara untuk memuat file tekstur dasar dengan benar (direferensikan di dalam file .gltf) tanpa harus menyematkan mipmaps di file .basis?

Saya bisa membuatnya memuat proplery ketika saya membuat file .basis dengan -mipmap , namun ini menambahkan banyak ukuran file ke file .basis - tetapi ketika saya membuat file .basis tanpa -mipmap opsi, itu hanya ditampilkan sebagai hitam di browser dengan threejs.

Dalam hal mipmaps, apakah ada cara untuk memuat file tekstur dasar dengan benar (direferensikan di dalam file .gltf) tanpa harus menyematkan mipmaps di file .basis?

Saya bisa membuatnya memuat proplery ketika saya membuat file .basis dengan -mipmap , namun ini menambahkan banyak ukuran file ke file .basis - tetapi ketika saya membuat file .basis tanpa -mipmap opsi, itu hanya ditampilkan sebagai hitam di browser dengan threejs.

Untuk saat ini, Anda dapat menonaktifkan mipmaps untuk menampilkan tekstur:
https://discourse.threejs.org/t/compressed-texture-workflow-gltf-basis/10039/12?u=johannesdeml
https://github.com/JohannesDeml/three.js/commit/909d9cc6dc9192f398df7455f52b7e71e3bf61e2

Itu tentu saja tidak mendukung mipmaps, tetapi jika tujuan Anda adalah hanya menampilkan tekstur, itu mungkin solusi mudah bagi Anda.

Itu sepertinya tidak berfungsi lagi, dan sepertinya BasisTextureLoader sekarang juga memiliki kode yang sama (mengatur min/magFilter = LinearFilter) ketika hanya 1 mipmap yang terdeteksi (https://github.com/mrdoob/three.js /blob/e66e86901abd84ffc260fea9665170631a2b0493/examples/js/loaders/BasisTextureLoader.js#L170-L171) - yang dihasilkan oleh basisu tanpa opsi -mipmap . Namun tetap hitam.

Bisakah Anda membagikan filenya? Saya melakukan ini baru-baru ini minggu lalu, meskipun itu adalah Basis dalam wadah .ktx2 daripada .basis ...

Dan hanya untuk mengonfirmasi – Anda sadar bahwa Anda tidak dapat membuat mipmap ini saat runtime, dan harus puas dengan batasan interpolasi yang terlibat?

Tentu, dan terima kasih telah melihat!

body_green.basis.zip

Dan hanya untuk mengonfirmasi – Anda sadar bahwa Anda tidak dapat membuat mipmap ini saat runtime, dan harus puas dengan batasan interpolasi yang terlibat?

Ya, saya mengetahuinya juga, sedikit memalukan karena banyak keuntungan yang saya lihat dalam ukuran file .basis yang lebih rendah dibandingkan dengan jpg terkompresi kemudian hilang - saya tahu perolehan memori GPU masih ada, tapi saya kebanyakan berfokus pada ukuran unduhan/transfer tekstur.

Dan hanya untuk mengonfirmasi – Anda sadar bahwa Anda tidak dapat membuat mipmap ini saat runtime, dan harus puas dengan batasan interpolasi yang terlibat?

Apakah ini selalu terjadi ketika menggunakan basis alih-alih jpg/png?

Bagaimana dengan kasus penggunaan pengemasan 6 tekstur sebagai facelist untuk peta kubus ke dalam satu file basis karena format mendukung/menyebutkannya di README. Apakah generator PMREM tidak berguna di sini dan file basis harus memiliki mipmaps untuk setiap tekstur yang dihasilkan?

Bagaimana dengan menyediakan data tekstur yang dikemas ini untuk digunakan sebagai peta kubus di ThreeJS? Biasanya Anda akan memberikan argumen untuk setiap tekstur individu? (Saya belum melihat dukungan pemuat tekstur ini untuk melihat apakah file basis dengan banyak tekstur dimungkinkan) Alternatif mungkin adalah melalui KTX2 yang mungkin lebih cocok untuk menyediakan file basis paket facelist untuk digunakan sebagai peta kubus?

Satu pertanyaan terakhir tentang penggunaan ini saat Anda mendiskusikan penanganan alfa, tekstur ini dapat dikodekan sebagai RGBE atau RGBM (ThreeJS memiliki dukungan untuk M7 dan M16). Saya belum menyelidiki seberapa baik kompres itu dengan basis, tetapi mereka dapat memiliki masalah yang sama seperti yang diketahui oleh peta normal. Data saluran alfa cukup penting untuk didukung di sana, saya tidak yakin format tekstur terkompresi apa yang akan mereka transkode, beberapa mungkin menghasilkan hasil yang sangat buruk karena artikel tertaut di bawah ini membahas.

ARM menulis artikel tentang masalah ASTC dan RGBM misalnya . Unity engine seperti yang disebutkan dalam artikel menggunakan RGBM5, yang dalam banyak kasus harus mencakup rentang HDR yang sesuai, pengali yang lebih rendah mungkin akan menghasilkan masalah kualitas kompresi yang lebih sedikit daripada konstanta pengali yang lebih tinggi jika data sesuai dengan batas jangkauan.

Maaf, saya tidak tahu jawaban untuk pertanyaan-pertanyaan ini. Anda mungkin lebih beruntung di repositori Basis Universal atau KTX GitHub. Saya tahu bahwa KTX2 dirancang untuk mendukung peta kubus dengan muatan Basis.

Saya mengangkatnya di sini karena tampaknya kasus yang relevan untuk menggunakan dukungan ThreeJS dengan dibahas di sini.

Basis dapat menyimpan semua 6 tekstur untuk cubemap dalam satu file basis. KTX2 dengan dukungan Basis dapat melayani peta kubus pendukung yang lebih baik dengan banyak tekstur tetapi satu file afaik.

ThreeJS mampu menanganinya di masa depan tidak jelas. Mungkin 6 file dasar yang berbeda perlu disediakan, atau dapatkan KTX2 dengan dukungan pemuat dasar.

RGBM5 akan membutuhkan PR terpisah, hanya saja RGBM7 atau RGBM16 yang ada saat ini, atau varian yang membutuhkan seragam untuk menyesuaikan nilai pengali. Bagian penting utama adalah alfa perlu ditangani dengan tepat untuk mengompres dengan benar, sehingga dapat memiliki kontrol atas hal itu seperti yang dibahas sebelumnya dalam masalah ini adalah contoh lain di mana hal itu akan berguna, mirip dengan Peta Normal dan Linear/ mereka. pengkodean non-warna, yang mungkin juga memiliki format yang dibagi menjadi dua kemungkinan tekstur (dari RGB warna tunggal untuk X, dan alfa untuk Y dalam file dasar) tergantung pada dukungan kompresi.

Three.js saat ini mendukung Basis Universal. Format Basis baru, UASTC, dirilis hanya beberapa minggu yang lalu. Saya tidak berpikir Basis mendukung cubemaps dalam satu file sebelumnya. Permintaan tarik akan diterima.

Loader KTX2 sedang berlangsung, dengan https://github.com/mrdoob/three.js/pull/18490.

Versi README for Basis yang lebih lama (sebelum UASTC, tetapi masih ada di README saat ini) menunjukkan penyebutan beberapa pengepakan tekstur ke dalam fitur file basis tunggal:

File dasar mendukung susunan tekstur yang tidak seragam, sehingga peta kubus, tekstur volume, susunan tekstur, level mipmap, urutan video, atau "ubin" tekstur arbitrer dapat disimpan dalam satu file. Kompresor mampu mengeksploitasi korelasi warna dan pola di seluruh file, sehingga banyak gambar dengan mipmaps dapat disimpan dengan sangat efisien dalam satu file.

Permintaan tarik akan diterima.

Saya tidak tahu harus mulai dari mana, saya juga tidak punya waktu luang saat ini. Mungkin setelah masalah ini berlanjut hingga selesai dan pemuat KTX2 siap, dukungan peta kubus terkompresi/dikemas dapat diatasi. Jika saya punya waktu luang saat itu, saya akan dengan senang hati mencoba menyumbangkan PR :)

Hai semua, saya mengalami masalah intermiten di iOS (aawww maaaaan!)
Pada dasarnya tekstur terkadang memuat dengan baik, terkadang tidak muncul.
Tidak ada kesalahan di konsol, kemajuan pemuatan adalah 100%, jadi jelas bukan masalah jaringan.
Diuji baik pada contoh resmi (https://threejs.org/examples/?q=basis#webgl_loader_texture_basis) dan pada proyek saya sendiri. Di iPhone X saya, di Safari, teksturnya terkadang muncul dan terkadang tidak.
Di iPhone 6, Safari, itu tidak pernah muncul.
Semua yang lain terlihat baik-baik saja.
Apa itu?

[EDIT] baru saja mendapat masalah yang sama di Safari di Mac OS, masih terputus-putus

@igghera Kedengarannya seperti ini mungkin bug, terutama jika itu terjadi pada contoh resmi. Apakah Anda keberatan membuka masalah baru untuk ini? Terima kasih!

Bagaimana cara menambahkan dukungan untuk tekstur larik 2D di BasisTextureLoader ? Saya melihat ke dalam ini sedikit tapi saya tidak begitu yakin bagaimana untuk melanjutkan.

Mengubah fungsi transcode untuk mengulang gambar dari hitungan yang dikembalikan oleh basisFile.getNumImages() tampaknya mudah, tetapi sepertinya ada tiga hal yang harus diatasi berikut ini:

1. compressedTexImage3D tidak ada di THREE.WebGLState dan harus melewati opsi untuk gl.TEXTURE_2D_ARRAY per WebGLRenderingContext.compressedTexImage3D
2. API Basis mengembalikan mipmap individual per indeks gambar, tetapi Anda memerlukan satu gumpalan tekstur besar untuk mengikat sampler2DArray ?
3. CompressedTexture akan membutuhkan cara untuk mengaitkan mipmaps per indeks gambar. Untuk 200 gambar larik dalam dan 6 level mipmap, itu akan menjadi 1.200 entri mipmap, jadi mungkin mipmaps di CompressedTexture menjadi larik bertingkat. Atau adakah cara WebGL mengabstraksi detail itu?

Kemudian, untuk tekstur video, mungkin perlu implementasi yang berbeda. Daripada melakukan transcoding dalam batch sekaligus, Anda akan membiarkan pegangan file dasar tetap terbuka dan memiliki beberapa cara untuk meminta frame berikutnya.