Three.js: WebGL2Renderer

Sangat bagus. :) Saya sebenarnya agak khawatir tentang bagaimana menangani kompleksitas WebGL 2 dan 1.

Akan lebih baik untuk memilih menggunakan UBO. :) Dan saya menyukai ide yang hanya mendukung BufferGeometry - yang seharusnya sangat menyederhanakan banyak hal.

Akan keren untuk mendukung sebagian besar shader yang sama meskipun jika kita tetap menggunakan rendering maju (yang tampaknya seperti yang dilakukan UE4 untuk kecepatan untuk VR.) Saya pikir kita mungkin dapat mengayunkannya? Bagaimana menurut anda?

Saya kira saya ingin mempertahankan kompatibilitas shader sehingga jika WebGL2 tidak tersedia, kami dapat kembali ke sesuatu yang terlihat serupa, hanya saja lebih lambat.

@mrdoob Hip hip hore! Dan senang mendengar bahwa BufferGeometry akan digunakan secara eksklusif. 👍

Saya mendukung saran @bhouston untuk lebih memilih UBO.

Apakah mungkin untuk juga memisahkan pencahayaan dan penanganan bayangan dari penyaji secara lebih lengkap? Defaultnya sangat berguna, tetapi ketika Anda ingin kontrol penuh atas logika pencahayaan dan bayangan, WebGLRenderer and co. merasa seperti mereka melakukan perlawanan.

Dan sementara saya mencantumkan item tipe wishlist-y, dapatkah algoritme pengurutan dibuat 'dapat dipasang'? Saya memiliki kebutuhan penyortiran yang berada di luar cakupan tiga, dan tampaknya sulit untuk mengesampingkan fungsi penyortiran dalam WebGLRenderer saat ini. Mungkin ini bisa menjadi pengaturan opsional saat membuat objek renderer?

Saya hampir bertanya-tanya apakah seseorang harus memodifikasi WebGLRenderer 1 dan menghapus dukungan untuk apa pun selain objek BufferGeometry. Itu mungkin cara yang lebih mudah ke depan. Jika ada fungsi sederhana untuk mengubah Geometri menjadi BufferGeometry yang memaksa orang untuk memanggil...

Saya kira saya mengatakan ini karena saya khawatir mencoba mempertahankan paritas fitur antara WebGLRenderer dan WebGLRenderer2. Lebih mudah untuk mengembangkan basis kode tunggal daripada mempertahankan dua secara paralel.

Saya hampir bertanya-tanya apakah seseorang harus memodifikasi WebGLRenderer 1 dan menghapus dukungan untuk apa pun selain objek BufferGeometry. Itu mungkin cara yang lebih mudah ke depan. Jika ada fungsi sederhana untuk mengubah Geometri menjadi BufferGeometry yang memaksa orang untuk memanggil...

Sudah ada fungsi seperti itu. Tapi tidak sesederhana itu...

Saya pikir lebih baik membangun WebGLRenderer2 dari awal sehingga kami dapat mempertimbangkan kembali API dan fitur yang didukung.

Firefox 51 sekarang memiliki dukungan WebGL 2: https://www.mozilla.org/en-US/firefox/51.0/releasenotes/

Tidak sabar untuk ini!

Chrome 56 yang mendukung WebGL 2.0 telah dirilis!
https://developers.google.com/web/updates/2017/01/nic56

Waktu yang tepat untuk memajukan WebGLRenderer2 ? XD

Haruskah kita juga membuat WebGLDeferredRenderer2?

Berencana untuk mulai melihat semua ini minggu depan! ️

Setiap kesempatan Anda sudah punya waktu untuk melihat ke dalamnya! Sangat menantikannya! (3D tekstur)

@mrdoob
Ada pembaruan?
Jika Anda memiliki beberapa kekhawatiran, silakan berbagi dengan kami!
Kita bisa berdiskusi dan membantu ;D

Belum sempat. Segera segera! 😇.

https://blog.chromium.org/2017/03/faster-3d-rendering-with-webgl-20.html

Ada pembaruan? Saya sangat tertarik pada tekstur 3D untuk volume rendering beberapa gambar medis. Saya juga bersedia membantu untuk menyukseskan pull request ini.

Kotak pasir three.js webgl2 saat ini tidak berfungsi :( https://threejs.org/examples/webgl2_sandbox.html
Mungkin masalah build versi three.js?

Jika online <script type="module"> sudah diimplementasikan...
https://groups.google.com/a/chromium.org/d/msg/blink-dev/uba6pMr-jec/tXdg6YYPBAAJ

Setidaknya Mozilla sedang mengerjakannya https://bugzilla.mozilla.org/show_bug.cgi?id=1240072

@mrdoob , Apakah ini berarti kita dapat mengharapkan API Three.js memanfaatkan <script type="module"> saat diperbarui ke WebGL 2.0? ;)

BTW Saya pikir ini paling mudah untuk sementara waktu hanya dengan menambahkan dukungan WebGL 2.0 ke WebGLRenderer. Saya pikir ini akan memungkinkan adopsi tambahan dan kami dapat melakukan deteksi fitur untuk melihat apakah kami dapat menggunakan fitur WebGL 2. Saya tidak berpikir itu adalah hal yang paling sulit untuk dilakukan. Saya tahu ini mengarah pada sedikit kerumitan dibandingkan dengan penyaji WebGL 2 murni, tetapi ini adalah jalur termudah dalam waktu dekat dan menengah. Dan kami perlahan berkembang di mana kami akhirnya meninggalkan WebGL 1 setelah WebGL 2 memiliki adopsi di atas 90%.

Khronos baru saja mengadakan webinar di webgl2:
https://docs.google.com/presentation/d/11-mTDNmSJzJnRVGu9Vu6AUzOt34yV3PO7oqw4E5wc2o/edit#slide =id.gd15060520_0_38
Media akan segera keluar, tetapi presentasinya sebagian besar berupa sulih suara slide dan demo terkait di slide.

Cukup jelas bahwa ini memerlukan awal yang baru, bukan "memperbarui" dari WebGLRenderer yang ada.

Dalam hal modul es6, saya pikir pendekatan sumber saat ini adalah modul es6, kemudian menggunakan rollup untuk bundel masih merupakan cara untuk mendukung "dual build".

Saya telah melakukan ini sekarang selama sekitar satu minggu, menguji modul di Safari Tech Preview dan bundel di semua browser. Benar-benar menghasilkan build/memiliki pohon sumber serta bundel saat ini. Rollup satu baris seperti yang Anda miliki saat ini, dan salinan pohon sumber untuk penggunaan modul.

@bhouston menggoda...

Status terakhir?

Aku punya entah bagaimana perasaan campur aduk tentang ini. Awalnya saya memikirkan jalur yang sama seperti yang diusulkan @bhouston , secara bertahap menambahkan fitur webgl2 ke WebGLRenderer saat ini. Tapi itu akan membuat penyaji lebih kompleks dan sulit untuk menangani fitur yang paling berbeda antara dua versi yang berakhir dengan kode berantakan yang penuh dengan cabang dan pemeriksaan kondisi.
Salah satu opsi adalah mengkloning WebGLRenderer sebagai titik awal untuk WebGL2Renderer dan terus menghapus/menambahkan fitur tanpa mengacaukan penyaji asli.
Jika kita melihat mesin seperti Playcanvas, yang mungkin merupakan salah satu di luar sana dengan dukungan webgl2 paling awal, kita dapat melihat bahwa itu bahkan tidak memanfaatkan fitur webgl2 baru seperti UBO atau VAO karena itu adalah sesuatu yang akan memodifikasi banyak bagian mesin.

Saya sangat percaya bahwa jika kita mencoba untuk mencampur kedua versi pada penyaji yang sama, kita akan berakhir dengan kode yang lebih sulit untuk dipelihara dan segera setelah webgl2 mendapatkan dukungan penuh, kita tetap harus memfaktorkan ulang ini karena saya kira kita akan melakukannya terpaksa mengikuti desain untuk menjaga kompatibilitas itu, alih-alih mendesainnya dari awal dengan mempertimbangkan webgl2.

Jadi pilihan saya adalah memulai WebGL2Renderer dari awal bahkan jika kita akan berjalan lambat (kita masih memiliki ruang untuk perbaikan sampai webgl2 akan mendekati 100% dukungan di luar sana).

Beberapa file selain dari renderer itu sendiri harus dimodifikasi, misalnya tekstur, program dan sebagainya. Haruskah kita membuat subfolder renderer\webgl2 dan terus menambahkan file yang akan dibuat khusus untuk perender itu?

Kami dapat membuat masalah dengan daftar perubahan yang harus kami lakukan untuk memiliki perender webgl2 yang sepenuhnya kompatibel untuk mengingatnya saat menulis perender, dan juga membuat daftar fitur yang kami ingin miliki untuk MVP untuk memfokuskan upaya kami pada diskusi ini dalam keadaan awal ini untuk memulai percakapan yang lebih dalam tentang implementasinya.

Ada update perkembangannya?

Belum. Saya memberikan prioritas ke WebVR bulan ini.

Saya mencoba konversi cepat di tempat ke bahasa shader WebGL2 dan ES3, seperti yang disarankan oleh @fernandojsg di atas. Inilah perbedaan yang terjepit: https://github.com/tstanev/three.js/compare/master...tstanev :traian/webgl2 Sebenarnya, itu tidak terlihat seburuk yang saya harapkan pada awalnya. Tampaknya tidak terlalu buruk untuk mendukung keduanya melalui beberapa ifdef yang ditempatkan secara strategis.
[Sunting: Tautan yang diperbarui.]

@tstanev Apakah Anda memiliki contoh kerja?

Contoh three.js yang dibundel di cabang tertaut berfungsi (seperti yang Anda lihat di diff, saya mengonversi yang memerlukan ekstensi sebelumnya). Anda dapat mengkloning repo/cabang dan menjalankannya secara lokal.

@tstanev Bagaimana membuat perbandingan kinerja untuk perubahan webgl2 online?) Akan menyenangkan untuk melihatnya. (three.js vs three.js di webgl2)

Hai
terima kasih untuk ide terbaik ini.
Saya ingin menggunakan webgl2renderer dalam program saya, tetapi saya tidak dapat menggunakannya dalam versi prakompilasi (r86) jadi saya mendapatkan sumber dan menghapus komentar webgl2rendrer di three.js mengimpor dan kemudian membangunnya.
sekarang kode saya dan contoh Anda (webgl2-sandbox) akan berjalan tanpa kesalahan tetapi tidak menunjukkan apa-apa

EDIT: Saya telah mengujinya di firefox 54 dan chrome 60
contoh saya menggunakan bufferGeometry dan ShaderMaterial dan akan berfungsi dengan benar di webglrenderer

tidak ada yang menjawabku? apa masalah webgl2renderer sekarang?

@MHA15 mungkin itu tidak termasuk dalam build karena belum siap untuk produksi.

Hai teman-teman, bagaimana perkembangan WebGL2Renderer?
Saya tahu bahwa keputusan dibuat untuk membuatnya kembali dari awal. Tapi itu sudah lama dan perkembangannya agak lambat pada topik ini karena saya percaya itu adalah pekerjaan yang sangat besar untuk membuatnya kembali.

Pada titik ini, dapatkah kita mempertimbangkan kembali untuk membuat tiruan WebGLRenderer dan mengubahnya menjadi WebGL2 seperti yang dilakukan @mattdesl di https://github.com/mrdoob/three.js/issues/8125 ?? Kami kemudian dapat memodifikasi penyaji berdasarkan beberapa fitur baru seperti UBO seperti yang dikatakan @fernandojsg . Akhirnya, kami akan menghapus semua kode lawas webgl 1 tersebut.

Menurut pendapat saya, membuat penyaji dari awal membutuhkan banyak pekerjaan dan idealnya hanya dapat dimulai dengan beberapa kontributor. Percakapan ini dimulai setahun yang lalu. Dan kecuali kita sampai pada titik kita memiliki penyelamat yang akan menghabiskan beberapa bulan penuh waktu membangunnya dari awal, saya yakin kita mungkin akan berada di halaman yang sama tahun depan.

Menurut pendapat saya, membuat penyaji dari awal membutuhkan banyak pekerjaan dan idealnya hanya dapat dimulai dengan beberapa kontributor.

Bahwa itu benar. Tetapi meskipun demikian, saya pikir itu lebih mudah daripada membuat WebGLRenderer lebih sulit untuk dipertahankan dengan menambahkan persyaratan di mana-mana. Saya telah menghabiskan sebagian besar dari 5 tahun terakhir saya mencoba membuat WebGLRenderer lebih mudah dibaca dan dipelihara.

Juga, saya pikir @fernandojsg berencana untuk mencobanya dalam beberapa minggu mendatang.

Itu luar biasa. Menantikan karya hebat dari @fernandojsg!!

PS Saya harus mengatakan.. Terima kasih semua kontributor proyek ini untuk memperluas cakrawala saya tentang grafik komputer. Berharap saya akan dapat memberikan beberapa contoh di masa depan.

Saya setuju dengan @mrdoob bahwa akan lebih mudah untuk membuat perender baru dari awal daripada memodifikasi yang sekarang.
Seperti yang dia katakan, saya ingin mencobanya di minggu-minggu berikutnya. Pendekatan saya adalah mulai membuat apa yang diperlukan untuk kotak sederhana di layar dan terus menambahkan fitur ke dalamnya selangkah demi selangkah, alih-alih mengambil apa yang sudah ada dan mencoba memfaktorkannya kembali.
Sebagai contoh, lihat saja keadaan WebGLRenderer saat ini, ada banyak diskusi tentang membuatnya lebih modular dan dapat disesuaikan, tetapi bahkan jika kode internal terus meningkat dari waktu ke waktu, di luar sana itu hanya kotak hitam.
Segera setelah saya memiliki sesuatu yang berfungsi, saya akan membuka PR sehingga kami dapat terus mendiskusikan langkah selanjutnya di sana.

Sementara kita melakukannya... 5f889ce296aaf447ec5992a6df726691098a9110 8aab6e0382cd6ba8fd3fb943e7f65141bf3a50bc
webgl2_sandbox berfungsi lagi (memerlukan modul es6).

@mrdoob apakah Anda memiliki perkiraan kasar kapan akan tersedia di master/rilis? :) Saya senang itu terjadi! :)

@wdanilo Tidak juga... Fitur apa dari WebGL2 yang Anda butuhkan?

@mrdoob peningkatan terbesar akan datang dari Uniform Buffer Objects dan Sampler2DArray. Array tekstur akan sangat bermanfaat untuk proyek saya saat ini karena kami menghadapi batas unit tekstur karena saya menggunakan shader kompleks yang melapisi banyak bahan yang ditutupi oleh peta alfa.

@mrdoob Kata kunci baru seperti flat di glsl juga akan sangat membantu.

Proyek saya membutuhkan tekstur 3D.

Menarik...
Sangat membantu untuk mengetahui kasus-kasus tertentu yang dibutuhkan orang untuk WebGL 2.0.
Jauhkan mereka datang!

Tekstur 3D juga merupakan fitur besar bagi kami. Saya pikir kami juga menggunakan beberapa fitur shader.

Terkadang saya ingin MRT

+1 untuk beberapa target render juga

Beberapa target render sudah didukung di WebGL1 melalui ekstensi, dan bahkan ada PR untuk itu di ThreeJS: https://github.com/mrdoob/three.js/pull/9358 ( demo ).

Saya pikir target render multisampel adalah fitur favorit saya. Sebagian besar klien meminta pasca-pemrosesan (bloom, LUT, dll) tetapi mereka kecewa dengan kurangnya anti-aliasing yang tepat setelah pos FX diimplementasikan. Dengan target render MSAA, kami akhirnya dapat memiliki _dan_ adegan pasca-pemrosesan anti-alias yang bagus.

Saya setuju. Solusi shader untuk anti aliasing pada adegan pascaproses dengan komposer efek tidak cukup untuk anti aliasing yang sebenarnya.

+1 untuk umpan balik undian. Atau sudah didukung sebagai ekstensi webgl1 di
tiga?

Pada Kam, 14 Des 2017 jam 21:45 Kyle [email protected] menulis:

Saya setuju. Solusi shader untuk anti aliasing pada adegan pasca-proses
dengan efek komposer tidak cukup untuk anti aliasing sejati.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/mrdoob/three.js/issues/9965#issuecomment-351815640 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AHTX1RhYdGuTVSpmOy1ka-6gy1eslHQAks5tAXrFgaJpZM4Kj_9l
.

Saya punya beberapa kasus penggunaan di sini:

1. Saya membutuhkan MRT - saat ini saya sedang merender shader yang sama 4 atau 5 kali, mengubah atribut hanya untuk mendapatkan buffer yang berbeda.
2. Merender ke tekstur dengan antialiasing adalah fitur penting bagi kami - kami membuat "editor simpul" dengan pratinjau visualisasi. Setiap visualisasi hanyalah tekstur yang kami gambar juga dan tidak ada antialiasing yang tepat yang menyebalkan di sini.
3. Kata kunci "flat" - Saya sekarang mengindeks geometri dengan atribut float, yang jelas kurang optimal - lebih buruk daripada mengindeks dengan uint one. Saya meneruskan atribut ini dari vertex ke fragment shader dan saya tidak dapat menggunakan uint sekarang, karena kami kekurangan dukungan kwrd "datar".
4. (lebih kecil) Tekstur 3D sangat bagus untuk visualisasi kelas atas yang ingin kami dukung dalam waktu dekat.

Menggunakan anti-aliasing dan pasca-pemrosesan bersama adalah yang paling penting bagi saya.

@mrdoob 3 Fitur WebGL 2 teratas saya/Kasus penggunaan (dalam urutan kepentingan):

1. Target Render Multisampled: Untuk (MS)AA yang tepat dalam pasca-pemrosesan.
2. Integer Textures: Untuk melakukan algoritma berbasis gambar seperti Signed Distance Fields, serta menggunakan data berbasis tekstur yang lebih eksotis seperti DEM (Digital Elevation Models).
3. Transformasi Umpan Balik: Untuk melakukan sistem partikel.

@mrdoob omong-omong, tahukah Anda mengapa #9358 PR tidak digabung? Seperti yang ditulis @mattalat , ini membawa rendering multitarget ke threejs. Dilakukan 2 tahun yang lalu, diperbaiki beberapa kali untuk mengikuti perubahan lain dan sampai sekarang tidak ada :(

Saya menanyakannya karena saya memiliki adegan yang banyak menggunakan deskripsi bentuk SDF. Setiap bentuk menghasilkan 6 keluaran yang berbeda, jadi sekarang saya menghitungnya 6 kali dengan meneruskan ke angka shader dari 0 hingga 5. Akan jauh lebih baik menggunakan keluaran mutliple dan itu akan memberikan peningkatan kinerja 5x saja.

@wdanilo Itu mungkin bukan waktu yang tepat (banyak hal bergerak di penyaji saat itu). Juga, sepertinya itu termasuk build yang menyebabkan konflik dengan mudah. Ada yang mau ngerjain PR baru?

/cc @edankwan

Kami membutuhkan target Tekstur 3D dan Render Multisampel.

Saya ingin menggunakannya sehingga saya dapat mengatur depthTexture.type = THREE.FloatType.. kecuali ada cara lain untuk saat ini melakukan hal seperti itu.

Apakah ada harapan bahwa LineThickness selain 1 akan bekerja pada Windows dan WebGL 2.0 ? Jika ya, itu akan meningkatkan beberapa output kami.

Dan di sini saya membalas diri saya sendiri. Membaca bahan dasar ketebalan-garis-menggunakan-tiga-garis pada SO Saya mengerti bahwa garis tebal akan membutuhkan geometri di masa depan.

@Richard004 Ini tidak ada hubungannya dengan WebGL 2. Kami sudah memiliki PR untuk permintaan fitur ini, lihat #11349 👍

Hai @mrdoob dan @Mugen87
Saya perlu manipulasi bit di dalam shader fragmen serta pengindeksan array dinamis. Yang pertama mungkin tidak terlalu umum, tetapi saya membutuhkannya karena saya mencoba mem-port kernel CUDA ke WebGL (GLSL) dan bahasa shader lainnya memungkinkan manipulasi bit, tetapi WebGL 1.0 (GLSL) tidak.

Yang kedua saya pikir banyak pengembang dapat mengambil manfaat dari: yaitu, mengakses elemen array dengan variabel. Saat ini di WebGL 1.0 (GLSL), program seperti ini akan gagal:

int myData[200];
int x = 3; // 'x' might change later based on my lookup needs
int requestedData = myData[x];

Namun di WebGL 2.0, Anda dapat melakukan ini. Ini sering diperlukan di dalam sebuah loop, di mana Anda perlu mendapatkan nilai yang berbeda dari sebuah array, tetapi Anda tidak bisa hanya melakukan loop berulang (0 hingga 199 dalam contoh di atas misalnya), karena Anda perlu memeriksa setiap elemen dan itu sangat lambat.

Antialiasing di Postprocessing pasti akan bermanfaat.

Di bawah semua ini adalah pertanyaan: apakah sudah waktunya untuk arsitektur baru untuk Tiga?

Saya baru-baru ini mulai menggunakan D3, versi 4. Itu adalah desain ulang yang lengkap . Es6
modul. Dan jauh lebih penting, 30 modul, yang masing-masing adalah miliknya sendiri
repo. Saya sangat merekomendasikan melihat arsitektur D3.

Saya tidak mengatakan kami membutuhkan ini untuk Tiga, tetapi saya pikir kami dapat mempertimbangkan a
benjolan versi utama. Sebagian karena webgl2. Tetapi juga karena kebutuhan untuk
sub-modul.

Contoh: Ada repo/sub-modul "seleksi" D3. Ini dasar Anda
modul jQuery DOM tetapi dengan semua verbositas DOM yang tersembunyi di a
fungsional, desain rantai. Itu dapat digunakan apa adanya tanpa menggunakan sisa
D3.

Tidakkah Anda menyukai modul Tiga independen yang membuat semua webgl
verbositas menghilang? Bahkan mungkin beberapa sub-modul untuk webgl ctx/shader
manajemen, manajemen buffer, dan sebagainya. Memang, geometri buffer adalah
banyak seperti ini. Ditto untuk pembuatan shader dari bagian.

Hanya pemikiran saja.

@fetox74 Cukup yakin Anda sudah bisa melakukan AA https://threejs.org/examples/?q=fxaa#webgl_postprocessing_fxaa

@elunty FXAAShader tidak menghasilkan hasil yang cukup baik dibandingkan dengan antialiasing asli, saya telah menggunakannya di alam liar.

saya sebagian besar tertarik pada VAO dan menulis ke mipmaps yang saya harap dimungkinkan di bawah spesifikasi itu.

@pailhead Terkait #8705 :wink:

Menantikan dukungan asli untuk EXT_shader_texture_lod .
Ini dapat menyelesaikan artefak yang dihasilkan saat menggunakan MeshStandardMaterial dan MeshPhysicalMaterial di sebagian besar perangkat Android dan MS Edge dan Internet Explorer

@mrdoob apakah ada rencana dari Anda atau tim Anda untuk memperbarui Threejs ke Webgl 2.0? Utas ini membutuhkan waktu bertahun-tahun dan tidak ada yang benar-benar berubah sementara semua kerangka kerja lainnya sudah bergerak maju. Saya akan segera mengambil keputusan sulit, kami mungkin harus pindah ke Babel atau semacamnya dan saya benar-benar ingin tinggal bersama Three. Saya akan, jika ada, sembarang rencana untuk modernisasinya.

@wdanilo jika WebGL 2.0 adalah prioritas untuk proyek Anda, saya akan merekomendasikan Anda untuk bermigrasi ke Babel. Saya tahu beberapa kontributor three.js berencana untuk mengerjakannya, tetapi saya pribadi fokus pada alur kerja WebVR dan artis (dukungan SVG, dll).

@mrdoob Saya sangat menghargai jawaban cepat Anda di sini. Saya benar-benar ingin tidak meninggalkan three.js. Saya suka bagaimana lib dibangun di bawah tenda dan asumsinya sebagai kerangka kerja "umum", bukan "berfokus pada permainan", dll. Bagaimanapun, terima kasih atas informasinya dan jelaskan ini.

(Terima kasih sekali lagi @takahirox , saya mengetahui utas ini). Saya baru saja membuat permintaan tarik #13692. Saya mengerti bahwa fokusnya bukan pada itu tetapi untuk tujuan kami, itu telah bekerja dengan baik.

Terkait #13702

Saya membuat cabang dasar WebGL2 mengikuti #9965 dan #12250

Repo: https://github.com/takahirox/three.js/tree/WebGL2Base
Contoh: https://rawgit.com/takahirox/three.js/WebGL2Base/examples/index.html

Anda dapat memulai WebGL2.0 + Three.js dengannya.

(Maaf bertentangan dengan pekerjaan @yoshikiohshima )

@mrdoob Bisakah kita memiliki cabang untuk WebGL2Renderer seperti three.js/dev-2.0? Atau bisakah kita menggabungkannya menjadi dev meskipun masih ada banyak kode duplikat antara untuk webgl1 dan untuk webgl2?

Saya baru mengetahui perkembangan masa lalu tentang masalah ini. @takahirox , dapatkah Anda merangkum strategi yang Anda ambil dan apa yang didukung oleh https://github.com/takahirox/three.js/tree/WebGL2Base? (dan sekali lagi maaf atas ketidaktahuan saya) tetapi saya tidak melihat perlunya banyak kode duplikat untuk mendukung WebGL2. Apa masalahnya?

@mrdoob Bisakah kita memiliki cabang untuk WebGL2Renderer seperti three.js/dev-2.0? Atau bisakah kita menggabungkannya menjadi dev meskipun masih ada banyak kode duplikat antara untuk webgl1 dan untuk webgl2?

Tidak yakin mengapa ini membutuhkan cabang baru. Mengapa ada kode duplikat?

Sepertinya tidak ada konflik. Ada dua tuntutan untuk WebGL2.0 sekarang.

1. Membuat WebGL2Renderer untuk mendukung fitur WebGL2.0 lengkap dan mengoptimalkan dengan baik
2. Menambahkan dukungan webgl2 ke WebGLRenderer yang ada. Tapi kami tidak sepenuhnya mendukung fitur WebGL2.0 di dalamnya dan tidak mengoptimalkan untuk WebGL2.0 karena kami tidak ingin membuat penyaji berantakan. Jadi pada dasarnya ini hanya untuk akses awal Three.js + WebGL2.0 + GLSL3.0

Milik saya untuk 1. Pekerjaannya untuk 2. Kami tidak memiliki kode duplikat dan tidak perlu membuat cabang baru untuk 2.

@takahirox Saya pikir akan lebih baik untuk bekerja di cabang yang sama untuk saat ini.

Jika Anda meningkatkan ...

https://github.com/mrdoob/three.js/blob/dev/src/renderers/WebGL2Renderer.js

dan contoh webgl2 mengimpor kelas secara langsung (tidak memerlukan build)...

https://github.com/mrdoob/three.js/blob/dev/examples/webgl2_sandbox.html#L39 -L47

seharusnya tidak ada konflik.

Anda dapat melupakan WebGL2Base saya sejauh ini karena sepertinya kami memulai dukungan WebGL2.0 dalam satu WebGLRenderer .

Apakah kita masih berpikir untuk mengimplementasikan WebGL2Renderer?
Saya telah mencari banyak akhir-akhir ini untuk menambahkan dukungan WebGL2, dan saya menunggu perubahan takahirox untuk rebase milik saya. Tetapi setelah melakukan beberapa perubahan, saya mulai berpikir bahwa menulis ulang penyaji akan menjadi ide yang sangat bagus, begitu juga dengan objek WebGLTextures. Jika masih topikal, saya akan senang untuk berpartisipasi.

Saya pikir begitu ya. Saya pikir menambahkan dukungan webgl 2.0 dasar ke WebGLRenderer saat ini hanya untuk memiliki sesuatu saat kami mengerjakan WebGL2Renderer .

Jangan ragu untuk mulai menulis ulang penyaji dan mengirim PR (idealnya selangkah demi selangkah).

Maaf jika menanyakan yang sudah jelas, tetapi setelah membaca seluruh masalah ini, dengan posting terakhir setengah tahun yang lalu, dan menemukan beberapa referensi ke webgl2 baik dalam kode sumber utama dan contoh, sepertinya saya masih tidak dapat memahaminya .

Ingin tahu apakah webgl2 dapat digunakan dalam kondisi saat ini di Three.js? (bahkan jika hanya merender mesh buffergeometry sederhana) Akankah EffectComposer bekerja dengan perender yang mendukung konteks webgl2? Apakah target render harus disesuaikan dengan cara apa pun?

Pertanyaan terbesar, tentu saja, apakah saat ini mungkin untuk mendapatkan antialiasing yang tepat saat menggunakan komposer dengan pass khusus?

Sepertinya pada akhirnya kita baru saja menambahkan fitur WebGL 2.0 ke WebGLRenderer .
WebGPU pasti akan membutuhkan WebGPURenderer sekalipun.