यह काफी उलझी हुई गाँठ है
http://jsbin.com/medezu/2/edit?html ,js,output

@coballast क्या आप उस कोड को पोस्ट कर सकते हैं जिसका उपयोग आपने निर्भरता जेसन उत्पन्न करने के लिए किया था?

बस पहले से तैयार तीन.min.js फ़ाइल का सीधे उपयोग करें। Browserfy के भीतर तीन.js को अलग-अलग फाइलों में विभाजित करने की कोई आवश्यकता नहीं है, आप बिना किसी वास्तविक लाभ के अपने जीवन को और अधिक कठिन बना रहे हैं।

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

इस उपयोग के मामले के लिए इस गाँठ को खोलना आवश्यक नहीं है।

@ कुमाविस मैंने अभी निर्भरता संरचना को छोड़ दिया है। निम्नलिखित कोड ने फिर ग्राफ उत्पन्न किया:

var fs = require('fs-extra');
var unique = require('uniq');
var util = require('util');

function getRequiredObjects(dependencies){
  var result = [];
  for(var i = 0; i < dependencies.usedObjects.length; i++){
    var object = dependencies.usedObjects[i];
    if(dependencies.definedObjects.indexOf(object) == -1)
      result.push(object);
  }

  return result;
};

var dependencies = JSON.parse(fs.readFileSync('./dependencies.json'));

var objects = [];
for(var f in dependencies){
  objects = objects.concat(dependencies[f].usedObjects);
  objects = objects.concat(dependencies[f].definedObjects);
}

objects = unique(objects);


var nodes = objects.map(function(o){
  return {data: {id: o} };
});

var edges = [];
for(var f in dependencies){
  var dependency = dependencies[f];
  var requiredObjects = getRequiredObjects(dependency);
  for(var j = 0; j < dependency.definedObjects.length; j++){
    for(var k = 0; k < requiredObjects.length; k++){
      edges.push({ data: { source: dependency.definedObjects[j], target: requiredObjects[k] } });
    }
  }
}

var graph = {nodes: nodes, edges: edges};

var eliminateImpossibleCycleNodes = function(graph){
  graph.nodes = graph.nodes.filter(function(node){
    var source_edge = null;
    var dest_edge = null;
    for(var i = 0; i < graph.edges.length; i++){
      if(graph.edges[i].data.source == node.data.id)
        source_edge = graph.edges[i];
      if(graph.edges[i].data.target == node.data.id)
        dest_edge = graph.edges[i];
    }

    if(source_edge != null && dest_edge != null)
      return true;
    else
      return false;
  });

  graph.edges = graph.edges.filter(function(edge){
    var source_exists = false, target_exists = false;
    for(var i = 0; i < graph.nodes.length; i++){
      if(edge.data.source == graph.nodes[i].data.id)
        source_exists = true;
      if(edge.data.target == graph.nodes[i].data.id)
        target_exists = true;
    }

    return source_exists && target_exists;
  });
};

for(var i = 0; i < 500; i++)
  eliminateImpossibleCycleNodes(graph)


console.log(JSON.stringify(graph));

@bhouston इसके तीन के स्वास्थ्य के बारे में अधिक है। जेएस कोडबेस

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

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

यहाँ एक मामला है जो सूक्ष्म जटिलताओं को दर्शाता है। स्पष्ट होने के लिए, यहाँ मैं स्वयं कार्यान्वयन की आलोचना नहीं कर रहा हूँ, बल्कि दुष्प्रभावों की।

Vector3 और Matrix4 एक चक्रीय निर्भरता बनाते हैं क्योंकि वे कई प्रकार के कार्यों को उजागर करते हैं जो एक दूसरे को इनपुट या आउटपुट प्रकार के रूप में उपयोग करते हैं। दोनों को थ्री.जेएस की सामान्य शैली के साथ लागू किया गया है, गणना करने के लिए स्क्रैच वैरिएबल को शामिल करने के लिए आईआईएफई के माध्यम से कार्यों को परिभाषित करना।

Matrix4#lookAt फ़ंक्शन परिभाषा के हिस्से के रूप में, तुरंत खरोंच को तुरंत चालू करने में सक्षम है।

lookAt: function () {

  var x = new THREE.Vector3();
  var y = new THREE.Vector3();
  var z = new THREE.Vector3();

  return function ( eye, target, up ) {
    /* ... */

Vector3#project हालांकि, पहले रन पर स्क्रैच को तुरंत चालू करना चाहिए।

project: function () {

  var matrix;

  return function ( camera ) {

    if ( matrix === undefined ) matrix = new THREE.Matrix4();

    /* ... */

क्यों? क्योंकि कक्षा को परिभाषित करते समय, सभी वर्गों को अभी तक परिभाषित नहीं किया गया है। Vector3 को परिभाषित करते समय, Matrix4 अभी तक मौजूद नहीं है। अब स्क्रैच वेरिएबल्स का वास्तविक तात्कालिकता समय वास्तव में महत्वपूर्ण नहीं है। यहां वास्तविक टेकअवे यह है कि वर्तमान कार्यान्वयन इस क्रम पर टिका है कि बिल्ड सिस्टम फाइलों को एक साथ जोड़ता है। यह वास्तव में एक दूर का युग्मन है, और बिल्ड सिस्टम में परिवर्तन या फाइलों का नाम इस तरह से बदलना कि यह कॉन्सैट ऑर्डर को बदल देता है, जिसके परिणामस्वरूप कोई स्पष्ट कनेक्शन नहीं होता है।

यह सिर्फ एक तरीका है कि यह गाँठ बग में प्रकट होता है। हालांकि, जबकि हम इस विशिष्ट मुद्दे को संबोधित कर सकते हैं, मेरे पास एक सामान्य समाधान नहीं है जिसके लिए एपीआई में बहुत सारे ब्रेकिंग परिवर्तनों की आवश्यकता नहीं है।

हम्म... मैंने ILM के C++ गणित पुस्तकालय पर एक नज़र डाली, जिसे मैं गणित पुस्तकालयों के संदर्भ में स्वर्ण मानक मानता हूँ। आश्चर्यजनक रूप से, वे चक्रीय नहीं हैं। उनके पास मूल रूप से सरल से जटिल प्रकारों का एक अच्छी तरह से परिभाषित क्रम है जिसे वे परिभाषित करते हैं और मुझे लगता है कि यदि आप इसे बहुत सावधानी से करते हैं तो यह काम करता है:

https://github.com/openexr/openexr/tree/master/IlmBase/Imath

गणित और फिर Vec सबसे सरल लगता है।

निर्भरता ग्राफ पर और अवलोकन:

Material s में उनके आधार वर्ग के साथ दो-तरफ़ा विवरण हैं

देखने में थोड़ा मुश्किल है, लेकिन लगता है कि Geometry s का आधार वर्ग पर अच्छा एकतरफा विवरण है

Light s और Camera s की स्थिति समान है - उनके आधार वर्ग के संबंध में अच्छा है, लेकिन Object3D की निर्भरता _उन पर_ अनावश्यक लगती है।


Curve s Path s Line s अच्छे लगते हैं, लेकिन Shape थोड़ा उलझा हुआ है।

@ कोबलास्ट धन्यवाद! यह महान अंतर्दृष्टि है।

टिप्पणियों के लिए खुद को जोड़ना :)

बीटीडब्ल्यू, मैंने उस तरह से देखा है जिस तरह से सामग्री MeshDepthMaterial पर निर्भर करती है, उदाहरण के लिए। यह सरल है

if ( this instanceof THREE.MeshDepthMaterial )

जिसे बदलने के लिए तुच्छ है

if ( this.type == 'MeshDepthMaterial' )

और वोइला - कोई निर्भरता नहीं। मुझे लगता है कि इस डरावने ग्राफ का आधा हिस्सा समान स्तर की समस्या है।

मजेदार बात यह है कि यह निर्भरता सिंगल टूJSON मेथड में होती है। मेरा मतलब है, क्या इसे इसके बजाय सिर्फ MeshDepthMaterial में बदला नहीं जा सकता है? कुछ इस तरह

THREE.MeshDepthMaterial.prototype.toJSON =  function () {
    var output = THREE.Material.prototype.toJSON.apply(this);
    if ( this.blending !== THREE.NormalBlending ) output.blending = this.blending;
    if ( this.side !== THREE.FrontSide ) output.side = this.side;

@makc सामान्य तौर पर हम कहीं भी instanceof कर रहे हैं, हमें उस कोड को विशिष्ट वर्ग में ही ले जाना चाहिए। यह बहुत सारी गांठों को हटाने में मदद करेगा।

सिर्फ यह कहना चाहता था कि एएमडी परिपत्र संदर्भों का समर्थन नहीं करता है, ES6 मॉड्यूल करता है https://github.com/ModuleLoader/es6-module-loader/wiki/Circular-References-&-Bindings

मैं निर्भरता समाधान समस्या के अलावा जानने के लिए उत्सुक हूं (जिसे मॉड्यूल सिस्टम लोडर जैसे सिस्टम.जेएस के कार्यान्वयन में हल किया जा सकता है), थ्री.जेएस में सर्कुलर रेफरेंसिंग से कौन से मुद्दे बनते हैं?

सौभाग्य से ऐसा लगता है कि हम इस पर चरणों में हमला कर सकते हैं। मुझे लगता है कि पिछले रिलीज में बहुत सारे एपीआई ब्रेकिंग बदलाव किए गए हैं, इसलिए मुझे यकीन नहीं है कि यह सवाल से बाहर है।

instanceof मामलों (शायद बहुमत) के लिए उन्हें परिवर्तनों को तोड़ने के साथ हल करने में सक्षम होना चाहिए।

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

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

@ zz85 मैंने परिपत्र निर्भरता की समस्या में भी भाग लिया है। यह ज्यादातर एक समस्या है जब हम सर्कुलर संदर्भित फाइलों के अंदर कुछ वस्तुओं को पूर्व-निर्मित करने का प्रयास कर रहे हैं।

6252 को Material और Object3D पर बहुत सारे सर्कुलर डिप्स को साफ़ करना चाहिए।

यहाँ Mesh कैसा दिखता है। हो सकता है कि कुछ बाहरी अवतरण हों लेकिन बहुत अधिक पागल न हों।

Object3D और Geometry के साथ परिपत्र। उपरोक्त पीआर में Object3D -> Mesh संदर्भ को संबोधित किया गया है। Mesh -> Geometry संदर्भ ठीक है, b/c Mesh Geometry के उदाहरण को नियंत्रित करता है। इसे अभी भी b/c से तोड़ा जा सकता है जो वर्ग-विशिष्ट व्यवहार ( Geometry / BufferGeometry ) के लिए टाइप-चेकिंग कर रहा है।

जहां तक Geometry -> Mesh संदर्भ की बात है, तो यह geometry.mergeMesh( mesh ) प्रदान करना है। Geometry Mesh की तुलना में निचले स्तर की अवधारणा है, इसलिए मैं इसे mesh.mergeIntoGeometry( geo ) के रूप में उलटा कर दूंगा और mergeMesh को हटा दूंगा।

अगर किसी को पीआर मर्ज किया जाता है जो इनमें से कुछ को ठीक करता है, तो मुझे बताएं और मैं वर्तमान स्थिति को दर्शाने के लिए ग्राफ को अपडेट करूंगा।

@ बौस्टन @ जीरो 3 मुझे विश्वास नहीं है कि गणित पुस्तकालय के लिए समान स्तर की उपयोगिता/उपयोगिता प्राप्त करने के लिए चक्रीय निर्भरताओं की आवश्यकता होती है। मैं गलत हो सकता था, लेकिन क्या हम वेक्टर3 को बाकी सिस्टम से पूरी तरह से अलग/अनभिज्ञ नहीं रख सकते थे और मैट्रिक्स 4 मॉड्यूल में मैट्रिक्स 4 को समायोजित करने के लिए इसके प्रोटोटाइप को संशोधित नहीं कर सकते थे? यह मेरे लिए अवधारणात्मक रूप से समझ में आता है, क्योंकि मैट्रिसेस वेक्टरों की तुलना में अधिक जटिल हैं। मुझे लगता है कि एक अच्छी तरह से परिभाषित आदेश होना बेहतर है जिसमें दुर्घटनाओं को रोकने के लिए प्रोटोटाइप और कक्षाओं का निर्माण किया जाता है।

@ बौस्टन @ जीरो 3 मुझे लगता है कि हम एपीआई को बदले बिना ऐसा करने में सक्षम हो सकते हैं। मैं चारों ओर प्रहार करूँगा और देखूँगा कि क्या है।

गणित की बात के बारे में, मुझे लगता है कि आप सभी "स्क्रैच पैड" एक ही स्थान पर बैठ सकते हैं। लेकिन मैं शर्त लगाता हूं कि 3js का एक भी प्रयोग करने योग्य ग्राफ नहीं होगा जिसमें वेक्टर 3 और मैट्रिक्स 4 दोनों नहीं होंगे

यदि कोई समाधान है जो गणित पुस्तकालय के प्रदर्शन या एपीआई को नहीं बदलता है, तो मैं इसके लिए तैयार हूं।

@coblast एक एपीआई परिवर्तन के चक्रीय डीपी को हटा नहीं सकता है, बी/सी दोनों अन्य प्रकार का उपयोग करने वाले तरीकों को प्रदान करते हैं। Vector3 Matrix4

जहां तक ​​ब्राउज़र की बात है, तो हमारी एकमात्र आवश्यकता स्क्रैच वर्र्स पर इंस्टेंटेशन को क्लास-डेफिनिशन टाइम से बाहर ले जाने की है (पहले रन पर उन्हें इंस्टेंट करें)। इस तरह आलसी बनाओ । इसका API या perf पर कोई प्रभाव नहीं पड़ेगा।

मुझे लगता है कि इस प्रकार के बदलाव ठीक हैं।

@ कुमाविस आह! हां। अच्छा अब मैं समझ गया। यह काफी आसान है।

मैं निम्नलिखित कारणों से आवश्यक संरचना के साथ तीन छोटे मॉड्यूल में विभाजित होने का पूरी तरह से समर्थन करता हूं:

1. तीन बहुत बड़ा है। यदि किसी उपयोगकर्ता को केवल वही चाहिए जो उन्हें चाहिए तो क्लाइंट बिल्ड आकार में कटौती हो सकती है। उदाहरण के लिए प्रतिक्रिया-बूटस्ट्रैप आपको var Alert = require('react-bootstrap/lib/Alert'); जैसी चीजें करने देता है जो प्रत्येक बूटस्ट्रैप मॉड्यूल को बंडल नहीं करता है।
2. कुछ "प्लगइन्स" हैं, जैसे OrbitControls.js जो स्वयं को THREE.OrbitControls पर डालते हुए, तीन वैश्विक ऑब्जेक्ट को संशोधित करते हैं। यह आधुनिक जावास्क्रिप्ट ढांचे में एक विरोधी पैटर्न है क्योंकि इसके लिए आवश्यक फाइलों की आवश्यकता के बजाय, निर्माण प्रक्रिया में वैश्विक नामस्थान पर तीन उपस्थित होने की आवश्यकता होती है। तीन भी आंतरिक रूप से ऐसा करते हैं, हमेशा तीन नामस्थान को संशोधित करते हैं, जो विशिष्ट तीन मॉड्यूल को शामिल करने के लिए आदर्श नहीं है।

खुद को तीन पर रखना। OrbitControls

लेकिन 3js में कोड का प्रत्येक टुकड़ा ऐसा करता है?

@DelvarWorld ने लिखा:

मैं निम्नलिखित कारणों से आवश्यक संरचना के साथ तीन छोटे मॉड्यूल में विभाजित होने का पूरी तरह से समर्थन करता हूं:

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

@makc की तरह, मैं भी @DelvarWorld के तीन नामस्थानों में चीजों को न रखने के सुझाव से हैरान हूं।

इसके बजाय वे कहाँ/कैसे होंगे?

मेरे लिए यह केवल एक वैश्विक वस्तु, तीन बनाने के लिए अच्छे पैटर्न की तरह लगता है, जिसमें इसके सभी भाग (और संभवतः कुछ एक्सटेंशन/प्लगइन्स) हैं।

मैं @DelvarWorld से सहमत हूं कि पुट-ऑन-द-ग्लोबल तकनीक कोडबेस के स्वास्थ्य के लिए अच्छी नहीं है - यह एक प्रकार का सूक्ष्म तर्क है b/c इसे वैश्विक पर रखना समस्या नहीं है, इसकी छिपी निर्भरता ग्राफ, और अन्य प्रथाएं जो वैश्विक उपलब्ध होने से निकलती हैं।

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

एक काउंटर तर्क यह है कि जब एक तीन.जेएस दृश्य जेसन को deserializing, प्रविष्टियां केवल अपनी कक्षा को एक स्ट्रिंग के रूप में सूचीबद्ध कर सकती हैं जिसे वैश्विक से खींचा जा सकता है: THREE[ obj.type ] । यह उन कक्षाओं के साथ काम करता है जो मानक तीन.js lib में नहीं हैं, जब तक कि आप उन्हें deserialize करने से पहले THREE पर परिभाषित करते हैं। सुनिश्चित नहीं है कि इस व्यवहार को THREE वैश्विक के बिना कैसे बदला जाए।

यह उन कक्षाओं के साथ काम करता है जो मानक तीन.जेएस लिब में नहीं हैं, जब तक कि आप उन्हें डिसेरिएलाइज़ करने से पहले तीन पर परिभाषित करते हैं। सुनिश्चित नहीं है कि थ्री ग्लोबल के बिना इस व्यवहार को कैसे बदला जाए।

यदि सब कुछ एक मॉड्यूल है तो आप यह पैटर्न (या इसके कुछ प्रकार) कर सकते हैं:

var objectType = require( "THREE." + obj.type );

मॉड्यूल के संबंध में ES6 के साथ बहुत सारे बदलाव आ रहे हैं। मैं उस समय थ्रीजेएस की प्रतिरूपकता पर फिर से विचार करूंगा।

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

var THREE = {
    Geometry: require("./geometry"),

आदि, जो अभी भी नवागंतुकों के लिए उपयोगी होगा, और आरंभ करना आसान होगा।

आधुनिक जावास्क्रिप्ट बिल्ड में npm और requjs/browserify/webpack से तीन का उपयोग करने वालों के लिए, हम कुछ ऐसा कर सकते हैं

var Scene = require("three/scene"),
     Camera = require("three/camera"),

आदि, जो क्लाइंट आकार बंडल में निर्मित तीन के आकार में से कुछ में कटौती कर सकता है। मैं गलत हो सकता था क्योंकि मुझे नहीं पता कि तीन में से कितना "कोर" है। अभी, हालांकि, यह असंभव है क्योंकि तीन आवश्यक कथनों का उपयोग नहीं करते हैं।

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

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

बस @DelvarWorld से अवगत रहें कि ES6 एक बहुत ही विशिष्ट और विशिष्ट सिंटैक्स के साथ आधिकारिक तौर पर जावास्क्रिप्ट में मॉड्यूल पेश करता है:

http://www.2ality.com/2014/09/es6-modules- final.html

@bhouston ओह हाँ पूरी तरह से, मैं बनाम आयात की आवश्यकता के लिए अज्ञेय हूं (आयात शायद बेहतर विकल्प है), बस सामान्य रूप से मॉड्यूल पैटर्न का समर्थन करता है।

@bhouston @DelvarWorld @kumavis मेरी लंबी अवधि की परियोजनाओं में से एक स्वचालित es5 -> es6 कनवर्टर लिखना है जो आम/एएमडी मॉड्यूल को es6 में समायोजित और परिवर्तित कर सकता है, और उम्मीद है कि कक्षाओं/जेनरेटर जैसे ईएस 6 संरचनाओं का उपयोग करके बहुत सी जावास्क्रिप्ट की पहचान और पुनर्लेखन करें और इसी तरह। जब ब्राउजर उपभोग के लिए कोड तैयार करने के लिए मानक तक पहुंच रहे हों, तो कोई es6ify जैसे ब्राउजराइज ट्रांसफॉर्म का उपयोग कर सकता है। केवल आंतरिक स्तर पर ब्राउज करने के लिए थ्री को स्थानांतरित करना ऐसे टूल के इनपुट के लिए इसे तैयार करने के लिए एक अच्छा पहला कदम है।

यह उस बिंदु के बगल में है जिसे मैं (जाहिरा तौर पर बहुत खराब) बनाने की कोशिश कर रहा था। मैं जितना संभव हो सके इन चक्रीय निर्भरताओं को हटाना चाहता हूं, किसी भी मॉड्यूलरिटी चिंताओं से स्वतंत्र, क्योंकि मेरा मानना ​​​​है कि यह तीन को और अधिक स्थिर, लचीला बना देगा, और शायद सुखद साइड इफेक्ट के रूप में बहुत सारी बग को खत्म कर देगा।

@coballast https://github.com/mrdoob/three.js/pull/6252 विलय कर दिया गया था, बहुत सारे चक्रीय डिपो में कटौती करनी चाहिए। लगता है कि आप एक नया डीपी ग्राफ उत्पन्न कर सकते हैं? शायद इसे रूपांतरण उपकरण रेपो में उपयोगिता बनाएं

अगला है: स्क्रैच वार्स बनाना Vector3 Matrix4 पहले उपयोग पर आलसी परिभाषित, परिभाषा समय पर नहीं

कोई स्वयंसेवक करना चाहता है? जल्दी होना चाहिए

ग्राफ अपडेट किया गया है। http://jsbin.com/medezu/3/

यहाँ एक स्क्रीनशॉट है:

मुझे यह बताते हुए खुशी हो रही है कि बड़ी संख्या में Object3Ds सर्किल डिपो समाप्त कर दिए गए हैं। अच्छा काम @kumavis!

वाह क्या वही कोडबेस है? पागल

ग्राफ जनरेशन को यूटिलिटी का हिस्सा बनाने पर काम करेंगे।

अकेले ग्राफ के निरीक्षण पर, Shape और Geometry संभव वर्ग के पेड़ प्रतीत होते हैं जिन्हें सुलझाया जा सकता है।

@coballast को लगता है कि आप इसे ले सकते हैं?

वेक्टर 3 मैट्रिक्स 4 में स्क्रैच वर्र्स बनाना पहले उपयोग पर आलसी परिभाषित करता है, परिभाषा समय पर नहीं

यह एक स्वचालित परिवर्तन के विपरीत अपस्ट्रीम dev के खिलाफ एक पीआर होगा

इसके अलावा, मुझे लगता है कि हम "गंभीर चक्रीय निर्भरता समस्याओं" से "चक्रीय निर्भरता" के मुद्दे के शीर्षक को डाउनग्रेड कर सकते हैं - स्थिति में बहुत सुधार हुआ है!

@ कुमाविस निश्चित बात। समय मिलने पर इस पर काम करेंगे।

यहाँ अन्योन्याश्रय सफाई की वर्तमान स्थिति है जैसा कि मैं इसे देख रहा हूँ:
(तीर ऐसे कनेक्शन दिखाते हैं जिन्हें उपयुक्त होने पर हटा दिया जाना चाहिए)

• [एक्स] सामग्री
• [x] ज्यामिति
• [x] ऑब्जेक्ट 3डी's
• [एक्स] मठ
• [x] आकार
  
  
  
  • [x] आकार -> FontUtils
  
  
  • [x] आकार -> ExtrudeGeometry
  
  
  • [x] आकार -> आकार ज्यामिति
  
  
  • [x] पथ -> आकार
  
  
• [] बॉक्स3
  
  
  
  • [ ] Box3 -> BufferGeometry
  
  
  • [] Box3 -> ज्यामिति
  
  

आकार:

बॉक्स3:

गणित:

ये नोड्स आपस में जुड़े हुए हैं, लेकिन इसके माध्यम से पर्याप्त सुविधा प्रदान करते हैं।

आकार इस तरह कोड के माध्यम से ExtrudeGeometry और ShapeGeometry के साथ निर्भरता लगता है:

// Convenience method to return ExtrudeGeometry

THREE.Shape.prototype.extrude = function ( options ) {

  var extruded = new THREE.ExtrudeGeometry( this, options );
  return extruded;

};

// Convenience method to return ShapeGeometry

THREE.Shape.prototype.makeGeometry = function ( options ) {

  var geometry = new THREE.ShapeGeometry( this, options );
  return geometry;

};

अब ऐसा प्रतीत होता है कि Shape Path एक उपवर्ग है, और ExtrudeGeometry और ShapeGeometry दोनों Geometry के उपवर्ग हैं। तो, पता है, आप यह पता लगा सकते हैं कि आदर्श मामले में किन निर्भरताओं को दूर करने की आवश्यकता होगी।

हाँ यह उसी श्रेणी में आता है जैसे Vector3 <-> Matrix4 । वे सुविधा के लिए जुड़े हुए हैं। मुझे लगता है कि यह एक बुरा विचार है लेकिन इससे लड़ने लायक नहीं है। मैं इसे पूर्ण के रूप में चिह्नित करूँगा

Shape -> FontUtils को triangulate जैसी मूविंग विधियों का उपयोग करके अधिक सामान्य यूटिल्स में हटाया जा सकता है। लेकिन ऐसा करना कोई बड़ी जीत नहीं है। इसे पूर्ण के रूप में चिह्नित करने जा रहे हैं।

Box3 -> BufferGeometry और Box3 -> Geometry दोनों को साफ किया जा सकता है।

इसका एक और मामला वर्ग-निर्भर व्यवहार को कक्षा में ही नहीं डालने का है।

स्रोत :

setFromObject: function () {

  // Computes the world-axis-aligned bounding box of an object (including its children),
  // accounting for both the object's, and childrens', world transforms

  /* ... */

  if ( geometry instanceof THREE.Geometry ) {
    /* ... */
  } else if ( geometry instanceof THREE.BufferGeometry && geometry.attributes[ 'position' ] !== undefined ) {
    /* ... */
  }

  /* ... */

}

दोनों ही मामलों में यह विश्व के माध्यम से पुनरावृति करने की कोशिश कर रहा है, ज्यामिति के कोने/स्थितियों को समन्वयित करता है। मुझे आश्चर्य है कि क्या यह $#$ BufferGeometry पर आलसी vertices ऑब्जेक्ट बनाने के लिए कोड को बहुत सरल करेगा जो मानों को अनुरोध के रूप में देखता है। पूर्ण प्रभाव के बारे में निश्चित नहीं है।

वैकल्पिक रूप से, हम उपयोग कर सकते हैं Geometry.computeBoundingBox :
Geometry
BufferGeometry

ब्राउजराइज़ बिल्ड चलाते समय Box3 एक समस्या स्थान है। कोबलास्ट/थ्रीजेएस-ब्राउज़राइज़-रूपांतरण-उपयोगिता#21 में नोट्स देखें।

@kumavis क्या आप Box3/ज्योमेट्री/बफरजियोमेट्री से निपटने के लिए अपने अनुशंसित समाधान की रूपरेखा तैयार करना चाहेंगे? अगर यह जल्दी है, तो मैं इसे लागू कर सकता हूं।

मैं इसे अभी नहीं देख सकता, लेकिन मैं ऊपर दिए गए अपने सुझाव के साथ geo.computeBoundingBox का उपयोग करने के लिए शुरू करूंगा जैसा कि Geometry और BufferGeometry पर लागू किया गया है यदि/अन्य के स्थान पर यहां . इसके बजाय box3.setFromObj को geometry.computeBoundingBox पर कॉल करना चाहिए और फिर उत्पादित बॉक्स 3 के आधार पर पैरा सेट करना चाहिए।

इससे सर्कुलर डिप्स के Box3 -> BufferGeometry और Box3 -> Geometry के अंत को हटा देना चाहिए। अगर मुझे कुछ याद आ रहा है तो मुझे बताएं।

हम्म शायद परिणामी कोड थोड़ा जटिल है, वास्तव में यहां क्या समझ में आता है? Box3.setFromObject मौजूद नहीं होना चाहिए, लेकिन यह कोई विकल्प नहीं है। जियो को बॉक्स3 का उत्पादन करने में सक्षम होना चाहिए, मुझे इससे कोई समस्या नहीं है। हाँ, मुझे लगता है कि Box3.setFromObject को जियो से बाउंडिंग बॉक्स / विस्तार के लिए पूछना चाहिए, लेकिन हो सकता है कि उन्हें बाउंडिंग बॉक्स / विस्तार के लिए Object3D / Mesh पूछना चाहिए।

क्षमा करें, थोड़ा उग्र हो गया। मुझे बताएं कि आपका क्या सोचना है।

संभावित रूप से प्रासंगिक: #6546

ऐसा कुछ के बिना, लोडर स्क्रिप्ट से उन गतिशील निर्भरताओं का विश्लेषण करना असंभव है।

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

मैंने अपने तीन कॉमनज ट्रांसपिलर का उपयोग करके npm पर तीन.cjs के रूप में एक पूर्ण सामान्य संस्करण प्रकाशित किया है

नोट: इसके लिए काम करने के लिए मुझे मास्टर पर मैन्युअल रूप से चेरीपिक # 6546 करना पड़ा। जबकि गतिशील निर्भरताएं node.js में अच्छी तरह से काम करती हैं, वे Browserify (या किसी अन्य cjs से ब्राउज़र टूल) में काम नहीं कर सकते क्योंकि उन्हें स्थिर निर्भरता विश्लेषण करने की आवश्यकता होती है।

ब्राउजराइज़ प्रूफ: http://requirebin.com/?gist=b7fe528d8059a7403960

@kamicane FYI - यहां वह जगह है जहां तीन को अज्ञात फ़ंक्शन के तर्क के रूप में Raycaster (पूर्व में Ray ) में जोड़ा गया था।

मैं एक अज्ञात फ़ंक्शन (ब्राउज़र में वैश्विक लीक को रोकने के लिए) की आवश्यकता को समझता हूं, हालांकि तर्क अनावश्यक है, और पूरी फ़ाइल गणना की गई निर्भरताओं की श्रेणी में आती है। जबकि एएसटी संशोधनों के साथ तर्क को गतिशील रूप से हटाया जा सकता है, यह कभी भी बुलेटप्रूफ समाधान नहीं हो सकता है (तर्क के लिए क्या लिखा जा रहा है, तर्क से पढ़ा जाता है, आदि के आधार पर)। स्थैतिक विश्लेषण लगभग असंभव हो जाता है। इस मामले में मैन्युअल हस्तक्षेप की आवश्यकता है।

अब जबकि Raycaster अधिक हल्का है, हम इसे बाकी वर्गों की तरह बनाने के लिए दे सकते हैं।

@mrdoob , @ Mugen87 हम रोलअप का उपयोग केवल तीन.जेएस के उन हिस्सों का उपयोग करने के लिए करते हैं जिनकी हमें वास्तव में आवश्यकता है। जब हम बिल्ट चलाते हैं तब भी हमें निम्नलिखित चेतावनी मिलती है:

(!) Circular dependency: node_modules/three/src/math/Vector3.js -> node_modules/three/src/math/Matrix4.js -> node_modules/three/src/math/Vector3.js
(!) Circular dependency: node_modules/three/src/math/Vector3.js -> node_modules/three/src/math/Quaternion.js -> node_modules/three/src/math/Vector3.js
(!) Circular dependency: node_modules/three/src/math/Sphere.js -> node_modules/three/src/math/Box3.js -> node_modules/three/src/math/Sphere.js
(!) Circular dependency: node_modules/three/src/objects/LineSegments.js -> node_modules/three/src/objects/Line.js -> node_modules/three/src/objects/LineSegments.js

क्या Three.js में अभी भी सर्कुलर डिपेंडेंसी हैं या हम कुछ गलत कर रहे हैं?

वेक्टर 3 और मैट्रिक्स 4 एक दूसरे से बंधे हैं, यदि आप एक में खींचते हैं, तो आपको दूसरे में खींचने की आवश्यकता है। तकनीकी रूप से परिपत्र निर्भरता की अनुमति दी जानी चाहिए।

@bhouston हाँ, मैं देखता हूँ, संकेत के लिए धन्यवाद। हां सर्कुलर निर्भरताओं की अनुमति है और रोलअप कोई परेशानी नहीं करता है लेकिन मुझे यकीन नहीं है कि सर्कुलर निर्भरताओं के लिए यह अच्छा अभ्यास है या नहीं। Vector3 केवल Matrix4 पर निर्भर करता है क्योंकि multiplyMatrices और getInverse अधिक जानकारी के लिए देखें (https://github.com/mrdoob/three.js/ ब्लॉब/देव/src/math/Vector3.js#L315)

@ रूमल-बिल्ड आईडीके, यार, सिर्फ इसलिए कि यह स्पष्ट रूप से मैट्रिक्स 4 कंस्ट्रक्टर का संदर्भ देता है? किस बारे में

    applyMatrix4: function ( m ) {

        var x = this.x, y = this.y, z = this.z;
        var e = m.elements;

        var w = 1 / ( e[ 3 ] * x + e[ 7 ] * y + e[ 11 ] * z + e[ 15 ] );

        this.x = ( e[ 0 ] * x + e[ 4 ] * y + e[ 8 ] * z + e[ 12 ] ) * w;
        this.y = ( e[ 1 ] * x + e[ 5 ] * y + e[ 9 ] * z + e[ 13 ] ) * w;
        this.z = ( e[ 2 ] * x + e[ 6 ] * y + e[ 10 ] * z + e[ 14 ] ) * w;

        return this;

},

?

आप कह सकते हैं कि आप {तत्व: [...]} पास कर सकते हैं और यह काम करेगा, लेकिन हम सभी जानते हैं कि यह वहां मैट्रिक्स 4 की अपेक्षा करता है

आइए Vector3 से शुरू करें।

Vector3 पर निर्भर करता है Matrix4 की वजह से project और unproject :

    project: function () {

        var matrix = new Matrix4();

        return function project( camera ) {

            matrix.multiplyMatrices( camera.projectionMatrix, matrix.getInverse( camera.matrixWorld ) );
            return this.applyMatrix4( matrix );

        };

    }(),

    unproject: function () {

        var matrix = new Matrix4();

        return function unproject( camera ) {

            matrix.multiplyMatrices( camera.matrixWorld, matrix.getInverse( camera.projectionMatrix ) );
            return this.applyMatrix4( matrix );

        };

    }(),

Vector3 पर निर्भर करता है Quaternion की वजह से applyEuler और applyAxisAngle :

    applyEuler: function () {

        var quaternion = new Quaternion();

        return function applyEuler( euler ) {

            if ( ! ( euler && euler.isEuler ) ) {

                console.error( 'THREE.Vector3: .applyEuler() now expects an Euler rotation rather than a Vector3 and order.' );

            }

            return this.applyQuaternion( quaternion.setFromEuler( euler ) );

        };

    }(),

    applyAxisAngle: function () {

        var quaternion = new Quaternion();

        return function applyAxisAngle( axis, angle ) {

            return this.applyQuaternion( quaternion.setFromAxisAngle( axis, angle ) );

        };

    }(),

सुझाव?

मुझे यकीन नहीं है कि हमें हर तरह से परिपत्र निर्भरताओं को हटाने की जरूरत है। लेकिन मैं multiplyMatrices को Math मॉड्यूल में ले जाने की कल्पना कर सकता था। फिर हस्ताक्षर निश्चित रूप से multiplyMatrices( a: Matrix4, b: Matrix4, result: Matrix4 ): Matrix4 में बदल जाएगा। Vector3 के अंदर आप import { multiplyMatrices } from './Math'; को Matrix4 ( Matrix4 की एपीआई सतह को समान रखने के लिए) में किया जा सकता है।

मैंने बस एक त्वरित नज़र डाली ( Quaternian मामले को नहीं देखा - केवल Vec3/Mat4 ) और मैं बाकी कोड बेस के लिए प्रदर्शन निहितार्थ और परिणामों के बारे में भी निश्चित नहीं हूं। इसके अलावा मुझे यह भी विश्वास नहीं है कि इन परिपत्र निर्भरताओं को हटाना बिल्कुल जरूरी है। बस अपने विचार साझा करना चाहता था क्योंकि @mrdoob ने सुझाव मांगे थे

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

@makc वास्तव में नहीं। यह बहुत से छोटे "सहायक" कार्यों के साथ एक बड़ा मॉड्यूल होगा। यह पेड़ को हिलाने आदि में भी मदद करेगा। एक गणित मॉड्यूल इस तरह दिख सकता है:

export const multiplyMatrices( a, b, result ) { // ... DO STUFF ... // }
export const getInverse( /* ... */ ) { // ... DO STUFF ... // }
// ...
// ...

और उपभोग करने वाला मॉड्यूल कुछ ऐसा करेगा:

import { Matrix4 } from './Matrix4.js';
import { multiplyMatrices } from './math';
const result = new Matrix4( );
multiplyMatrices( a, b, result );

सब कुछ एक साथ बंडल करते समय, रोलअप अपना जादू करता है और सबसे कुशल बंडल बनाता है।

बहुत सारे लोकप्रिय पुस्तकालय यही कर रहे हैं। वास्तव में RxJS ने अपने import "तर्क" को भी मेरे द्वारा वर्णित पैटर्न में बदल दिया। वहां ऐसा कुछ दिखता है:

 import { flatMap, map, tap } from 'rxjs/operators';

myObject.run().pipe(
  tap(result => doSomething()), 
  flatMap(() => doSomethingElse()), 
  map(() => doAnotherThing())
);

आप RxJS 6 में "क्यों और कैसे" के बारे में पढ़ सकते हैं, उदाहरण के लिए कई ब्लॉगपोस्ट में: https://auth0.com/blog/whats-new-in-rxjs-6/

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

@ रूमल-बिल्ड हम्म तो आप कह रहे हैं कि रोलअप समझ सकता है कि एक ही दायरे में कोड को वास्तव में पूरे दायरे की आवश्यकता नहीं है, अच्छा।

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

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

@makc वास्तव में नहीं। यह बहुत से छोटे "सहायक" कार्यों के साथ एक बड़ा मॉड्यूल होगा। यह पेड़ को हिलाने आदि में भी मदद करेगा। एक गणित मॉड्यूल इस तरह दिख सकता है:

यदि यह प्रस्तावित किया जा रहा है, तो इसे सही ढंग से वर्णित किया जाना चाहिए। यह थ्री.जेएस का डिज़ाइन की ऑब्जेक्ट-ओरिएंटेड शैली से कार्यात्मक डिज़ाइन में परिवर्तन है।

@ रूमल-बिल्ड हम्म तो आप कह रहे हैं कि रोलअप समझ सकता है कि एक ही दायरे में कोड को वास्तव में पूरे दायरे की आवश्यकता नहीं है, अच्छा।

हाँ रोलअप समझता है कि सभी आयात एक-दूसरे से कैसे संबंधित हैं और ट्री-शेकिंग, डेड कोड एलिमिनेशन आदि करता है। रोलअप के नए संस्करण "चंकिंग" और बहुत सी अन्य अच्छी चीजें भी कर सकते हैं। लेकिन वर्तमान परियोजना संरचना इन सुविधाओं का पूरा लाभ नहीं उठाती है।

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

मुझे नहीं लगता कि ये दोनों प्रतिमान परस्पर अनन्य हैं। मुझे लगता है कि आप इन दो प्रतिमानों को मिला सकते हैं और मेल कर सकते हैं। मैं कार्यात्मक प्रोग्रामिंग में बदलने का भी प्रस्ताव नहीं करता हूं। मैं सिर्फ चक्रीय निर्भरता से छुटकारा पाने के तरीके का वर्णन करना चाहता था। आप multiplyMatrices विधि को Math ऑब्जेक्ट से भी जोड़ सकते हैं। लेकिन अगर कोई इस तरह के सामान को फिर से लिखता है तो ES6 मॉड्यूल की सुविधाओं का उपयोग करने पर विचार करना समझ में आता है। लेकिन जैसा कि मैंने कहा, मैं थ्री.जेएस कोडबेस का विशेषज्ञ नहीं हूं और यह सिर्फ एक विचार था कि चक्रीय निर्भरता को कैसे खत्म किया जाए। मुझे लगता है कि Three.js एक बेहतरीन कोड बेस वाला एक शानदार प्रोजेक्ट है और मैं इसके बारे में सोचना नहीं चाहता। इसलिए मुझे उम्मीद है कि मेरी टिप्पणियों से किसी को बुरा नहीं लगेगा

मुझे यकीन नहीं है कि हमें किसी मुद्दे में डिजाइन निर्णयों पर चर्चा करनी चाहिए। क्या आपके पास कोई जगह है जहां इस तरह की चीजें बेहतर फिट बैठती हैं?

BTW gl-matrix एक कार्यात्मक गणित पुस्तकालय है: https://github.com/toji/gl-matrix/tree/master/src/gl-matrix

@ रूमल-बिल्ड

वर्तमान में गणित मॉड्यूल पर सभी विधियां "स्थिर प्रकार" से जुड़ी हुई हैं।

ऐसा कैसे?

@mrdoob मेरा मानना ​​​​है कि ग्लो-मैट्रिक्स के कार्यात्मक डिजाइन के साथ vec3 के प्रत्येक फ़ंक्शन (vec3 फ़ाइल में मैंने अपनी पिछली टिप्पणी में लिंक किया है) व्यक्तिगत रूप से निर्यात किया जाता है। यह आपको आयात करने के लिए कौन से फ़ंक्शन चुनने और चुनने की अनुमति देता है। आपको सभी vec3 साथ लाने की आवश्यकता नहीं है।

जहां थ्री.जेएस के साथ, क्योंकि यह ऑब्जेक्ट-ओरिएंटेड डिज़ाइन का उपयोग करता है, वेक्टर 3 के लिए सभी गणित फ़ंक्शन वेक्टर 3 ऑब्जेक्ट प्रोटोटाइप से जुड़े होते हैं और आप केवल वेक्टर 3 क्लास को ही आयात करते हैं।

इस प्रकार थ्री.जेएस में आयात पूरे वर्ग के होते हैं जबकि एक कार्यात्मक दृष्टिकोण के साथ आप व्यक्तिगत कार्यों को आयात करते हैं।

(ग्ल-मैट्रिक्स लाइब्रेरी के बारे में दूसरी बहुत साफ बात यह है कि सभी व्यक्तिगत फ़ंक्शन अन्य कार्यों का उपयोग नहीं करते हैं, @toji ने मूल रूप से प्रत्येक व्यक्तिगत ऑपरेशन में सभी गणित के एक अनुकूलित संस्करण को रेखांकित किया है। यह गति के मामले में काफी कुशल है। लेकिन इससे पुस्तकालय को बनाए रखना मुश्किल हो जाता है।)

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

@ बौस्टन समझ गया। स्पष्टीकरण के लिए बहुत धन्यवाद! मैं

मैं सिर्फ इस विषय पर अनुवर्ती कार्रवाई करना चाहता था। लेकिन मैं importing function vs importing classes से cyclic dependencies को हल करने के विषय पर वापस आना चाहता हूं। (मैं यह भी नहीं देखता कि import { someFunction } from 'SomeModule' import SomeClass from 'SomeModule' #$ से कम रखरखाव योग्य क्यों है, लेकिन यह निश्चित रूप से इस मुद्दे/बातचीत का विषय नहीं है।

चक्रीय निर्भरता को हल करने के लिए कार्यक्षमता को एक अलग वर्ग में रखना संभव होगा। आप गणित-कक्षा में multiplyMatrices विधि संलग्न कर सकते हैं या एक गुणक-वर्ग बना सकते हैं जिसमें multiplyMatrices विधि हो। लेकिन जैसा कि मैंने पहले कहा था, मुझे यकीन नहीं है कि हमें चक्रीय निर्भरता को हटाना है या नहीं। अगर उन्हें नहीं हटाने का फैसला है, तो मुझे लगता है कि यह मुद्दा करीब हो सकता है

#19137 को हल करने के बाद, इसे अब बंद किया जा सकता है .

@ Mugen87 वाह, 5 साल! अंत में इसे हिट करने के लिए बधाई :fire: :clap:
मुझे उन रेखांकन को वापस बनाने में बहुत मज़ा आया: मुस्कान_कैट: