Ini terlihat sangat bagus!

Omong-omong, kami berencana untuk menghapus THREE.GLTFLoader dan mengganti nama GLTF2Loader → GLTFLoader waktu dekat*. Mungkin ide yang baik untuk mengganti nama eksportir sebagai GLTFExporter sebelum r87 mendarat, untuk menghindari kebingungan sehingga tidak akan ada perubahan nama yang diperlukan di antara rilis. Ups, saya rindu Anda sudah menamakannya seperti itu .. lanjutkan! 😆

* @mrdoob , ada preferensi kapan itu harus terjadi? IMO kita bisa melakukan ini sekarang, kecuali jika kita ingin menyimpan GLTFLoader di r87 hanya dengan peringatan penghentian, dan menghapusnya di r88?

Saya pikir lebih cepat lebih baik. Selama GLTFLoader yang baru mampu mendeteksi 1.0 dan memperingatkan pengguna bahwa kami hanya mendukung 2.0+.

IIRC dapat kita deteksi dengan melihat asset seperti yang saya sebutkan sebelumnya.

IIRC dapat kita deteksi dengan melihat aset seperti yang saya sebutkan sebelumnya.

Ya! https://github.com/mrdoob/three.js/pull/11864

Dingin! Tapi saya menemukan bug kecil. Aku sedang mengerjakan PR sekarang. Mari kita gabungkan sebelum kita mengganti nama.

Bisakah kita menentukan item yang sedang dikerjakan seseorang di daftar periksa?

@takahirox yakin! orang hanya bisa menulis komentar di sini dan saya bisa memperbarui daftar dan menunjuk ke PR jika sudah ada sesuatu yang terjadi

Hal berikutnya yang akan saya kerjakan adalah pada tekstur, untuk mengubahnya menjadi base64 daripada hanya menggunakan url

Terima kasih! Saya ingin membantu membuat eksportir glTF. Saya mencari apa yang bisa saya bantu di daftar periksa ...

BTW apakah Anda dengan sengaja membiarkan dua variabel WEBGL_CONSTANTS dan THREE_TO_WEBGL global?

@takahirox keren!
Mengenai dua variabel, ini adalah sesuatu yang akan saya bahas dalam PR berikut untuk menjadikannya bagian dari WebGLUtils dan hanya mengimpornya. Tidak masuk akal bahwa masing-masing yang membutuhkan konstanta ini perlu mendefinisikannya kembali setiap saat.

@takahirox btw jangan ragu untuk mengusulkan item baru ke daftar tentu saja! ;)

@fernandojsg Tentu! Tentang variabel, saya ingin mengusulkan untuk memindahkannya ke suatu tempat jika mereka sengaja dideklarasikan sebagai global jadi senang mengetahui bahwa Anda melakukannya.

Saya ingin mengerjakan tampilan buffer bersama.

BufferViews: Saat ini saya sedang membuat bufferView baru untuk setiap Accessor, ini harus diperbaiki agar hanya menggunakan satu untuk atribut ini yang memiliki componentType yang sama

Alasan mengapa satu untuk atribut yang memiliki componentType yang sama, bukan satu untuk semua atribut, adalah untuk penyelarasan data, benar?

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#data -alignment

Keren, saya baru saja menambahkan Anda ke daftar 👍 Ya, pada dasarnya Anda ingin berbagi tampilan buffer yang sama untuk komponen dengan tipe yang sama, misalnya jika Anda memiliki posisi dan normal, Anda akan memiliki dua pengakses VEC3 tetapi mereka akan menunjuk ke tampilan buffer yang sama. Itu bisa menjadi titik awal yang bagus ;)

Maksud saya, alasan mengapa kami tidak membiarkan tampilan buffer dibagikan di antara componentType yang berbeda (mis: float dan short) adalah untuk menjaga keselarasan data yang baik, benar?

Saya yakin Anda dapat menyimpan dalam tampilan buffer yang sama jenis komponen yang berbeda selama mereka memiliki target , misalnya normal (Vec3) , position (Vec3) dan uv (Vec2) bisa berada dalam tampilan buffer yang sama tetapi indices tidak. @donmccurdy dapatkah Anda mengonfirmasinya?

Ya, setuju. Dan seperti yang disebutkan oleh spesifikasi glTF ini

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#data -alignment

Offset pengakses ke bufferView (yaitu, accessor.byteOffset) dan offset pengakses ke buffer (yaitu, accessor.byteOffset + bufferView.byteOffset) harus kelipatan dari ukuran jenis komponen pengakses.

Sebaiknya kita memisahkan tampilan buffer antara componentType(=tipe data yang berbeda seperti float dan short, bukan vec2 atau vec3) untuk kesederhanaan. Jika kita memisahkannya di antara tipe komponen panjang data yang berbeda, itu akan lebih dioptimalkan.

BTW apakah ada alasan khusus mengapa eksportir saat ini hanya mendukung accessor.componentType float, uint, dan ushort? glTF 2.0 dapat menangani char, uchar, dan short, selain itu.

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#accessorcomponenttype -white_check_mark

@takahirox tidak juga, saya baru saja mendefinisikan ini sekarang karena yang digunakan untuk jenis atribut yang kami dukung saat ini (posisi, normal, warna, uvs, indeks ..).
Langkah selanjutnya yang saya kerjakan adalah teksturnya jadi di sana kita akan membutuhkan yang lain seperti uchar misalnya

OK, jadi pertama-tama saya akan mengerjakan accessor.componentType s kecuali jika Anda sudah mulai mengimpl.

Hampir siap tetapi PR saya harus bertentangan dengan #11978.
Jadi saya mengirim milik saya setelah #11978 digabungkan dan saya memperbaiki konfliknya.

Apakah Anda akan menambahkan animasi ke dalam daftar?

@takahirox yakin, itu bagus untuk menambahkan animasi. Saya hanya tidak menambahkannya karena saya tidak cukup akrab dengan keadaan fitur animasi saat ini di three.js, tetapi jika Anda ingin mengambil alih, itu akan bagus ;)

Apakah Anda berencana untuk mendukung grup BufferGeometry?
Apakah spesifikasi GLTF mencakup itu atau akan menghasilkan pembuatan Mesh baru untuk setiap grup?
Ini juga harus diperhatikan, properti material dari Mesh menjadi susunan material.

@marcatec Spesifikasi glTF memang memiliki perbedaan "mesh" vs. "primitif" yang memungkinkan Anda membuat grup BufferGeometry yang masing-masing dapat mereferensikan materi yang berbeda. Saat ini THREE.GLTFLoader tidak mengoptimalkan pemuatan primitif — ini membuat jerat terpisah — tetapi itu bisa diimplementasikan.

Kerja bagus, daftar bagus, dan senang mengetahui bahwa sudah ada begitu banyak dukungan pada format! Juga bekerja sangat baik bersama dengan eksportir blender gltf juga. Tidak bisa menunggu dukungan lampu! Pertahankan pekerjaan hebat.

Saya setuju, kerja bagus!

Apakah ada rencana untuk menambahkan dukungan untuk material lain selain StandardMaterial?

Terima kasih!

@homerjam properti material apa pun yang dibagikan dengan MeshStandardMaterial akan dipertahankan — jadi misalnya, MeshPhongMaterial menggunakan map dan normalMap akan mengekspor dengan tekstur tersebut utuh, tetapi ketika Anda mengimpornya kembali ke three.js akan menjadi MeshStandardMaterial. Eksportir saat ini melakukan konversi naif ke PBR untuk ini.

Dukungan pulang-pergi (ekspor Phong dari GLTFExporter, muat Phong dari GLTFLoader) akan memerlukan pekerjaan yang sedang berlangsung pada format glTF: https://github.com/KhronosGroup/glTF/pull/1150

baseColorTexture : Didukung (material.map) tetapi texCoord selalu disetel ke 0

@fernandojsg dapatkah Anda mengklarifikasi apa yang hilang di sini? Karena .map selalu merupakan set UV pertama di three.js, ini terdengar seperti cara yang benar untuk merepresentasikannya di glTF?

Juga, saya mencoret tiga item dalam daftar. Alasan di bawah ini:

• garis singgung
  
  
  
  • three.js hanya menghitungnya di GPU; menambahkan implementasi hanya untuk eksportir terdengar tidak ideal.
  
  
• pengakses jarang
  
  
  
  • Saya pikir ini sebaiknya diserahkan ke pengoptimalan pasca-ekspor, seperti skrip mattdesl .
  
  
• periksa apakah materi cocok dengan default glTF dan hilangkan
  
  
  
  • terasa seperti kasus tepi / kekacauan, jangan ragu untuk menerapkannya jika seseorang merasa sangat kuat
  
  

Dengan mengekspor ke GLB dari editor, saya perhatikan bahwa alphaMap , roughnessMap dan metalnessMap tidak diekspor.

Di #13397 saya mengatakan normalMap tidak ada yang diekspor tetapi sepertinya saya salah.

Dengan mengekspor ke GLB dari editor, saya perhatikan bahwa alphaMap, roughnessMap, dan metalnessMap tidak diekspor.

Saya akan mengerjakan ini hari ini kecuali ada yang sudah memulai.

@donmccurdy

pengakses jarang
Saya pikir ini sebaiknya diserahkan ke pengoptimalan pasca-ekspor, seperti skrip mattdesl.

Merasa ingin membiarkan eksportir mendukung pengakses yang jarang untuk morph. Saya akan mencoba nanti.

@takahirox keren! lanjutkan!

Saya rasa alphaMap tidak didukung di glTF 2.0.

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#material

Ya, saya takut itu.... Bagaimana dengan metalnessMap dan roughnessMap ?

Saya sedang mengerjakannya sekarang!

13415

Mengenai format gambar. glTF 2.0 hanya mendukung .png dan .jpg sebagai file gambar eksternal. Saya sedang mempertimbangkan cara menangani file format gambar yang tidak didukung (misalnya: .bmp) pada mode non embedImages .

1. Konversikan ke .png atau .jpg dan sematkan
2. Tidak peduli. Ekspor sebagai file gambar asli
3. Jangan ekspor

Saya lebih suka 1. Ada pendapat?

Wow, sangat menghargai karya-karya kalian.

Semoga Multi-material meshes segera diimplementasikan karena sebagian besar model 3D menggunakan Multi-material.

1. Konversikan ke .png atau .jpg dan sematkan
2. Tidak peduli. Ekspor sebagai file gambar asli
3. Jangan ekspor

Saya memilih 3 dan mencatat peringatan di konsol.

Berharap mesh Multi-material akan segera diimplementasikan karena sebagian besar model 3D menggunakan Multi-material.

Setuju, bagi saya ini adalah masalah nomor satu yang mencegah penggunaan eksportir.

Berharap mesh Multi-material akan segera diimplementasikan karena sebagian besar model 3D menggunakan Multi-material.

Seperti yang saya katakan di utas lain, saya sedang mengerjakannya.

1. Konversikan ke .png atau .jpg dan sematkan
2. Tidak peduli. Ekspor sebagai file gambar asli
3. Jangan ekspor

Saya memilih 3 dan mencatat peringatan di konsol

Ya, saya berpikir 3. akan lebih sederhana dan tidak membingungkan pengguna. Mendapatkan gambar yang disematkan pada mode non emedImages akan sedikit membingungkan.

Alasan mengapa saya lebih memilih 1. adalah untuk mengonversi dari format lain ke glTF. Beberapa (atau banyak) format lain tidak memiliki batasan format gambar.

Eksportir mengonversi pada mode embedImages . Jadi menambahkan "gunakan opsi embedImages jika Anda ingin mengonversi" ke peringatan konsol akan baik, saya pikir.

Aku akan pergi juga untuk 3 juga. Karena mengonversi dari format lain bisa jadi membosankan, dan Anda tetap harus memprioritaskan beberapa format dibandingkan format lainnya. Mungkin layak untuk melakukan 3 sekarang dan menunggu untuk melihat apakah gltf menambahkan dukungan ke format tekstur baru seperti ktx atau lebih dan kami dapat meninjau kembali implementasinya.

Seperti yang dibahas di https://github.com/mrdoob/three.js/pull/13415#issuecomment -369022383, alangkah baiknya jika eksportir dapat membuat tekstur ambientRoughnessMetalness untuk pengguna. Mungkin lebih baik menempatkan kode itu di ImageUtils .

Saya telah memperbarui daftar periksa dengan perubahan terbaru. Saya telah menambahkan @takahirox ke multimaterial , dan saya akan mengambil sendiri tugas pembuatan gambar.
Saya telah menambahkan juga ekstensi material_unlit, meskipun masih dalam draf, saya yakin itu cukup dekat untuk dirilis dan tidak akan banyak berubah (/ cc @donmccurdy)

Berharap mesh Multi-material akan segera diimplementasikan karena sebagian besar model 3D menggunakan Multi-material.

Seperti yang saya katakan di utas lain, saya sedang mengerjakannya.

WIP... (Miku memiliki multi-bahan)

Tentang format gambar yang tidak didukung, oke mari kita ke 3.

@takahirox terlihat bagus! 👍

BTW, apakah Anda tertarik dengan dukungan arsip zip? .glTF + .bin eksternal dan tekstur akan cocok untuk alat pembuat lainnya (mungkin), tetapi sulit dilakukan dengan non-arsip. Jadi arsip zip akan diperlukan. Dan kita dapat mengurangi ukuran file yang diekspor.

Saya menginginkannya dan mencoba di cabang lokal saya sebelumnya, saya dapat membagikannya nanti jika Anda tertarik.

Bukankah itu hampir sama dengan gzip glb?

.glTF + .bin eksternal dan tekstur akan sesuai dengan alat pembuat lainnya (mungkin)

Saya harap alat pembuat tidak memerlukan file terpisah; kami mendorong semua orang untuk menggunakan GLB secara default. Tetapi lebih mudah untuk mengedit gambar dengan tangan jika tidak disematkan, pasti.

Tidak ada pendapat yang kuat tentang apakah kita ingin menempatkan fungsionalitas itu ke dalam THREE.GLTFExporter secara langsung... tetapi saya hampir berpikir bahwa kita seharusnya tidak memiliki terlalu banyak opsi yang bisa menjadi pasca-optimasi pada glTF. Contoh lain, Draco agak rumit dan memerlukan beberapa file eksternal, jadi mungkin lebih baik membiarkan alat glTF-ke-glTF khusus melakukan pengoptimalan itu? Dan juga kita bisa membuat glb-unpacker (kebalikan dari http://glb-packer.glitch.me/) untuk membantu orang membongkar file dari GLB ke ZIP jika kita mengetahui bahwa orang membutuhkannya.

Dari https://github.com/KhronosGroup/glTF/issues/1256 —

... maksud asli dari gltf-pipeline - dan benar-benar glTF secara umum - membuat eksportir sesederhana mungkin dan mendorong pengoptimalan ke alat umum. Ini juga akan, tentu saja, membantu dengan fragmentasi.

yang mengatakan, belum ada glb-unpacker yang saya ketahui ...

@mrdoob

Saya ingin gambar tekstur menjadi eksternal, bukan .glTF vs .glb.

@donmccurdy

Saya menindaklanjuti diskusi https://github.com/KhronosGroup/glTF/issues/1117 dan setuju dengan mendorong .glb + file yang disematkan dan pendekatan pipa sekarang. Satu .glb bagus untuk transmisi data terutama untuk web dan pendekatan pipeline dapat membuat eksportir dan alat tetap sederhana dan dapat digunakan kembali. (Saya juga menyukai pendekatan pipa perintah UNIX/Linux!)

Jadi saya rasa eksportir tidak memerlukan dukungan arsip zip sekarang. Dan mungkin juga tidak membutuhkan sparse accessor dan draco support karena alasan yang sama.

Mengenai glb-unpacker, saya mungkin akan membuatnya di waktu luang saya. Saya rasa beberapa artis menyukai file .glTF + eksternal karena dapat dibaca tanpa alat khusus glTF. Dan terkadang file eksternal dapat mengurangi waktu pemuatan karena memuat file secara paralel sehingga dapat digunakan untuk tujuan optimasi.

Mengenai alat pipa/optimasi, saya ingin mencatat bahwa kami tidak ingin mentransfer data besar melalui jaringan. Pengguna ingin mengoptimalkan/kompres sebelum ~mengubah~ mentransfer data. Jadi layanan web pengoptimalan glTF terkadang tidak berfungsi dengan baik untuk data yang besar karena pengguna perlu mengirim file besar ke server.

Plus, untuk Three.js dan mesin berbasis browser JavaScript lainnya, kami akan senang jika kami memiliki alat pengoptimalan glTF yang berjalan di browser. Kami dapat mengoptimalkan/kompres sebelum data diteruskan ke pengguna. Tanpa mereka, pengguna perlu mengunduh data yang diekspor secara manual dan kemudian meneruskannya ke alat pipa karena keterbatasan browser.

Dari sudut pandang ini, saya ingin alat dapat berjalan di mana saja, di browser, di server, CUI, dan sebagainya, agar lebih umum dan dapat digunakan kembali. Kami tidak ingin membuat alat tujuan yang sama dua kali atau lebih untuk platform yang berbeda. Jadi alat berbasis node.js akan bagus? Apakah tim glTF (pipa) punya saran? (Mungkin diskusi ini harus dilakukan di glTF, bukan di sini.)

Untuk jaga-jaga, dalam GLTFLoader dukungan biner diimplementasikan sebagai ekstensi tetapi .glb dalam spesifikasi inti glTF 2.0, benar?

Untuk jaga-jaga, dalam dukungan biner GLTFLoader diimplementasikan sebagai ekstensi tetapi .glb dalam spesifikasi inti glTF 2.0, benar?

Ya, itu adalah ekstensi di glTF 1.0 dan saya tidak pernah memindahkan atau mengganti nama kode itu setelah menjadi bagian dari spesifikasi inti glTF 2.0.

Dari sudut pandang ini, saya ingin [alat pengoptimalan] dapat berjalan di mana saja, di browser, di server, CUI, dan sebagainya, agar lebih umum dan dapat digunakan kembali. Jadi alat berbasis node.js akan bagus? Apakah tim glTF (pipa) punya saran? (Mungkin diskusi ini harus dilakukan di glTF, bukan di sini.)

Sebaiknya tanyakan tentang peta jalan glTF-Pipeline ... tidak yakin seberapa umum mereka menginginkan glTF-Pipeline, atau apakah itu terutama untuk penggunaan Cesium, atau apakah itu hanya masalah waktu pengembang yang terbatas. Juga glTF-Toolkit terlihat relevan, tetapi (saat ini) hanya berjalan di Windows. Saya pribadi suka Node.js tetapi C++ atau Rust bisa menjadi pilihan yang masuk akal dengan kompilasi ke WASM.

Oh, saya melewatkan kompilasi ke WASM. Menentukan beberapa platform dev yang direkomendasikan akan bagus untuk optimasi devs. Jadi saya akan mengusulkan ke utas yang sesuai.

Saya setuju dengan @donmccurdy karena saya merasa optimasi ini pada pipeline dapat hidup dalam repo yang berbeda dari three.js, sehingga semua orang dapat mengambil manfaat darinya. Saya masih perlu memeriksa perbedaan antara pipa gltf dan alat toolkit, tetapi saya berharap fitur semacam ini disertakan di dalamnya.
Saya juga setuju bahwa selama kita memiliki WASM, bahasa sumber tidak akan menjadi masalah, tetapi juga benar bahwa jika ditulis dalam node.js mungkin banyak komunitas di sekitar mesin web 3d dapat membantu meningkatkannya sebagai sekarang adalah target utama untuk format file ini pula.

Saya tidak yakin saya mengerti tentang "mengoptimalkan sebelum mengubah" ... ada beberapa jenis transformasi yang mungkin dilakukan pipa pada suatu model, dan pengoptimalan mungkin merupakan jenis transformasi yang paling umum?

Setuju lebih dari itu. Baik untuk memiliki alat tingkat rendah dan terfokus yang dapat digunakan untuk membangun alat lain atau dicolokkan ke GUI yang lebih ramah pengguna.

Ups, itu salah ketik. Bukan mengubah tapi mentransfer. Maksud saya, sebagian besar pengguna ingin mengoptimalkan/kompres sebelum mengirim data melalui jaringan. Saya telah memperbarui posting agar lebih jelas.

Halo kawan-kawan

Saya menggunakan THREE.js GLTF Exporter untuk mengekspor seluruh adegan aframe sebagai objek gltf.
Bagaimana saya bisa mendapatkan tag animasi yang ditentukan pada aframe untuk menjadi bagian dari animasi di objek gltf?

@donmccurdy @fernandojsg @mrdoob

Hai @siddhartpai — THREE.GLTFExporter hanya mengonversi objek THREE.AnimationClip menjadi animasi glTF, sedangkan sistem animasi A-Frame menggunakan TweenJS. Jadi saat ini tidak mungkin. Anda mungkin ingin membuka masalah pada A-Frame atau A-Frame Inspector, yang juga menggunakan GLTFExporter , untuk memintanya sebagai fitur di masa mendatang.

Dukungan multi-material #13536

Saya baru saja memperhatikan bahwa validator melempar kesalahan pada setiap elemen normal pada bufferview yang tidak dinormalisasi. misalnya Jika saya menyimpan nilai yang tidak diinisialisasi seperti [0,0,0] itu akan membuang kesalahan itu.
Karena ini adalah kesalahan dan bukan peringatan/pemberitahuan, saya melihatnya sensitif untuk diperbaiki. Apa pendapat Anda tentang memastikan elemen bufferview normal dinormalisasi? Meski begitu, untuk nilai yang tidak bisa dinormalisasi seperti [0,0,0], haruskah kita menggunakan vektor satuan yang valid? /cc @donmccurdy

Sepertinya NORMAL harus dinormalisasi.

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#meshes

NORMAL | "VEC3" | 5126 (FLOAT) | Normalisasi simpul XYZ yang dinormalisasi

Setuju dengan memastikan karena Three.js normal tidak memiliki batasan seperti itu.

Ya, tetapi apa yang harus dilakukan ketika Anda tidak memiliki normal yang sebenarnya, seperti nilai [0,0,0] yang tidak digunakan, buat saja yang valid dan tidak apa-apa? katakanlah [1,0,0]. Jadi kita harus memodifikasi kode bufferview untuk mendeteksi bahwa kita sedang mengurai atribut normal dan menormalkan masing-masing sebelum menyimpannya ke dataview.

apa yang harus dilakukan ketika Anda tidak memiliki normal yang sebenarnya, seperti nilai yang tidak digunakan [0,0,0]

Hm.... diganti dengan yang valid dan menampilkan peringatan?

Jadi kita harus memodifikasi kode bufferview untuk mendeteksi bahwa kita sedang mengurai atribut normal dan menormalkan masing-masing sebelum menyimpannya ke dataview.

Saya lebih suka melakukan itu di processMesh() karena akan lebih sederhana, seperti

var originalNormal = geometry.attributes.normal;

if ( hasNonNormalizedValues( originalNormal ) ) {

    geometry.attributes.normal = createNormalizedAttribute( originalNormal );

}

processAccessorHere();

geometry.attributes.normal = originalNormal;

Jika kita melakukannya di processBufferView() , kodenya akan menjadi sedikit rumit karena kita perlu berhati-hati jika data dibagi di antara atribut yang berbeda, misalnya posisi dan normal. (Saya tahu ini kasus penggunaan yang sangat jarang tetapi Three.js tidak membatasi.)

Ya saya suka pendekatan itu, saya takut untuk mengubah normal setelah mengekspor, tetapi seharusnya tidak masalah jika kita menyimpan referensi, pasang kembali setelah selesai. :+1: Maukah Anda mendorong PR dengan perubahan ini? atau ingin aku melakukannya?

Oke, saya akan melakukannya. (Apakah Anda terburu-buru untuk memperbaikinya?)

@takahirox keren, terima kasih! tapi jangan buru-buru saya hanya meninjau keadaan eksportir ^_^

Oke, kalau begitu aku akan melakukannya ~besok~ minggu ini.

Benar, glTF tidak mengizinkan untuk menghilangkan normal pada simpul tertentu tetapi tidak pada simpul lain dalam satu primitif. Kita perlu memberikan semacam nilai, menghapus simpul ini, atau melempar kesalahan.

Saya lebih suka membuat segalanya lebih mudah bagi pengguna sehingga suara saya adalah untuk membuat array normal baru yang menormalkannya dan menambahkan nilai (0,1,0) untuk yang kosong.

Sepertinya bagus. Jika lambat untuk model besar, kami mungkin menginginkan opsi checkNormals atau sesuatu seperti itu, sehingga pengguna yang tidak membutuhkan ini dapat memilih keluar, daripada memindai setiap simpul.

Ya, saya baru saja akan menulis hal yang sama! :D

Jika lambat untuk model besar, kami mungkin menginginkan opsi checkNormals atau semacamnya, sehingga pengguna yang tidak memerlukan ini dapat memilih keluar, daripada memindai setiap simpul.

Saya akan membuat PR tanpa opsi itu terlebih dahulu. Mari kita tambahkan bila/jika perlu. Secara pribadi saya kira pemeriksaan ini tidak terlalu lambat.

Saya akan membuat PR tanpa opsi itu terlebih dahulu. Mari kita tambahkan bila/jika perlu. Secara pribadi saya kira pemeriksaan ini tidak terlalu lambat.

Saya menormalkan seluruh buffer saat memuat setiap goresan pada a-painter dan itu cukup lambat

Bahkan jika hanya memeriksa apakah mereka dinormalisasi?

@takahirox Anda tetap harus menghitung panjangnya jadi saya kira itu tidak akan banyak berubah

HM Oke. Saya akan mengevaluasi dengan PR.

Ini adalah fitur GLTFExporter pertama yang kami perkenalkan yang melakukan perhitungan apa pun dengan setiap simpul (kecuali konversi target morf relatif/absolut) jadi ya berpotensi lebih lambat .. bagaimanapun juga.

Kerja bagus! IMHO harus digabung menjadi inti three.js, bukan dalam "contoh".
Akan senang melihat dukungan KHR_lights_punctual !

PR https://github.com/mrdoob/three.js/pull/15519 menambahkan KHR_lights_punctual. :)

Saya pikir masalah ini mungkin dapat diselesaikan — item yang tersisa adalah kenyamanan atau pengoptimalan yang kurang penting, dan dapat dilacak di tempat lain:

• [ ] menggunakan kembali tampilan buffer
• [ ] secara otomatis menggabungkan tekstur logam/kasar/ao

Hai teman-teman, adakah yang tahu bagaimana saya bisa mengekspor mesh berbentuk khusus dengan perubahan morf menerapkan morf dan menghapusnya dari objek akhir?
Sukai pertanyaan ini
Terima kasih sebelumnya!

@vini-guerrero Silakan gunakan forum (https://discourse.threejs.org/) atau Stack Overflow untuk bantuan, daripada masalah GitHub.