풀어야 할 매듭이다.
http://jsbin.com/medezu/2/edit?html,js ,출력

@coballast 종속성 json을 생성하는 데 사용한 코드를 게시할 수 있습니까?

미리 컴파일된 three.min.js 파일을 직접 사용하세요. Three.js를 Browserfy 내에서 개별 파일로 분해할 필요가 없습니다. 실제 이익 없이 삶을 더 어렵게 만들 뿐입니다.

저는 경험에 비추어 우리가 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 는 아직 존재하지 않습니다. 이제 스크래치 변수의 실제 인스턴스화 시간은 그다지 중요하지 않습니다. 여기서 진정한 의미는 현재 구현이 빌드 시스템이 파일을 함께 연결하는 순서에 달려 있다는 것입니다. 이는 매우 먼 연결이며, 빌드 시스템을 변경하거나 연결 순서를 변경하는 방식으로 파일 이름을 변경하면 명백한 연결 없이 잘못된 빌드가 발생할 수 있습니다.

이것은 이 매듭이 버그로 나타나는 방식 중 하나일 뿐입니다. 그러나 이 특정 문제를 해결할 수는 있지만 API에 대한 많은 주요 변경 사항이 필요하지 않은 일반적인 솔루션은 없습니다.

흠... ILM의 C++ 수학 라이브러리를 살펴보았습니다. 수학 라이브러리 측면에서 최고의 표준이라고 생각하는 라이브러리입니다. 놀랍게도, 그것들은 순환적이지 않습니다. 그들은 기본적으로 그들이 정의하는 간단한 유형에서 복잡한 유형의 잘 정의된 순서를 가지고 있으며 매우 신중하게 수행하면 작동한다고 생각합니다.

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

Math와 Vec이 가장 단순한 것 같습니다.

종속성 그래프에 대한 추가 관찰:

Material 에는 기본 클래스와 양방향 dep가 있습니다.

보기가 조금 어렵지만 Geometry s는 기본 클래스에서 좋은 단방향 dep를 가지고 있는 것 같습니다.

Light s 와 Camera s 는 비슷한 상황을 가지고 있습니다 -- 그들의 기본 클래스에 관해서는 좋지만 Object3D 의 의존성은 _그들에 대한_ 불필요한 것 같습니다.


Curve s Path s Line s 괜찮아 보이지만 Shape 는 약간 엉켜 있습니다.

@coballast 감사합니다! 이것은 훌륭한 통찰력입니다.

댓글을 위해 저를 추가합니다 :)

Btw, 예를 들어 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 에 대한 많은 순환 dep를 정리해야 합니다.

Mesh 는 다음과 같습니다. 일부 관련 없는 dep가 있을 수 있지만 너무 미친 것은 아닙니다.

Object3D 및 Geometry 가 있는 원형 Object3D -> Mesh 참조는 위의 PR에 나와 있습니다. Mesh -> Geometry 참조는 괜찮습니다. b/c Mesh 는 Geometry 의 인스턴스를 제어합니다. 클래스별 동작( Geometry / BufferGeometry )에 대한 유형 검사를 수행하는 경우에는 여전히 중단될 수 있습니다.

Geometry -> Mesh 참조는 geometry.mergeMesh( mesh ) 를 제공하는 것입니다. Geometry 는 Mesh 보다 낮은 수준의 개념이므로 mesh.mergeIntoGeometry( geo ) mergeMesh $ 를 사용하지 않습니다.

누군가가 이 중 일부를 수정하는 병합을 받으면 알려주시면 현재 상황을 반영하도록 그래프를 업데이트하겠습니다.

@bhouston @gero3 수학 라이브러리에 대해 동일한 수준의 유용성/유틸리티를 얻기 위해 순환 종속성이 필요하다고 확신하지 않습니다. 내가 틀릴 수도 있지만 Vector3를 나머지 시스템과 완전히 격리/무지하게 유지하고 Matrix4 모듈에서 Matrix4를 수용하도록 프로토타입을 수정할 수는 없습니까? 행렬은 벡터보다 복잡하기 때문에 개념적으로 이해가 됩니다. 사고를 방지하기 위해 프로토타입과 클래스가 구성되는 잘 정의된 순서를 갖는 것이 더 낫다고 생각합니다.

@bhouston @gero3 api를 전혀 변경하지 않고도 그렇게 할 수 있다고 생각합니다. 이리저리 찔러보고 뭐지.

수학 문제에 관해서는 모든 "스크래치 패드"를 한 곳에 놓을 수 있습니다. 하지만 Vector3와 Matrix4를 모두 포함하지 않는 3js의 사용 가능한 단일 그래프는 없을 것입니다.

수학 라이브러리의 성능이나 API를 변경하지 않는 솔루션이 있다면 저는 전적으로 찬성합니다.

@coballast 는 API 변경 없이 주기적 dep를 제거할 수 없으며 b/c는 둘 다 다른 유형을 사용하는 메소드를 제공합니다. Vector3 Matrix4

Browserify compat의 경우, 우리의 유일한 요구 사항은 스크래치 변수에 대한 인스턴스화를 클래스 정의 시간 밖으로 옮기는 것입니다(처음 실행 시 인스턴스화되도록 함). 이것을 게으르게 만드십시오 . 이는 API 또는 성능에 영향을 미치지 않습니다.

그런 변화는 괜찮다고 생각합니다.

@kumavis 아! 예. 알겠습니다. 이제 이해합니다. 충분히 쉽습니다.

다음과 같은 이유로 3개를 require 구조로 더 작은 모듈로 나누는 것을 전적으로 지원합니다.

1. THREE는 매우 큽니다. 사용자가 필요한 것만 요구할 수 있다면 클라이언트 빌드 크기를 줄일 수 있습니다. 예를 들어 react-bootstrap 을 사용하면 모든 부트스트랩 모듈을 번들로 묶지 않는 var Alert = require('react-bootstrap/lib/Alert'); 와 같은 작업을 수행할 수 있습니다.
2. $#$2 THREE.OrbitControls #$ 에 3개의 전역 개체 자체를 수정하는 OrbitControls.js 와 같은 일부 "플러그인"이 있습니다. 이것은 빌드 프로세스의 전역 네임스페이스에 필요한 파일이 아닌 3개가 필요하기 때문에 최신 자바스크립트 프레임워크에서 안티패턴입니다. THREE는 내부적으로도 이 작업을 수행하여 항상 THREE 네임스페이스를 수정하므로 특정 THREE 모듈을 포함하는 데 적합하지 않습니다.

THREE.OrbitControls에 자신을 배치

하지만 3js의 모든 코드가 그렇게 합니까?

@DelvarWorld 는 다음과 같이 썼습니다.

다음과 같은 이유로 3개를 require 구조로 더 작은 모듈로 나누는 것을 전적으로 지원합니다.

쪼개는게 좋은 아이디어라고 생각했는데 지금처럼 ThreeJS에 단순함이 있다. 3D를 처음 접하는 사람들은 현재 개발팀의 최우선 과제인 형태로 더 유용하게 사용할 수 있습니다. 모듈 시스템 없이도 ThreeJS를 사용할 수 있습니다.

@makc 처럼 저도 @DelvarWorld 의 THREE 네임스페이스에 아무것도 넣지 말자는 제안에 대해 의아해합니다.

그들은 대신 어디에 / 어떻게 될까요?

나에게는 모든 부분(및 일부 확장/플러그인)이 있는 하나의 전역 개체인 THREE만 만드는 것이 좋은 패턴인 것 같습니다.

저는 @DelvarWorld 와 함께 put-it-on-global 기술이 코드베이스의 건강에 좋지 않다는 데 동의합니다. 전역 자체에 적용하는 일종의 미묘한 논쟁은 문제가 아니며, 숨겨진 종속성 그래프 및 전역을 사용할 수 있게 된 다른 방법.

그러나 그 주장은 대부분 내부 개발 및 코드 구조로 제한됩니다. 라이브러리를 정적 코드 번들로 제공하는 경우 모든 클래스를 전역 THREE에 배치하는 것이 합리적입니다.

반대 주장은 THREE.js 장면 json을 역직렬화할 때 항목이 THREE[ obj.type ] 와 같이 전역에서 끌어낼 수 있는 문자열로 클래스를 나열할 수 있다는 것입니다. 이것은 역직렬화하기 전에 THREE 에 정의하는 한 표준 three.js 라이브러리에 없는 클래스와 함께 작동합니다. THREE 전역 없이 이 동작을 대체하는 가장 좋은 방법은 확실하지 않습니다.

이것은 역직렬화하기 전에 THREE에서 정의하는 한 표준 three.js 라이브러리에 없는 클래스에서 작동합니다. THREE 전역 없이 이 동작을 대체하는 가장 좋은 방법은 확실하지 않습니다.

모든 것이 모듈인 경우 이 패턴(또는 일부 변형)을 수행할 수 있습니다.

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

모듈과 관련하여 ES6에는 많은 변경 사항이 있습니다. 그 시점에서 ThreeJS의 모듈성을 다시 살펴보겠습니다.

3의 빌드된 버전(사람들이 수동으로 다운로드할 수 있는 자바스크립트 파일)은 여전히 ​​3개의 네임스페이스에 모든 것을 가지고 있습니다. 다음과 같은 빌드의 진입점 파일을 사용하여 이 작업을 수행할 수 있습니다.

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

등, 여전히 초보자에게 유용하고 시작하기 쉽습니다.

최신 자바 스크립트 빌드에서 npm 및 requirejs/browserify/webpack의 세 가지를 사용하는 경우 다음과 같이 할 수 있습니다.

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

등, 클라이언트 크기 번들에 내장된 3개의 크기 중 일부를 줄일 수 있습니다. 세 가지 중 얼마나 많은 것이 "핵심"인지 모르기 때문에 틀릴 수 있습니다. 하지만 지금은 three가 require 문을 사용하지 않기 때문에 불가능합니다.

어느 쪽이든 현대적인 패턴은 모듈을 필요로 하며 모든 코드가 다른 라이브러리를 수정하도록 하는 대신(글로벌 THREE 수정, 잘못된) 코드는 독립적이고 모듈식이며 require 문으로 필요한 것을 지정합니다. 예를 들어 React 소스 코드 .

require/module 구문 사용에 대한 완전한 주장을 하려고 하는 것은 도움이 될 것이라고 생각하지 않습니다. 온라인에 이에 대한 좋은 리소스가 많이 있기 때문입니다. 그러나 다른 사람들이 OrbitControls와 같은 플러그인을 추가하기 위해 THREE 네임스페이스를 수정하도록 권장하는 것은 좋지 않습니다.

@DelvarWorld ES6은 매우 구체적이고 독특한 구문을 사용하여 JavaScript에 공식적으로 모듈을 도입한다는 점에 유의하십시오.

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

@bhouston 오 예 완전히, 나는 일반적으로 모듈 패턴을 지원하기만 하면 import vs import(가져오기가 더 나은 선택)에 불가지론적입니다.

@bhouston @DelvarWorld @kumavis 내 장기 프로젝트 중 하나는 commonjs/amd 모듈을 수용하고 es6으로 변환할 수 있는 자동 es5 -> es6 변환기를 작성하는 것입니다. 등등. 브라우저가 표준을 따라잡으면서 코드를 사용할 수 있도록 준비하는 동안 es6ify와 같은 브라우저화 변환을 사용할 수 있습니다. 내부 수준에서 THREE를 browserify로 옮기는 것은 그러한 도구에 대한 입력을 준비하기 위한 좋은 첫 번째 단계입니다.

이것은 내가 (분명히 매우 형편없게) 만들려고 했던 요점에서 벗어났습니다. 모듈성 문제와 상관없이 이러한 순환 종속성을 가능한 한 많이 제거하고 싶습니다. 왜냐하면 이것이 3개를 보다 안정적이고 유연하게 만들고 즐거운 부작용으로 많은 버그를 제거할 것이라고 믿기 때문입니다.

@coballast https://github.com/mrdoob/three.js/pull/6252 가 병합되었으며 많은 순환 dep를 줄여야 합니다. 새로운 깊이 그래프를 생성할 수 있다고 생각하십니까? 변환 도구 저장소에서 유틸리티로 만들 수도 있습니다.

다음은 Vector3 Matrix4 의 스크래치 변수를 정의 시간이 아니라 처음 사용할 때 느리게 정의하는 것입니다.

자원봉사 하고 싶은 사람? 빨라야 한다

그래프가 업데이트되었습니다. http://jsbin.com/medezu/3/

다음은 스크린샷입니다.

수많은 Object3D circ dep가 제거되었음을 보고하게 되어 기쁩니다. 잘했어 @kumavis!

와우 같은 코드베이스인가요? 미친

유틸리티의 그래프 생성 부분을 만드는 작업을 할 것입니다.

그래프만 보아도 Shape 와 Geometry 는 풀 수 있는 가능한 클래스 트리로 보입니다.

@coballast 당신이 이것을 감당할 수 있다고 생각합니까?

Vector3 Matrix4의 스크래치 변수를 정의 시간이 아니라 처음 사용할 때 느리게 정의

자동 변경이 아닌 업스트림 dev 에 대한 PR입니다.

또한 문제 제목을 "심각한 순환 종속성 문제"에서 "순환 종속성"으로 다운그레이드할 수 있다고 생각합니다. 상황이 훨씬 개선되었습니다!

@kumavis 물론입니다. 시간이 허락할 때 작업할 것입니다.

내가 볼 때 상호 의존성 정리의 현재 상태는 다음과 같습니다.
(화살표는 적절한 경우 제거 해야 하는 연결을 나타냄)

• [x] 재료
• [x] 기하학
• [x] Object3D
• [x] 수학
• [x] 모양
  
  
  
  • [x] 모양 -> FontUtils
  
  
  • [x] 모양 -> ExtrudeGeometry
  
  
  • [x] 모양 -> 모양 기하
  
  
  • [x] 경로 -> 모양
  
  
• [ ] 상자3
  
  
  
  • [ ] 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 둘 다 정리할 수 있습니다.

클래스 자체에 클래스 종속 동작을 적용하지 않는 또 다른 경우입니다.

출처 :

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를 기반으로 매개변수를 설정해야 합니다.

그러면 순환 dep의 Box3 -> BufferGeometry 및 Box3 -> Geometry 끝이 제거됩니다. 내가 빠진 것이 있으면 알려주십시오.

흠 아마도 결과 코드가 약간 복잡할 것입니다. 여기서 실제로 의미가 있는 것은 무엇입니까? Box3.setFromObject 는 존재해서는 안 되지만 옵션은 아닙니다. Geo's는 box3s를 생산할 수 있어야 합니다. 나는 그것에 대해 아무런 문제가 없습니다. 예, Box3.setFromObject 는 경계 상자/범위에 대해 지역에 요청해야 하지만 경계 상자/범위에 대해서는 Object3D / Mesh 를 요청해야 합니다.

죄송합니다. 당신이 어떻게 생각하는지 알아요.

관련 가능성: #6546

이와 같은 것이 없으면 로더 스크립트에서 이러한 동적 종속성을 분석하는 것이 불가능합니다.

내 테스트에 따르면 순환 종속성은 commonJSification의 문제가 아닙니다. 그것들은 올바르게 처리되어야 하며 이전에 이 스레드에서 언급했듯이 종속성 그래프를 상당히 엉망으로 만들지만 THREE.js가 commonJS 환경에서 작동하는 것을 막지는 않습니다(물론 변환될 때).

3개의 commonjs 변환기 를 사용하여 npm에 전체 commonjs 버전을 three.cjs로 게시했습니다.

참고: 이 작업을 수행하려면 마스터에서 #6546을 수동으로 체리픽해야 했습니다. 동적 종속성은 node.js에서 잘 작동하지만 정적 종속성 분석을 수행해야 하기 때문에 Browserify(또는 다른 모든 cjs에서 브라우저 도구로)에서는 작동하지 않습니다.

브라우저화 증명 : http://requirebin.com/?gist=b7fe528d8059a7403960

@kamicane 참고 - Raycaster (이전에는 Ray )에 익명 함수의 인수로 THREE 가 추가되었습니다.

익명 함수의 필요성을 이해하지만(브라우저에서 전역 누수를 방지하기 위해) 인수가 불필요하고 전체 파일이 계산된 종속성 범주에 속하게 됩니다. 인수는 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/를 참조하세요. 블롭/dev/src/math/Vector3.js#L315)

@roomle-build Idk, Man, Matrix4 생성자를 명시적으로 참조하기 때문에? ~는 어때

    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 부터 시작하겠습니다.

Vector3 는 project 및 unproject 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 정말 아닙니다. 작은 "도우미" 기능이 많은 하나의 큰 모듈이 될 것입니다. 이것은 트리 흔들기 등에도 도움이 됩니다. 수학 모듈은 다음과 같습니다.

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

https://auth0.com/blog/whats-new-in-rxjs-6/ 과 같은 여러 블로그 게시물에서 RxJS 6에서 이 항목을 변경한 "이유와 방법"에 대해 읽을 수 있습니다.

그러나 내가 말했듯이 이것은 단지 생각일 뿐이며 이것이 나머지 코드베이스에 미칠 영향에 대해 확신할 수 없습니다. 또한 현재 math 모듈은 이와 같이 사용할 "준비"가 되어 있지 않습니다. 현재 수학 모듈의 모든 메서드는 "정적 종류"에 연결되어 있습니다. 이것은 또한 롤업이 실제로 필요한 것을 감지하는 것을 방지합니다...

@roomle-build 흠 그래서 롤업이 동일한 범위의 코드가 실제로 전체 범위를 필요로 하지 않는지 이해할 수 있다는 뜻입니다.

객체 지향 접근 방식(객체에 멤버 함수가 있음)이 아닌 기능적 접근 방식(객체를 취하는 함수)으로 이동하는 것에 대해 이야기하고 있습니다. 이것은 실제이지만 Three.JS가 완전히 객체 지향임을 감안할 때 이러한 유형의 변경을 제안하는 것은 꽤 큰 것이고 기존의 모든 코드를 깨뜨릴 것입니다.

이 변경에 찬성하는 주장이 모든 이전 버전과의 호환성을 깨는 것을 정당화하기 위해 현 시점에서 그렇게 중요한지 확신할 수 없습니다.

@makc 정말 아닙니다. 작은 "도우미" 기능이 많은 하나의 큰 모듈이 될 것입니다. 이것은 트리 흔들기 등에도 도움이 됩니다. 수학 모듈은 다음과 같습니다.

이것이 제안된 것이라면 올바르게 설명되어야 합니다. Three.JS의 객체 지향적인 디자인에서 기능적인 디자인으로의 변화입니다.

@roomle-build 흠 그래서 롤업이 동일한 범위의 코드가 실제로 전체 범위를 필요로 하지 않는지 이해할 수 있다는 뜻입니다.

예 롤업은 모든 가져오기가 서로 어떻게 관련되어 있는지 이해하고 트리 흔들기, 데드 코드 제거 등을 수행합니다. 롤업의 새 버전은 "청킹" 및 기타 많은 좋은 작업도 수행할 수 있습니다. 그러나 현재 프로젝트 구조에서는 이러한 기능을 충분히 활용하지 못합니다.

객체 지향 접근 방식(객체에 멤버 함수가 있음)이 아닌 기능적 접근 방식(객체를 취하는 함수)으로 이동하는 것에 대해 이야기하고 있습니다. 이것은 실제이지만 Three.JS가 완전히 객체 지향임을 감안할 때 이러한 유형의 변경을 제안하는 것은 꽤 큰 것이고 기존의 모든 코드를 깨뜨릴 것입니다.

나는 이 두 패러다임이 상호 배타적이라고 생각하지 않습니다. 나는 당신이 이 두 패러다임을 혼합하고 일치시킬 수 있다고 생각합니다. 나는 또한 함수형 프로그래밍으로의 변경을 제안하지 않습니다. 순환 종속성을 제거하는 방법을 설명하고 싶었습니다. multiplyMatrices 메서드를 Math 개체에 연결할 수도 있습니다. 그러나 누군가가 이런 종류의 것을 다시 작성한다면 ES6 모듈의 기능을 사용하는 것을 고려하는 것이 합리적일 것입니다. 그러나 내가 말했듯이 나는 Three.js 코드베이스의 전문가가 아니며 순환 종속성을 제거하는 방법에 대한 생각이었습니다. 저는 Three.js가 훌륭한 코드 기반을 갖춘 멋진 프로젝트라고 생각하며 잔소리를 하고 싶지 않습니다. 그러니 아무도 내 댓글에 기분이 상하지 않길 바랍니다 😉

어떤 문제에서 디자인 결정에 대해 논의해야 하는지 잘 모르겠습니다. 이런거 잘어울릴곳 없나요?

BTW gl-matrix는 기능적 수학 라이브러리입니다: https://github.com/toji/gl-matrix/tree/master/src/gl-matrix

@룸빌드

현재 수학 모듈의 모든 메서드는 "정적 종류"에 연결되어 있습니다.

어때요?

@mrdoob 나는 gl-matrix의 기능적 디자인으로 vec3의 각 기능(이전 의견에서 링크한 vec3 파일에서)이 개별적으로 내보내진다고 믿습니다. 이를 통해 가져올 함수를 선택하고 선택할 수 있습니다. vec3를 모두 가져올 필요는 없습니다.

Three.JS와 마찬가지로 객체 지향 설계를 사용하기 때문에 Vector3의 모든 수학 함수는 Vector3 객체 프로토타입에 첨부되며 Vector3 클래스 자체만 가져옵니다.

따라서 Three.JS의 가져오기는 전체 클래스인 반면 기능적 접근 방식에서는 개별 기능을 가져옵니다.

(gl-matrix 라이브러리의 또 다른 멋진 점은 모든 개별 함수가 다른 함수를 사용하지 않는다는 것입니다. @toji 는 기본적으로 모든 수학의 최적화된 버전을 각 개별 작업에 인라인했습니다. 이것은 속도 면에서 상당히 효율적일 것입니다. 그러나 라이브러리를 유지 관리하기가 어렵습니다.)

나는 우리가 three.js의 다른 디렉토리에 대한 /math의 참조를 제거하는 것을 제외하고는 Three.JS의 이 부분을 리팩토링할 필요가 없다고 생각합니다. 수학 라이브러리는 상당히 작으며 요즘 내 프로파일링 테스트에 실제로 나타나지 않습니다. 예, 최대로 효율적이지는 않지만 유지 가능한 가독성과 사용 용이성을 유지하면서 충분히 가깝습니다.

@bhouston 알겠습니다. 많은 설명 감사합니다! 😊

나는 단지 그 주제에 대해 후속 조치를 취하고 싶었을 뿐입니다. 하지만 importing function vs importing classes 에서 cyclic dependencies 를 해결하는 주제로 돌아가고 싶습니다. (또한 import { someFunction } from 'SomeModule' 이 import SomeClass from 'SomeModule' 보다 유지 관리가 덜 쉬운 이유를 알 수 없지만 확실히 이 문제/대화의 주제는 아닙니다.

순환 종속성을 해결하려면 기능을 별도의 클래스에 넣는 것이 가능합니다. multiplyMatrices multiplyMatrices 가 있는 Multiplier-Class를 생성할 수 있습니다. 그러나 전에 말했듯이 순환 종속성을 제거해야 하는지 확실하지 않습니다. 삭제하지 않기로 결정했다면 이 문제가 해결될 수 있다고 생각합니다 😃

#19137 해결 후 지금 닫을 수 있습니다🎉 .

@Mugen87 와, 5년차! 드디어 성공을 축하합니다 :fire: :clap:
그 당시에는 그 그래프를 만드는 것이 매우 즐거웠습니다 :smile_cat: