それは解くためのかなりの結び目です
http://jsbin.com/medezu/2/edit?html、js、output

@coballastは、依存関係jsonを生成するために使用したコードを投稿できますか？

プリコンパイルされたthree.min.jsファイルを直接使用するだけです。 Browserfy内でThree.jsを個々のファイルに分割する必要はありません。実際の利益のために、人生をより困難にしているだけです。

私は経験から話します。私たちはthree.jsのnpmモジュールを使用しており、それはうまく機能します。 単一のファイルとしてパッケージ化し、CommonJSスタイルのモジュールにラップするだけです。 このアプローチはbrowserfyで機能し、多くの人がすでにそれを行っていると私は理解しています。

このユースケースでは、この結び目を解く必要はありません。

@kumavis依存関係構造をダンプしました。 次に、次のコードがグラフを生成しました。

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は、three.jsコードベースの健全性について詳しく説明しています。

私がかなり手伝った数学ライブラリでは、循環依存がすべての言語の標準であることを知っています。 Matrix4の関数はVector3をパラメーターとして受け取る可能性があり、Vector3はMatrix4によって変換できる可能性があるためです。 数学ライブラリですべての依存関係を一方向にすると、ライブラリのその部分を使用するのが面倒になります。

今、私は数学ライブラリがライブラリの他の部分について知らないことを主張します-より複雑なタイプは実際にはそのモジュールに漏れるべきではありません。 したがって、その意味で、モジュール間の巡回依存を減らすことを提唱しますが、モジュール内の個々のファイル間のすべての巡回依存を削除するわけではありません。

これは、微妙な合併症を説明するケースです。 明確にするために、ここで私は実装自体には批判的ではありませんが、副作用に批判的です。

Vector3とMatrix4は、相互に入力または出力タイプとして使用する一連の関数を公開するため、循環依存関係を形成します。 どちらもThree.jsに共通のスタイルで実装され、計算を実行するためのスクラッチ変数を含むようにIIFEを介して関数を定義します。

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はまだ存在していません。 現在、スクラッチ変数の実際のインスタンス化時間はそれほど重要ではありません。 ここでの本当のポイントは、現在の実装は、ビルドシステムがファイルを連結する順序に依存しているということです。 これは非常に遠い結合であり、ビルドシステムを変更したり、連結順序を変更するようにファイルの名前を変更したりすると、明確な接続がなく、無効なビルドが発生する可能性があります。

これは、この結び目がバグに現れる方法の1つにすぎません。 ただし、この特定の問題に対処することはできますが、APIに多くの重大な変更を加える必要のない一般的なソリューションはありません。

うーん... ILMのC ++数学ライブラリを見てみました。これは、数学ライブラリのゴールドスタンダードだと思います。 驚いたことに、それらは循環的ではありません。 それらは基本的に、それらが定義する単純なタイプから複雑なタイプの明確に定義された順序を持っており、それを非常に注意深く行うと、うまくいくと思います。

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

数学、そしてベックが最も単純なようです。

依存関係グラフの詳細：

Materialには、基本クラスとの双方向のdepsがあります

少し見づらいですが、 Geometryは、基本クラスで一方向の深さが良いようです。

LightとCameraは同様の状況にあります。基本クラスに関しては良好ですが、 Object3Dの依存関係は不要のようです。


Curve s Path s Lineは良さそうですが、 Shapeは少し絡み合っています。

@coballastありがとう！ これは素晴らしい洞察です。

コメントのために自分自身を追加します:)

ところで、たとえば、MaterialがMeshDepthMaterialに依存する方法を調べました。 簡単です

if ( this instanceof THREE.MeshDepthMaterial )

に変更するのは簡単です

if ( this.type == 'MeshDepthMaterial' )

そして出来上がり-依存関係はありません。 この恐ろしいグラフの半分は同じレベルの問題だと思います。

面白いことに、この依存関係は単一のtoJSONメソッドで発生します。 つまり、代わりに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を実行している場所では、そのコードを特定のクラス自体に移動する必要があります。 それは多くの結び目を取り除くのに役立ちます。

AMDは循環参照をサポートしていませんが、ES6モジュールはhttps://github.com/ModuleLoader/es6-module-loader/wiki/Circular-References-&-Bindingsをサポートしています。

依存関係を解決する問題（ system.jsなどのモジュールシステムローダーの実装で解決できます）とは別に、three.jsで循環参照が作成する問題は何ですか？

幸い、これを段階的に攻撃できるようです。 以前のリリースでは多くのAPIブレークの変更が行われたと思うので、それが問題外かどうかはわかりません。

instanceofの場合（おそらく大多数）、重大な変更なしで解決できるはずです。

私もここで購読しています。 ここでステップバイステップで行きましょう。
重要なもののように、不要な循環依存関係をすべて削除する必要があることに同意します。
また、 @ bhoustonにも同意します。相互作用が数学ライブラリを有用にするため、数学ライブラリは相互に非常に依存しているからです。

誰かが簡単なものを計画することはできますか？ ライブラリを妨げないのであれば、循環依存を少なくすることは常に良い考えです。 後で他の人をどうするかを見ることができます。

@ zz85循環依存の問題にも遭遇しました。 これは主に、循環参照ファイル内に特定のオブジェクトを事前に作成しようとしている場合に問題になります。

6252は、 MaterialとObject3Dの多くの循環深度をクリアする必要があります。

Meshは次のようになります。 たぶん、いくつかの無関係なデップですが、あまりクレイジーではありません。

Object3DとGeometryの円形。 Object3D -> Mesh参照は、上記のPRで扱われています。 Mesh -> Geometry参照は問題ありません、b / c MeshはGeometryのインスタンスを制御します。 それでも、クラス固有の動作（ Geometry / BufferGeometry ）の型チェックを実行することで中断される可能性があります。

Geometry -> Mesh参照については、 geometry.mergeMesh( mesh )を提供することです。 GeometryはMeshよりも低レベルの概念なので、 mesh.mergeIntoGeometry( geo )として反転し、$＃ mergeMesh $を廃止します。

誰かがこれらのいくつかを修正するPRをマージした場合は、私に知らせてください。現在の状況を反映するようにグラフを更新します。

@bhouston @ gero3数学ライブラリで同じレベルのユーザビリティ/ユーティリティを取得するには、循環依存関係が必要であるとは確信していません。 私は間違っている可能性がありますが、Vector3をシステムの残りの部分から完全に分離/無知に保ち、そのプロトタイプを変更してMatrix4モジュールのMatrix4に対応することはできませんか？ 行列はベクトルよりも複雑なので、これは概念的には理にかなっています。 事故を防ぐために、プロトタイプとクラスを構築する順序を明確にした方がよいと思います。

@bhouston @ gero3APIをまったく変更せずにそれを実行できる可能性があると思います。 じっくり見て、何が何なのか見てみましょう。

数学に関しては、すべての「スクラッチパッド」を1か所に配置するだけでよいと思います。 しかし、Vector3とMatrix4の両方を持たない3jsの単一の使用可能なグラフはないでしょう。

数学ライブラリのパフォーマンスやAPIを変更しないソリューションがあれば、私はそれですべてです。

@coballastは、APIの変更なしで循環依存を削除できません。b/ cはどちらも、他のタイプを使用するメソッドを提供します。 Vector3 Matrix4

browserify compatに関しては、唯一の要件は、スクラッチ変数のインスタンス化をクラス定義時間外に移動することです（最初の実行でインスタンス化するようにします）。 このようにこれを怠惰にします。 それはAPIやパフォーマンスに影響を与えません。

そのような変化は大丈夫だと思います。

@kumavisああ！ はい。 オーケー、わかりました。 それは簡単です。

次の理由により、3つがrequire構造を持つ小さなモジュールに分割されることを完全にサポートします。

1. THREEは非常に大きいです。 ユーザーが必要なものだけを要求できる場合は、クライアントのビルドサイズを削減できます。 たとえば、 react-bootstrapを使用すると、すべてのブートストラップモジュールをバンドルしないvar Alert = require('react-bootstrap/lib/Alert');のようなことができます。
2. OrbitControls.jsのように、3つのグローバルオブジェクト自体を変更してTHREE.OrbitControlsに置く「プラグイン」がいくつかあります。 これは、ビルドプロセスでグローバル名前空間に3つ存在する必要があるため、最新のjavascriptフレームワークではアンチパターンです。これは、それを必要とするファイルではなく、3つ存在する必要があるためです。 THREEはこれを内部的にも実行し、常にTHREE名前空間を変更します。これは、特定のTHREEモジュールを含めるのに理想的ではありません。

THREE.OrbitControlsに身を置く

しかし、3jsのすべてのコードはそれを行いますか？

@DelvarWorldは書いた：

次の理由により、3つがrequire構造を持つ小さなモジュールに分割されることを完全にサポートします。

以前は分割するのがいいと思っていましたが、今のところThreeJSにはシンプルさがあります。 3Dを初めて使用する人にとっては、現在の形で、開発チームの優先事項であるという形で、より使いやすくなっています。 モジュールシステムを必要とせずにThreeJSを使用できます（モジュールシステムはたくさんあり、すべてが完全に互換性があるわけではありません）。

@makcのように、私も@DelvarWorldがTHREE名前空間に物を入れないという提案に戸惑っています。

代わりにどこに/どのようになりますか？

私には、1つのグローバルオブジェクトTHREEのみを作成するのが良いパターンのように思えます。このオブジェクトには、そのすべての部分（および場合によっては一部の拡張機能/プラグイン）が含まれています。

私は@DelvarWorldに同意します。グローバルに配置する手法は、コードベースの健全性に適していないということです。グローバル自体に配置するという一種の微妙な議論は問題ではありません。隠された依存関係グラフ、およびグローバルを利用可能にすることから生じる他のプラクティス。

しかし、その議論は主に内部開発とコード構造に限定されています。 ライブラリを静的コードバンドルとして提供することに関しては、すべてのクラスをグローバルTHREEに配置することは私にとって理にかなっています。

反論は、THREE.jsシーンjsonを逆シリアル化する場合、エントリはクラスを文字列としてリストするだけで、 THREE[ obj.type ]のようにグローバルから引き出すことができるというものです。 これは、逆シリアル化する前にTHREEで定義している限り、標準のthree.jslibにないクラスで機能します。 THREEグローバルなしでこの動作を置き換える最善の方法がわかりません。

これは、逆シリアル化する前にTHREEで定義している限り、標準のthree.jslibにないクラスで機能します。 THREEグローバルなしでこの動作を置き換える最善の方法がわかりません。

すべてがモジュールである場合は、このパターン（またはその変形）を実行できます。

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

モジュールに関しては、ES6に伴う多くの変更があります。 その時点で、ThreeJSのモジュール性を再検討します。

ビルドされたバージョンの3（ユーザーが手動でダウンロードできるjavascriptファイル）には、3つの名前空間にすべてが含まれています。 これは、ビルドのエントリポイントファイルを使用して行うことができます。

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

など、これはまだ初心者にとっては便利で、簡単に始めることができます。

最新のjavascriptビルドでnpmとrequirejs / browserify / webpackの3つを使用している場合は、次のようなことができます。

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

など、クライアントサイズバンドルに組み込まれている3つのサイズの一部を削減する可能性があります。 3つのうちどれだけが「コア」であるかわからないので、私は間違っている可能性があります。 ただし、現時点では、3つはrequireステートメントを使用しないため、これは不可能です。

いずれにせよ、最新のパターンではモジュールが必要であり、すべてのコードで別のライブラリを変更する（グローバルTHREEを変更する、悪い）代わりに、コードは独立してモジュール化され、 requireステートメントで必要なものを指定します。 Reactソースコードなど。

それについてオンラインで多くの良いリソースがあるので、require / module構文を使用するための完全な議論をしようとすることは役に立たないと思います。 しかし、OrbitControlsのようなプラグインを追加するために3つの名前空間を変更するように他の人に勧めるのは悪いことです。

@DelvarWorldは、ES6がモジュールをJavaScriptに公式に導入し、非常に具体的で明確な構文を使用していることに注意してください。

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

@bhoustonそうそう、私は必要なものとインポートするものを区別せず（インポートがおそらくより良い選択です）、一般的なモジュールパターンをサポートするだけです。

@bhouston @DelvarWorld @kumavis私の長期的なプロジェクトの1つは、commonjs / amdモジュールに対応してes6に変換できる自動es5-> es6コンバーターを作成することです。できれば、クラス/ジェネレーターなどのes6コンストラクトを使用して多くのJavaScriptを識別して書き直します。等々。 ブラウザーが標準に追いついている間に、es6ifyのようなbrowserify変換を使用して、コードを使用できるように準備することができます。 内部レベルで3つをbrowserifyに移行することは、そのようなツールへの入力の準備をするための良い最初のステップです。

これは、私が（明らかに非常に貧弱に）作ろうとしていた点の横にあります。 モジュール性の懸念に関係なく、これらの循環依存関係を可能な限り削除したいと思います。これにより、THREEがより安定して柔軟になり、快適な副作用として多くのバグがなくなると思います。

@coballast https://github.com/mrdoob/three.js/pull/6252がマージされ、周期的な深度の多くを削減する必要があります。 新しいdepグラフを生成できると思いますか？ 多分それを変換ツールリポジトリのユーティリティにします

次は、 Vector3 Matrix4のスクラッチ変数を、定義時ではなく、最初の使用時に遅延定義することです。

ボランティアをしたい人はいますか？ 速いはずです

グラフが更新されました。 http://jsbin.com/medezu/3/

これがスクリーンショットです：

膨大な数のObject3Dの循環が排除されたことを報告できてうれしいです。 よくやった@kumavis！

うわー、それは同じコードベースですか？ クレイジー

グラフ生成をユーティリティの一部にする作業を行います。

グラフだけを見ると、 ShapeとGeometryは、解明できる可能性のあるクラスツリーのようです。

@coballastはあなたがこれを引き受けることができると思いますか？

Vector3 Matrix4のスクラッチ変数を、定義時間ではなく、最初の使用時に遅延定義する

これは、自動変更ではなく、アップストリームdevに対するPRになります

また、問題のタイトルを「深刻な循環依存の問題」から「循環依存」にダウングレードできると思います。状況は大幅に改善されました。

@kumavisもちろんです。 時間が許せばそれに取り組みます。

これが、相互依存関係のクリーンアップの現在の状態です。
（矢印は、必要に応じて削除する必要がある接続を示しています）

• [x]材料
• [x]ジオメトリ
• [x] Object3Dの
• [x]数学
• [x]形状
  
  
  
  • [x]形状-> FontUtils
  
  
  • [x]形状-> ExtrudeGeometry
  
  
  • [x]形状-> ShapeGeometry
  
  
  • [x]パス->形状
  
  
• [] Box3
  
  
  
  • [] Box3-> BufferGeometry
  
  
  • [] Box3->ジオメトリ
  
  

形：

ボックス3：

算数：

これらのノードは相互接続されていますが、これにより十分な利便性が提供されます。

Shapeには、次のようなコードを介して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などのより一般的なUtilsへの移動方法を使用して削除できます。 しかし、それを行うのに大きな勝利ではありません。 完了としてマークします。

Box3 -> BufferGeometryとBox3 -> Geometryの両方をクリーンアップできます。

クラスに依存する動作をクラス自体に適用しないというもう1つのケース。

ソース：

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 ) {
    /* ... */
  }

  /* ... */

}

どちらの場合も、ジオメトリのworldCoordinate頂点/位置を反復処理しようとしているだけです。 BufferGeometryに、要求された値を検索する遅延verticesオブジェクトを作成することで、コードが大幅に簡素化されるのではないかと思います。 パフォーマンスへの影響についてはよくわかりません。

または、 Geometry.computeBoundingBoxを使用することもできます。
Geometry
BufferGeometry

Box3は、browserifyビルドを実行する際の問題箇所です。 coballast / threejs-browserify-conversion-utility＃21のメモを参照してください。

@kumavis Box3 / Geometry / BufferGeometryを処理するための推奨ソリューションの概要を教えていただけますか？ 速ければ実装できます。

今は見ることができませんが、ここでのif / elseの代わりにGeometryとBufferGeometryに実装されているgeo.computeBoundingBoxを使用するという上記の提案から始めます。 代わりにbox3.setFromObjはgeometry.computeBoundingBoxを呼び出してから、生成されたbox3に基づいてパラメーターを設定する必要があります。

これにより、循環深度のBox3 -> BufferGeometryとBox3 -> Geometryの終わりが削除されます。 何か足りないものがあれば教えてください。

うーん、結果のコードは少し複雑かもしれませんが、ここで実際に意味があるのは何ですか？ Box3.setFromObjectは存在すべきではありませんが、それはオプションではありません。 Geoはbox3を作成できるはずですが、問題はありません。 ええ、 Box3.setFromObjectはgeoにバウンディングボックス/エクステントを要求する必要があると思いますが、おそらく彼らはObject3D / Meshにバウンディングボックス/エクステントを要求する必要があります。

すみません、少しガタガタしました。 lemmeはあなたの考えを知っています。

おそらく関連性がある：＃6546

このようなものがなければ、ローダースクリプトからこれらの動的な依存関係を分析することは不可能です。

私のテストによると、循環依存関係はcommonJSificationの問題ではありません。 これらは正しく処理する必要があり、このスレッドで前述したように、依存関係グラフはかなり混乱しますが、THREE.jsがcommonJS環境で動作することを妨げません（もちろん、変換された場合）。

3つのcommonjsトランスパイラーを使用して、完全なcommonjsバージョンをthree.cjsとしてnpmに公開しました。

注：これを機能させるには、マスターで手動で＃6546をチェリーピックする必要がありました。 動的依存関係はnode.jsでうまく機能しますが、静的依存関係分析を実行する必要があるため、Browserify（または他のcjs to browserツール）では機能しません。

Browserifyの証明： http ：//requirebin.com/？gist = b7fe528d8059a7403960

@kamicane FYI-ここで、匿名関数の引数としてTHREEがRaycaster （以前のRay ）に追加されました。

（ブラウザでのグローバルリークを防ぐための）無名関数の必要性を理解していますが、引数は不要であり、ファイル全体が計算された依存関係のカテゴリに分類されます。 引数はASTの変更で動的に削除できますが、防弾ソリューションになることはありません（引数に書き込まれる内容、引数から読み取られる内容などによって異なります）。 静解析はほとんど不可能になります。 この場合、手動による介入が必要です。

Raycasterがより軽量になったので、他のクラスと同じように作成することができます。

@ mrdoob 、 @ Mugen87 Rollupを使用して、本当に必要なThree.jsの部分のみを使用します。 ビルドを実行しても、次の警告が表示されます。

(!) 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にはまだ循環依存関係がありますか、それとも何か間違ったことをしていますか？

Vector3とMatrix4は互いに結びついています。一方を引き込む場合は、もう一方を引き込む必要があります。 循環依存は技術的に許可されるべきです。

@bhoustonええ、わかりました、ヒントをありがとう。 はい、循環依存は許可されており、ロールアップで問題は発生しませんが、循環依存を使用するのが適切かどうかはわかりません。 Vector3はmultiplyMatricesとgetInverse $のため、$ Matrix4 $にのみ依存します。詳細については、（https://github.com/mrdoob/three.js/を参照してください）。 blob / dev / src / math / Vector3.js＃L315）

@ roomle-Matrix4コンストラクターを明示的に参照しているという理由だけで、Idkをビルドしますか？ どうですか

    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;

},

？

{elements：[....]}を渡すことができ、それは機能すると言うことができますが、Matrix4がそこにあることを期待していることは誰もが知っています

Vector3から始めましょう。

$＃ projectとunproject $のため、$ Vector3はMatrix4 $に依存します：

    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はapplyEulerとapplyAxisAngle $のため、$ Quaternion $に依存します：

    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のAPIサーフェスを同じに保つため）。

簡単に調べたところ（ Quaternianの場合は見ていませんでした- Vec3/Mat4のみ）、残りのコードベースのパフォーマンスへの影響と結果についてもわかりません。 さらに、これらの循環依存関係を削除することが絶対に必要であると私は確信していません。 @mrdoobが提案を求めたので、私の考えを共有したかっただけです

@ roomle-buildなので、基本的に循環依存がないようにモジュールを追加しますが、それでもこれらすべてのモジュールを使用しますか？ これは、すべての数学メソッドが独自のモジュールである場合、おそらくより理にかなっている可能性があります。その場合、使用するものだけを取り込むことになりますが、それは多くのモジュールになります。

@makcは実際にはそうではありません。 これは、多くの小さな「ヘルパー」関数を備えた1つの大きなモジュールになります。 これは、ツリーの揺れなどにも役立ちます。数学モジュールは次のようになります。

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

彼らがRxJS6でこのようなものを変更した「理由と方法」については、いくつかのブログ投稿で読むことができます。たとえば、 https ：//auth0.com/blog/whats-new-in-rxjs-6/

しかし、私が言ったように、それは単なる考えであり、これがコードベースの残りの部分に与えるすべての影響についてはわかりません。 また、現在のmathモジュールは、このように使用するために「準備」されていません。 現在、数学モジュールのすべてのメソッドは「一種の静的」にアタッチされています。 これはまた、ロールアップが本当に必要なものを検出するのを防ぎます...

@ roomle-うーん、ロールアップは同じスコープ内のコードが実際にスコープ全体を必要としないかどうかを理解できると言っているので、いいですね。

オブジェクト指向アプローチ（オブジェクトがメンバー関数を持つ）ではなく、機能的アプローチ（オブジェクトを取る関数）に移行することについて話しているのです。これは本物ですが、Three.JSが完全にオブジェクト指向であることを考えると、このタイプの変更を提案することはかなり大きなものであり、既存のすべてのコードを壊してしまいます。

この変更を支持する議論が、すべての下位互換性を破ることを正当化するために、現時点でそれほど重要であるかどうかはわかりません。

@makcは実際にはそうではありません。 これは、多くの小さな「ヘルパー」関数を備えた1つの大きなモジュールになります。 これは、ツリーの揺れなどにも役立ちます。数学モジュールは次のようになります。

これが提案されているものである場合、それは正しく記述されるべきです。 これは、Three.JSのオブジェクト指向スタイルのデザインから機能的なデザインへの変更です。

@ roomle-うーん、ロールアップは同じスコープ内のコードが実際にスコープ全体を必要としないかどうかを理解できると言っているので、いいですね。

はい、ロールアップはすべてのインポートが互いにどのように関連しているかを理解し、ツリーのシェイク、デッドコードの除去などを行います。新しいバージョンのロールアップは、「チャンキング」やその他の多くの優れた機能も実行できます。 しかし、現在のプロジェクト構造はこれらの機能を十分に活用していません。

オブジェクト指向アプローチ（オブジェクトがメンバー関数を持つ）ではなく、機能的アプローチ（オブジェクトを取る関数）に移行することについて話しているのです。これは本物ですが、Three.JSが完全にオブジェクト指向であることを考えると、このタイプの変更を提案することはかなり大きなものであり、既存のすべてのコードを壊してしまいます。

これらの2つのパラダイムは相互に排他的ではないと思います。 これらの2つのパラダイムを組み合わせて組み合わせることができると思います。 また、関数型プログラミングに変更することも提案していません。 循環依存を取り除く方法を説明したかっただけです。 multiplyMatricesメソッドをMathオブジェクトにアタッチすることもできます。 しかし、誰かがこの種のものを書き直した場合、ES6モジュールの機能の使用を検討することは理にかなっています。 しかし、私が言ったように、私はThree.jsコードベースの専門家ではなく、循環依存を排除​​する方法を考えただけでした。 Three.jsは素晴らしいコードベースを備えた素晴らしいプロジェクトだと思います。 だから私は誰も私のコメントに腹を立てないことを願っています😉

ある問題で設計上の決定について話し合うべきかどうかはわかりません。 この種のものがよりよく合う場所がありますか？

ところで、gl-matrixは機能的な数学ライブラリです： https ：//github.com/toji/gl-matrix/tree/master/src/gl-matrix

@ roomle-build

現在、数学モジュールのすべてのメソッドは「一種の静的」にアタッチされています。

どうして？

@mrdoob gl-matrixの機能設計では、たとえばvec3の各機能（以前のコメントでリンクしたvec3ファイル内）が個別にエクスポートされると思います。 これにより、インポートする関数を選択できます。 すべてのvec3を持参する必要はありません。

Three.JSと同様に、オブジェクト指向設計を使用しているため、Vector3のすべての数学関数がVector3オブジェクトのプロトタイプにアタッチされ、Vector3クラス自体のみをインポートします。

したがって、Three.JSでのインポートはクラス全体ですが、機能的なアプローチでは、個々の関数をインポートします。

（gl-matrixライブラリのもう1つの非常に優れた点は、すべての個々の関数が他の関数を使用しないことです。 @ tojiは基本的に、すべての数学の最適化されたバージョンを個々の操作にインライン化します。これは、速度の点で非常に効率的です。ただし、ライブラリの保守が困難になります。）

/ math内の他のディレクトリへの参照を削除する場合を除いて、Three.JSのこの部分をリファクタリングする必要はないと思います。 数学ライブラリはかなり小さく、最近の私のプロファイリングテストには実際には表示されません。 はい、それは最大限に効率的ではありませんが、可読性と使いやすさを維持しながら十分に近いです。

@bhouston了解しました。 説明ありがとうございます！ 😊

このトピックについてフォローアップしたかっただけです。 しかし、 importing function vs importing classesからcyclic dependenciesの解決のトピックに戻りたいと思います。 （また、 import { someFunction } from 'SomeModule'がimport SomeClass from 'SomeModule'よりも保守性が低い理由もわかりませんが、それは間違いなくこの問題/会話のトピックではありません。

循環依存を解決するために、機能を別のクラスに入れることが可能です。 multiplyMatricesメソッドをMath-Classにアタッチするか、 multiplyMatricesメソッドを持つMultiplier-Classを作成することができます。 しかし、前に言ったように、循環依存関係を削除する必要があるかどうかはわかりません。 それらを削除しないという決定であれば、この問題は近いかもしれないと思います😃

＃19137を解決した後、これを閉じることができます🎉。

@ Mugen87うわー、5年！ ついにそれを打ったことをおめでとう：fire ：： clap：
当時、私はそれらのグラフを作成するのがとても楽しかったです：smile_cat：