Three.js: UV offset / repeat harus menjadi bagian dari bahan daripada tekstur

Posting terkait: https://github.com/mrdoob/three.js/issues/3549

anda harus mengkloning tekstur per bahan (membuang banyak memori)

Dalam arti apa banyak memori terbuang?

kemungkinan membutuhkan penyeimbangan/pengulangan UV bersama pada tekstur "bersama" adalah rendah

Bagaimana apanya?

Jika kita mempertahankan pendekatan saat ini, satu hal yang perlu diubah, adalah ketika tekstur dikloning, gambar yang dibagikan hanya boleh diteruskan ke GPU satu kali.

jika Anda memiliki objek dengan banyak bingkai/lembar, ada banyak objek tidak berguna yang dibuat, dan seperti yang Anda nyatakan, Gambar disalin beberapa kali ke GPU yang sangat boros. Lebih boros lagi, jika Anda memiliki banyak objek yang perlu berada di titik berbeda dalam animasi yang berbeda, Anda harus membuat kumpulan tekstur yang unik per bahan/objek yang unik, sehingga dengan cepat menjadi menjengkelkan untuk ditangani, di mana seragam bahan bisa jauh lebih mudah dimanipulasi tanpa tekstur ekstra offset/ulangi struktur data yang dibangun di sekitar API yang dipikirkan dengan buruk hanya untuk membuatnya bekerja. Saya mengalami perlambatan besar dalam kasus penggunaan tertentu dari aplikasi saya di mana saya harus membuat grup tekstur unik ini di mana-mana, dan merasa seperti satu-satunya solusi adalah mengganti semua bahan stok yang saya gunakan dengan shadermaterials untuk mengatasi masalah tunggal ini, atau garpu versi THREE.js saya dan buat modifikasi yang diperlukan.

Sehubungan dengan pernyataan kedua:

Maksud saya paradigma saat ini hanya memfasilitasi pekerjaan dalam kasus di mana Anda ingin menerapkan tekstur yang sama dengan offset/pengulangan UV yang sama, tetapi itu umumnya kasus yang jarang terjadi, karena sepertinya Anda ingin mendefinisikan ini seperti yang lain. seragam, per bahan, dan berbagi bahan bukan hanya tekstur.

Peringatan utama dengan sys. adalah bahwa offset/pengulangan hanya benar-benar ada sebagai satu seragam yang mempengaruhi semua tekstur di shader, namun faktanya itu melekat pada TIGA. Tekstur berarti tidak dapat digunakan dengan benar sebagai seragam dan membodohi orang dengan berpikir bahwa offset/pengulangan dapat dipilih secara berbeda untuk berbagai tekstur yang dapat diterapkan pada bahan stok (yaitu Anda dapat menentukan offset difus dan offset peta normal yang berbeda, tetapi ini sebenarnya tidak mungkin meskipun mereka dapat diatur secara unik pada tekstur yang berbeda). Saya dapat melihat itu mungkin sisa dari penyaji kanvas tetapi itu tidak masuk akal dengan sistem materi webGLrender / GLSL, yang sebagian besar telah merebutnya.

mrdoob menyatakan bahwa itu harus dalam bentuk berikut sebagai alasan untuk tidak memilikinya per materi,

materi.peta
material.mapOffset
materi.petaUlangi
materi.env
materi.envOffset
materi.envUlangi
... dll.

tetapi sekali lagi, offset/ulangi tidak berfungsi per-tipe-peta bahkan sekarang, jadi ini sebenarnya bukan argumen yang valid. Itu akan membuang terlalu banyak seragam untuk memilikinya per tipe peta, (belum lagi Anda biasanya hanya menggunakan satu set UV sehingga Anda tidak akan benar-benar memiliki banyak offset untuk peta normal / bumpmap / diffusemap / specularmap). Saya pikir jika Anda menimbang semua opsi yang masuk akal, itu benar-benar harus menjadi properti material daripada properti tekstur. Saya benar-benar tidak merasa ada keuntungan dari sistem saat ini. Saya merasa menjiwai materi melalui offset UV adalah alasan utama untuk memiliki properti sama sekali, dan bahkan tidak dapat digunakan dengan benar untuk itu. Belum lagi jika Anda tidak membutuhkan seragam itu, mereka dapat dihilangkan dari kompilasi shader, sedangkan sekarang mereka ada di sana selama ada peta.

@QuaziKb Dengan segala hormat, jika Anda akan mengusulkan perubahan mendasar ke perpustakaan, seperti yang Anda usulkan di sini, Anda harus memberikan argumen yang jelas dan meyakinkan untuk perubahan itu. Berdebat dari kerangka acuan aplikasi khusus Anda tidak akan memotongnya.

Karena itu, saya juga ingin melihat offset/repeat dipindahkan dari Texture ke materi.

Saya percaya masuk akal untuk menganggap peta berikut memiliki nilai offset/pengulangan yang sama:

specularMap
normalMap
bumpMap
alphaMap
aoMap (future)
glossMap (future)
displacementMap (future)

Pengecualian tunggal adalah

Ini adalah cara yang diterapkan sekarang; meskipun setiap peta memiliki nilai offset/pengulangan sendiri, mereka tidak dihormati.

Jadi, kita bisa menambahkan MeshPhongMaterial , MeshLambertMaterial , MeshBasicMaterial , dan SpriteMaterial , kita akan menambahkan

mapOffset // or mapTranslate
mapRepeat // or mapScale

Kami akan menghapus offset dan repeat dari Texture .

Dengan cara ini, penerapan sprite sheet dapat dilakukan dengan mudah. Setiap sprite memiliki material, dan material tersebut memiliki tekstur tunggal. Tekstur memiliki gambar. Teksturnya tidak lagi harus dikloning. Di sisi GPU, materi akan berbagi program shader tunggal.

IMHO, ini adalah API yang lebih alami.

Saya mencoba mengingat mengapa API diimplementasikan seperti itu. Saya berharap ada alasan bagus.

Maaf tidak bermaksud menyarankan itu khusus untuk contoh saya, hanya bahwa api saat ini mengarah ke kembung yang signifikan ketika digunakan untuk menganimasikan sprite sheet/offset per objek/material unik, tanpa solusi nyata. Secara alami tujuan utama memiliki ini sebagai seragam daripada hanya memanggang offset/ulangi ke UV vertex model adalah untuk menganimasikan offset, dan saya menyarankan ini tidak dapat dilakukan tanpa berkeliling API, membuat seragam jauh kurang berguna melekat pada tekstur daripada jika itu pada materi.

Saya percaya masuk akal untuk menganggap peta berikut memiliki nilai offset/pengulangan yang sama:
peta
...
alphaMap

FWIW, perilaku ini (implementasi saat ini) menyebabkan frustrasi yang signifikan bagi saya saat ini. Saya mencoba untuk menganimasikan pengungkapan mesh dengan mengubah offset alphaMap material mesh secara independen dari peta difusnya (yang tetap). Setelah beberapa frustrasi saya menemukan melalui https://github.com/mrdoob/three.js/pull/4987 dan bug ini bahwa ini tidak mungkin.

@jcarpenter Apa "bug" yang Anda maksud? Apa saran Anda untuk perbaikan?

Koreksi: dengan "bug" maksud saya masalah ini. Kekacauan karena waktu yang berlebihan dalam budaya Bugzilla. :p Saya mengerti bahwa ini bukan bug, melainkan perilaku yang dimaksudkan.

WRT untuk peningkatan, berdasarkan pengalaman saya dengan aplikasi pembuatan konten 3D tradisional seperti Cinema 4D, saya membayangkan pengguna dapat melakukan keduanya:

• tentukan offset/skala/ulangi untuk setiap tekstur dalam suatu material, tidak tergantung pada tekstur lainnya, _dan_
• tentukan offset/skala/ulangi bahan induk

Atau untuk kasus penggunaan yang sedang saya kerjakan ("mencoba menganimasikan pengungkapan mesh"), akan luar biasa jika memiliki opsi untuk wrapS dan wrapT yang tidak membungkus sama sekali. Per GIF terlampir dari Cinema4D, yang memiliki opsi untuk menonaktifkan ubin sepenuhnya untuk pemetaan UVW. Berdasarkan pengujian yang cukup ekstensif dengan metode wrapS dan wrapT yang ada, hal seperti ini tidak mungkin dilakukan. Artinya pilihan saya untuk menganimasikan pengungkapan item di three.js tampaknya terbatas pada posisi tweening dan opacity dari seluruh mesh... Kecuali jika saya melewatkan sesuatu.

Sepakat. Rencananya adalah untuk menyederhanakan semua ini (menggunakan matriks3 tunggal di shader) dan memiliki offset/ulangi (atau terjemahkan/skala) per tekstur.

Siapa pun yang ingin membantu dengan ini akan sangat dihargai!

@jcarpenter

sayangnya satu-satunya cara untuk melakukan ini sekarang adalah dengan beberapa jerat dengan bahan yang berbeda, atau bahan shader khusus. Keduanya agak terlibat untuk pengguna yang baru saja melompat ke alur kerja three.js.

Ada tradeoff konstan antara kegunaan, kinerja dan ekstensibilitas. Saran saya adalah menulis ulang cara tekstur dan bahan bekerja saat ini di api, sehingga tekstur adalah parameter yang Anda masukkan, dan nilai yang sebenarnya seragam di shader seperti mode offset/ulangi/bungkus ditautkan secara khusus ke bahan. Dalam beberapa kasus, Anda tidak ingin seragam terbuang untuk mengontrol UV untuk tekstur yang tidak perlu diubah (akan menjadi pemborosan besar untuk memiliki 4*5 seragam ekstra dalam bahan phong jika Anda hanya membutuhkannya untuk difus), jadi akan keren jika ada keajaiban di balik layar yang mendeteksi jika UV tertentu diperlukan dan teksturnya dibangun kembali untuk memenuhi tuntutan tersebut, atau jika beberapa parameter dapat secara opsional dimasukkan untuk menentukan jumlah UV yang dapat disesuaikan & apa memetakan mereka mengimbangi & bagaimana, tetapi ini adalah masalah yang sulit untuk diselesaikan.

Rencananya adalah untuk menyederhanakan semua ini (menggunakan matriks3 tunggal di shader) dan memiliki offset/ulangi (atau terjemahkan/skala) per tekstur.

@mrdoob

1. Maksudnya _per material.map_ jadi texture transform ada di material? Sayangnya, ada banyak peta material. Kita dapat terus menganggap semua transformasi tekstur adalah sama, kecuali lightmap.
2. Apakah Anda ingin mendukung rotasi juga? Jika demikian, Anda juga harus menambahkan pusat rotasi -- kecuali jika Anda ingin memasang pusat rotasi ke tengah tekstur.

Ini akan menjadi perubahan yang sangat dihargai. Harus mengkloning tekstur hanya untuk menempatkannya pada nilai pengulangan yang unik terasa sangat merepotkan. Apakah ini cara perpustakaan lain melakukannya?

1. Maksudnya _per material.map_ jadi texture transform ada di material? Sayangnya, ada banyak peta material. Kita dapat terus menganggap semua transformasi tekstur adalah sama, kecuali lightmap.

Saya pikir kita harus memiliki mat3 per peta dan harus terdiri dari properti Texture .

1. Apakah Anda ingin mendukung rotasi juga? Jika demikian, Anda juga harus menambahkan pusat rotasi -- kecuali jika Anda ingin memasang pusat rotasi ke tengah tekstur.

Rotasi ya. Pusat atau tidak... Saya tidak yakin, tapi sejauh yang saya mengerti, semua ini dapat dikodekan dalam satu mat3 untuk shader (per peta).

Berikut adalah prototipe yang menunjukkan bagaimana Matrix3 dapat diteruskan ke shader dan mewakili transformasi yang ditentukan oleh offsetX , offsetY , repeatX , repeatY , rotation , rotationCenterX , dan rotationCenterY .

Jika center tidak diizinkan sebagai opsi, maka itu harus di-hardwire ke ( 0.5, 0.5 ) .

Komentar dipersilahkan.

EDIT: demo diperbarui

INI HEBAT! :+1: :+1:

Saya pikir saya akan pergi dengan translation dan scale (bukan offset dan repeat ) sekalipun.

Apa, tepatnya, seharusnya sifat material baru itu? Ada banyak peta materi.

Apa yang harus dihapus dari properti tekstur?

Saya berasumsi bahwa wrapS/T harus tetap pada tekstur.

Saya pikir texture.offset dan texture.repeat harus dihapus.

Saya pikir properti baru harus... texture.translation , texture.rotation , texture.scale , texture.center dan texture.matrix . Kita mungkin juga membutuhkan metode texture.updateMatrix() yang akan dipanggil pada waktu render. Ini, tentu saja, memiliki tantangan untuk memastikan bahwa kita hanya melakukannya sekali meskipun teksturnya digunakan kembali.

Mengacu pada judul posting ini, dan argumen di https://github.com/mrdoob/three.js/issues/5876#issuecomment -69483293, saya pikir intinya adalah memindahkan properti ini ke materi.

/ping @bhouston untuk komentar.

Pikiran saya adalah bahwa tekstur offset/ulangi harus dipanggang ke dalam UV sebanyak mungkin. Ini lebih mudah. Ini adalah bagaimana UE4/Unity 5 melakukannya untuk sebagian besar.

Pengecualiannya adalah bahwa Unity 5 memang memiliki kemampuan untuk menentukan satu offset/pengulangan global per materi yang dibagikan di semua tekstur -- tetapi itu tidak memengaruhi apa yang dianggap sebagai peta yang dipanggang seperti peta lightMap atau ambientOcclusion (yang tidak masuk akal untuk disesuaikan.)

Alasan mengapa saya tidak menganjurkan banyak fleksibilitas di sini adalah karena model yang dibuat secara profesional memiliki UV yang tepat yang membuat ini umumnya tidak diperlukan -- alat pembuatan konten memiliki cara untuk memanggangnya. Masalah lainnya adalah bahwa WebGL memiliki batas bawah yang sangat rendah untuk Fragment Uniforms -- 16 Vec4. Jika Anda harus memiliki pengulangan/offset per peta, dan kami akan segera mendapatkan banyak peta, kami menyia-nyiakan Seragam Fragmen dengan nilai yang sangat kecil.

Saya benar-benar menambahkan pengulangan/pengimbangan dan kemudian kontrol kecerahan/perolehan per tekstur di Clara.io baru-baru ini dan saya akan membatalkan perubahan ini karena hal itu menyebabkan Seragam Fragmen meluap pada perangkat kelas bawah -- seperti setiap perangkat Apple iOS. Meskipun pengulangan/offset dan kecerahan/penguatan berfungsi dengan baik di desktop dengan NVIDIA 980-an, tetapi kami harus mendesain untuk semua orang, bukan mesin kelas atas. ;)

Kita harus memperlakukan Seragam Fragmen dengan hormat dan hanya menggunakannya jika diperlukan. Ini saya percaya bukan salah satu dari kasus-kasus itu.

Pengecualiannya adalah bahwa Unity 5 memang memiliki kemampuan untuk menentukan satu offset/pengulangan global per materi

Ini pada dasarnya apa yang dilakukan three.js sekarang -- meskipun mendapatkan offset/pengulangan dari peta difus, dan semua tekstur material lainnya menggunakan pengaturan dari peta itu.

Usulannya adalah untuk menghapus offset/pengulangan dari tekstur, dan menambahkannya ke material sebagai gantinya -- mungkin dengan perubahan nama. Sekali lagi, semua tekstur material akan berbagi pengaturan yang sama (walaupun beberapa pengguna tidak akan menyukainya). Ini akan menjaga penggunaan seragam tetap rendah.

Sayangnya, kami tidak mendapatkan banyak konsensus tentang hal ini.

Melakukan apa yang Unity 5 lakukan adalah ide yang bagus. Saya akan meletakkannya di bahan bukan tekstur juga. Anda memiliki dukungan saya.

Per peta tidak terlalu ideal, tetapi dapat diselesaikan dengan menetapkannya dengan bendera/kunci entah bagaimana ketika bahan dibuat, jika diperlukan.

Umumnya satu-satunya alasan untuk memodifikasi UV di shader adalah karena Anda ingin mereka dianimasikan. Jika Anda hanya ingin mengubah UV secara statis, kita tidak boleh memodifikasi shader untuk menambahkan fungsi ini.

Satu-satunya perubahan yang diusulkan pada shader adalah mengganti

vUv = uv * offsetRepeat.zw + offsetRepeat.xy;

dengan

vUv = ( uvTransform * vec3( uv, 1 ) ).xy;

Oke. Bagaimana dengan ini... Kami menambahkan texture.dynamic ( false secara default) yang menghasilkan:

vUV = uv;

Jika pengguna menetapkan texture.dynamic ke true maka kita menghitung texture.matrix dari texture.translation , texture.rotation , texture.scale dan texture.center , kami meneruskannya ke programa dan kami menghasilkan:

vUv = ( uvTransform * vec3( uv, 1 ) ).xy;

Tentu saja, jika texture.dynamic berubah, kita perlu mengkompilasi ulang program.

Dengan begitu kita mendapatkan yang terbaik dari kedua dunia?

@mrdoob

1. Dalam pandangan Anda, apakah scale merupakan sifat tekstur atau texture.scale merupakan sifat material? Saya harap ini yang terakhir, karena itulah inti dari utas ini.
2. Kami tidak membutuhkan properti .matrix . Matrix3 adalah uniform yang menggantikan material uniform offsetRepeat . Itu dihitung dari parameter lain di perender dan diteruskan ke GPU seperti seragam lainnya.

1. Dalam pandangan Anda, apakah scale merupakan sifat tekstur atau texture.scale merupakan sifat material? Saya harap ini yang terakhir, karena itulah inti dari utas ini.

Saya tidak setuju dengan utas ini. Saya tidak berpikir kita harus mencemari bahan dengan mapMatrix , envMapMatrix , ... Atau mapTranslation , mapRotation , mapScale . Saya pikir lebih bersih jika THREE.Texture memiliki translation , rotation , scale dan, mungkin center .

1. Kami tidak membutuhkan properti .matrix . Matrix3 adalah uniform yang menggantikan material uniform offsetRepeat . Itu dihitung dari parameter lain di perender dan diteruskan ke GPU seperti seragam lainnya.

Kami agak membutuhkan sesuatu seperti itu. Katakanlah seseorang menggunakan kembali tekstur yang sama di peta yang berbeda. Kami tidak ingin menghitung Matrix3 untuk setiap instance.

Saya tidak setuju dengan utas ini. Saya tidak berpikir kita harus mencemari materi dengan mapMatrix, envMapMatrix, ... Atau mapTranslation, mapRotation, mapScale. Saya pikir itu lebih bersih jika TIGA. Tekstur memiliki terjemahan, rotasi, skala dan, mungkin pusat.

Apakah tekstur masih perlu dikloning untuk memiliki sifat pengulangan yang berbeda? Dalam adegan kecil ini mungkin bukan masalah besar, tetapi dalam adegan besar di mana sudah ada 40+ tekstur, ini adalah mimpi buruk memori.

@titansoftime image harus dipisahkan dari THREE.Texture . Idealnya satu THREE.Image dapat digunakan oleh THREE.Texture berbeda masing-masing dengan translation , rotation , ... yang berbeda.

@titansoftime gambar harus dipisahkan dari TIGA.Tekstur. Idealnya satu TIGA.Gambar tunggal dapat digunakan oleh TIGA yang berbeda.Tekstur masing-masing dengan terjemahan, rotasi, ... konfigurasi yang berbeda.

Itu masuk akal. Apakah texture.clone() sudah bekerja dengan cara ini, atau harus diatur secara manual?

texture.clone() berfungsi seperti itu, tetapi WebGLRenderer tidak dapat mengetahui bahwa gambarnya sama sehingga tidak perlu mengunggah tekstur...

Saya tidak setuju dengan utas ini. Saya tidak berpikir kita harus mencemari materi dengan mapMatrix, envMapMatrix, ... Atau mapTranslation, mapRotation, mapScale. Saya pikir itu lebih bersih jika TIGA. Tekstur memiliki terjemahan, rotasi, skala dan, mungkin pusat.

Ini pada dasarnya adalah apa yang kita lakukan sekarang. Setiap tekstur memiliki properti offset , dan offset individu tidak dihormati -- penyaji menggunakan offset yang sama untuk setiap peta materi.

FWIW, saya pikir kita harus melakukan apa yang saya katakan di https://github.com/mrdoob/three.js/issues/5876#issuecomment -69483293 .

Saya tidak mengerti mengapa API tidak mengizinkan melakukan apa yang ingin dilakukan @jcarpenter (menganimasikan offset alphaMap , sementara map tetap sama). Orang bisa melakukannya di kanvas, tapi saya pikir itu tugas GPU saja.

Ada banyak hal yang bisa dilakukan dengan bermain dengan offset peta yang berbeda... mengimbangi alphaMap saja, menskalakan normalMap , dll

Memiliki hanya satu uvTransform per materi tampaknya sangat membatasi.

Oh tunggu. Saya pikir saya mengerti mengapa kalian lebih suka per materi. Dengan cara itu, satu vUv dihitung di shader vertex, alih-alih menghitung uv per piksel di shader fragmen. Benar?

per material sangat ideal karena offset sebenarnya hanya diimplementasikan menggunakan seragam material dan tidak ada hubungannya dengan tekstur, jadi kita berakhir dengan solusi yang tidak masuk akal jika kita perlu mengubah seragam per material yang harus dibuat banyak objek/tekstur baru (yang sangat buruk di JS/mengerikan di WebGL) hanya untuk mengontrol sesuatu yang sebenarnya hanyalah fitur dari seragam material yang disembunyikan dari pengguna. Sama sekali tidak menjadikannya bagian dari tekstur yang menguntungkan, lebih efisien, atau bahkan lebih jelas, dan itu berarti satu-satunya aplikasi nyata untuk menentukan UV yang berubah saat runtime, animasi, dibuat lambat dan tidak efisien karena api.

Tekstur harus menentukan gambar, dan apa pun yang berkaitan dengan gambar itu. Offset UV tidak ada hubungannya dengan properti gambar / gambar, dan semuanya berkaitan dengan materi yang menampilkan tekstur, adalah tidak masuk akal untuk memiliki fitur ini jika itu bukan bagian dari materi, karena perlu banyak kloning yang terjadi per misalnya, dan memperbarui banyak tekstur secara bersamaan jika seseorang ingin benar-benar menggunakan fitur tersebut dalam banyak kasus.

bayangkan seseorang memiliki gambar yang berbeda untuk setiap bingkai ubin animasi, dan juga ingin mengontrol offset/pengulangan ubin itu. Mereka harus memperbarui setiap bingkai yang masuk dengan offset, serta memiliki salinan setiap bingkai untuk setiap contoh unik material yang menggunakan ubin itu, dengan cepat menjadi ratusan objek baru dan tugas tambahan, untuk sesuatu yang sebenarnya hanya mengendalikan beberapa pelampung per materi di belakang layar menggunakan semua objek ini tanpa alasan yang jelas.

untuk transformasi per peta, meskipun akan menyenangkan, biaya seragam terlalu tinggi tanpa alasan dalam banyak kasus, kecuali jika kita memiliki API yang kompleks untuk mengontrol kapan dan bagaimana transformasi harus unik atau dibagikan atau dinamis, IMO memiliki kontrol itu akan menjadi hal yang baik, tetapi itu harus dipikirkan dengan hati-hati.

Oh tunggu. Saya pikir saya mengerti mengapa kalian lebih suka per materi. Dengan cara itu, satu vUv dihitung di shader vertex, alih-alih menghitung uv per piksel di shader fragmen. Benar?

Tidak. uv dihitung dalam shader vertex seperti biasa.

Bayangkan sebuah sprite sheet dan 20 sprite. Saat ini, kami membutuhkan 20 bahan kloning dan 20 tekstur kloning -- seperti di http://threejs.org/examples/misc_ubiquity_test2.html. (BTW, perhatikan kita sudah memiliki SpriteMaterial.rotation .)

Memindahkan offset ke material, kita membutuhkan 20 material kloning dan satu tekstur.

Padahal, untuk memindahkan offset ke sprite, kita membutuhkan 1 material dan 1 tekstur.

Bayangkan sebuah sprite sheet dan 20 sprite. Saat ini, kami membutuhkan 20 bahan kloning dan 20 tekstur kloning

Ohm, saya tidak mempertimbangkan kasus penggunaan ini. Terima kasih!

aku akan memikirkan ini...

Saya menganjurkan untuk tidak mengubah tekstur UV.

Karena dua alasan: (1) membingungkan, (2) ada lebih banyak acara untuk disebarkan, dan (2) boros.

Kebingungan: Alasannya adalah kami hanya memiliki satu variabel UV untuk peta utama, tetapi jika ada transformasi UV pada salah satu tekstur, membingungkan bahwa transformasi UV ini dapat diterapkan ke semua peta yang menggunakan UV pertama. saluran, apakah tekstur lainnya mengalami transformasi atau tidak. Jika kami mengizinkan setiap peta memiliki transformasi UV sendiri dalam materi, saya akan lebih setuju dengan transformasi UV yang terkait dengan tekstur -- tetapi itu sulit dilakukan karena penggunaan fragmennya yang seragam.

Lebih Banyak Propagasi Acara: Masalah lain yang saya temui di Clara.io adalah propagasi acara ketika mencoba menganimasikan parameter tekstur. Seseorang membutuhkan setiap tekstur untuk melacak setiap bahan yang menggunakannya, dan kemudian memberi tahu bahan-bahan itu bahwa mereka kotor dan perlu dihitung ulang. Bukan tidak mungkin untuk melakukan ini, hanya lebih banyak pekerjaan.

Pemborosan: Masalah lainnya adalah jika Anda memiliki beberapa contoh model atau dendam 3D dan semuanya memiliki tekstur animasi yang sama. Dalam hal ini Anda harus memiliki salinan tekstur yang berbeda di memori hanya untuk membuatnya dianimasikan secara berbeda -- meskipun data tekstur itu sendiri sama. Ini agak boros dalam pengertian itu dibandingkan dengan menempatkan data transformasi UV pada bahan.

Jadi jika kita hanya memiliki satu UV Transform yang diizinkan per material, saya akan meletakkannya di material itu sendiri. Saya akan mengikuti model Unity 5 di mana mereka memiliki offset UV, rotasi material. Pengembang game sudah akrab dengan pendekatan ini.

Saya pikir sprite ditangani dengan baik oleh UV Transform pada materialnya juga -- sangat mirip dengan model 3D di atas.

Having only one uvTransform per material seems very very limiting.

Sangat setuju di sini. Tidak memiliki fungsi ini sangat membatasi. Ada efek fantastis yang dapat diberikan di sini yang tidak hanya karena setiap offset dikunci bersama.

Tapi bagaimana fungsi ini tersedia tanpa tersedak klon?

Saya pikir memiliki nilai pada Material daripada tekstur masuk akal untuk kasus penggunaan umum di mana semua tekstur Anda akan dicocokkan.

Sangat setuju di sini. Tidak memiliki fungsi ini sangat membatasi. Ada efek fantastis yang dapat diberikan di sini yang tidak hanya karena setiap offset dikunci bersama.

Tapi bagaimana fungsi ini tersedia tanpa tersedak klon?

THREE.ShaderMaterial atau THREE.RawShaderMaterial akan memberi Anda kemampuan ini, dan karena saat ini tidak berfungsi dengan materi biasa, ini adalah rute yang harus Anda gunakan.

Jika Anda melakukan sesuatu yang lebih funky, itu mungkin akan lebih funky daripada hanya menyesuaikan pengulangan peta dan offset secara independen, jadi Anda mungkin akan tetap bersandar dengan cara ini.

+1 untuk ini, teman-teman.

Ini akan sangat berguna ketika Anda memiliki sprite sheet raksasa (alias atlas) dan ingin menggunakan kembali teksturnya pada beberapa instance THREE.Sprite .

Ada berita tentang ini? Masalah ini masih merupakan cacat yang cukup mencolok di API. Sebagian besar jenis peta memiliki offset/pengulangan yang tidak digunakan, dan propagasi acara membuat sesuatu seperti sprite animasi di pesawat jauh lebih lambat/memori lebih berat dari yang seharusnya.

Fleksibilitas untuk peta animasi TIDAK ADA di sistem saat ini. Argumen terus muncul bahwa kami akan mengurangi fleksibilitas dengan mengikat pengaturan ke materi. Argumen ini diperdebatkan karena fleksibilitas ini tidak ada dalam sistem saat ini. Anda hanya dapat mengatur offset/repeat secara global untuk material, dan itu diambil dari peta difus(?). Ini mengarah ke masalah yang lebih buruk di mana ada pengaturan "offset" / "ulangi" yang berlebihan pada sebagian besar peta yang digunakan, dan kapan pun Anda ingin berbagi tekstur untuk animasi, Anda tidak bisa, Anda perlu membuat klon, jadi fleksibilitas sangat penting. berkurang. Anda mengharapkan setiap tekstur/peta memiliki offset unik tetapi ini tidak mungkin karena keadaan, dan dalam kebanyakan kasus Anda benar-benar menginginkan satu set offset UV karena akan mengganggu untuk mengatur offset ke hal yang sama untuk normal/spec /diffuse (peta normal yang bergulir di atas peta difus tetap adalah penggunaan khusus di mana bahan shader dapat digunakan).

Jika Anda melihat shader yang sebenarnya sedang dibangun, tekstur offset / repeat IS terikat pada material, tetapi anehnya disalin dari satu peta yang sama sekali tidak boleh dikendalikan. Bahan HARUS dikendalikan agar cepat dan elegan tanpa redundansi.

Yang terbaik dari kedua dunia dimungkinkan dengan banyak bendera tambahan, tetapi saya tidak berpikir ini adalah solusi yang lebih baik daripada hanya mengarahkan pengguna untuk mencoba menggunakan bahan shader alih-alih untuk jenis kasus tepi khusus ini.

Solusi untuk ini adalah @sunag 's NodeMaterial btw.

Juga menambahkan +1 saya untuk ini! Akan membuat bekerja dengan sprite sheet jauh lebih baik.

:+1: Saya menemukan ini mengejutkan. Saya harus mulai menduplikasi tekstur saya untuk setiap sprite dalam game, karena semua sprite saya yang berulang saling menjiwai. Kedengarannya seperti ini berarti saya memuat data sprite yang berlebihan ke GPU?

Apakah ada yang punya solusi untuk masalah ini? Mungkinkah memanipulasi offset UV dengan langsung menyetel seragam pada shader, melewati antarmuka Tekstur?

Solusi untuk ini adalah @sunag 's NodeMaterial btw.

@bhouston , bisakah Anda memberikan tautan? Tidak ada repositori publik di bawah akun @sunag dengan nama itu.

@rhys-vdw Itu terletak di sini di cabang dev saja:

https://github.com/mrdoob/three.js/tree/dev/examples/js/nodes

Ini baru jadi saya tidak yakin apakah itu siap digunakan pada sprite, tetapi ini adalah sistem shader berbasis grafik sepenuhnya, jadi ini akan memberi Anda fleksibilitas untuk mengubah akses tekstur secara sewenang-wenang.

Ini baru jadi saya tidak yakin apakah itu siap digunakan pada sprite, tetapi ini adalah sistem shader berbasis grafik sepenuhnya, jadi ini akan memberi Anda fleksibilitas untuk mengubah akses tekstur secara sewenang-wenang.

@bhouston Saya dapat membuat contoh dengan Node, ini terlihat bagus.

Tentang THREE.SpriteMaterial Anda dapat mengakses offset/skala untuk membuat spritesheet dengan ini misalnya:

var offsetX = frameX / mapWidth;
var scaleX = mapWidth / frameWidth;

sprite.material.map.offset.x = offsetX;
sprite.material.map.repeat.x = scaleX;

https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/plugins/SpritePlugin.js#L53

Sistem berbasis simpul bukanlah perbaikan... Masih tidak mengatasi masalah dengan api. Dibutuhkan 2 detik untuk menambahkan offset/pengulangan ke prototipe material, dan membuat penyaji membacanya sebagai ganti tekstur. Saya sudah melakukannya untuk proyek saya, tetapi faktanya tetap merupakan cacat yang jelas dalam api yang harus diubah secara resmi untuk mencegah sakit kepala bagi pengguna baru yang AKAN mengalami masalah ini jika mereka mencoba melakukan sesuatu yang umum.

...sehingga akan memberi Anda fleksibilitas untuk mengubah akses tekstur secara sewenang-wenang.

tbh ga ngerti maksudnya. Untuk menganimasikan seragam shader set individu untuk "offset" dan "ulangi" pada basis per material.

Tentang THREE.SpriteMaterial Anda dapat mengakses offset/skala untuk membuat spritesheet dengan ini misalnya...

@sunag , mungkin masalahnya tidak jelas. Kode yang Anda bagikan mengubah tekstur, yang dibagikan oleh semua contoh materi itu. Ini berarti bahwa tidak mungkin memiliki dua bahan yang berbagi tekstur, tetapi dengan offset yang unik - misalnya, dua sprite musuh menunjukkan bingkai animasi yang berbeda.

Saya sudah melakukannya untuk proyek saya, tetapi faktanya tetap merupakan cacat yang jelas dalam api yang harus diubah secara resmi untuk mencegah sakit kepala bagi pengguna baru yang AKAN mengalami masalah ini jika mereka mencoba melakukan sesuatu yang umum.

@QuaziKb Apakah ada PR yang dapat saya targetkan untuk proyek saya?

Meskipun semua ini tidak akan menjadi masalah jika, seperti yang dikatakan @WestLangley , yang berikut ini benar:

Jika kita mempertahankan pendekatan saat ini, satu hal yang perlu diubah, adalah ketika tekstur dikloning, gambar yang dibagikan hanya boleh diteruskan ke GPU satu kali.

Apakah itu benar?

@sunag , mungkin masalahnya tidak jelas. Kode yang Anda bagikan mengubah tekstur, yang dibagikan oleh semua contoh materi itu. Ini berarti bahwa tidak mungkin memiliki dua bahan yang berbagi tekstur, tetapi dengan offset yang unik - misalnya, dua sprite musuh menunjukkan bingkai animasi yang berbeda.

Hmm, untuk NodeMaterial pasti akan terpecahkan, Anda akan dapat berbagi tekstur yang sama dengan bahan yang berbeda dan offset uv independen dan keuntungan seperti filter khusus dan hal lain yang dapat ditawarkan oleh bahan berbasis simpul.

https://github.com/mrdoob/three.js/issues/7522

Tetapi pada saat seseorang mencoba membuat instantiate uuid seperti ini :?

THREE.Texture.prototype.createInstance = function() {

    var inst = this.clone();

    inst.uuid = this.uuid;
    inst.version = this.version;

    return inst;

}

jika Anda menggunakan needsUpdate perbarui semua instance version juga.

Contoh:

var uniqueTextureOffset = map.createInstance();
var material = new THREE.SpriteMaterial( { map: uniqueTextureOffset } );

Pertahankan uuid dan version akan membagikan texture pada GPU.

https://github.com/mrdoob/three.js/blob/master/src/renderers/WebGLRenderer.js#L2832
https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLProperties.js#L11

Meskipun bagi saya itu adalah solusi sementara. Saya percaya pada NodeMaterial untuk masa depan.

Bisakah kami memindahkan transformasi uv ke materi?

Bagaimana dengan yang terbaik dari kedua dunia. Tambahkan flag overrideOffsetRepeat pada materi dengan uvOffset dan uvRepeat pada materi. Dengan cara ini jika bendera salah, itu kompatibel ke belakang, dan itu adalah default. Dan jika benar menggunakan bahan offset/repeat. Saya akan mendukung ini karena tampaknya kebutuhannya intens dan meluas. @WestLangley? @mrdoob?

(Meskipun saya benar-benar mendukung penggunaan NodeMaterial untuk semua yang akan datang, tetapi sulit untuk beralih ke sana.)

Saya masih berpikir solusi untuk ini adalah membuat THREE.Image . https://github.com/mrdoob/three.js/issues/5876#issuecomment -81189892

THREE.Image

@mrdoob , apakah itu berarti bahwa setiap Texture ditetapkan akan dikloning bersama dengan Material ?

@mrdoob menulis:

Saya masih berpikir solusi untuk ini adalah membuat TIGA. Gambar

Ya itu akan berhasil, itu akan menjadi sedikit kurang kompatibel (jika sekarang kita mengharuskan semua orang untuk membuat Gambar sebelum membuat Tekstur), tetapi desain keseluruhan yang lebih bersih. Mungkinkah Gambar dibuat secara otomatis per Tekstur jika seseorang tidak menentukannya secara terpisah, maka itu akan mencapai kompatibilitas ke belakang? Dan Anda hanya perlu memanipulasi Gambar secara langsung jika Anda ingin melakukan sesuatu yang rumit.

Saya kira solusi ini akan membutuhkan dua kali objek baru untuk satu set sprite - satu Tekstur untuk setiap sprite dan satu Material? Di mana pendekatan lain hanya membutuhkan Material baru per setiap sprite?

Saya tahu bahwa Unity mendukung pengulangan/offset per Material, tetapi alat VFX kelas atas seperti 3DS Max, Maya, Softimage tidak -- mereka hanya memiliki simpul Bitmap dan simpul Tekstur (yang berisi simpul Bitmap serta Pemetaan UV anggukan), yang mirip dengan desain @mrdoob .

UE4 juga mirip dengan apa yang @mrdoob usulkan, mereka memiliki simpul "Tekstur" yang merupakan pemuat bitmap, dan kemudian mereka memiliki serangkaian simpul Pemetaan UV untuk melakukan berbagai jenis pemetaan UV.

Alat-alat canggih memang memisahkan Gambar/Bitmap dari Tekstur dan mereka juga membagi simpul pemetaan UV yang terpisah, dalam bentuk ini:

 -> Bitmap
 -> UVMapping

Kami tidak mengizinkan banyak opsi UVMapping di StandardMaterial utama saat ini. Tetapi berbagai jenis UVMappings yang digunakan di UE4, Maya, Softimage, 3DS Max, akan saluran mana yang digunakan, transformasi yang diterapkan padanya, menggunakan Koordinat Dunia sebagai sumbernya, atau jika seseorang harus melakukan proyeksi Spherical, Cube, Planar berdasarkan parameter yang diperlukan untuk proyeksi tersebut.

UE4 memiliki tekstur sprite yang memungkinkan pengulangan/pengimbangan dalam materi:

https://docs.unrealengine.com/latest/INT/Engine/Paper2D/Sprites/index.html

Maya, Softimage, 3DS Max, dan UE4 memiliki pemisahan Bitmap/Gambar dari Tekstur (dan dari Generasi UV) seperti yang disarankan oleh @mrdoob , tetapi mereka semua juga menggunakan grafik shader untuk mencapai ini. Unity3D, yang tidak memiliki grafik shader adalah alat yang menggabungkan offset/pengulangan ke dalam materi itu sendiri, mungkin karena tidak dapat memisahkannya dengan benar menjadi simpul grafik shader.

Mungkinkah Gambar dibuat secara otomatis per Tekstur jika seseorang tidak menentukannya secara terpisah, maka itu akan mencapai kompatibilitas ke belakang? Dan Anda hanya perlu memanipulasi Gambar secara langsung jika Anda ingin melakukan sesuatu yang rumit.

Tepat

Mungkin agak tidak pada tempatnya untuk disebutkan tetapi saya ingin merekomendasikan PTEX untuk dimasukkan sesegera mungkin.
http://ptex.us/PtexFile.html
Jika ada cara untuk membuat proyeksi khas dll dilemparkan/dikonversi ke NodeTexture (?) Atau opsi yang merupakan sistem pemetaan tekstur tingkat dasar baru yang lebih kuat dan komprehensif? ...baiklah mungkin itu sesuatu yang perlu dipertimbangkan sebelumnya.
[Lebih lanjut ke poin yang sama:]
Konsep dengan ptex sebenarnya bukan gambar 2d tetapi hubungan uv sehingga Anda dapat melukis/mencap/memproyeksikan di sekitar permukaan yang kompleks tanpa konsep/tantangan tentang cara menerjemahkan 2d ke 3d, yang secara matematis merupakan peretasan terbaik dalam perbandingan ( selalu secara teknis berjuang dengan destortion).
Saya hanya menunjukkan bahwa ptex seharusnya lebih masuk akal dan menjadi prioritas 20+ tahun yang lalu dan tidak boleh dianggap sebagai ekstensi atau pemain kelas dua, tetapi sebenarnya bagi saya itu sebaliknya. Ini harus menjadi cara orisinal lama untuk secara deklaratif mengatakan bagaimana gambar 2d diproyeksikan/dicap ke dalam sistem tingkat dasar ptex yang selalu berfungsi. Pokoknya hanya menegakkan ide itu harus diintegrasikan jika tidak terbaik untuk mengambil gulungan yang lebih sentral.
Terima kasih atas kesempatan untuk membuat saran yang tinggi. Saya sangat senang bahwa ptex dibuat dengan spesifikasi. Saya memikirkannya sendiri 10+ tahun sebelumnya tetapi sebagai seorang anak tidak memiliki kekuatan untuk menentukan spesifikasi baru, dll. Di belakang saya seharusnya melihat bahwa mungkin saya bisa mencoba membuat perbedaan alih-alih daftar pengamat yang masih saya pertahankan. Jadi di sini adalah upaya untuk membatalkan kesalahan lama.

Mungkin seseorang dapat memulai utas baru jika siapa pun dengan pemahaman yang lebih dalam tentang metode saat ini yang berpotensi di Flux dapat membuat proposal yang lebih dapat diterapkan tentang cara kerjanya di THREEjs.
Sekali lagi terima kasih atas kesempatan untuk didengar.

@MasterJames agak di luar topik... tolong buat utas baru?

Bahkan jika kami memiliki gambar sehingga "tekstur" masih dapat digunakan, semua bahan perlu ditulis ulang, karena sebenarnya tidak mendukung lebih dari satu offset/pengulangan uv. Jelas ini dapat berubah, tetapi mungkin pada akhirnya akan menambah kerumitan karena seragam yang berlebihan akan diperlukan (seberapa sering Anda menginginkan lebih dari satu set offset/pengulangan sehingga misalnya peta normal diimbangi dari difus) saya pikir pada akhirnya untuk web di mana kinerjanya premium, kasus penggunaan yang paling umum adalah kasus di mana ada satu offset/pengulangan global yang memengaruhi setiap peta, dan masuk akal jika ini ada di material karena akhirnya menjadi bagian dari arsitektur material. Bahan shader khusus dapat menangani casing tepi dengan baik.

@QuaziKb Ya. Itulah yang ditangani NodeMaterial .

Bukankah Texture menggunakan contoh tekstur OpenGL yang sama untuk setiap .clone() , atau apakah saya melewatkan sesuatu. Apakah itu benar-benar mengunggah ulang untuk setiap klon? Jika itu masalahnya, maka ini adalah masalah _sangat_ serius.

@evrimoztamur , saya percaya itu menyalin tekstur setiap kali. Anda dapat memeriksa apa yang terjadi menggunakan WebGL Inspector .

Saya mencoba mencoba setiap pendekatan yang dapat saya pikirkan, termasuk solusi @sunag , tetapi tidak ada yang berhasil. Berdasarkan eksperimen saya yang tidak membuahkan hasil, dan diskusi di atas, saya melihat-lihat bagaimana perpustakaan lain menangani animasi sprite. Saya menemukan Sprite dan SpriteManager API

@rhys-vdw: Untuk proyek saat ini saya berakhir dengan versi MeshBasicMaterial bajingan:
https://Gist.github.com/karimbeyrouti/790d2e1a8c0137b16bae

Saat Anda mengatur Peta, ini secara otomatis menetapkan seragam offset / pengulangan (yang ada di material yang tersimpan). Anda dapat dengan mudah mengaturnya secara terpisah - itu akan menghentikan Anda perlu mengkloning tekstur untuk saat ini. (bekerja dengan r73)

Saya baru saja mengirimkan PR yang harus mengatasi masalah ini, PR #8278

@WestLangley menulis:

Saya percaya masuk akal untuk menganggap peta berikut memiliki nilai offset/pengulangan yang sama:

peta
specularPeta
peta biasa
benjolanPeta
alphaMap
aoMap (masa depan)
glossMap (masa depan)
perpindahanPeta (masa depan)

Tidak selalu. Saat ini saya menggunakan nilai pengulangan yang berbeda untuk peta dan bumpmap pada bahan yang sama (aspal) untuk menyembunyikan fakta bahwa keduanya ubin dengan ubin yang agak kecil. Dengan begitu, saya tidak perlu menghasilkan/memiliki tekstur yang besar. Hal ini sangat nyaman. :-)

EDIT: Yah, setidaknya itulah yang saya pikir telah saya lakukan. Triknya mungkin diabaikan. Dan saya dapat mencapai hasil yang serupa dengan menambahkan noise di shader atau semacamnya. Demo Matrix3 WestLangley keren.

Saya pikir ini memecahkan masalah instance dengan UV yang berbeda di Sprite. Dimungkinkan untuk memodifikasi vertex dan pixel shader mempertahankan tekstur yang sama.

https://threejs.org/examples/#webgl_sprite_nodes

Itu menggunakan SpriteNodeMaterial dan Mesh dengan PlaneBufferGeometry . Antarmuka tidak sesuai untuk Sprite tetapi berfungsi. Mungkin bisa berevolusi menjadi SpriteMesh untuk membuat antarmuka lebih ramah

utas ini adalah TL;DR untuk saya. tapi saya baru saja menemukan kode ini di r68 (proyek lama, ya):

        // uv repeat and offset setting priorities
        //  1. color map
        //  2. specular map
        //  3. normal map
        //  4. bump map
        //  5. alpha map

        var uvScaleMap;

        if ( material.map ) {

            uvScaleMap = material.map;

        } else if ( material.specularMap ) {

            uvScaleMap = material.specularMap;

        } else if ( material.normalMap ) {

            uvScaleMap = material.normalMap;

        } else if ( material.bumpMap ) {

            uvScaleMap = material.bumpMap;

        } else if ( material.alphaMap ) {

            uvScaleMap = material.alphaMap;

        }

        if ( uvScaleMap !== undefined ) {

            var offset = uvScaleMap.offset;
            var repeat = uvScaleMap.repeat;

            uniforms.offsetRepeat.value.set( offset.x, offset.y, repeat.x, repeat.y );

        }

jadi, ya...

jika Anda akan mengusulkan perubahan mendasar pada perpustakaan, seperti yang Anda usulkan di sini, Anda harus memberikan argumen yang jelas dan meyakinkan untuk perubahan itu

Saya mencoba mengatur pengulangan yang berbeda pada peta difus dan normal dan mencabut rambut saya karena tidak berhasil. karena API menempatkan pengaturan ini dalam tekstur, saya pikir saya bisa melakukannya. jadi ya, bagaimana kalau menyelamatkan rambut saya untuk argumen yang meyakinkan? tiket ini masih terbuka, 3js masih memiliki pengaturan ini pada tekstur, dan ini hanya berlaku untuk salah satu tekstur = ini, pada dasarnya, sudah merupakan pengaturan per-bahan.

Jika Anda tidak akan memindahkan ini ke tempatnya, setidaknya katakan itu tidak berpengaruh di dokumen?

@sunag Untuk PR:
https://github.com/mrdoob/three.js/pull/11531

Satu masalah yang saya alami:
https://jsfiddle.net/f0j2v3s8/

Sepertinya transparansi SpriteNodeMaterial hilang, tidak ada kombinasi pencampuran yang dapat saya gunakan untuk menjalankan contoh ini.

Ada ide?

@karimbeyrouti menulis:

Saat Anda mengatur Peta, ini secara otomatis menetapkan seragam offset / pengulangan (yang ada di material yang tersimpan). Anda dapat dengan mudah mengaturnya secara terpisah - itu akan menghentikan Anda perlu mengkloning tekstur untuk saat ini. (bekerja dengan r73)

Saya yakin ini sudah usang karena uniforms.offsetRepeat diubah menjadi uniforms.uvTransform (r88).

Mengenai kasus penggunaan 'menggunakan kembali atlas tekstur dengan beberapa instance Object3D', saya menyarankan jalan-jalan sederhana:

1. menyimpan data UV (offset, ulangi) dalam objek atlas json;
2. kaitkan pasangan fungsi onBeforeRender\onAfterRender dari Object3D;
3. di panggilan balik sebelum render, muat data UVs dari objek atlas json dan setel ke material.map;
4. di panggilan balik setelah render, setel ulang;

Ini akan menghasilkan:

1. hanya satu Tekstur & satu Materi yang dibagikan oleh banyak objek, tidak diperlukan Klon dan penghitung info.memory.textures tidak akan bertambah;
2. tapi tetap saja semua peta lainnya (normal, ao, perpindahan...) harus sesuai dengan terjemahan UV yang sama;