Three.js: Pindah ke arsitektur modular

Salah satu keuntungannya adalah bahwa ini akan menerapkan arsitektur modular untuk pengembangan berkelanjutan dari three.js.

Gaya umum di node/browserify membuat setiap file mendeklarasikan dependensinya di bagian atas, dan menganggap variabel global sebagai anti-pola.

Berikut adalah contoh cuplikan:

// src/geometry/BoxGeometry.js
var Geometry = require('./Geometry.js');
var Vector3 = require('../core/Vector3.js');
module.exports = BoxGeometry;

function BoxGeometry() {
  // ...
}

BoxGeometry.prototype = Geometry.prototype;

Keuntungan lainnya adalah konsumen three.js menggunakan browserify dapat memilih suku cadang yang mereka inginkan. Mereka hanya bisa mengimpor Scene , BoxGeometry , PerspectiveCamera , dan WebGLRenderer , mendapatkan dependensi untuk semua itu secara otomatis ( Object3D dll ), dan memiliki bundel kecil javascript yang hanya mendukung set fitur yang mereka inginkan.

Ini dapat dilakukan dengan cara yang tidak memaksakan perubahan yang melanggar. Di tingkat atas, kami akan mengekspor semua kelas yang kami anggap sebagai bagian dari paket standar

// src/three.js
var THREE = { rev: 101 }
module.exports = THREE

THREE.Geometry = require('./geometry/Geometry.js')
THREE.BoxGeometry = require('./geometry/BoxGeometry.js')
// ...

catatan: Saya tidak benar-benar membutuhkan dependensi di bagian atas dalam contoh ini, karena file ini hampir secara eksklusif membutuhkan pernyataan.

Akhirnya kami akan membungkusnya dalam Definisi Modul Universal yang mendeteksi jika sistem modul (node/browserify, AMD) sedang digunakan, dan jika demikian mengekspornya, atau menambahkannya ke objek global ( window ).

Mari kita tinjau:

• menerapkan gaya modular yang baik
• memungkinkan konsumen three.js menggunakan browserify untuk memilih dan memilih fungsionalitas
• tidak ada perubahan yang melanggar

Ini akan membutuhkan penggantian sistem build, tetapi yang baru akan cukup mudah.

Beberapa keuntungan lainnya:

• Anda dapat menyusun kode Anda
• Anda dapat membuat / menggunakan kembali modul tanpa mencemari namespace global
• Anda dapat membangun untuk produksi
• Anda dapat melakukan debug dengan lebih mudah karena setiap modul memiliki filenya sendiri, Anda tidak perlu mencari modul yang sesuai dalam file three.js yang besar

@shi-314 Saya kira saya sedikit bingung, saya merasa You can structure your code dan You can build for production adalah hal-hal yang dapat Anda lakukan tanpa perubahan arsitektur? Apakah Anda berbicara tentang sumber three.js atau hal-hal yang dibangun menggunakan three.js?

Salah satu praktik yang digunakan three.js yang membuatnya sulit untuk digunakan di lingkungan commonjs adalah penggunaan instanceof : https://github.com/mrdoob/three.js/blob/master/src/core/Geometry .js#L82

Ini karena dalam aplikasi Anda sering berakhir dengan versi berbeda dari pustaka yang sama di pohon sumber Anda, jadi memeriksa instanceof tidak berfungsi di antara versi berbeda dari pustaka yang sama. Akan lebih baik dalam persiapan untuk pindah ke sistem modul commonjs untuk menggantikan pemeriksaan instanceof tersebut dengan pemeriksaan fitur di belakang antarmuka gaya Geometry.isGeometry(geom) .

@kumavis Saya berbicara tentang hal-hal yang dibangun di three.js. Katakanlah Anda ingin membuat materi Anda sendiri dengan shader Anda, dll. Saat ini Anda perlu memperluas objek THREE global agar tetap konsisten dengan kode three.js lainnya:

THREE.MeshMyCoolMaterial = function (...) { ... }

Tetapi jika kami memiliki Browserify daripada yang dapat Anda lakukan:

var MeshLambertMaterial = require('./../MeshLambertMaterial');
var MeshMyCoolMaterial = function (...) {...}

Jadi namespace Anda tetap konsisten dan Anda tidak perlu menggunakan THREE.MeshLambertMaterial dan MeshMyCoolMaterial dalam kode Anda.

Dan dengan You can build for production pada dasarnya maksud saya sama dengan yang Anda sebutkan: allows three.js consumers using browserify to pick and choose functionality .

@shi-314 terima kasih, itu lebih jelas. Itu berdampak pada solusi umum yang saya usulkan untuk deserialisasi kelas yang ditentukan konsumen:

// given that `data` is a hash of a serialized object
var ObjectClass = THREE[ data.type ]
new ObjectClass.fromJSON( data )

Ini dari refactor serialisasi/deserialisasi yang saya usulkan
https://github.com/mrdoob/three.js/pull/4621

Performa seharusnya tidak terpengaruh oleh perubahan seperti ini.

Ini adalah perubahan yang cukup besar tetapi saya juga mendukungnya.

Beberapa keuntungan utama lainnya:

• Anda dapat menggunakan opsi standalone browserify untuk menghasilkan build UMD untuk Anda. Tidak perlu mengotak-atik secara manual dengan pembungkus UMD.
• Paket dapat dengan mudah dikonsumsi oleh pengguna browserify/NPM
• Menarik dependensi untuk threejs (seperti poly2tri, color-string , dll) menjadi lebih mudah
• Modul yang "tidak benar-benar milik" di perpustakaan rendering (seperti perpustakaan vektor/matematika) dapat ditarik sebagai modul NPM terpisah dan digunakan kembali untuk banyak jenis proyek lainnya. Salah satu manfaat utama dari ini adalah bahwa masing-masing modul memiliki repositori sendiri untuk bug/masalah, PR, dll (membersihkan masalah ThreeJS).
• NPM akan menangani versi semantik untuk kami. misalnya kita dapat mendorong perubahan yang melanggar di threejs-vecmath tanpa khawatir tentang pemecahan kode semua orang. Dan di sisi lain, jika kita membuat patch atau rilis minor pada modul tertentu, orang yang menggunakan modul tersebut akan bisa mendapatkan perubahan secara otomatis.
• Itu membuat "ekstra" seperti EffectComposer dan berbagai shader mudah dikemas dan dikonsumsi (bayangkan npm install threejs-shader-bloom )
• Saat modul ditarik keluar, ukuran distribusi akhir akan mulai menjadi lebih kecil dan lebih spesifik untuk aplikasi. Pada akhirnya tidak akan diperlukan "tipe build" yang berbeda karena kita hanya akan require() modul yang sebenarnya digunakan oleh aplikasi kita.

Kepada @mrdoob dan penulis lainnya; jika Anda tidak memiliki banyak pengalaman dengan NPM/Browserify, saya akan menyarankan untuk membuat beberapa proyek kecil dengannya dan merasakan "filosofi"-nya. Ini sangat berbeda dari arsitektur ThreeJS; daripada kerangka besar itu mendorong banyak hal-hal kecil .

Keuntungan lain dari pendekatan ini adalah bahwa bisa ada ekosistem open source, modul Three.JS pihak ketiga, terutama shader, geometri, model loader, dll. Diterbitkan melalui NPM atau Github/Component yang kemudian dapat dengan mudah dirujuk dan digunakan orang. Saat ini barang-barang dibagikan dengan mengadakan demo yang kemudian orang-orang 'melihat sumber'. Three.JS layak mendapatkan yang lebih baik!

Saya pikir salah satu masalah yang saya miliki dengan Three.JS adalah seberapa cepat kode menjadi tidak kompatibel dengan versi Three.JS saat ini. Keuntungan lain dari beralih ke sesuatu seperti ini adalah dapat menentukan versi _bits_ tertentu dari Three.JS akan sangat kuat dan praktis.

+1

+1 untuk arsitektur CommonJS/browserify, itu akan membuat inti lebih ringan dan ekstensi akan cocok bahkan jika mereka berasal dari pihak ketiga

Memecahkan three.js menjadi modul kecil juga membutuhkan banyak biaya. Sistem saat ini memungkinkan tambahan pihak ketiga yang cukup sederhana (saksi misalnya modul THREEx jetienne). Ada banyak yang bisa dikatakan tentang kesederhanaan pengaturan saat ini, selama sistem modul JS hanya membungkus sistem build.

Cara lain untuk meminimalkan ukuran build adalah yang dilakukan ClojureScript. Mereka mengikuti beberapa konvensi untuk memungkinkan kompiler Penutupan Google melakukan analisis seluruh program dan penghapusan kode mati.

+1 untuk keanggunan kesederhanaan yang tidak dihargai, dan sering diabaikan

+1

Memecahkan three.js menjadi modul kecil juga membutuhkan banyak biaya. Sistem saat ini memungkinkan tambahan pihak ketiga yang cukup sederhana (saksi misalnya modul THREEx jetienne).

Idenya di sini adalah bahwa build UMD akan tetap disediakan untuk lingkungan non-Node. Plugin seperti THREEx akan bekerja dengan cara yang sama untuk mereka yang bergantung pada ThreeJS dengan tag <script> .

Hal yang rumit adalah: bagaimana kita require() plugin tertentu jika kita berada di lingkungan CommonJS? Mungkin browserify-shim bisa membantu.

Ada banyak yang bisa dikatakan tentang kesederhanaan pengaturan saat ini, selama sistem modul JS hanya membungkus sistem build.

Sistem plugin/ekstensi ThreeJS saat ini cukup buruk untuk digunakan, dan jauh dari "sederhana" atau mudah. Sebagian besar proyek ThreeJS cenderung menggunakan beberapa bentuk plugin atau ekstensi, seperti EffectComposer, atau FirstPersonControls, atau pemuat model, atau salah satu dari banyak file JS lain yang beredar di folder examples . Saat ini satu-satunya cara untuk bergantung pada plugin ini:

• Unduh versi ThreeJS saat ini
• Copy-paste file yang diperlukan ke folder vendor
• Pasang tugas gulp/grunt untuk menyatukan dan mengecilkan semua plugin yang Anda butuhkan; pastikan untuk menyatukannya _dalam urutan yang benar_ jika tidak, semuanya akan rusak. Pertahankan daftar ini secara manual saat Anda menambahkan lebih banyak plugin.
• Ulangi langkah 1 dan 2 setiap kali ThreeJS diperbarui; dan kemudian tarik rambut Anda saat Anda menyadari bahwa kode baru tidak kompatibel ke belakang

Sekarang, bayangkan, dengan browserify Anda dapat melakukan sesuatu seperti ini:

var FirstPersonControls = require('threejs-controls').FirstPersonControls;

//more granular, only requiring necessary files
var FirstPersonControls = require('threejs-controls/lib/FirstPersonControls');

Plugin tersebut akan require('threejs') dan apa pun yang mungkin mereka perlukan (seperti cuplikan GLSL atau triangulasi teks ). Manajemen ketergantungan/versi semuanya tersembunyi bagi pengguna, dan tidak perlu untuk tugas-tugas grunt/gulp concat yang dikelola secara manual.

Hal yang rumit adalah: bagaimana kita membutuhkan() plugin tertentu jika kita berada di lingkungan CommonJS?

Saya telah menggunakan CommonJS untuk proyek TIGA.js sekarang. Ini sedikit proses manual, mengubah potongan kode orang lain menjadi modul dan saya tidak berpikir akan ada cara mudah untuk menghindarinya untuk kode lama yang tidak dikonversi oleh penulis atau kontributor.

Yang penting adalah bahwa ada modul yang mengekspor seluruh objek TIGA 'standar', yang kemudian dapat diminta oleh apa pun yang ingin memperluasnya.

var THREE = require('three');

THREE.EffectComposer = // ... etc, remembering to include copyright notices :)

Ini telah bekerja cukup baik untuk saya, terutama ketika proyek berkembang dan saya mulai menambahkan shader dan geometri saya sendiri ke dalam modul mereka sendiri, dll.

Selama ada paket npm 'threejs-full' atau 'threejs-classic' maka ini menjadi cara yang cukup layak untuk bekerja dengan barang-barang Three.js lama di lingkungan CommonJS tapi saya curiga ini cukup niche!

+1
Saya percaya setelah modul threejs yang terfragmentasi tersedia di npm, plugin
pengembang akan senang bermigrasi ke CommonJS env.
Pada tanggal 5 Juni 2014 21:19, "Charlotte Gore" [email protected] menulis:

Hal yang sulit adalah: bagaimana kita membutuhkan() plugin tertentu jika kita
berada di lingkungan CommonJS?

Saya telah menggunakan CommonJS untuk proyek TIGA.js sekarang. Itu sedikit
dari proses manual, mengubah potongan kode orang lain menjadi modul
dan saya tidak berpikir akan ada cara mudah untuk menghindarinya untuk kode lama
yang tidak dikonversi oleh penulis atau kontributor.

Yang penting adalah ada modul yang mengekspor seluruh 'standar'
TIGA objek, yang kemudian dapat diminta oleh apa pun yang ingin diperluas
dia.

var TIGA = membutuhkan('tiga');
THREE.EffectComposer = // ... dll, ingat untuk menyertakan pemberitahuan hak cipta :)

Ini telah bekerja cukup baik untuk saya, terutama ketika proyek tumbuh dan saya
mulai menambahkan shader dan geometri saya sendiri ke dalam modul mereka sendiri, dll.

Selama ada paket npm 'threejs-full' atau 'threejs-classic' maka
ini menjadi cara yang cukup layak untuk bekerja dengan barang-barang Three.js lama di a
Lingkungan CommonJS tapi saya curiga ini cukup niche!

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/mrdoob/three.js/issues/4776#issuecomment -45236911.

Bisa juga membuat shader dibuat modular juga, misal menggunakan glslify . Bahkan hal-hal seperti membuat middleware Express yang menghasilkan shader sesuai permintaan menjadi lebih mudah.

Beberapa bulan yang lalu saya memindahkan frame.js ke require.js dan akhirnya saya mengerti cara kerja AMD ini.

Saya masih perlu belajar, bagaimanapun, bagaimana "mengkompilasi" ini. Apa alat/alur kerja untuk menghasilkan three.min.js dari daftar modul?

Saya lebih suka gulp.js sebagai sistem build dengan plugin gulp-browserify . Sangat mudah dimengerti dan kodenya terlihat lebih bersih daripada gerutuan menurut saya. Lihat ini: http://travismaynard.com/writing/no-need-to-grunt-take-a-gulp-of-fresh-air :wink:

beberapa pemikiran: (berdasarkan pengalaman saya yang terbatas dengan node, npm, tentu saja browserify)

1. saya pikir modul node.js sangat bagus (itu npm, modules, dan require()s)
2. saya pikir browserify juga bagus

yang mengatakan, mengikuti diskusi di utas ini, saya tidak yakin apakah semua orang memiliki pemahaman yang sama tentang browserify (browserify, commonjs, requirejs, amd, umd agak terkait meskipun mungkin tidak perlu hal yang sama).

sekarang jika Anda dapat mengikuti rantai pemikiran saya sedikit.

1. JS hebat, ini berjalan cepat di seluruh browser.
2. wow, sekarang JS berjalan di sisi server juga.
3. itu node.js, itu keren, jadi mari kita membuat kode di node.js
4. tetapi saya tidak ingin menulis/tidak dapat menulis semuanya/menemukan sesuatu untuk digunakan.
5. jangan khawatir, sekarang jalankan npm install modules
6. sekarang membutuhkan modul keren ini agar kita dapat menggunakannya.
7. bekerja dengan baik!
8. sekarang tunggu, kami baru saja menulis banyak hal di JS yang berjalan di node.js
9. bukankah js seharusnya ada di browser? bagaimana kita membuat kode ini berjalan di sana lagi?

Di situlah Browserify muncul. Nah, secara teknis seseorang dapat menggunakan requireJS di browser. Tetapi Anda ingin menggabungkan file js bersama-sama tanpa membuat terlalu banyak panggilan jaringan (tidak seperti sistem file yang membutuhkan () yang cepat). Di sanalah Browserify melakukan beberapa hal keren seperti analisis statis untuk melihat modul mana yang perlu diimpor dan membuat build yang lebih dioptimalkan untuk aplikasi Anda. (Tentu saja ada batasan, mungkin tidak dapat menguraikan require('bla' + variabel)) bahkan dapat menukar bagian yang memerlukan lapisan emulasi untuk hal-hal yang bergantung pada node.js. ya, ini menghasilkan build js yang sekarang dapat saya sertakan di browser saya.

Berikut adalah beberapa hal yang dapat dilakukan browserify https://github.com/substack/node-browserify#usage

Kedengarannya seperti semuanya bagus sejauh ini... tapi ada beberapa poin yang menurut saya layak dipertimbangkan untuk pindah ke "arsitektur browser"

• perlu ada perubahan pola pikir untuk pengembang three.js (sistem modul yang diperlukan harus digunakan tentu saja)
• lapisan kompatibilitas dapat dibangun sehingga pengguna three.js masih dapat menggunakan three.js dengan cara lama tanpa menuai manfaat modular
• untuk dapat menghasilkan build yang dioptimalkan, pengguna three.js perlu pindah ke sistem yang dibutuhkan
• proses pembuatan baru kemungkinan akan melibatkan rantai alat browserify (saat ini kita dapat menggunakan python, node.js, atau salin dan tempel sederhana dll) atau beberapa alat yang diperlukan.
• jika kita ingin three.js benar-benar lebih modular, dengan pembuatan versi pada setiap komponen, seperti misalnya TrackballControls, kita perlu membaginya, dan itu dapat menyebabkan fragmentasi
• yang mungkin mengarah pada keragaman juga, namun satu kekuatan dari three.js saat ini sepertinya merupakan titik terpusat dari banyak ekstensi

Jadi jika kita melihat keragaman ini dan pemuatan modul yang nyaman (terutama mengendarai ekosistem npm) bersama dengan build yang disesuaikan adalah hal yang hebat, maka mungkin ada baiknya melakukan perubahan paradigma, refactoring kode dan mengubah sistem build kita saat ini.

@mrdoob beberapa alat di sekitar browserify tercantum di sini: https://github.com/substack/node-browserify/wiki/browserify-tools.

mengenai three.min.js , Anda tidak akan menggunakan kode yang diperkecil dalam proyek Anda. yang Anda lakukan hanyalah var three = require('three') di project.js dan kemudian jalankan browserify project.js > bundle.js && uglifyjs bundle.js > bundle.min.js . catatan: Anda masih dapat mengirimkan kode yang diperkecil seharga <script src="min.js"> .

saya saat ini membungkus three.js dengan

if ('undefined' === typeof(window))
  var window = global && global.window ? global.window : this
var self = window

dan

module.exports = THREE

lalu saya membungkus ekstensi dengan

module.exports = function(THREE) { /* extension-code here */ }

jadi saya bisa memintanya seperti itu:

var three = require('./wrapped-three.js')
require('./three-extension')(three)

jadi ini tidak optimal, tetapi saya pribadi sebenarnya dapat menerimanya dan berpikir itu tidak terlalu buruk - meskipun proposal @kumavis akan menjadi keuntungan _besar_.

tapi mungkin masuk akal untuk membagi tiga dan meletakkan semua hal di modul terpisah hanya untuk melihat bagaimana hasilnya.

juga checkout http://modules.gl/ yang sangat didasarkan pada browserify (meskipun Anda dapat menggunakan setiap modul sendiri tanpa browserify).

@mrdoob @shi-314 gulp-browserify telah masuk daftar hitam karena hanya menggunakan browserify secara langsung (yaitu melalui vinyl-source-stream).

Alat seperti grunt/gulp/etc terus berubah, dan Anda akan menemukan banyak pendapat yang berbeda. Pada akhirnya tidak masalah yang Anda pilih, atau apakah Anda hanya melakukannya dengan skrip khusus. Pertanyaan yang lebih penting adalah: bagaimana pengguna akan menggunakan ThreeJS, dan seberapa banyak kompatibilitas mundur yang ingin Anda pertahankan?

Setelah beberapa pemikiran lagi, saya pikir akan _sangat_ sulit untuk memodulasi semuanya tanpa sepenuhnya memfaktorkan ulang kerangka kerja dan arsitekturnya. Berikut adalah beberapa masalah:

• Semua kode namespace harus diubah menjadi ekspor/persyaratan CommonJS. Ini adalah usaha yang cukup besar dan akan ada banyak ../../../math/Vector2 jelek dll.
• Di dunia yang ideal, perpustakaan akan terfragmentasi, jadi three-scene akan dipisahkan dari three-lights dll. Kemudian Anda dapat membuat versi setiap paket secara terpisah. Fragmentasi semacam ini tampaknya tidak realistis untuk kerangka kerja sebesar ThreeJS, dan akan sulit untuk dipertahankan.
• Jika kita _tidak_ memecah kerangka kerja menjadi komponen-komponen kecil, maka versi semantik akan menjadi mimpi buruk. Perubahan kecil yang melanggar di mana pun dalam kerangka kerja akan membutuhkan benjolan versi besar untuk semuanya. Dan mengkonsumsi API akan sangat buruk: require('three/src/math/Vector2')

Saran saya? Kami mempertimbangkan dua hal untuk maju:

1. Mulai dari yang kecil; mengeluarkan beberapa fitur penting dan dapat digunakan kembali seperti Vektor/Quaternion, konversi warna, triangulasi, dll. Hal-hal ini adalah kandidat yang baik untuk NPM karena berguna di luar cakupan ThreeJS. Mereka juga dapat memiliki rangkaian pengujian, pembuatan versi, dan pelacakan masalah sendiri.
2. Ketika kode baru perlu ditambahkan ke ThreeJS, seperti fitur baru, atau ketergantungan (misalnya poly2tri/Tess2), pertimbangkan untuk menariknya keluar sebagai modul terpisah dan bergantung padanya melalui NPM.

Saya ingin melihat semuanya termodulasi, tetapi saya tidak yakin dengan pendekatan yang realistis untuk ThreeJS. Mungkin seseorang harus melakukan eksperimen di garpu untuk melihat seberapa layak hal itu.

Terima kasih atas penjelasannya teman-teman!

Yang saya takutkan adalah memperumit hal-hal bagi orang-orang yang baru memulai. Memaksa mereka untuk mempelajari hal-hal browserify/modul ini mungkin bukan ide yang baik ...

Harus setuju dengan @mrdoob di sini. Saya, dan banyak rekan, bukan pemrogram web (lebih tepatnya VFX/TD animasi). Mengambil WebGL dan Tiga tentu saja sudah cukup bekerja seperti di atas beban kerja kami saat ini (dan dalam beberapa kasus beberapa dari kami harus belajar js di tempat). Banyak dari apa yang saya baca di utas ini, kadang-kadang, membuat saya bergidik memikirkan berapa banyak lagi pekerjaan yang akan ditambahkan ke piring saya jika Tiga pindah ke struktur ini. Saya bisa saja salah, tetapi begitulah yang terbaca bagi saya.

Dengan build UMD ( browserify --umd ) yang telah dikompilasi di repo, tidak ada perubahan pada alur kerja untuk pengembang yang ada.

@mrdoob Ide sistem manajemen ketergantungan adalah kesederhanaan. Membaca lusinan posting tentang opsi dan membangun sistem mungkin berlebihan, tetapi pada akhirnya sistem saat ini tidak berkelanjutan. Setiap kali satu file bergantung pada yang lain, itu adalah perburuan -dan- pencarian yang harus dilakukan pengembang baru untuk menemukan referensi. Dengan browserify, ketergantungannya eksplisit dan ada jalur ke file.

@repsac Sistem ketergantungan harus membuat Tiga lebih mudah diakses oleh pengguna bahasa lain karena menghindari cakupan global, memuat mimpi buruk urutan dan mengikuti paradigma yang mirip dengan bahasa populer lainnya. var foo = require('./foo'); adalah (loosly) mirip dengan C # 's using foo; atau Jawa import foo;

Saya ingin melihat semuanya termodulasi, tetapi saya tidak yakin dengan pendekatan yang realistis untuk ThreeJS. Mungkin seseorang harus bereksperimen di garpu untuk melihat seberapa layak hal itu

Saya pikir ini adalah cara untuk pergi, sungguh. Selesaikan pekerjaan, tunjukkan cara kerjanya.

Dan mengkonsumsi API akan cukup ugly: require('three/src/math/Vector2')

Sebagai percobaan, saya baru saja mengonversi 'memulai' dari Tiga dokumen ke pendekatan modular baru ini. Saya bisa membayangkan ada banyak referensi kecuali orang-orang cukup ketat dalam memecah kode mereka menjadi modul-modul kecil.

Keuntungan utama dari melakukan ini adalah bahwa ukuran build yang dihasilkan akan menjadi sebagian kecil dari ukuran Three.js penuh karena Anda hanya akan memasukkan hal-hal yang secara khusus dirujuk di sini dan kemudian hal-hal yang bergantung pada hal-hal itu.

Saya kira mereferensikan semua dependensi yang Anda butuhkan (dan menginstal semuanya secara individual) dapat terbukti agak terlalu buruk dalam praktiknya.

Jika Anda secara eksplisit menargetkan perangkat seluler maka pendekatan yang sangat terperinci ini akan menjadi sempurna tetapi pada kenyataannya saya menduga kita akan membutuhkan paket yang mengekspor seluruh TIGA api yang akan berfungsi seperti biasa, kemudian paket yang lebih kecil yang merangkum semua geometri bonus, semua penyaji, semua matematika, semua materi dll, lalu turun ke tingkat modul individu sehingga pengembang dapat memutuskan sendiri.

Dan ya, pengkodean untuk web itu menyebalkan.

Pokoknya, dengan percobaan ...

Instal dependensi kami..

npm install three-scene three-perspective-camera three-webgl-renderer three-cube-geometry three-mesh-basic-material three-mesh three-raf

Tulis kode kita...

// import our dependencies..
var Scene = require('three-scene'),
  Camera = require('three-perspective-camera'),
  Renderer = require('three-webgl-renderer'),
  CubeGeometry = require('three-cube-geometry'),
  MeshBasicMaterial = require('three-mesh-basic-material'),
  Mesh = require('three-mesh'),
  requestAnimationFrame = require('three-raf');

// set up our scene...
var scene = new Scene();
var camera = new Camera(75, window.innerWidth / window.innerHeight, 0.1, 1000);
var renderer = new Renderer();
renderer.setSize(window.innerWidth, window.innerHeight);
document.body.appendChild(renderer.domElement);

// create the cube...
var geometry = new CubeGeometry(1, 1, 1);
var material = new MeshBasicMaterial({color: 0x00ff00});
var cube = new Mesh(geometry, material);
scene.add(cube);
// position the camera...
camera.position.z = 5;
// animate the cube..
var render = function () {
  requestAnimationFrame(render);
  cube.rotation.x += 0.1;
  cube.rotation.y += 0.1;
  renderer.render(scene, camera);
};
// begin!
render();

lalu buat file kami

browserify entry.js -o scripts/hello-world.js

kemudian sertakan di halaman kami

<script src="/scripts/hello-world.js" type="text/javascript"></script>

Saya kira mereferensikan semua dependensi yang Anda butuhkan (dan menginstal semuanya secara individual) dapat terbukti agak terlalu buruk dalam praktiknya.

Pengguna akhir tidak perlu menggunakan browserify dalam proyek mereka agar Three menggunakan browserify untuk mengelola basis kodenya. Tiga dapat diekspos sebagai THREE global seperti sekarang...termasuk file build dan jalankan dengannya.

@repsac @mrdoob perubahan akan kompatibel ke belakang, sehingga pengguna saat ini tidak perlu mengubah apa pun jika mereka tidak mau. Saran ini adalah untuk meningkatkan pemeliharaan jangka panjang dan umur panjang dari basis kode ThreeJS yang luas dan monolitik. Hal-hal seperti ketergantungan dan manajemen versi mungkin terdengar seperti memusingkan bagi yang belum tahu, tetapi mereka luar biasa untuk mereka yang mengembangkan alat, kerangka kerja, plugin, dan situs web skala besar di atas ThreeJS.

yaitu Kode pengguna akhir masih dapat terlihat sama, dan examples tidak perlu diubah sama sekali:

<script src="three.min.js"></script>

<script>
var renderer = new THREE.WebGLRenderer();
</script>

Untuk pengembang yang lebih ambisius yang mencari bangunan modular, _atau_ bagi mereka yang ingin mengembangkan solusi jangka panjang di atas ThreeJS (yaitu dan memanfaatkan manajemen versi/dependensi), mungkin terlihat seperti ini:
npm install three-vecmath --save

Kemudian, dalam kode:

var Vector2 = require('three-vecmath').Vector2;

//.. do something with Vector2

Dan, lebih jauh lagi, ini memungkinkan orang untuk menggunakan hal-hal seperti matematika vektor ThreeJS, konversi warna, triangulasi, dll. di luar cakupan ThreeJS.

Meskipun saya pikir kekacauan require() adalah ide yang buruk dan tradeoff yang buruk, itu akan menjadi ide yang lebih buruk untuk mengekspos pengguna ke dua jenis kode three.js yang berbeda, memberi tahu pengguna satu adalah rasa sistem modul yang mewah dan yang lainnya adalah rasa sistem modul yang lebih sederhana (tetapi kelas dua).

@erno Saya pikir Anda melewatkan intinya, three.js akan diatur oleh struktur modul secara internal, tetapi itu digunakan untuk menghasilkan file build yang tidak berbeda dari pengaturan saat ini.

Keuntungan utama adalah meningkatkan pengalaman mengembangkan dan memelihara three.js .

@kumavis - tidak @erno sebenarnya tidak melewatkan itu, tapi saya mengerti(*) bahwa dia menyatakan bahwa jika three.js terkadang digunakan melalui require dan terkadang tidak, itu bisa membingungkan. Misalnya seseorang melihat keduanya pada tiga sumber dan kemudian beberapa contoh pihak ke-3 dan menemukan perbedaan dalam cara kerjanya dan semuanya.

(*) kita sudah membicarakan ini di irc hari ini.

Saya pikir itu semacam poin yang valid tetapi saya tidak yakin apakah/bagaimana cara kerjanya pada akhirnya - apakah itu benar-benar masalah dengan modul & membangun penggunaan. Tapi tentu tampaknya layak untuk dipikirkan dan secara keseluruhan tampak baik bagi saya bahwa masalah keseluruhan telah dipertimbangkan di sini dengan cermat, terima kasih atas info dan pandangan sejauh ini dari pihak saya.

@anton saya mengerti. Orang-orang telah menyarankan berbagai pendekatan berbeda di sini, saya berasumsi bahwa kami terutama akan menyediakan dokumentasi untuk penggunaan tingkat atas (menarik semuanya dari THREE ), tetapi orang lain mungkin membuat contoh yang tidak akan mengikuti ini dan mungkin menyebabkan beberapa kebingungan. Dan itu kekhawatiran yang valid.

Saya pikir saya agak bingung dengan bahasanya.

dan lainnya adalah rasa sistem modul yang lebih sederhana (tetapi kelas dua).

Ini hanya mengacu pada file build, ya?

Dalam pemahaman saya, ya. Tidak bisa membayangkan apa lagi selain bisa kehilangan sesuatu.

antont, kumavis: Proposal di sini telah berbicara tentang mengekspos kode gaya require() kepada pengguna akhir juga, lihat mis. komentar terbaru mattdesl.

"Untuk pengembang yang lebih ambisius yang mencari bangunan modular, atau bagi mereka yang ingin mengembangkan solusi jangka panjang di atas ThreeJS (yaitu dan memanfaatkan manajemen versi/dependensi) [...]"

salah satu cara untuk memiliki build yang lebih optimal sebenarnya adalah memiliki skrip yang mengetahui dependensi Anda secara otomatis dan menghasilkan modul yang diperlukan.

saat ini bower & browserify tidak diperlukan, tetapi itu bukan satu-satunya solusi. saya tidak tahu apakah ada proyek open source off-the-shelf lain yang melakukan itu (mungkin seperti ng-dependencies) tetapi saya telah menulis alat seperti itu sebelumnya saya pikir akan ada pendekatan lain untuk menyelesaikan rasa sakit ini.

kompiler penutupan google mungkin merupakan alat seperti itu?

Di sisi pengguna, mungkinkah ini bisa membantu?
http://marcinwieprzkowicz.github.io/three.js-builder/

itu cukup menarik @erichlof :) saya ingin tahu apakah @marcinwieprzkowicz membuat ini dengan tangan... https://github.com/marcinwieprzkowicz/three.js-builder/blob/gh-pages/threejs-src/r66/modules.json

Salah satu praktik yang digunakan three.js yang membuatnya sulit untuk digunakan di lingkungan commonjs adalah penggunaan instanceof: https://github.com/mrdoob/three.js/blob/master/src/core/Geometry.js#L82

Ini karena dalam aplikasi Anda sering berakhir dengan versi berbeda dari pustaka yang sama di pohon sumber Anda, jadi memeriksa instanceof tidak berfungsi di antara versi berbeda dari pustaka yang sama. Akan lebih baik dalam persiapan untuk pindah ke sistem modul js umum untuk mengganti contoh pemeriksaan tersebut dengan pemeriksaan fitur di belakang antarmuka gaya Geometry.isGeometry(geom).

di git/three.js/src:

grep -r instanceof . | wc -l 
164

di git/three.js/examples:

grep -r instanceof . | wc -l 
216

jadi ada total 380 penggunaan instanceof di three.js. Apa yang akan menjadi implementasi terbaik sebagai pengganti?

Saya baru-baru ini menambahkan properti type yang dapat digunakan untuk menggantikan sebagian besar properti tersebut.

Saya baru-baru ini menambahkan properti tipe yang dapat digunakan untuk menggantikan sebagian besar dari mereka.

baik! Akan menyiapkan PR.

Untuk contoh bagaimana ini ditangani di perpustakaan JS populer dan besar lainnya, lihat https://github.com/facebook/react . Basis kode disusun menggunakan sistem modul berbasis gaya simpul (yang diimplementasikan oleh browserify) tetapi dibuat untuk rilis menggunakan grunt. Solusi ini fleksibel untuk 3 kasus penggunaan.

1. Konsumen murni Three.js yang menulis vanilla JS masih bisa menggunakan file build seperti biasa. Tidak ada perubahan untuk kasus penggunaan ini.
2. Konsumen Three.js yang menggunakan browserify dapat mendeklarasikan Three.js sebagai dependensi dalam sebuah proyek dan hanya require dependensi spesifik. Manfaat dari manajemen ketergantungan yang tepat telah didokumentasikan dengan baik.
3. Berkontribusi ke Three.js sekarang harus lebih sederhana karena dependensi antar komponen didokumentasikan secara eksplisit.

Saya membuat beberapa penelitian ...

Kemarin saya meretas skrip (agak bodoh) yang mengubah kode sumber Three.js untuk menggunakan pernyataan CommonJS require() untuk mendeklarasikan dependensi antar file. Hanya untuk melihat apa yang terjadi... Ini:

1. Itu akhirnya memiliki pernyataan persyaratan yang agak konyol seperti ini (dari WebGLRenderer):

var THREE = require('../Three.js'); require('../math/Color.js'); require('../math/Frustum.js'); require('../math/Matrix4.js'); require('../math/Vector3.js'); require('./webgl/WebGLExtensions.js'); require('./webgl/plugins/ShadowMapPlugin.js'); require('./webgl/plugins/SpritePlugin.js'); require('./webgl/plugins/LensFlarePlugin.js'); require('../core/BufferGeometry.js'); require('./WebGLRenderTargetCube.js'); require('../materials/MeshFaceMaterial.js'); require('../objects/Mesh.js'); require('../objects/PointCloud.js'); require('../objects/Line.js'); require('../cameras/Camera.js'); require('../objects/SkinnedMesh.js'); require('../scenes/Scene.js'); require('../objects/Group.js'); require('../lights/Light.js'); require('../objects/Sprite.js'); require('../objects/LensFlare.js'); require('../math/Matrix3.js'); require('../core/Geometry.js'); require('../extras/objects/ImmediateRenderObject.js'); require('../materials/MeshDepthMaterial.js'); require('../materials/MeshNormalMaterial.js'); require('../materials/MeshBasicMaterial.js'); require('../materials/MeshLambertMaterial.js'); require('../materials/MeshPhongMaterial.js'); require('../materials/LineBasicMaterial.js'); require('../materials/LineDashedMaterial.js'); require('../materials/PointCloudMaterial.js'); require('./shaders/ShaderLib.js'); require('./shaders/UniformsUtils.js'); require('../scenes/FogExp2.js'); require('./webgl/WebGLProgram.js'); require('../materials/ShaderMaterial.js'); require('../scenes/Fog.js'); require('../lights/SpotLight.js'); require('../lights/DirectionalLight.js'); require('../textures/CubeTexture.js'); require('../lights/AmbientLight.js'); require('../lights/PointLight.js'); require('../lights/HemisphereLight.js'); require('../math/Math.js'); require('../textures/DataTexture.js'); require('../textures/CompressedTexture.js');

Kami akan membutuhkan beberapa refactoring besar, mungkin membagi WebGLRenderer (dan semacamnya) menjadi beberapa modul (atm file lebih dari 6000 baris).

1. Kita perlu menemukan solusi untuk potongan GLSL. Atm file-file itu dikompilasi menjadi THREE.ShaderChunk pada waktu kompilasi dan kemudian ke THREE.ShaderLib saat runtime (bergabung dengan array THREE.ShaderChunk s) yang agak sulit dilakukan hanya dengan browserify. Saya kira itu akan membutuhkan transformasi browserify yang melakukan hal yang sama.

React.js menggunakan orang biasa untuk mencari modul mereka tanpa harus merujuknya melalui jalur file. Mungkin kita bisa melakukan hal yang sama dan juga menentukan aturan khusus yang memungkinkan kita mengubah file GLSL require menjadi sintaks JS.

@rasteiner Anda mungkin sangat senang belajar tentang https://github.com/stackgl/glslify , itu berasal dari keluarga http://stack.gl yang berkembang

Saya memiliki sedikit pengalaman dengan modul dan pendekatan "unixy" dalam beberapa bulan terakhir dan pemikiran saya sekarang adalah bahwa itu terlalu sedikit terlambat, dan refactoring threejs untuk modul modularitas atau npm akan menjadi tujuan yang tidak realistis.

Inilah yang saat ini saya lakukan untuk mengatasi masalah modularitas/penggunaan kembali:

• Saya meletakkan beberapa shader yang dapat digunakan kembali untuk blur/fxaa/etc di NPM. Lihat ini:
  https://www.npmjs.org/package/three-shader-fxaa (yang menggunakan mesin agnostik glsl-fxaa)
• komponen yang dapat digunakan kembali seperti OrbitController dan EffectComposer juga sedang diterbitkan sesuai kebutuhan. Misalnya:
  https://www.npmjs.org/package/three-orbit-controls
• alih-alih bergantung pada "tiga", modul ini mengekspor fungsi yang mengambil TIGA, dan mengembalikan kelas utilitas. Dengan cara ini dapat digunakan dengan threejs global, atau commonjs.
• versi adalah rasa sakit. Saya mencoba menyelaraskan versi utama saya dengan nomor rilis threejs. Setiap versi baru dari threejs memperkenalkan banyak perubahan yang melanggar, sehingga harus ditangani dengan hati-hati.
• modul yang berhubungan dengan matematika seharusnya hanya beroperasi pada array dan menggunakan gl-vec3 modular, gl-mat4, dll. dengan cara ini mereka generik dan berguna di luar threejs. Kemudian, pengguna threejs hanya perlu menangani pembungkus/pembukaan ke array. Lihat sistem verlet, jalur penyederhanaan, dll.
• jika saya membutuhkan fitur webGL yang benar-benar modular atau kecil, saya akan menggunakan stackgl/glslify ke depan. Ini juga dapat berfungsi dalam ThreeJS selama Anda mengatur ulang status GL. Misalnya: https://www.npmjs.org/package/gl-sprite-text

Proyek baru saya cenderung menggunakan "tiga" di npm hanya untuk bangun dan berjalan. Akan sangat luar biasa jika ThreeJS secara resmi menerbitkan build ke npm menggunakan tag versi yang sesuai dengan nomor rilis.

PS: bagi mereka yang tertarik untuk membawa shader yang dapat digunakan kembali/modular ke alur kerja mereka:
https://Gist.github.com/mattdesl/b04c90306ee0d2a412ab

dikirim dari iPhone saya

Pada 20 November 2014, pukul 07:42, aaron [email protected] menulis:

@rasteiner Anda mungkin sangat senang belajar tentang https://github.com/stackgl/glslify , itu berasal dari keluarga http://stack.gl yang berkembang

—
Balas email ini secara langsung atau lihat di GitHub.

Jika ini membantu orang lain yang mungkin mencari cara menggunakan Three.js dengan browserify, dan tersandung di utas ini, cara saya baru saja mengaturnya sendiri adalah dengan menggunakan browserify-shim .

Mengikuti bagian README pada _"Anda terkadang akan a) Mengekspos variabel global melalui global"_, saya menyertakan tag skrip terpisah untuk Three.js dan mengonfigurasinya untuk mengekspos variabel TIGA global.

Dan kemudian sedikit yang harus saya kerjakan sendiri adalah bagaimana memasukkan ekstra seperti ColladaLoader, OrbitControls dll. Saya melakukan ini seperti ini:

Dari package.json:

    "browser": {
        "three": "bower_components/threejs/build/three.js"
    },
    "browserify-shim": "browserify-shim-config.js",
    "browserify": {
        "transform": [ "browserify-shim" ]
    }

browserify-shim-config.js:

    module.exports = {
        "three": { exports: "global:THREE" },
        "./vendor/threejs-extras/ColladaLoader.js": { depends: {"three": null}, exports: "global:THREE.ColladaLoader" },
        "./vendor/threejs-extras/OrbitControls.js": { depends: {"three": null}, exports: "global:THREE.OrbitControls" }
    };

Kemudian dalam skrip saya sendiri, main.js:

    require('../vendor/threejs-extras/ColladaLoader.js');
    require('../vendor/threejs-extras/OrbitControls.js');

    var loader = new THREE.ColladaLoader(),
        controls = new THREE.OrbitControls(camera);
...

Browserify memerlukan pembuatan ulang seluruh skrip saat Anda memodifikasi bahkan pada byte. Saya pernah menggunakan browserify untuk mengemas proyek yang membutuhkan THREE.js, kemudian dibutuhkan lebih dari dua detik untuk membuat batasan dan memblokir livereload setiap kali saya melakukan perubahan. Itu terlalu membuat frustrasi.

Anda biasanya menggunakan watchify selama pengembangan dengan livereload. Yang satu membangun bundel secara bertahap.

watchify tidak bekerja untuk saya. Ketika saya mengubah file dan menyimpannya, watchify dan livereload yang gemuk menyajikan versi yang lebih lama/cache. Saya tidak tahu mengapa ini terjadi. Untungnya, browserify sudah bekerja dengan cukup baik.

@ChiChou Lewati --noparse=three ke browserify. Ini mengambil langkah bundel browserify dari 1000ms ke 500ms di mesin saya, yang cukup layak untuk merasakan umpan balik instan.

@rasteiner Saya ingin mengucapkan terima kasih lagi atas penelitian informal Anda tentang interdependensi three.js. Sementara daftar besar deps itu adalah beberapa kode yang tampak jelek, sebenarnya keburukan itu ada apa adanya, hanya tidak terlihat. Kekuatan Browserify adalah mengharuskan kita untuk mengudara cucian kotor kita dan mengejar sistem yang tidak terlalu kusut.

Ada banyak tempat di Three.js di mana kita mengambil beberapa objek, memahami jenisnya, dan melakukan tugas yang berbeda berdasarkan jenis itu. Dalam sebagian besar kasus tersebut, kode yang bergantung pada tipe itu dapat dipindahkan ke tipe itu sendiri, dan kita tidak perlu memiliki pemahaman tentang semua kemungkinan tipe yang sedang kita operasikan.

Berikut ini adalah contoh singkat dari WebGLRenderer :

if ( texture instanceof THREE.DataTexture ) {
  // ...
} else if ( texture instanceof THREE.CompressedTexture ) {
  // ...
} else { // regular Texture (image, video, canvas)
  // ...
}

harus lebih dari bentuk

texture.processTexImage( _gl, mipmaps, otherData )

Biarkan tipe menentukan bagaimana menangani dirinya sendiri. Ini juga memungkinkan konsumen perpustakaan untuk menggunakan jenis Tekstur baru yang tidak terpikirkan oleh kami. Struktur ini harus mengurangi saling ketergantungan.

Saya pikir pindah ke arsitektur browserify jelas merupakan cara yang harus dilakukan. Pembangunan UMD akan membuat konsumsi THREE.js lebih mudah. Ini juga akan memungkinkan kita untuk membagi WebGLRenderer menjadi beberapa file, karena saat ini terlihat agak monolitik dan menakutkan.

Saya telah memulai cabang tempat saya sedang bekerja untuk memindahkannya ke sini: https://github.com/cobalast/three.js/tree/browserify-build-system

Tolong beritahu saya bagaimana menurut anda.

Inilah perubahan @cobalast .

Sepertinya Anda menggunakan pendekatan konversi otomatis dengan file browserifyify.js , yang menurut saya adalah cara yang tepat.

Satu hal yang belum banyak kita diskusikan adalah cara terbaik untuk mentransisikan library besar yang selalu berubah ini ke browserify. Anda dapat membuat perubahan dan kemudian membuka PR, tetapi itu akan segera kedaluwarsa. Itulah yang menarik tentang pendekatan otomatis.

Jika kita bisa:

• berikan skrip konversi src three.js (seperti browserifyify.js )
• berikan dokumen yang menjelaskan cara kerja proses konversi
• berikan dokumen yang menjelaskan cara kerja sistem build baru
• jalankan tes pasca konversi
• tidak menyertakan perubahan apa pun pada file yang ada yang dapat menyebabkan konflik penggabungan

...lalu kita dapat mengubahnya menjadi konversi tombol-tekan yang akan tetap berfungsi di masa mendatang. kesederhanaan itu memungkinkan gagasan melamun tentang pergeseran arsitektur mendasar ke proyek besar seperti itu untuk diselesaikan ketika argumen ideologis menang.

@cobalast untuk itu, saya akan menghapus perubahan ke src/Three.js jika berfungsi sama.

Catatan: tidak hanya mengembalikan, tetapi menghapus perubahan itu dari riwayat cabang melalui cabang baru atau dorongan paksa

@coballast Saya ingin tahu apakah akan lebih masuk akal jika utilitas konversi bukan garpu three.js , tetapi utilitas eksternal yang Anda tunjuk pada direktori pengembangan three.js , dan itu mengubah sumbernya file, menambahkan skrip build, dan menjalankan tes.

@kumavis Saya setuju dengan meninggalkan direktori src sendirian. Saya pikir hal yang harus dilakukan adalah meminta utilitas menulis direktori duplikat dengan kode commonjs, dan kita dapat menguji dan menjalankan browserify build dari sana untuk memastikan semua contoh berfungsi sebelum kita mencoba melakukan sesuatu yang besar.

Ada juga peluang menarik di sini untuk menulis beberapa hal analisis statis yang secara otomatis akan memeriksa dan menerapkan gaya yang konsisten di seluruh basis kode.

@cobalast terdengar hebat.
Ada banyak alat di luar sana untuk penulisan ulang kode otomatis, misalnya escodegen . Perlu memastikan bahwa kami mempertahankan komentar, dll.
Ingin memulai repo utilitas konversi threejs?

@cobalast yang mengatakan, mempertahankan fokus yang tajam untuk utilitas ini adalah penting

@kumavis Anggap sudah selesai. Saya sangat ingin ini terjadi. Ini hanya satu dari dua proyek yang saya kerjakan saat ini.

@kumavis @mrdoob Beberapa diskusi di sini tampaknya seputar gagasan membagi TIGA menjadi beberapa modul terpisah yang mungkin dapat diinstal melalui npm dan kemudian dikompilasi dengan browserify. Saya tidak langsung menentang gagasan itu, tetapi saya pikir itu harus menjadi masalah yang terpisah. Satu-satunya hal yang saya anjurkan pada saat ini adalah menggunakan browserify untuk mengelola basis kode TIGA secara internal. Pindahkan, dan buat bekerja dengan cara yang sama seperti biasanya bagi pengguna, lalu evaluasi apa yang masuk akal.

Saya akan penasaran untuk melihat apa output dari utilitas itu ^^

@cobalast menautkan repo untuk kami lacak, meskipun saat ini kosong. Kita bisa membangun dari sana.

https://github.com/cobalast/threejs-browserify-conversion-utility

Kodenya berantakan, akan segera dibersihkan.

Ini dia! :roket:

Saya sekarang memiliki utilitas dalam keadaan di mana ia menghasilkan browserify src dan akan membangunnya tanpa masalah. Saya akan memperbarui repo dengan instruksi tentang cara melakukannya sendiri. Pada titik ini, contoh tidak berfungsi. Ada beberapa masalah yang perlu ditangani untuk memperbaikinya. Saya akan menambahkannya ke repo jika ada yang ingin menyingsingkan lengan baju mereka dan membantu.

@cobalast ya tolong ajukan masalah sebagai TODO, dan saya atau orang lain akan melompat semampu kami.

Masalah serius telah muncul. Lihat #6241

Inilah analisis saya tentang apa yang perlu terjadi agar ini berfungsi: https://github.com/coballast/threejs-browserify-conversion-utility/issues/9#issuecomment -83147463

browserify setidaknya mengangkut berlebihan (menyangkal) karena desainnya. Ini membuatnya menggunakan biaya yang melambung (paket data siapa?) Dan lambat.

Solusi sederhana untuk ini adalah dengan memisahkan dokumen dari kode perpustakaan yang akan memerlukan dua file klien dan bukan satu. Ini adalah praktik umum untuk js sisi klien.

Jika pada awalnya browserify rusak dan itu sendiri perlu diperbaiki, saya hampir tidak dapat melihat mengapa itu harus dipertimbangkan untuk meningkatkan apa pun apalagi sesuatu seperti threejs.

@spaesani Karena data untuk threejs harus tetap diunduh. Jika kita membagi threejs menjadi modul yang lebih kecil dan membiarkan sistem build otomatis memilih apa yang dibutuhkan untuk satu aplikasi, sebenarnya sebagian besar aplikasi threejs di luar sana akan lebih ringan.

Jika karena alasan tertentu Anda masih ingin memisahkan "dokumen dari kode perpustakaan", Anda masih dapat melakukan ini dan menggunakan versi pra-bangun seperti yang kami lakukan sekarang. Anda bahkan dapat membagi aplikasi yang dibuat dengan browserify menjadi modul terpisah dengan menggunakan flag --standalone dan --exclude .

Browserify hanyalah cara untuk menggunakan API definisi modul (CommonJS) yang terbukti dalam pertempuran di browser. Ini akan sangat menyederhanakan pengembangan plugin threejs dan meningkatkan kejelasan kode dan oleh karena itu produktivitas, ini akan memungkinkan kita untuk berintegrasi ke dalam ekosistem yang lebih besar (npm) di mana kode secara inheren dipelihara oleh lebih banyak orang sambil tetap mempertahankan integritas melalui sistem versi (pikirkan tentang keluarga stackgl ), dan itu bahkan tidak akan memaksa orang masuk ke CommonJS jika mereka tidak menginginkannya.

Tentu saja ada kerugiannya, tetapi itu bukan yang Anda sebutkan.

three.js dan three.min.js dapat di-cache untuk menghemat transportasi (data) baik oleh proxy, solusi seluler umum, atau browser caching.
Saat Anda memilih dan menggabungkan kode threejs dengan kode khusus dokumen, caching tidak layak.
Jika browserify memungkinkan seseorang untuk