Three.js: मॉड्यूलर आर्किटेक्चर की ओर बढ़ना

एक फायदा यह है कि यह तीन.जेएस के चल रहे विकास के लिए एक मॉड्यूलर वास्तुकला को लागू करेगा।

नोड/ब्राउज़राइज़ में सामान्य शैली में प्रत्येक फ़ाइल शीर्ष पर अपनी निर्भरता घोषित करती है, और वैश्विक चर को एक विरोधी पैटर्न मानती है।

यहाँ एक उदाहरण स्निपेट है:

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

function BoxGeometry() {
  // ...
}

BoxGeometry.prototype = Geometry.prototype;

एक अन्य लाभ यह है कि three.js उपभोक्ता browserify का उपयोग करके अपने इच्छित भागों को चुनने और चुनने में सक्षम होंगे। वे केवल Scene , BoxGeometry , PerspectiveCamera , और WebGLRenderer आयात कर सकते हैं, उन सभी के लिए निर्भरता स्वचालित रूप से प्राप्त कर सकते हैं ( Object3D आदि), और जावास्क्रिप्ट का एक छोटा बंडल है जो केवल उनके इच्छित फीचर सेट का समर्थन करता है।

यह इस तरह से किया जा सकता है कि कोई ब्रेकिंग परिवर्तन न हो। शीर्ष स्तर पर, हम उन सभी वर्गों को निर्यात करेंगे जिन्हें हम मानक पैकेज का हिस्सा मानते हैं

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

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

नोट: मुझे इस उदाहरण में शीर्ष पर निर्भरताओं की बिल्कुल आवश्यकता नहीं है, क्योंकि इस फ़ाइल को लगभग विशेष रूप से कथन की आवश्यकता होगी।

अंत में हम इसे एक सार्वभौमिक मॉड्यूल परिभाषा में लपेटेंगे जो यह पता लगाता है कि क्या एक मॉड्यूल सिस्टम (नोड/ब्राउज़राइज़, एएमडी) उपयोग में है, और यदि ऐसा है तो इसे निर्यात करता है, या अन्यथा इसे वैश्विक ऑब्जेक्ट ( window ) में जोड़ता है।

पिछली समीक्षा:

• अच्छी मॉड्यूलर शैली लागू करता है
• कार्यक्षमता चुनने और चुनने के लिए three.js ब्राउज़र का उपयोग करने वाले उपभोक्ताओं को अनुमति देता है
• कोई ब्रेकिंग परिवर्तन नहीं

इसके लिए बिल्ड सिस्टम को बदलने की आवश्यकता होगी, लेकिन नया बहुत सीधे आगे होगा।

कुछ अन्य फायदे:

• आप अपने कोड की संरचना कर सकते हैं
• आप वैश्विक नाम स्थान को प्रदूषित किए बिना मॉड्यूल बना/पुन: उपयोग कर सकते हैं
• आप उत्पादन के लिए निर्माण कर सकते हैं
• आप अधिक आसानी से डिबग कर सकते हैं क्योंकि प्रत्येक मॉड्यूल की अपनी फ़ाइल होती है, आपको बड़ी तीन.जेएस फ़ाइल में संबंधित मॉड्यूल की खोज करने की आवश्यकता नहीं होती है

@ shi-314 मुझे लगता है कि मैं थोड़ा भ्रमित हूं, मुझे ऐसा लगता है कि You can structure your code और You can build for production ऐसी चीजें हैं जो आप आर्किटेक्चरल शिफ्ट के बिना कर सकते हैं? क्या आप तीन.जेएस स्रोत या तीन.जेएस का उपयोग करके निर्मित चीजों के बारे में बात कर रहे हैं?

एक अभ्यास जो तीन.जेएस का उपयोग करता है, जो सामान्य वातावरण में उपयोग करना मुश्किल बनाता है, वह है instanceof : https://github.com/mrdoob/three.js/blob/master/src/core/Geometry .js#L82

ऐसा इसलिए है क्योंकि किसी एप्लिकेशन में आप अक्सर अपने स्रोत ट्री में एक ही लाइब्रेरी के विभिन्न संस्करणों के साथ समाप्त होते हैं, इसलिए एक ही लाइब्रेरी के विभिन्न संस्करणों के बीच इंस्टॉफ़ की जाँच करना काम नहीं करता है। Geometry.isGeometry(geom) स्टाइल इंटरफ़ेस के पीछे फीचर-चेकिंग के साथ चेक के उन उदाहरणों को बदलने के लिए एक कॉमनज मॉड्यूल सिस्टम में जाने की तैयारी में अच्छा होगा।

@kumavis मैं

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

लेकिन अगर आपके पास Browserify होता तो आप:

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

इसलिए आपका नेमस्पेस एक जैसा बना रहता है और आपको अपने कोड में THREE.MeshLambertMaterial और MeshMyCoolMaterial का उपयोग करने की आवश्यकता नहीं है।

और You can build for production मेरा मूल रूप से वही मतलब था जिसका आपने उल्लेख किया था: allows three.js consumers using browserify to pick and choose functionality ।

@ shi-314 धन्यवाद, यह अधिक स्पष्ट है। यह डिसेरिएलाइज़ेशन उपभोक्ता-परिभाषित वर्गों के लिए मेरे प्रस्तावित सामान्य समाधान को प्रभावित करता है:

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

यह मेरे प्रस्तावित क्रमांकन / अक्रमांकन रिफैक्टर से है
https://github.com/mrdoob/three.js/pull/4621

इस तरह के बदलाव से प्रदर्शन प्रभावित नहीं होना चाहिए।

यह बहुत बड़ा बदलाव है लेकिन मैं भी इसके पक्ष में हूं।

कुछ अन्य प्रमुख लाभ:

• अपने लिए UMD बिल्ड जेनरेट करने के लिए आप browserify के standalone विकल्प का उपयोग कर सकते हैं। यूएमडी रैपर के साथ मैन्युअल रूप से टिंकर करने की आवश्यकता नहीं है।
• इस पैकेज का उपयोग ब्राउज़रीफाई/एनपीएम के उपयोगकर्ता आसानी से कर सकते हैं
• तीनjs (जैसे poly2tri, color-string , आदि) के लिए निर्भरता में खींचना बहुत आसान हो जाता है
• मॉड्यूल जो एक प्रतिपादन पुस्तकालय (जैसे वेक्टर/गणित पुस्तकालय) में "वास्तव में संबंधित नहीं हैं" को अलग एनपीएम मॉड्यूल के रूप में निकाला जा सकता है और कई अन्य प्रकार की परियोजनाओं के लिए पुन: उपयोग किया जा सकता है। इसका एक प्रमुख लाभ यह है कि अलग-अलग मॉड्यूल में बग/मुद्दों, पीआर आदि के लिए अपना स्वयं का भंडार होता है (थ्रीजेएस मुद्दों की सफाई)।
• एनपीएम हमारे लिए सिमेंटिक वर्जनिंग को हैंडल करेगा। उदाहरण के लिए हम हर किसी के कोड ब्रेकिंग की चिंता किए बिना threejs-vecmath में एक ब्रेकिंग बदलाव को आगे बढ़ा सकते हैं। और दूसरी तरफ, यदि हम किसी विशेष मॉड्यूल में पैच या मामूली रिलीज करते हैं, तो उन मॉड्यूल का उपभोग करने वाले लोग स्वचालित रूप से परिवर्तन प्राप्त करने में सक्षम होंगे।
• यह "अतिरिक्त" जैसे EffectComposer और विभिन्न शेड्स को पैकेज करने और उपभोग करने में आसान बनाता है (कल्पना करें npm install threejs-shader-bloom )
• जैसे-जैसे मॉड्यूल बाहर निकाले जाते हैं, अंतिम वितरण आकार छोटा और अधिक एप्लिकेशन-विशिष्ट होना शुरू हो जाएगा। अंततः विभिन्न "बिल्ड प्रकार" की कोई आवश्यकता नहीं होगी क्योंकि हम केवल require() मॉड्यूल का उपयोग करेंगे जो हमारा ऐप वास्तव में उपयोग कर रहा है।

@mrdoob और अन्य लेखकों को; यदि आपके पास NPM/Browserify के साथ अधिक अनुभव नहीं है, तो मैं इसके साथ कुछ छोटी परियोजनाएँ बनाने और इसके "दर्शन" के लिए एक अनुभव प्राप्त करने का सुझाव दूंगा। यह थ्रीजेएस आर्किटेक्चर से बहुत अलग है; बड़े ढांचे के बजाय यह बहुत सी छोटी चीजों को प्रोत्साहित

इस दृष्टिकोण का एक अन्य लाभ यह है कि ओपन सोर्स, थर्ड पार्टी थ्री.जेएस मॉड्यूल, विशेष रूप से शेडर्स, जियोमेट्री, मॉडल लोडर आदि का एक पारिस्थितिकी तंत्र हो सकता है। एनपीएम या जीथब / घटक के माध्यम से प्रकाशित किया जाता है जिसे लोग आसानी से केवल संदर्भ और उपयोग कर सकते हैं। फिलहाल एक डेमो होस्ट करके सामान साझा किया जाता है, जिस पर लोग 'स्रोत देखें'। तीन.जेएस बेहतर के हकदार हैं!

मुझे लगता है कि मेरे पास तीन में से एक समस्या है। जेएस यह है कि थ्री.जेएस के वर्तमान संस्करण के साथ कोड कितनी जल्दी असंगत हो जाता है। कुछ इस तरह से स्विच करने का एक अन्य लाभ _bits_ of Three.JS के विशिष्ट संस्करणों को निर्दिष्ट करने में सक्षम होना बहुत शक्तिशाली और आसान होगा।

+1

कॉमनजेएस/ब्राउज़राइज़ आर्किटेक्चर के लिए +1, यह कोर को अधिक हल्का बना देगा और एक्सटेंशन फिट होंगे, भले ही वे तीसरे पक्ष से आए हों

तीन.जेएस को छोटे मॉड्यूल में विभाजित करने पर भी बहुत अधिक लागत आती है। वर्तमान प्रणाली बहुत ही सरल तृतीय पक्ष ऐडऑन (गवाह जैसे जेटिएन के THREEx मॉड्यूल) की अनुमति देती है। वर्तमान सेटअप की सादगी के बारे में बहुत कुछ कहा जा सकता है, जब तक कि जेएस मॉड्यूल सिस्टम बिल्ड सिस्टम के चारों ओर केवल रैपर हैं।

क्लोजरस्क्रिप्ट क्या करता है बिल्ड आकार को कम करने का एक और तरीका है। वे Google के क्लोजर कंपाइलर को संपूर्ण-कार्यक्रम विश्लेषण और मृत कोड उन्मूलन करने की अनुमति देने के लिए कुछ सम्मेलनों का पालन करते हैं।

सरलता की शान के लिए +1, और अक्सर अनदेखी की गई, सादगी के लिए

+1

तीन.जेएस को छोटे मॉड्यूल में विभाजित करने पर भी बहुत अधिक लागत आती है। वर्तमान प्रणाली बहुत ही सरल तृतीय पक्ष ऐडऑन (गवाह जैसे जेटिएन के THREEx मॉड्यूल) की अनुमति देती है।

यहां विचार यह है कि गैर-नोड वातावरण के लिए एक यूएमडी बिल्ड अभी भी प्रदान किया जाएगा। THREEx जैसे प्लगइन्स थ्रीजेएस के आधार पर साधारण <script> टैग वाले लोगों के लिए उसी तरह काम करेंगे।

मुश्किल बात यह होगी: अगर हम कॉमनजेएस वातावरण में हैं तो हम require() एक विशेष प्लगइन कैसे करते हैं? शायद browserify-shim मदद कर सकता है।

वर्तमान सेटअप की सादगी के बारे में बहुत कुछ कहा जा सकता है, जब तक कि जेएस मॉड्यूल सिस्टम बिल्ड सिस्टम के चारों ओर केवल रैपर हैं।

थ्रीजेएस का वर्तमान प्लगइन/एक्सटेंशन सिस्टम काम करने के लिए बहुत भयानक है, और "सरल" या आसान से बहुत दूर है। अधिकांश थ्रीजेएस प्रोजेक्ट प्लगइन या एक्सटेंशन के किसी न किसी रूप का उपयोग करते हैं, जैसे इफेक्टकंपोजर, या फर्स्टपर्सनकंट्रोल, या एक मॉडल लोडर, या examples फ़ोल्डर में तैरती अन्य कई जेएस फाइलों में से एक। अभी इन प्लगइन्स पर निर्भर रहने का एकमात्र तरीका है:

• थ्रीजेएस का वर्तमान निर्माण डाउनलोड करें
• आवश्यक फ़ाइलों को अपने vendor फ़ोल्डर में कॉपी-पेस्ट करें
• आपको आवश्यक सभी प्लगइन्स को संक्षिप्त और छोटा करने के लिए गल्प / ग्रंट कार्यों को तार दें; उन्हें _सही क्रम में जोड़ना सुनिश्चित करना_ अन्यथा चीजें टूट जाएंगी। जैसे ही आप अधिक प्लगइन्स जोड़ते हैं, इस सूची को मैन्युअल रूप से बनाए रखें।
• हर बार थ्रीजेएस अपडेट होने पर चरण 1 और 2 दोहराएं; और फिर अपने बालों को बाहर निकालें जब आपको पता चले कि नया कोड पिछड़ा-संगत नहीं है

अब, कल्पना कीजिए, browserify के साथ आप ऐसा कुछ कर सकते हैं:

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

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

वे प्लगइन्स require('threejs') और कुछ और जो उन्हें चाहिए (जैसे GLSL स्निपेट्स या टेक्स्ट ट्राइंगुलेशन ) होंगे। निर्भरता/संस्करण प्रबंधन सभी उपयोगकर्ता के लिए छिपा हुआ है, और मैन्युअल रूप से बनाए रखने वाले ग्रंट/गल्प कॉन्सट कार्यों की कोई आवश्यकता नहीं है।

मुश्किल बात यह होगी: अगर हम कॉमनजेएस वातावरण में हैं तो हमें एक विशेष प्लगइन की आवश्यकता () कैसे होगी?

मैं कुछ समय के लिए तीन.जेएस परियोजनाओं के लिए कॉमनजेएस का उपयोग कर रहा हूं। यह एक मैनुअल प्रक्रिया है, अन्य लोगों के कोड के कुछ हिस्सों को मॉड्यूल में परिवर्तित करना और मुझे नहीं लगता कि विरासत कोड के लिए इससे बचने का एक आसान तरीका होगा जो लेखकों या योगदानकर्ताओं द्वारा परिवर्तित नहीं किया गया है।

महत्वपूर्ण बात यह है कि पूरे 'मानक' तीन ऑब्जेक्ट को निर्यात करने वाला एक मॉड्यूल है, जिसे तब किसी भी चीज़ की आवश्यकता हो सकती है जो इसे विस्तारित करना चाहता है।

var THREE = require('three');

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

इसने मेरे लिए बहुत अच्छा काम किया है, खासकर जैसे-जैसे परियोजना बढ़ती है और मैं अपने स्वयं के शेड्स और ज्यामिति को अपने मॉड्यूल आदि में जोड़ना शुरू कर देता हूं।

जब तक 'थ्रीजेएस-फुल' या 'थ्रीजेएस-क्लासिक' एनपीएम पैकेज है तो यह कॉमनजेएस वातावरण में पुराने थ्री.जेएस सामान के साथ काम करने का एक बहुत ही व्यवहार्य तरीका बन जाता है, लेकिन मुझे संदेह है कि यह बहुत अच्छा है!

+1
मेरा मानना ​​​​है कि एक बार खंडित तीनj मॉड्यूल npm, प्लगइन में उपलब्ध हैं
डेवलपर्स CommonJS env में माइग्रेट करना पसंद करेंगे।
5 जून 2014 को रात 9:19 बजे, "शार्लोट गोर" नोटिफिकेशन @github.com ने लिखा:

मुश्किल बात यह होगी: हमें किसी विशेष प्लगइन की आवश्यकता कैसे होगी () यदि हम?
कॉमनजेएस पर्यावरण में हैं?

मैं कुछ समय के लिए तीन.जेएस परियोजनाओं के लिए कॉमनजेएस का उपयोग कर रहा हूं। यह एक सा है
एक मैनुअल प्रक्रिया के, अन्य लोगों के कोड के भाग को मॉड्यूल में परिवर्तित करना
और मुझे नहीं लगता कि लीगेसी कोड के लिए इससे बचने का कोई आसान तरीका होगा
जो लेखकों या योगदानकर्ताओं द्वारा परिवर्तित नहीं किया गया है।

महत्वपूर्ण बात यह है कि संपूर्ण 'मानक' निर्यात करने वाला एक मॉड्यूल है
तीन वस्तु, जिसे तब किसी भी चीज़ की आवश्यकता हो सकती है जो विस्तार करना चाहती है
यह।

वर तीन = आवश्यकता ('तीन');
THREE.EffectComposer = // ... आदि, कॉपीराइट नोटिस शामिल करना याद रखना :)

इसने मेरे लिए बहुत अच्छा काम किया है, खासकर जब परियोजना बढ़ती है और मैं
अपने स्वयं के शेड्स और ज्यामिति को अपने मॉड्यूल आदि में जोड़ना शुरू करें।

जब तक 'थ्रीज-फुल' या 'थ्रीजेएस-क्लासिक' एनपीएम पैकेज है, तब तक
यह पुराने तीन.जेएस सामान के साथ काम करने का एक बहुत ही व्यवहार्य तरीका बन जाता है
कॉमनजेएस पर्यावरण लेकिन मुझे संदेह है कि यह बहुत बढ़िया है!

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/mrdoob/three.js/issues/4776#issuecomment -45236911।

यह शेडर्स को मॉड्यूलर भी बना सकता है, उदाहरण के लिए glslify का उपयोग

कुछ महीने पहले मैंने फ्रेम.जेएस को आवश्यकता.जेएस में स्थानांतरित

हालांकि, मुझे अभी भी सीखने की ज़रूरत है कि इसे "संकलित" कैसे करें। मॉड्यूल की सूची से three.min.js उत्पन्न करने के लिए टूल/वर्कफ़्लो क्या है?

मैं gulp.js को gulp- browserify प्लगइन के साथ एक बिल्ड सिस्टम के रूप में पसंद करता http://travismaynard.com/writing/no-need-to-grunt-take-a-gulp-of-fresh-air :wink:

कुछ विचार: (नोड के साथ मेरे सीमित अनुभव के आधार पर, npm, निश्चित रूप से browserify)

1. मुझे लगता है कि node.js मॉड्यूल बहुत अच्छे हैं (वह npm, मॉड्यूल, और आवश्यकता () है)
2. मुझे लगता है कि browserify भी बढ़िया है

उस ने कहा, इस धागे पर चर्चा के बाद, मुझे यकीन नहीं है कि अगर सभी को ब्राउजराइज़ की समान समझ थी (ब्राउज़राइज़, कॉमनज, रिक्वायरज, एएमडी, यूएमडी कुछ हद तक संबंधित हैं, हालांकि वे आवश्यक नहीं हो सकते हैं)।

अब अगर आप मेरे विचारों की श्रृंखला का थोड़ा सा अनुसरण कर सकते हैं।

1. जेएस बहुत अच्छा है, यह सभी ब्राउज़रों में तेजी से चलता है।
2. वाह, अब जेएस सर्वर की तरफ भी चलता है।
3. वह node.js है, यह अच्छा है, तो चलिए node.js में सामान कोड करते हैं
4. लेकिन मैं लिखना नहीं चाहता/सब कुछ नहीं लिख सकता/उपयोग करने के लिए कुछ ढूंढ सकता हूं।
5. कोई चिंता नहीं, अब npm इंस्टाल मॉड्यूल चलाएँ
6. अब इन शांत मॉड्यूल की आवश्यकता है ताकि हम उनका उपयोग कर सकें।
7. बहुत अच्छा काम करता है!
8. अब रुकिए, हमने अभी-अभी JS में ढेर सारी चीज़ें लिखी हैं जो node.js . पर चलती हैं
9. जेएस ब्राउज़र में नहीं माना जाता है? हम इन कोड को फिर से वहां कैसे चला सकते हैं?

वहीं पर Browserify तस्वीर में आता है। ठीक है, तकनीकी रूप से कोई भी ब्राउज़र में requJS का उपयोग कर सकता है। लेकिन आप बहुत अधिक नेटवर्क कॉल किए बिना जेएस फाइलों को एक साथ बंडल करना चाहते हैं (फाइल सिस्टम की आवश्यकता के विपरीत() जो तेज हैं)। यह देखने के लिए कि कौन से मॉड्यूल को आयात करने की आवश्यकता है और आपके एप्लिकेशन के लिए अधिक अनुकूलित बिल्ड बनाता है, यह देखने के लिए Browserify स्थिर विश्लेषण जैसी कुछ अच्छी चीजें करता है। (निश्चित रूप से सीमाएं हैं, यह संभवतः आवश्यकता ('ब्ला' + चर) को पार्स नहीं कर सकता है) यह उन हिस्सों को भी स्वैप कर सकता है जिनके लिए नोड.जेएस निर्भर सामान के लिए अनुकरण परत की आवश्यकता होती है। हाँ, यह एक जेएस बिल्ड उत्पन्न करता है जिसे अब मैं अपने ब्राउज़र में शामिल कर सकता हूं।

यहाँ कुछ सामान हैं जो ब्राउज़र कर सकते हैं https://github.com/substack/node-browserify#usage

ऐसा लगता है कि अब तक सब कुछ बहुत अच्छा है ... लेकिन कुछ बिंदु हैं जो मुझे लगता है कि हम "ब्राउज़र आर्किटेक्चर" पर जाने पर विचार करने लायक हैं।

• तीन.जेएस डेवलपर्स के लिए मानसिकता में बदलाव की जरूरत है (निश्चित रूप से आवश्यकता मॉड्यूल सिस्टम का उपयोग किया जाना चाहिए)
• एक संगतता परत बनाई जा सकती है ताकि तीन.जेएस उपयोगकर्ता अभी भी मॉड्यूलर लाभ प्राप्त किए बिना पुराने तरीके से तीन.जेएस का उपयोग कर सकें
• अनुकूलित बिल्ड बनाने में सक्षम होने के लिए, तीन.जेएस उपयोगकर्ताओं को आवश्यकता प्रणाली पर जाने की आवश्यकता होगी
• नई निर्माण प्रक्रिया में संभवतः ब्राउजराइज़ टूलचेन (वर्तमान में हम अजगर, नोड.जेएस, या साधारण कॉपी और पेस्ट आदि का उपयोग कर सकते हैं) या कुछ आवश्यकताजेएस उपकरण शामिल होंगे।
• अगर हम चाहते हैं कि तीन.जेएस वास्तव में अधिक मॉड्यूलर हों, प्रत्येक घटक पर संस्करण के साथ, जैसे कि ट्रैकबॉलकंट्रोल, हमें उन्हें विभाजित करने की आवश्यकता होगी, और इससे विखंडन हो सकता है
• इससे विविधता भी हो सकती है, हालांकि तीन.जेएस की एक ताकत वर्तमान में ऐसा लगता है कि यह कई एक्सटेंशन का केंद्रीकृत बिंदु है

इसलिए यदि हम इस विविधता और सुविधाजनक मॉड्यूल लोडिंग (मुख्य रूप से npm पारिस्थितिकी तंत्र पर सवारी) के साथ-साथ अनुकूलित बिल्ड को देखते हैं, तो यह एक छोटी सी बात हो सकती है कि प्रतिमान में बदलाव हो, कोड को रिफैक्ट करना और हमारे वर्तमान बिल्ड सिस्टम को बदलना।

@mrdoob browserify के आसपास के कुछ टूल यहां सूचीबद्ध हैं: https://github.com/substack/node-browserify/wiki/browserify-tools।

three.min.js , आप अपने प्रोजेक्ट में छोटा कोड का उपयोग नहीं करेंगे। तुम सब है var three = require('three') अपने में project.js और फिर चलाने browserify project.js > bundle.js && uglifyjs bundle.js > bundle.min.js । नोट: आप अभी भी <script src="min.js"> के लिए छोटा कोड भेज सकते हैं।

मैं वर्तमान में तीन.जेएस के साथ लपेट रहा हूं

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

तथा

module.exports = THREE

फिर मैं एक्सटेंशन को लपेटता हूं

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

तो मुझे इसकी आवश्यकता हो सकती है:

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

तो यह इष्टतम नहीं है, लेकिन मैं व्यक्तिगत रूप से इसके साथ रह सकता हूं और सोचता हूं कि यह इतना बुरा नहीं है - हालांकि @kumavis प्रस्ताव एक _विशाल_ लाभ होगा।

लेकिन शायद यह समझ में आता है कि तीन को फोर्क करना और सभी चीजों को अलग-अलग मॉड्यूल में रखना है, यह देखने के लिए कि यह कैसे काम करेगा।

http://modules.gl/ भी चेकआउट करें जो कि बहुत हद तक ब्राउजराइज़ पर आधारित है (हालाँकि आप बिना ब्राउजर के हर मॉड्यूल का उपयोग अपने आप कर सकते हैं)।

@mrdoob @shi-314 gulp- browserify (यानी vinyl-source-stream के माध्यम से) का उपयोग करने के पक्ष में ब्लैकलिस्ट किया गया है।

ग्रंट/गल्प/आदि जैसे उपकरण लगातार प्रवाह में हैं, और आपको बहुत सारी अलग-अलग राय मिल जाएगी। अंत में इससे कोई फर्क नहीं पड़ता कि आप किसे चुनते हैं, या आप इसे केवल एक कस्टम स्क्रिप्ट के साथ करते हैं या नहीं। अधिक महत्वपूर्ण प्रश्न हैं: उपयोगकर्ता थ्रीजेएस का उपभोग कैसे करेंगे, और आप कितनी पिछड़ी-संगतता बनाए रखना चाहते हैं?

कुछ और विचार करने के बाद, मुझे लगता है कि ढांचे और इसकी वास्तुकला को पूरी तरह से रिफैक्टर किए बिना सबकुछ मॉड्यूलर करना मुश्किल होगा। यहां कुछ समस्याएं हैं:

• सभी नेमस्पेस कोड को कॉमनजेएस निर्यात/आवश्यकता में बदलना होगा। यह एक बहुत बड़ा उपक्रम है और बहुत सारे बदसूरत ../../../math/Vector2 आदि होंगे।
• एक आदर्श दुनिया में, पुस्तकालय खंडित हो जाएगा, इसलिए three-scene को three-lights आदि से अलग कर दिया जाएगा। फिर आप प्रत्येक पैकेज को अलग से संस्करणित कर सकते हैं। इस तरह का विखंडन थ्रीजेएस जैसे बड़े ढांचे के लिए अवास्तविक लगता है, और इसे बनाए रखने के लिए गधे में दर्द होगा।
• यदि हम फ्रेमवर्क को छोटे-छोटे घटकों में विभाजित नहीं कर रहे हैं, तो सिमेंटिक वर्जनिंग एक दुःस्वप्न होगा। ढांचे में कहीं भी एक छोटे से ब्रेकिंग परिवर्तन को पूरी चीज के लिए एक प्रमुख संस्करण टक्कर की आवश्यकता होगी। और एपीआई का उपभोग बहुत बदसूरत होगा: require('three/src/math/Vector2')

मेरा सुझाव? हम आगे बढ़ने वाली दो चीजों पर विचार करते हैं:

1. छोटा शुरू करो; वेक्टर/क्वाटरनियन, रंग रूपांतरण, त्रिभुज इत्यादि जैसी कुछ आवश्यक और पुन: प्रयोज्य सुविधाओं को बाहर निकालें। ये चीजें एनपीएम के लिए अच्छे उम्मीदवार हैं क्योंकि वे थ्रीजेएस के दायरे से बाहर उपयोगी हैं। उनके पास अपना स्वयं का परीक्षण सूट, संस्करण निर्धारण और समस्या ट्रैकिंग भी हो सकती है।
2. जब नए कोड को थ्रीजेएस में जोड़ने की आवश्यकता होती है, जैसे कि एक नई सुविधा, या एक निर्भरता (जैसे पॉली2ट्री/टेस2), तो इसे एक अलग मॉड्यूल के रूप में बाहर निकालने पर विचार करें और एनपीएम के माध्यम से इसके आधार पर।

मुझे सब कुछ मॉड्यूलर देखना अच्छा लगेगा, लेकिन मुझे ऐसे दृष्टिकोण के बारे में निश्चित नहीं है जो थ्रीजेएस के लिए यथार्थवादी है। हो सकता है कि किसी को कांटे में कुछ प्रयोग करने चाहिए कि यह देखने के लिए कि चीजें कितनी व्यवहार्य हैं।

स्पष्टीकरण के लिए धन्यवाद दोस्तों!

मुझे जो डर लगता है वह उन लोगों के लिए जटिल है जो अभी शुरू हो रहे हैं। उन्हें इस ब्राउज़र/मॉड्यूल सामग्री को सीखने के लिए मजबूर करना एक अच्छा विचार नहीं हो सकता है ...

यहां @mrdoob से सहमत होना होगा। मैं, और बहुत से सहयोगी, वेब प्रोग्रामर नहीं हैं (बल्कि वीएफएक्स/एनीमेशन टीडी)। वेबजीएल और थ्री को चुनना निश्चित रूप से हमारे वर्तमान कार्यभार के शीर्ष पर पर्याप्त काम रहा है (और कुछ मामलों में हममें से कुछ को मौके पर ही जेएस सीखना पड़ा)। इस सूत्र में मैंने जो कुछ पढ़ा है, उसमें से कई बार, मुझे यह सोचकर कांपने लगता है कि अगर तीन इस संरचना में चले गए तो मेरी प्लेट में और कितना काम जुड़ जाएगा। मैं गलत हो सकता था लेकिन निश्चित रूप से यह मुझे कैसे पढ़ता है।

रेपो में पहले से संकलित UMD ( browserify --umd ) बिल्ड के साथ, मौजूदा डेवलपर्स के लिए वर्कफ़्लो में कोई बदलाव नहीं हुआ है।

@mrdoob एक निर्भरता प्रबंधन प्रणाली का विचार सरलता है। विकल्प और बिल्ड सिस्टम पर दर्जनों पोस्ट पढ़ना भारी पड़ सकता है, लेकिन अंततः मौजूदा सिस्टम टिकाऊ नहीं है। कभी भी एक फ़ाइल दूसरे पर निर्भर करती है, यह एक खोज- और- खोज है किसी भी नए डेवलपर को संदर्भ खोजने के लिए प्रदर्शन करना पड़ता है। ब्राउज़र के साथ, निर्भरता स्पष्ट है और फ़ाइल के लिए एक पथ है।

@repsac एक निर्भरता प्रणाली को अन्य भाषाओं के उपयोगकर्ताओं के लिए तीन और सुलभ बनाना चाहिए क्योंकि यह वैश्विक दायरे, लोड ऑर्डर दुःस्वप्न से बचाता है और अन्य लोकप्रिय भाषाओं के समान प्रतिमान का पालन करता है। var foo = require('./foo'); सी# के using foo; या जावा के import foo; समान (शिथिल) है

मुझे सब कुछ मॉड्यूलर देखना अच्छा लगेगा, लेकिन मुझे ऐसे दृष्टिकोण के बारे में निश्चित नहीं है जो थ्रीजेएस के लिए यथार्थवादी है। हो सकता है कि किसी को कांटे में कुछ प्रयोग करने चाहिए कि यह देखने के लिए कि चीजें कितनी व्यवहार्य हैं

मुझे लगता है कि यह जाने का रास्ता है, वास्तव में। काम पूरा करो, दिखाओ कि यह कैसे काम करता है।

और एपीआई का उपभोग बहुत अच्छा होगा ugly: require('three/src/math/Vector2')

एक प्रयोग के रूप में मैंने अभी तीन दस्तावेज़ों से 'आरंभ करना' को इस नए मॉड्यूलर दृष्टिकोण में परिवर्तित कर दिया है। मैं कल्पना कर सकता हूं कि बहुत सारे संदर्भ हैं जब तक कि लोग अपने कोड को छोटे मॉड्यूल में तोड़ने के बारे में बहुत सख्त न हों।

ऐसा करने का मुख्य लाभ यह होगा कि परिणामी निर्माण आकार पूर्ण तीन.जेएस के आकार का एक छोटा सा अंश होगा क्योंकि आप केवल उन चीजों को शामिल करेंगे जो विशेष रूप से यहां संदर्भित हैं और फिर वे चीजें जिन पर निर्भर हैं।

मुझे लगता है कि आपको आवश्यक सभी निर्भरताओं का संदर्भ देना (और उन सभी को व्यक्तिगत रूप से स्थापित करना) अभ्यास में थोड़ा सा भयानक साबित हो सकता है।

यदि आप मोबाइल उपकरणों को स्पष्ट रूप से लक्षित कर रहे हैं तो यह अत्यधिक बारीक दृष्टिकोण सही होगा लेकिन वास्तव में मुझे संदेह है कि हमें ऐसे पैकेजों की आवश्यकता होगी जो संपूर्ण तीन एपीआई निर्यात करते हैं जो सामान्य रूप से काम करेंगे, फिर छोटे पैकेज जो सभी बोनस ज्यामिति को समाहित करते हैं, सभी रेंडरर्स, सभी गणित, सभी सामग्री आदि, फिर व्यक्तिगत मॉड्यूल स्तर तक, ताकि डेवलपर्स अपने लिए निर्णय ले सकें।

और हाँ, वेब के लिए कोडिंग एक दर्द है।

वैसे भी, प्रयोग के साथ...

हमारी निर्भरता स्थापित करें ..

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

हमारा कोड लिखें...

// 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();

फिर हमारी फाइल बनाएं

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

फिर इसे हमारे पेज में शामिल करें

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

मुझे लगता है कि आपको आवश्यक सभी निर्भरताओं का संदर्भ देना (और उन सभी को व्यक्तिगत रूप से स्थापित करना) अभ्यास में थोड़ा सा भयानक साबित हो सकता है।

अपने कोडबेस को प्रबंधित करने के लिए ब्राउज़र का उपयोग करने के लिए तीन के लिए अंतिम उपयोगकर्ता को अपने प्रोजेक्ट में ब्राउज़रिफ़ का उपयोग करने की आवश्यकता नहीं है। तीन को वैश्विक THREE रूप में उजागर किया जा सकता है जैसा कि अभी है ... बिल्ड फ़ाइल शामिल करें और इसके साथ चलाएं।

@repsac @mrdoob परिवर्तन पिछड़े-संगत होंगे, ताकि वर्तमान उपयोगकर्ताओं को कुछ भी बदलने की आवश्यकता न हो यदि वे नहीं चाहते हैं। ये सुझाव थ्रीजेएस के विशाल और अखंड कोडबेस की दीर्घकालिक रखरखाव और दीर्घायु में सुधार करने के लिए हैं। निर्भरता और संस्करण प्रबंधन जैसी चीजें शुरुआती लोगों के लिए सिरदर्द की तरह लग सकती हैं, लेकिन वे उन विकासशील टूल, फ्रेमवर्क, प्लगइन्स और थ्रीजेएस के शीर्ष पर बड़े पैमाने पर वेबसाइटों के लिए बहुत बढ़िया हैं।

यानी अंतिम-उपयोगकर्ता कोड अभी भी वही दिख सकता है, और examples को बिल्कुल भी बदलने की आवश्यकता नहीं है:

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

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

अधिक महत्वाकांक्षी डेवलपर्स के लिए जो मॉड्यूलर बिल्ड की तलाश में हैं, _or_ उन लोगों के लिए जो थ्रीजेएस के शीर्ष पर दीर्घकालिक समाधान विकसित करना चाहते हैं (यानी और संस्करण/निर्भरता प्रबंधन का लाभ उठाएं), यह इस तरह दिख सकता है:
npm install three-vecmath --save

फिर, कोड में:

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

//.. do something with Vector2

और, इसके अलावा, यह लोगों को थ्रीजेएस के दायरे से बाहर थ्रीजेएस के वेक्टर गणित, रंग रूपांतरण, त्रिभुज इत्यादि जैसी चीजों का उपयोग करने की अनुमति देता है।

भले ही मुझे लगता है कि आवश्यकता() गड़बड़ी एक बुरा विचार है और खराब ट्रेडऑफ़ है, उपयोगकर्ताओं को दो अलग-अलग प्रकार के तीन.जेएस कोड को उजागर करना एक और भी बुरा विचार होगा, उपयोगकर्ताओं को बता रहा है कि एक फैंसी मॉड्यूल सिस्टम स्वाद है और दूसरा है सरल (लेकिन द्वितीय श्रेणी) मॉड्यूल सिस्टम स्वाद।

@erno मुझे लगता है कि आप बिंदु से चूक गए हैं, three.js आंतरिक रूप से एक मॉड्यूल संरचना द्वारा आयोजित किया जाएगा, लेकिन इसका उपयोग वर्तमान सेटअप से अलग एक बिल्ड फ़ाइल बनाने के लिए किया जाता है।

प्राथमिक लाभ three.js को विकसित करने और बनाए रखने के अनुभव में सुधार कर रहा है।

@kumavis - नहीं @erno ने वास्तव में इसे याद नहीं किया, लेकिन मैं समझ गया (*) कि वह यह बिंदु बनाता है कि यदि three.js कभी-कभी आवश्यकता के माध्यम से उपयोग किया जाता है और कभी-कभी यह भ्रमित नहीं हो सकता है। उदाहरण के लिए, कोई व्यक्ति तीनों स्रोतों और फिर कुछ तृतीय पक्ष उदाहरणों को देखता है और इस बात में अंतर पाता है कि यह सब कैसे है और कैसे काम करता है।

(*)हमने आज पहले आईआरसी पर इस बारे में बात की थी।

मुझे लगता है कि यह एक तरह का वैध बिंदु है लेकिन मुझे यकीन नहीं है कि यह अंत में कैसे काम करता है - क्या मॉड्यूल के साथ कोई समस्या है और वास्तव में चीज़ का उपयोग करता है। लेकिन निश्चित रूप से एक विचार के लायक लगता है और कुल मिलाकर मुझे अच्छा लगा कि समग्र मामले पर यहाँ ध्यान से विचार किया गया है, मेरी ओर से अब तक की जानकारी और विचारों के लिए धन्यवाद।

@ मुझे दिखाई नहीं देता। लोगों ने यहां कई तरह के अलग-अलग तरीकों का सुझाव दिया है, मैं मान रहा था कि हम मुख्य रूप से शीर्ष-स्तरीय उपयोग के लिए दस्तावेज़ीकरण प्रदान करेंगे ( THREE से सब कुछ खींचकर), लेकिन अन्य ऐसे उदाहरण बना सकते हैं जो इसका पालन नहीं करेंगे और यह हो सकता है कुछ भ्रम पैदा करते हैं। और यह एक वाजिब चिंता है।

मुझे लगता है कि मैं भाषा से थोड़ा भ्रमित था।

और दूसरा सरल (लेकिन द्वितीय श्रेणी) मॉड्यूल सिस्टम स्वाद है।

यह सिर्फ बिल्ड फ़ाइल की बात कर रहा है, हाँ?

मेरी समझ में, हाँ। और क्या कल्पना नहीं कर सकता, लेकिन कुछ याद आ सकता है।

एंटोन, कुमाविस: यहां के प्रस्तावों ने अंतिम उपयोगकर्ताओं को भी आवश्यकता () शैली कोड को उजागर करने के बारे में बात की है, उदाहरण के लिए देखें। mattdesl की सबसे हालिया टिप्पणी।

"अधिक महत्वाकांक्षी डेवलपर्स के लिए जो मॉड्यूलर बिल्ड की तलाश में हैं, या उन लोगों के लिए जो थ्रीजेएस के शीर्ष पर दीर्घकालिक समाधान विकसित करना चाहते हैं (यानी संस्करण/निर्भरता प्रबंधन का लाभ उठाएं) [...]"

अधिक अनुकूलित बिल्ड बनाने का एक तरीका वास्तव में एक स्क्रिप्ट है जो आपकी निर्भरताओं को स्वचालित रूप से समझती है और आवश्यक मॉड्यूल को मंथन करती है।

अभी Bower & browserify आवश्यकता के साथ काम करता है, लेकिन वे एकमात्र समाधान नहीं हैं। मुझे नहीं पता कि अन्य ऑफ-द-शेल्फ ओपन सोर्स प्रोजेक्ट हैं जो ऐसा करता है (शायद एनजी-निर्भरता की तरह) लेकिन मैंने इससे पहले ऐसे टूल लिखे हैं, मुझे लगता है कि इन दर्दों को हल करने के लिए अन्य दृष्टिकोण होंगे।

Google का क्लोजर कंपाइलर ऐसा टूल हो सकता है?

उपयोगकर्ता के पक्ष में, क्या यह कुछ मदद की हो सकती है?
http://marcinwieprzkowicz.github.io/three.js-builder/

यह बहुत दिलचस्प है @erichlof :) मुझे आश्चर्य है कि क्या @marcinwieprzkowicz ने इसे हाथ से उत्पन्न किया है ... https://github.com/marcinwieprzkowicz/three.js-builder/blob/gh-pages/threejs-src/r66/modules.json

एक अभ्यास जो थ्री.जेएस का उपयोग करता है, जो सामान्य वातावरण में उपयोग करना मुश्किल बनाता है, वह है इंस्टेंस का उपयोग: https://github.com/mrdoob/three.js/blob/master/src/core/Geometry.js#L82

ऐसा इसलिए है क्योंकि किसी एप्लिकेशन में आप अक्सर अपने स्रोत ट्री में एक ही लाइब्रेरी के विभिन्न संस्करणों के साथ समाप्त होते हैं, इसलिए एक ही लाइब्रेरी के विभिन्न संस्करणों के बीच इंस्टॉफ़ की जाँच करना काम नहीं करता है। ज्यामिति.isGeometry(geom) शैली इंटरफ़ेस के पीछे फीचर-चेकिंग के साथ चेक के उन उदाहरणों को बदलने के लिए एक सामान्य मॉड्यूल सिस्टम के लिए एक कदम की तैयारी में अच्छा होगा।

git/three.js/src में:

grep -r instanceof . | wc -l 
164

git/three.js/examples में:

grep -r instanceof . | wc -l 
216

इसलिए तीन.जेएस में instanceof कुल 380 उपयोग हैं। प्रतिस्थापन के रूप में सबसे अच्छा कार्यान्वयन क्या होगा?

मैंने हाल ही में एक type संपत्ति जोड़ी है जिसका उपयोग उनमें से अधिकांश को बदलने के लिए किया जा सकता है।

मैंने हाल ही में एक प्रकार की संपत्ति जोड़ी है जिसका उपयोग उनमें से अधिकतर को बदलने के लिए किया जा सकता है।

अच्छा! पीआर तैयार करेंगे।

एक अन्य लोकप्रिय और बड़ी जेएस लाइब्रेरी में इसे कैसे संभाला जाता है, इसके उदाहरण के लिए https://github.com/facebook/react पर एक नज़र डालें। कोडबेस को नोड स्टाइल आधारित मॉड्यूल सिस्टम (जो ब्राउज़र को लागू करता है) का उपयोग करके संरचित किया गया है, लेकिन ग्रंट का उपयोग करके रिलीज के लिए बनाया गया है। यह समाधान 3 उपयोग के मामलों के लिए लचीला है।

1. थ्री.जेएस लेखन वैनिला JS का शुद्ध उपभोक्ता अभी भी हमेशा की तरह बिल्ड फ़ाइल का उपयोग कर सकता है। इस उपयोग के मामले में कोई बदलाव नहीं है।
2. ब्राउजर का उपयोग करने वाले थ्री.जेएस के उपभोक्ता एक परियोजना में तीन.जेएस को एक निर्भरता के रूप में घोषित कर सकते हैं और केवल require विशिष्ट निर्भरताएं घोषित कर सकते हैं। उचित निर्भरता प्रबंधन के लाभों को अच्छी तरह से प्रलेखित किया गया है।
3. Three.js में योगदान करना अब आसान होना चाहिए क्योंकि घटकों के बीच निर्भरता स्पष्ट रूप से प्रलेखित है।

मैंने कुछ शोध किया ...

कल मैंने एक (बल्कि बेवकूफ) स्क्रिप्ट को एक साथ हैक किया जो फाइलों के बीच निर्भरता घोषित करने के लिए CommonJS require() स्टेटमेंट का उपयोग करने के लिए Three.js स्रोत कोड को बदल देता है। बस देखने के लिए क्या होता है... यह:

1. यह समाप्त होता है बल्कि हास्यास्पद रूप से इस तरह के बयानों की आवश्यकता होती है (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');

हमें कुछ प्रमुख रिफैक्टरिंग की आवश्यकता होगी, शायद WebGLRenderer (और ऐसे) को कई मॉड्यूल में विभाजित करना (एटीएम फ़ाइल 6000 लाइनों से अधिक लंबी है)।

1. हमें GLSL विखंडू के लिए एक समाधान खोजने की जरूरत है। एटीएम उन फ़ाइलों को संकलन समय पर THREE.ShaderChunk में संकलित किया जाता है और फिर रनटाइम पर THREE.ShaderLib में ( THREE.ShaderChunk s के साथ मिलकर) जो कि केवल ब्राउज़र के साथ करना मुश्किल है। मुझे लगता है कि इसे एक ब्राउजराइज़ ट्रांसफॉर्म की आवश्यकता होगी जो वही करता है।

React.js अपने मॉड्यूल को फ़ाइल पथ द्वारा संदर्भित किए बिना देखने के लिए सामान्य का उपयोग करता है। हो सकता है कि हम ऐसा ही कर सकें और कस्टम नियमों को भी परिभाषित कर सकें जो हमें require GLSL फ़ाइलों को JS सिंटैक्स में बदलने की अनुमति देते हैं।

@rasteiner आपको https://github.com/stackgl/glslify के बारे में जानकर बहुत खुशी हो सकती है, यह बढ़ते http://stack.gl परिवार से आता है

मुझे पिछले कुछ महीनों में मॉड्यूल और "यूनिक्सी" दृष्टिकोण के साथ काफी अनुभव हुआ है और अब मेरा विचार यह है कि बहुत कम देर हो चुकी है, और मॉड्यूलरिटी या एनपीएम मॉड्यूल के लिए थ्रीजे को रिफैक्टर करना एक अवास्तविक लक्ष्य होगा।

यहाँ मैं वर्तमान में प्रतिरूपकता/पुन: प्रयोज्यता की समस्या से निपटने के लिए क्या कर रहा हूँ:

• मैं एनपीएम पर धुंध/एफएक्सएए/आदि के लिए कुछ पुन: प्रयोज्य शेडर्स डाल रहा हूं। यह देखो:
  https://www.npmjs.org/package/three-shader-fxaa (जो इंजन अज्ञेय glsl-fxaa का उपयोग करता है)
• OrbitController और EffectComposer जैसे पुन: प्रयोज्य घटकों को भी आवश्यकतानुसार प्रकाशित किया जा रहा है। जैसे:
  https://www.npmjs.org/package/three-orbit-controls
• "तीन" पर निर्भर होने के बजाय, ये मॉड्यूल एक फ़ंक्शन निर्यात करते हैं जो तीन लेता है, और उपयोगिता वर्ग देता है। इस तरह इसे ग्लोबल थ्रीज या कॉमनज के साथ इस्तेमाल किया जा सकता है।
• वर्जनिंग एक दर्द है। मैं अपने प्रमुख संस्करणों को तीनjs रिलीज़ नंबरों के साथ संरेखित करने का प्रयास कर रहा हूं। थ्रीजे के हर नए संस्करण में बहुत सारे ब्रेकिंग बदलाव होते हैं, इसलिए इसे सावधानी से संभालना होगा।
• मॉड्यूल जो गणित से संबंधित हैं, उन्हें केवल सरणियों पर काम करना चाहिए और मॉड्यूलर gl-vec3, gl-mat4, आदि का उपयोग करना चाहिए। इस तरह वे तीनj के बाहर सामान्य और उपयोगी हैं। फिर, तीनjs उपयोगकर्ताओं को केवल सरणियों में रैपिंग/अनरैपिंग को संभालना होगा। वर्लेट-सिस्टम, सरल-पथ, आदि देखें।
• अगर मुझे वास्तव में मॉड्यूलर या छोटी वेबजीएल सुविधा की आवश्यकता है, तो मैं आगे बढ़ने के लिए स्टैकग्ल/ग्लिस्लिफाई का उपयोग कर रहा हूं। जब तक आप जीएल स्थिति को रीसेट करते हैं, तब तक ये थ्रीजेएस के भीतर भी काम कर सकते हैं। जैसे: https://www.npmjs.org/package/gl-sprite-text

मेरी नई परियोजनाएं npm पर "तीन" का उपयोग केवल उठने और चलने के लिए करती हैं। यह बहुत बढ़िया होगा अगर थ्रीजेएस ने आधिकारिक तौर पर रिलीज नंबरों के साथ संरेखित संस्करण टैग का उपयोग करके एनपीएम को बिल्ड प्रकाशित किया।

पीएस: पुन: प्रयोज्य/मॉड्यूलर शेडर्स को अपने वर्कफ़्लो में लाने में रुचि रखने वालों के लिए:
https://gist.github.com/mattdesl/b04c90306ee0d2a412ab

मेरे आईफोन से भेजा गया

नवंबर 20, 2014, पर पसंद करें 7:42 AM पर, हारून [email protected] लिखा है:

@rasteiner आपको https://github.com/stackgl/glslify के बारे में जानकर बहुत खुशी हो सकती है, यह बढ़ते http://stack.gl परिवार से आता है

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

यदि यह अन्य लोगों की मदद करता है जो यह देख रहे हैं कि कैसे तीन.जेएस का उपयोग ब्राउज़र के साथ करना है, और इस धागे पर ठोकर खाई है, तो जिस तरह से मैंने इसे स्वयं सेट किया है, वह है browserify-shim का उपयोग करना।

_"आप कभी-कभी a) वैश्विक चर के माध्यम से वैश्विक चर का खुलासा करेंगे"_ पर README अनुभाग के बाद, मैंने तीन.जेएस के लिए एक अलग स्क्रिप्ट टैग शामिल किया और इसे वैश्विक तीन चर को उजागर करने के लिए कॉन्फ़िगर किया।

और फिर मुझे बस इतना ही काम करना था कि कोलाडालोडर, ऑर्बिटकंट्रोल इत्यादि जैसे अतिरिक्त कैसे शामिल किया जाए। मैंने इसे ऐसा किया:

पैकेज.जेसन से:

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

फिर मेरी अपनी लिपि में, 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 को संपूर्ण स्क्रिप्ट के पुनर्निर्माण की आवश्यकता होती है। मैं एक बार एक प्रोजेक्ट को पैक करने के लिए ब्राउजराइज़ का उपयोग करता हूं जिसके लिए तीन.जेएस की आवश्यकता होती है, फिर एक सीमा बनाने में दो सेकंड से अधिक समय लगता है और हर बार जब मैं कोई बदलाव करता हूं तो लाइवरेलोड को अवरुद्ध करता है। यह बहुत निराशाजनक है।

आप सामान्य रूप से विकास के दौरान livereload के साथ watchify का उपयोग करते हैं। वह क्रमिक रूप से बंडल बनाता है।

watchify मेरे लिए काम नहीं करता है। जब मैं एक फ़ाइल बदलता हूं और इसे सहेजता हूं, तो देखें और बीफ का लिवरलोड पुराने/कैश्ड संस्करण की सेवा करता है। मुझे नहीं पता कि ऐसा क्यों होता है। शुक्र है, browserify पहले से ही बहुत अच्छा काम करता है।

@ChiChou पास में --noparse=three ब्राउजराइज करने के लिए। यह मेरी मशीन पर ब्राउजराइज़ बंडल स्टेप को 1000ms से 500ms तक ले जाता है, जो कि तत्काल फीडबैक फील के लिए पर्याप्त है।

@rasteiner मैं तीन.जेएस अंतर-निर्भरता में आपके अनौपचारिक शोध के लिए फिर से आपको धन्यवाद देना चाहता हूं। जबकि डिपो की वह विशाल सूची कुछ बदसूरत दिखने वाला कोड है, वास्तव में वह कुरूपता मौजूद है, बस अदृश्य है। Browserify की ताकत यह है कि हमें अपने गंदे कपड़े धोने और कम पेचीदा सिस्टम का पीछा करने की आवश्यकता होती है।

थ्री.जे में ऐसे बहुत से स्थान हैं जहां हम किसी वस्तु को लेते हैं, उसके प्रकार को समझते हैं, और उस प्रकार के आधार पर विभिन्न कार्य करते हैं। उनमें से अधिकतर मामलों में, उस प्रकार-निर्भर कोड को स्वयं प्रकार में स्थानांतरित किया जा सकता है, और हमें उन सभी संभावित प्रकारों की समझ नहीं होगी जिन पर हम काम कर रहे हैं।

निम्नलिखित WebGLRenderer का एक संक्षिप्त उदाहरण है:

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

फॉर्म का अधिक होना चाहिए

texture.processTexImage( _gl, mipmaps, otherData )

प्रकार को यह निर्धारित करने दें कि स्वयं को कैसे संभालना है। यह पुस्तकालय उपभोक्ता को उन उपन्यास बनावट प्रकारों का उपयोग करने की भी अनुमति देता है जिनके बारे में हमने सोचा नहीं था। इस संरचना को अन्योन्याश्रितता को कम करना चाहिए।

मुझे लगता है कि ब्राउजराइज़ आर्किटेक्चर में जाना निश्चित रूप से जाने का रास्ता है। UMD बिल्ड से तीन.js की खपत आसान हो जाएगी। यह हमें WebGLRenderer को कई फाइलों में विभाजित करने की भी अनुमति देगा, क्योंकि अभी यह अखंड और डरावना दिखता है।

मैंने एक शाखा शुरू की है जहाँ मैं वर्तमान में इसे यहाँ ले जाने पर काम कर रहा हूँ: https://github.com/coballast/three.js/tree/browserify-build-system

मुझे बताओ कि तुम क्या सोचते हो।

यहाँ @coballast के परिवर्तन हैं ।

ऐसा लगता है कि आप अपनी browserifyify.js फ़ाइल के साथ स्वचालित रूपांतरण दृष्टिकोण अपना रहे हैं, जो मुझे लगता है कि जाने का सही तरीका है।

एक बात जिस पर हम सभी ने अभी तक ज्यादा चर्चा नहीं की है, वह यह है कि इस बड़े, हमेशा बदलते पुस्तकालय को ब्राउज़र में बदलने के लिए सबसे अच्छा कैसे है। आप परिवर्तन कर सकते हैं और फिर एक पीआर खोल सकते हैं, लेकिन यह तुरंत पुराना हो जाएगा। स्वचालित दृष्टिकोण के बारे में यही सम्मोहक है।

अगर हम यह कर सकते हैं:

• एक तीन.js स्रोत रूपांतरण स्क्रिप्ट प्रदान करें (जैसे आपकी browserifyify.js )
• एक दस्तावेज़ प्रदान करें जो बताता है कि रूपांतरण प्रक्रिया कैसे काम करती है
• एक दस्तावेज़ प्रदान करें जो बताता है कि नया बिल्ड सिस्टम कैसे काम करता है
• रूपांतरण के बाद परीक्षण चलाएँ
• मौजूदा फ़ाइलों में कोई भी परिवर्तन शामिल न करें जिससे मर्ज विरोध हो सकता है

...तो हम इसे एक पुश-बटन रूपांतरण में बदल सकते हैं जो अभी भी निकट भविष्य में काम करेगा। वह सादगी एक मौलिक वास्तुकला की इस स्वप्निल धारणा को इतनी बड़ी परियोजना में बदलने में सक्षम बनाती है जब वैचारिक तर्क जीत जाते हैं।

@coballast उस अंत तक, मैं src/Three.js में परिवर्तन हटा

नोट: न केवल पूर्ववत करें, बल्कि शाखा के इतिहास से उन परिवर्तनों को एक नई शाखा या बल धक्का के माध्यम से हटा दें

@coballast मुझे आश्चर्य है कि क्या रूपांतरण उपयोगिता के लिए three.js का कांटा नहीं होना अधिक समझ में आता है, लेकिन एक बाहरी उपयोगिता जिसे आप three.js विकास डीआईआर पर इंगित करते हैं, और यह स्रोत को परिवर्तित करता है फ़ाइलें, एक बिल्ड स्क्रिप्ट जोड़ता है, और परीक्षण चलाता है।

@kumavis मैं अकेले src निर्देशिका छोड़ने से सहमत हूं। मुझे लगता है कि करने की बात यह है कि उपयोगिता कॉमनज कोड के साथ एक डुप्लिकेट निर्देशिका लिखती है, और हम कुछ भी बड़ा करने का प्रयास करने से पहले उदाहरण सभी काम करने के लिए सुनिश्चित करने के लिए वहां से ब्राउजराइज बिल्ड का परीक्षण और चला सकते हैं।

यहां कुछ स्थिर विश्लेषण सामग्री लिखने का एक दिलचस्प अवसर भी है जो स्वचालित रूप से संपूर्ण कोडबेस में सुसंगत शैली की जांच करेगा और लागू करेगा।

@coballast बहुत अच्छा लगता है।
स्वचालित कोड पुनर्लेखन के लिए बहुत सारे उपकरण हैं, जैसे escodegen । यह सुनिश्चित करने की आवश्यकता है कि हम टिप्पणियां आदि बनाए रख रहे हैं।
तीनjs-रूपांतरण-उपयोगिता रेपो शुरू करना चाहते हैं?

@coballast ने कहा, इस उपयोगिता के लिए एक तेज फोकस बनाए रखना महत्वपूर्ण है

@ कुमाविस इसे पूरा करने पर विचार करें। मैं वास्तव में चाहता हूं कि ऐसा हो। यह उन दो परियोजनाओं में से केवल एक है जिन पर मैं इस समय काम कर रहा हूं।

@kumavis @mrdoob यहां कुछ चर्चा तीन को कई अलग-अलग मॉड्यूल में विभाजित करने के विचार के आसपास प्रतीत होती है जिसे संभावित रूप से एनपीएम के माध्यम से स्थापित किया जा सकता है और फिर ब्राउज़र के साथ संकलित किया जा सकता है। मैं इस विचार के बिल्कुल खिलाफ नहीं हूं, लेकिन मुझे लगता है कि यह एक अलग मुद्दा होना चाहिए। इस बिंदु पर मैं केवल एक चीज की वकालत कर रहा हूं, आंतरिक रूप से तीन के कोडबेस को प्रबंधित करने के लिए ब्राउज़र का उपयोग कर रहा है। इसे स्थानांतरित करें, और इसे उसी तरह से काम करें जैसे यह हमेशा उपयोगकर्ताओं के लिए होता है, और फिर मूल्यांकन करें कि क्या समझ में आता है।

मैं यह देखने के लिए उत्सुक हूं कि उस उपयोगिता का आउटपुट क्या है ^^

@coballast हमारे लिए ट्रैक करने के लिए एक रेपो लिंक करता है, भले ही वह इस बिंदु पर खाली हो। हम वहां से निर्माण कर सकते हैं।

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

कोड एक गड़बड़ है, जल्द ही साफ हो जाएगा।

ये रहा! :रॉकेट:

अब मेरे पास ऐसी स्थिति में उपयोगिता है जहां यह ब्राउज़रीकृत स्रोत उत्पन्न करता है और बिना किसी समस्या के इसे बनाएगा। मैं रेपो को इस निर्देश के साथ अपडेट करूंगा कि इसे स्वयं कैसे करें। इस बिंदु पर, उदाहरण काम नहीं करते। ऐसे कई मुद्दे हैं जिनसे निपटने के लिए इसे ठीक करने की आवश्यकता है। अगर कोई अपनी आस्तीन ऊपर करना चाहता है और मदद करना चाहता है तो मैं उन्हें रेपो में जोड़ दूंगा।

@coballast हाँ कृपया मुद्दों को कूदेंगे जैसा हम कर सकते हैं।

गंभीर समस्याएं सामने आई हैं। देखें #6241

यहाँ मेरा विश्लेषण है कि इसे काम करने के लिए क्या करना होगा: https://github.com/coballast/threejs-browserify-conversion-utility/issues/9#issuecomment -83147463

इसके डिजाइन के कारण browserify कम से कम परिवहन अनावश्यक (congestive) पर है। यह इसके उपयोग की लागत को बढ़ा देता है (डेटा प्लान किसी को भी?) और धीमा।

इसका एक सरल उपाय यह है कि दस्तावेज़ को लाइब्रेरी कोड से अलग किया जाए, जिसमें दो क्लाइंट फ़ाइलें होंगी और एक नहीं। क्लाइंट साइड जेएस के लिए यह आम बात है।

अगर शुरुआत में ब्राउजराइज दोषपूर्ण है और खुद को ठीक करने की जरूरत है तो मैं शायद ही यह देख सकता हूं कि इसे कुछ भी सुधारने के लिए क्यों माना जाना चाहिए, अकेले कुछ जैसे थ्रीजे।

@spaesani क्योंकि

यदि किसी कारण से आप अभी भी "दस्तावेज़ को लाइब्रेरी कोड से अलग करना चाहते हैं", तो आप अभी भी ऐसा कर सकते हैं और पूर्व-निर्मित संस्करण का उपयोग कर सकते हैं जैसे हम अभी करते हैं। आप --standalone और --exclude फ़्लैग का उपयोग करके अपने

Browserify ब्राउज़र पर युद्ध सिद्ध मॉड्यूल परिभाषा API (CommonJS) का उपयोग करने का एक तरीका है। यह थ्रीजेएस प्लगइन्स के विकास को बहुत सरल करेगा और कोड स्पष्टता और इसलिए उत्पादकता को बढ़ाएगा, यह हमें एक बड़े पारिस्थितिकी तंत्र (एनपीएम) में एकीकृत करने की अनुमति देगा, जहां संस्करण प्रणाली के माध्यम से अखंडता बनाए रखते हुए कोड को अधिक लोगों द्वारा स्वाभाविक रूप से बनाए रखा जाता है (इसके बारे में सोचें) स्टैकग्ल परिवार), और अगर वे इसे नहीं चाहते हैं तो यह लोगों को

बेशक इसमें कमियां हैं, लेकिन वे वे नहीं हैं जिनका आपने उल्लेख किया है।

थ्री.जेएस और थ्री.मिन.जेएस को प्रॉक्सी, कॉमन मोबाइल सॉल्यूशन या कैशिंग ब्राउजर के जरिए ट्रांसपोर्ट (डेटा) पर सेव करने के लिए कैश किया जा सकता है।
जिस क्षण आप चेरी चुनते हैं और दस्तावेज़ विशिष्ट कोड के साथ थ्रीजेएस कोड एकत्र करते हैं, कैशिंग संभव नहीं है।
यदि browserify एक को अनुमति देता है