Three.js: 모듈식 아키텍처로 이동

한 가지 장점은 이것이 three.js의 지속적인 개발을 위해 모듈식 아키텍처를 적용한다는 것입니다.

node/browserify의 공통 스타일은 각 파일이 상단에 종속성을 선언하고 전역 변수를 반패턴으로 간주합니다.

다음은 예시 스니펫입니다.

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

function BoxGeometry() {
  // ...
}

BoxGeometry.prototype = Geometry.prototype;

또 다른 이점은 browserify를 사용하는 three.js 소비자가 원하는 부분을 선택하고 선택할 수 있다는 것입니다. 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')
// ...

참고: 이 파일은 거의 독점적으로 require 문이기 때문에 이 예제의 맨 위에 있는 종속성을 정확히 요구하지는 않습니다.

마지막으로 모듈 시스템(node/browserify, AMD)이 사용 중인지 감지하는 범용 모듈 정의로 이를 래핑하고, 사용 중인 경우 내보내거나 전역 개체( window )에 추가합니다.

복습 해보자:

• 좋은 모듈식 스타일을 적용합니다.
• 브라우저화를 사용하는 three.js 소비자가 기능을 선택하고 선택할 수 있습니다.
• 주요 변경 사항 없음

이를 위해서는 빌드 시스템을 교체해야 하지만 새 시스템은 매우 간단합니다.

다른 장점:

• 코드를 구성할 수 있습니다.
• 전역 네임스페이스를 오염시키지 않고 모듈을 생성/재사용할 수 있습니다.
• 생산을 위해 구축할 수 있습니다.
• 모든 모듈에는 자체 파일이 있으므로 더 쉽게 디버그할 수 있습니다. 큰 three.js 파일에서 해당 모듈을 검색할 필요가 없습니다.

@shi-314 제가 좀 혼란스럽네요. You can structure your code 와 You can build for production 가 아키텍처 변경 없이 할 수 있는 일인가요? three.js 소스 또는 three.js를 사용하여 빌드된 것들에 대해 이야기하고 있습니까?

three.js가 commonjs 환경에서 사용하기 어렵게 만드는 한 가지 방법은 instanceof . https://github.com/mrdoob/three.js/blob/master/src/core/Geometry .js#L82

이는 애플리케이션에서 소스 트리에 동일한 라이브러리의 다른 버전이 있는 경우가 많기 때문에 instanceof 검사가 동일한 라이브러리의 다른 버전 간에 작동하지 않기 때문입니다. 이러한 instanceof 검사를 Geometry.isGeometry(geom) 스타일 인터페이스 뒤의 기능 검사로 대체하기 위해 commonjs 모듈 시스템으로 이동하는 것을 준비하는 것이 좋습니다.

@kumavis 저는 three.js로 빌드된 것들에 대해 이야기하고 있습니다. 셰이더 등으로 자신만의 머티리얼을 만들고 싶다고 가정해 보겠습니다. 현재 나머지 three.js 코드와 일관성을 유지하기 위해 전역 THREE 객체를 확장해야 합니다.

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

성능은 이와 같은 변경으로 인해 영향을 받지 않아야 합니다.

이것은 꽤 큰 변화이지만 나는 또한 그것에 찬성합니다.

기타 주요 이점:

• Browserify의 standalone 옵션을 사용하여 UMD 빌드를 생성할 수 있습니다. UMD 래퍼를 수동으로 수정할 필요가 없습니다.
• 브라우저화/NPM 사용자가 패키지를 쉽게 사용할 수 있습니다.
• threejs(예: poly2tri, color-string 등)에 대한 종속성을 가져오는 것이 훨씬 쉬워집니다.
• 벡터/수학 라이브러리와 같은 렌더링 라이브러리에 "실제로 속하지 않는" 모듈은 별도의 NPM 모듈로 가져와서 다른 많은 유형의 프로젝트에 재사용할 수 있습니다. 이것의 주요 이점 중 하나는 개별 모듈에 버그/문제, PR 등을 위한 자체 저장소가 있다는 것입니다(ThreeJS 문제 정리).
• NPM은 의미론적 버전 관리를 처리합니다. 예를 들어 모든 사람의 코드 깨짐에 대해 걱정하지 않고 threejs-vecmath 의 주요 변경 사항을 푸시할 수 있습니다. 그리고 반대로 특정 모듈에서 패치나 마이너 릴리스를 만들면 해당 모듈을 사용하는 사람들이 자동으로 변경 사항을 받을 수 있습니다.
• EffectComposer 및 다양한 셰이더와 같은 "추가 기능"을 쉽게 패키지하고 소비할 수 있습니다( npm install threejs-shader-bloom 상상).
• 모듈이 제거됨에 따라 최종 배포 크기는 점점 작아지고 응용 프로그램에 따라 달라집니다. 우리 앱이 실제로 사용하고 있는 모듈을 require() 만 사용하기 때문에 결국 다른 "빌드 유형"이 필요하지 않습니다.

@mrdoob 및 다른 저자에게; NPM/Browserify에 대한 경험이 많지 않다면 NPM/Browserify로 몇 가지 작은 프로젝트를 만들고 "철학"에 대한 느낌을 얻는 것이 좋습니다. ThreeJS 아키텍처와 매우 다릅니다. 큰 프레임워크보다는 작은 것들을 많이 장려합니다.

이 접근 방식의 또 다른 이점은 오픈 소스, 타사 Three.JS 모듈, 특히 셰이더, 지오메트리, 모델 로더 등의 생태계가 있을 수 있다는 것입니다. NPM 또는 Github/Component를 통해 게시되어 사람들이 쉽게 참조하고 사용할 수 있습니다. 현재 사람들이 '소스 보기'를 할 수 있는 데모를 호스팅하여 물건을 공유하고 있습니다. Three.JS는 더 나은 가치가 있습니다!

Three.JS에 대한 문제 중 하나는 코드가 현재 버전의 Three.JS와 얼마나 빨리 호환되지 않는지입니다. 이와 같은 것으로 전환할 때의 또 다른 이점은 Three.JS의 _bits_ 특정 버전을 지정할 수 있다는 점입니다. 매우 강력하고 편리합니다.

+1

CommonJS/browserify 아키텍처의 경우 +1, 코어를 더 가볍게 만들고 타사에서 제공한 확장 기능도 적합합니다.

three.js를 작은 모듈로 조각화하는 데에도 많은 비용이 듭니다. 현재 시스템은 아주 간단한 타사 애드온을 허용합니다(예: jetienne의 THREEx 모듈). JS 모듈 시스템이 빌드 시스템을 둘러싼 래퍼인 한 현재 설정의 단순성에 대해 할 말이 많습니다.

빌드 크기를 최소화하는 또 다른 방법은 ClojureScript가 하는 일입니다. 그들은 Google의 Closure 컴파일러가 전체 프로그램 분석 및 데드 코드 제거를 수행할 수 있도록 몇 가지 규칙을 따릅니다.

감사하지 않고 종종 간과되는 단순함의 우아함 +1

+1

three.js를 작은 모듈로 조각화하는 데에도 많은 비용이 듭니다. 현재 시스템은 아주 간단한 타사 애드온을 허용합니다(예: jetienne의 THREEx 모듈).

여기서 아이디어는 노드가 아닌 환경에 대해 UMD 빌드가 계속 제공된다는 것입니다. THREEx와 같은 플러그인은 간단한 <script> 태그가 있는 ThreeJS에 의존하는 플러그인과 동일한 방식으로 작동합니다.

까다로운 점은 다음과 같습니다. CommonJS 환경에 있는 경우 특정 플러그인을 require() 하는 방법은 무엇입니까? 아마도 browserify-shim이 도움이 될 수 있습니다.

JS 모듈 시스템이 빌드 시스템을 둘러싼 래퍼인 한 현재 설정의 단순성에 대해 할 말이 많습니다.

ThreeJS의 현재 플러그인/확장 시스템은 작업하기가 매우 끔찍하며 "단순"하거나 쉽지 않습니다. 대부분의 ThreeJS 프로젝트는 EffectComposer, FirstPersonControls, 모델 로더 또는 examples 폴더에 떠다니는 다른 많은 JS 파일 중 하나와 같은 플러그인이나 확장 기능을 사용하는 경향이 있습니다. 현재 이 플러그인에 의존하는 유일한 방법은 다음과 같습니다.

• ThreeJS의 현재 빌드 다운로드
• 필요한 파일을 vendor 폴더에 복사하여 붙여넣습니다.
• 꿀꺽 꿀꺽 꿀꺽 꿀꺽 꿀꺽 꿀꺽 마시며 필요한 모든 플러그인을 연결하고 축소하세요. 그것들을 _올바른 순서로_ 연결해야 합니다. 그렇지 않으면 일이 깨질 것입니다. 플러그인을 추가할 때 이 목록을 수동으로 유지 관리하십시오.
• ThreeJS가 업데이트될 때마다 1단계와 2단계를 반복합니다. 그런 다음 새 코드가 이전 버전과 호환되지 않는다는 것을 깨달았을 때 머리를 빼십시오.

이제 브라우저화를 사용하여 다음과 같은 작업을 수행할 수 있다고 상상해 보십시오.

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

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

이러한 플러그인은 require('threejs') 및 필요할 수 있는 기타 모든 것(예: GLSL 스니펫 또는 텍스트 삼각 측량 )입니다. 종속성/버전 관리는 모두 사용자에게 숨겨져 있으며 수동으로 유지 관리되는 grunt/gulp 연결 작업이 필요하지 않습니다.

까다로운 점은 다음과 같습니다. CommonJS 환경에 있는 경우 특정 플러그인을 어떻게 요구합니까()?

저는 지금 THREE.js 프로젝트에 CommonJS를 사용하고 있습니다. 다른 사람의 코드 덩어리를 모듈로 변환하는 약간의 수동 프로세스이며 작성자나 기여자가 변환하지 않은 레거시 코드의 경우 이를 피할 수 있는 쉬운 방법이 없을 것이라고 생각합니다.

중요한 점은 전체 '표준' THREE 개체를 내보내는 모듈이 있다는 것입니다. 그러면 확장하려는 모든 개체에서 이 개체가 필요할 수 있습니다.

var THREE = require('three');

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

이것은 특히 프로젝트가 성장하고 내 자신의 셰이더와 지오메트리를 자체 모듈 등에 추가하기 시작함에 따라 꽤 잘 작동했습니다.

'threejs-full' 또는 'threejs-classic' npm 패키지가 있는 한 이것은 CommonJS 환경에서 오래된 Three.js 항목으로 작업하는 꽤 실행 가능한 방법이 되지만 이것이 꽤 틈새 시장이라고 생각합니다!

+1
단편화 된 threejs 모듈을 npm, 플러그인에서 사용할 수 있다고 생각합니다.
개발자는 CommonJS 환경으로 마이그레이션하는 것을 좋아할 것입니다.
2014년 6월 5일 오후 9시 19분에 "Charlotte Gore" [email protected]이 다음과 같이 썼습니다.

까다로운 점은 다음과 같습니다.
CommonJS 환경에 있습니까?

저는 지금 THREE.js 프로젝트에 CommonJS를 사용하고 있습니다. 조금이다
다른 사람의 코드 덩어리를 모듈로 변환하는 수동 프로세스
레거시 코드에서 이를 피할 수 있는 쉬운 방법은 없을 것이라고 생각합니다.
작성자나 기여자가 변환하지 않은 것입니다.

중요한 점은 전체 '표준'을 내보내는 모듈이 있다는 것입니다.
확장하고자 하는 모든 것이 요구할 수 있는 3개의 객체
그것.

var THREE = 요구('3');
THREE.EffectComposer = // ... 등, 저작권 표시 포함 기억 :)

이것은 특히 프로젝트가 성장하고 내가
내 자신의 셰이더와 지오메트리를 자체 모듈 등에 추가하기 시작합니다.

'threejs-full' 또는 'threejs-classic' npm 패키지가 있는 한
이것은 오래된 Three.js로 작업하는 꽤 실용적인 방법이 됩니다.
CommonJS 환경이지만 이것이 꽤 틈새 시장이라고 생각합니다!

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/mrdoob/three.js/issues/4776#issuecomment -45236911.

예를 들어 glslify를 사용하여 셰이더를 모듈식으로 만들 수도 있습니다. 요청 시 셰이더를 생성하는 Express 미들웨어를 만드는 것과 같은 작업도 더 쉬워집니다.

몇 달 전에 나는 frame.js 를 require.js로

그러나 이것을 "컴파일"하는 방법을 배워야 합니다. 모듈 목록에서 three.min.js 을 생성하기 위한 도구/워크플로는 무엇입니까?

gulp -browserify 플러그인이 있는 빌드 시스템으로 gulp.js 를 선호합니다. 정말 이해하기 쉽고 코드는 내 의견으로는 grunt보다 더 깔끔해 보입니다. 이것을 확인하십시오: http://travismaynard.com/writing/no-need-to-grunt-take-a-gulp-of-fresh-air :wink:

몇 가지 생각: (노드, npm, 물론 브라우저화에 대한 나의 제한된 경험을 기반으로 함)

1. 나는 node.js 모듈이 훌륭하다고 생각합니다 (즉, npm, 모듈 및 require()s)
2. 나는 브라우저화도 훌륭하다고 생각한다

즉, 이 스레드에 대한 토론에 따라 모든 사람이 browserify에 대해 동일한 이해를 갖고 있는지 확신할 수 없습니다(browserify, commonjs, requirejs, amd, umd는 필요하지 않을 수도 있지만 어느 정도 관련되어 있음).

이제 내 생각의 사슬을 조금 따라갈 수 있다면.

1. JS는 훌륭하며 여러 브라우저에서 빠르게 실행됩니다.
2. 와우, 이제 JS는 서버 측에서도 실행됩니다.
3. 그게 node.js입니다. 멋집니다. node.js에서 코드를 작성해 보겠습니다.
4. 하지만 쓰고 싶지 않습니다/ 모든 것을 쓸 수 없습니다/ 사용할 무언가를 찾습니다.
5. 걱정하지 마세요. 이제 npm 설치 모듈을 실행하세요.
6. 이제 우리가 사용할 수 있도록 이 멋진 모듈이 필요합니다.
7. 잘 작동합니다!
8. 이제 잠깐만, 우리는 node.js에서 실행되는 JS로 많은 것들을 작성했습니다.
9. js는 브라우저에 있지 않습니까? 이 코드를 다시 실행하려면 어떻게 해야 합니까?

Browserify가 그림에 등장하는 곳입니다. 기술적으로 브라우저에서 requireJS를 사용할 수 있습니다. 그러나 (빠른 파일 시스템 require()와 달리) 너무 많은 네트워크 호출을 수행하지 않고 js 파일을 함께 묶고 싶습니다. Browserify는 어떤 모듈을 가져와야 하는지 확인하고 애플리케이션에 더 최적화된 빌드를 생성하기 위해 정적 분석과 같은 몇 가지 멋진 작업을 수행하는 곳입니다. (물론, 아마도 require('bla' + variable)를 구문 분석할 수 없는 제한 사항이 있습니다) node.js 종속 항목에 대한 에뮬레이션 레이어가 필요한 부분을 교체할 수도 있습니다. 예, 이제 내 브라우저에 포함할 수 있는 js 빌드를 생성합니다.

다음은 browserify가 https://github.com/substack/node-browserify#usage 를 수행할 수 있는 몇 가지 사항입니다.

지금까지는 모든 것이 훌륭해 보이지만 "건축 탐색"으로 이동하는 것을 고려할 가치가 있다고 생각한 몇 가지 사항이 있습니다.

• three.js 개발자의 사고방식 전환이 필요합니다(물론 require 모듈 시스템을 사용해야 함)
• 호환성 레이어를 구축하여 three.js 사용자가 모듈식 이점을 얻지 않고도 여전히 three.js를 이전 방식으로 사용할 수 있습니다.
• 최적화된 빌드를 생성할 수 있으려면 three.js 사용자가 require 시스템으로 이동해야 합니다.
• 새 빌드 프로세스에는 browserify 도구 체인(현재 python, node.js 또는 간단한 복사 및 붙여넣기 등을 사용할 수 있음) 또는 일부 requireJS 도구가 포함될 수 있습니다.
• 우리가 TrackballControls와 같이 각 구성 요소에 대한 버전 관리와 함께 three.js가 더 모듈화되기를 원한다면 그것들을 분할해야 하며, 이는 단편화로 이어질 수 있습니다.
• 그것은 다양성으로 이어질 수도 있지만 현재 three.js의 한 가지 강점은 많은 확장의 중앙 집중식 인 것처럼 보입니다.

따라서 사용자 정의 빌드와 함께 이러한 다양성과 편리한 모듈 로딩(주로 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"> 대해 축소된 코드를 배송할 수 있습니다.

나는 현재 three.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 제안이 _거대한_ 이점이 될지라도.

하지만 어떻게 작동하는지 보기 위해 3개를 분기하고 모든 것을 별도의 모듈에 넣는 것이 합리적일 수 있습니다.

또한 http://modules.gl/ 을 확인

@mrdoob @shi-314 browserify는 browserify를 직접 사용하기 위해 블랙리스트에 올라

grunt/gulp/etc와 같은 도구는 끊임없이 유동적이며 다양한 의견을 찾을 수 있습니다. 결국 어떤 것을 선택하든, 아니면 그냥 사용자 정의 스크립트로 하든 상관없습니다. 더 중요한 질문은 사용자가 ThreeJS를 어떻게 사용하며 이전 버전과의 호환성을 얼마나 유지하기를 원하는가입니다.

좀 더 생각해본 결과, 프레임워크와 아키텍처를 완전히 리팩토링하지 않고 모든 것을 모듈화하는 것은 _정말_ 어려울 것이라고 생각합니다. 다음은 몇 가지 문제입니다.

• 모든 네임스페이스 코드는 CommonJS 내보내기/요구로 변경해야 합니다. 이것은 꽤 거대한 사업이며 많은 추악한 ../../../math/Vector2 등이 있을 것입니다.
• 이상적인 세계에서는 라이브러리가 조각화되어 three-scene 가 three-lights 등에서 분리됩니다. 그런 다음 각 패키지를 개별적으로 버전화할 수 있습니다. 이러한 종류의 단편화는 ThreeJS와 같은 큰 프레임워크에서는 비현실적이며 유지 관리하는 데 골치 아픈 일입니다.
• 프레임워크를 작은 구성 요소로 조각화하지 _않으면_ 시맨틱 버전 관리는 악몽이 될 것입니다. 프레임워크의 어느 곳에서나 작은 변경 사항은 전체에 대한 주요 버전 범프가 필요합니다. 그리고 API를 사용하는 것은 꽤 추한 것입니다: require('three/src/math/Vector2')

나의 제안? 앞으로 두 가지 사항을 고려합니다.

1. 작게 시작하십시오. Vector/Quaternion, 색상 변환, 삼각 측량 등과 같은 몇 가지 필수적이고 재사용 가능한 기능을 꺼내십시오. 이것들은 ThreeJS의 범위 밖에서 유용하기 때문에 NPM에 대한 좋은 후보입니다. 또한 자체 테스트 스위트, 버전 관리 및 문제 추적을 가질 수 있습니다.
2. 새 기능이나 종속성(예: poly2tri/Tess2)과 같이 새 코드를 ThreeJS에 추가해야 하는 경우 별도의 모듈로 가져와 NPM을 통해 종속시키는 것을 고려하십시오.

모든 것이 모듈화되는 것을 보고 싶지만 ThreeJS에 현실적인 접근 방식이 확실하지 않습니다. 어쩌면 누군가가 포크에서 몇 가지 실험을 하여 일이 얼마나 실현 가능한지 확인해야 할 수도 있습니다.

설명 감사합니다 여러분!

내가 두려워하는 것은 이제 막 시작하는 사람들에게 일을 복잡하게 만드는 것입니다. 그들에게 이 브라우저화/모듈화 내용을 배우도록 강요하는 것은 좋은 생각이 아닐 수 있습니다...

여기서 @mrdoob 에 동의

리포지토리에 미리 컴파일된 UMD( browserify --umd ) 빌드를 사용하면 기존 개발자의 워크플로에 변경 사항이 없습니다.

@mrdoob 종속성 관리 시스템의 아이디어는 단순합니다. 옵션 및 빌드 시스템에 대한 수십 개의 게시물을 읽는 것은 압도적일 수 있지만 궁극적으로 현재 시스템은 지속 가능하지 않습니다. A의 파일이 다른에 따라 언제든지 하나, 사냥 및 - 검색 새로운 개발자는 참조를 찾기 위해 수행 할 수있다. Browserify를 사용하면 종속성이 명시적이며 파일 경로가 있습니다.

@repsac 종속성 시스템은 전역 범위, 로드 순서 악몽을 피하고 다른 인기 있는 언어와 유사한 패러다임을 따르기 때문에 다른 언어 사용자가 Three에 더 쉽게 액세스할 수 있도록 해야 합니다. var foo = require('./foo'); 는 (느슨하게) C#의 using foo; 또는 Java의 import foo; 와 유사합니다.

모든 것이 모듈화되는 것을 보고 싶지만 ThreeJS에 현실적인 접근 방식이 확실하지 않습니다. 어쩌면 누군가가 포크에서 몇 가지 실험을 하여 실현 가능한지 확인해야 할 수도 있습니다.

나는 이것이 갈 길이라고 생각한다, 정말로. 작업을 완료하고 작동 방식을 보여줍니다.

API를 사용하는 것은 꽤 ugly: require('three/src/math/Vector2')

실험으로 저는 세 문서의 '시작하기'를 이 새로운 모듈식 접근 방식으로 변환했습니다. 사람들이 코드를 작은 모듈로 나누는 것에 대해 매우 엄격하지 않는 한 많은 참조가 있다고 상상할 수 있습니다.

이 작업의 주요 이점은 결과 빌드 크기가 전체 Three.js 크기의 아주 작은 부분일 것이라는 점입니다. 여기에서 구체적으로 참조된 항목과 해당 항목이 의존하는 항목만 포함하기 때문입니다.

필요한 모든 종속성을 참조하고 모두 개별적으로 설치하는 것은 실제로는 너무 끔찍할 수 있습니다.

모바일 장치를 명시적으로 대상으로 하는 경우 이 매우 세분화된 접근 방식이 완벽할 수 있지만 실제로는 정상적으로 작동하는 전체 3개의 API를 내보내는 패키지와 모든 보너스 지오메트리를 캡슐화하는 더 작은 패키지가 필요합니다. 렌더러, 모든 수학, 모든 재료 등, 개발자가 스스로 결정할 수 있도록 개별 모듈 수준으로 내려갑니다.

예, 웹 코딩은 고통스럽습니다.

어쨌든 실험을 계속...

우리의 의존성을 설치하십시오..

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가 코드베이스를 관리하기 위해 browserify를 사용하기 위해 최종 사용자가 반드시 프로젝트에서 browserify를 사용할 필요는 없습니다. 3개는 지금과 같이 글로벌 THREE 로 노출될 수 있습니다...빌드 파일을 포함하고 함께 실행하십시오.

@repsac @mrdoob 변경 사항은 이전 버전과 호환되므로 현재 사용자가 원하지 않는 경우 변경할 필요가 없습니다. 이러한 제안은 ThreeJS의 확장되고 모놀리식 코드베이스의 장기적인 유지 관리 가능성과 수명을 개선하기 위한 것입니다. 종속성 및 버전 관리와 같은 것은 초심자에게는 골칫거리처럼 들릴 수 있지만 ThreeJS를 기반으로 도구, 프레임워크, 플러그인 및 대규모 웹 사이트를 개발하는 사람들에게는 훌륭합니다.

즉, 최종 사용자 코드는 여전히 동일하게 보일 수 있으며 examples 는 전혀 변경할 필요가 없습니다.

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

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

모듈식 빌드를 찾고 있는 더 야심찬 개발자, _또는_ ThreeJS 위에 장기 솔루션을 개발하려는 개발자(즉, 버전/종속성 관리 활용)의 경우 다음과 같이 보일 수 있습니다.
npm install three-vecmath --save

그런 다음 코드에서:

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

//.. do something with Vector2

또한, 이를 통해 사람들은 ThreeJS의 범위 밖에서 ThreeJS의 벡터 수학, 색상 변환, 삼각 측량 등을 사용할 수 있습니다.

나는 require() 엉망이 나쁜 생각이고 나쁜 절충안이라고 생각하지만, 사용자에게 두 가지 다른 종류의 three.js 코드를 노출시키는 것은 더 나쁜 생각일 것입니다. 사용자에게 하나는 멋진 모듈 시스템 풍미이고 다른 하나는 더 단순한(그러나 2급) 모듈 시스템 풍미.

@erno three.js 는 내부적으로 모듈 구조로 구성되지만 현재 설정과 다르지 않은 빌드 파일을 생성하는 데 사용됩니다.

주요 이점은 three.js 개발 및 유지 관리 경험을 개선하는 것입니다.

@kumavis - 아니요 @erno 는 실제로 그것을 놓치지 않았지만 three.js 가 요구를 통해 사용되는 경우도 있고 사용하지 않는 경우 혼동될 수 있다는 점을 이해했습니다(*). 예를 들어 누군가는 세 가지 소스를 모두 살펴본 다음 일부 타사 예제를 보고 모든 것이 어떻게 작동하는지 차이점을 발견합니다.

(*) 우리는 오늘 일찍 irc에서 이에 대해 이야기했습니다.

나는 그것이 일종의 유효한 요점이라고 생각하지만 그것이 결국 어떻게 작동하는지 확실하지 않습니다. 실제로 모듈 및 빌드 사용에 문제가 있는지 여부입니다. 그러나 확실히 생각해볼 가치가 있는 것 같고 전반적인 문제가 여기에서 신중하게 고려되었다는 것이 전반적으로 나에게 좋은 것처럼 보였습니다. 지금까지 제 부분에서 정보와 견해에 감사드립니다.

@anton 알겠습니다 . 사람들은 여기에서 다양한 접근 방식을 제안했습니다. 저는 주로 최상위 사용에 대한 문서를 제공할 것이라고 가정했지만( THREE 모든 것을 제거), 다른 사람들은 이를 따르지 않는 예제를 만들 수 있으며 약간의 혼란을 야기합니다. 그리고 그것은 유효한 우려입니다.

언어가 좀 헷갈렸던 것 같아요.

다른 하나는 더 단순한(그러나 2급) 모듈 시스템입니다.

이것은 단지 빌드 파일을 참조하는 것입니다. 네?

제 이해로는 그렇습니다. 다른 것은 상상할 수 없지만 뭔가를 놓칠 수 있습니다.

antont, kumavis: 여기 제안은 require() 스타일 코드를 최종 사용자에게도 노출하는 것에 대해 이야기했습니다. mattdesl의 가장 최근 댓글입니다.

"모듈식 빌드를 찾고 있는 더 야심찬 개발자 또는 ThreeJS 위에 장기적인 솔루션을 개발하려는 개발자(예: 버전/종속성 관리 활용) [...]"

더 최적화된 빌드를 갖는 한 가지 방법은 실제로 종속성을 자동으로 파악하고 필요한 모듈을 만드는 스크립트를 사용하는 것입니다.

지금은 bower & browserify가 require를 사용하지만 이것이 유일한 솔루션은 아닙니다. 나는 그것을 수행하는 다른 기성 오픈 소스 프로젝트가 있는지 모르지만 (ng-dependencies와 같은) 그러한 도구를 작성한 적이 있기 때문에 이러한 고통을 해결하는 다른 접근 방식이 있을 것이라고 생각합니다.

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

three.js가 commonjs 환경에서 사용하기 어렵게 만드는 한 가지 방법은 instanceof를 사용하는 것입니다. https://github.com/mrdoob/three.js/blob/master/src/core/Geometry.js#L82

이는 애플리케이션에서 소스 트리에 동일한 라이브러리의 다른 버전이 있는 경우가 많기 때문에 instanceof 검사가 동일한 라이브러리의 다른 버전 간에 작동하지 않기 때문입니다. 해당 instanceof 검사를 Geometry.isGeometry(geom) 스타일 인터페이스 뒤의 기능 검사로 대체하기 위해 commonjs 모듈 시스템으로 이동하는 것을 준비하는 것이 좋습니다.

git/three.js/src에서:

grep -r instanceof . | wc -l 
164

git/three.js/examples:

grep -r instanceof . | wc -l 
216

따라서 three.js에는 총 380개의 instanceof 이 있습니다. 대안으로 가장 좋은 구현은 무엇입니까?

나는 최근에 그 대부분을 대체하는 데 사용할 수 있는 type 속성을 추가했습니다.

나는 최근에 그 대부분을 대체하는 데 사용할 수 있는 유형 속성을 추가했습니다.

멋진! PR을 준비합니다.

다른 인기 있는 대규모 JS 라이브러리에서 이것이 어떻게 처리되는지에 대한 예는 https://github.com/facebook/react를 살펴보십시오. 코드베이스는 (browserify가 구현하는) 노드 스타일 기반 모듈 시스템을 사용하여 구성되지만 grunt를 사용하여 릴리스를 위해 구축되었습니다. 이 솔루션은 3가지 사용 사례에 대해 유연합니다.

1. 바닐라 JS를 작성하는 Three.js의 순수한 소비자는 여전히 빌드 파일을 언제나처럼 사용할 수 있습니다. 이 사용 사례에는 변경 사항이 없습니다.
2. Browserify를 사용하는 Three.js의 소비자는 Three.js를 프로젝트의 종속성으로 선언할 수 있으며 require 특정 종속성만 선언할 수 있습니다. 적절한 종속성 관리의 이점은 잘 문서화되어 있습니다.
3. 구성 요소 간의 종속성이 명시적으로 문서화되어 있으므로 이제 Three.js에 기여하는 것이 더 간단해야 합니다.

조사를 좀 해보니...

어제 저는 Three.js 소스 코드를 CommonJS require() 문을 사용하여 파일 간의 종속성을 선언하도록 변환 하는 (다소 어리석은) 스크립트 를 함께 해킹했습니다. 무슨 일이 일어나는지 보기 위해... 이것은:

1. (WebGLRenderer에서) 다음과 같은 다소 우스꽝스러운 require 문을 갖게 됩니다.

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(및 기타)를 여러 모듈(atm 파일 길이가 6000줄 이상)로 분할하는 등 몇 가지 주요 리팩토링이 필요합니다.

1. GLSL 청크에 대한 솔루션을 찾아야 합니다. Atm 해당 파일 은 컴파일 시간에 THREE.ShaderChunk 로 컴파일된 다음 런타임에 THREE.ShaderLib 로 컴파일됩니다( THREE.ShaderChunk 의 배열을 결합). 동일한 작업을 수행하는 브라우저화 변환이 필요하다고 가정합니다.

React.js는 commoner 를 사용하여 파일 경로로 참조할 필요 없이 모듈을 조회합니다. 어쩌면 우리는 동일한 작업을 수행하고 require GLSL 파일을 JS 구문으로 변환할 수 있는 사용자 정의 규칙을 정의할 수도 있습니다.

@rasteiner https://github.com/stackgl/glslify 에 대해 알게 되어 매우 기쁠 수 있습니다. 이는 성장하는 http://stack.gl 제품군에서 비롯됩니다.

나는 지난 몇 달 동안 모듈과 "unixy" 접근 방식에 대한 상당한 경험이 있었고 지금은 너무 늦었다고 생각하고 모듈화 또는 npm 모듈을 위해 threejs를 리팩토링하는 것은 비현실적인 목표가 될 것입니다.

다음은 모듈성/재사용성 문제를 해결하기 위해 현재 하고 있는 일입니다.

• NPM에 Blur/fxaa/etc용으로 재사용 가능한 셰이더를 추가하고 있습니다. 이것 좀 봐:
  https://www.npmjs.org/package/three-shader-fxaa (엔진에 구애받지 않는 glsl-fxaa 사용)
• OrbitController 및 EffectComposer와 같은 재사용 가능한 구성 요소도 필요에 따라 게시됩니다. 예:
  https://www.npmjs.org/package/three-orbit-controls
• "three"에 의존하는 대신 이 모듈은 THREE를 취하는 함수를 내보내고 유틸리티 클래스를 반환합니다. 이런 식으로 전역 threejs 또는 commonjs와 함께 사용할 수 있습니다.
• 버전 관리는 고통스럽습니다. 내 주요 버전을 threejs 릴리스 번호에 맞추려고 합니다. threejs의 모든 새 버전은 많은 주요 변경 사항을 도입하므로 신중하게 처리해야 합니다.
• 수학을 다루는 모듈은 배열에서 작동하고 모듈식 gl-vec3, gl-mat4 등을 사용해야 합니다. 이런 식으로 그들은 threejs 외부에서 일반적이고 유용합니다. 그러면 threejs 사용자는 배열에 대한 래핑/언래핑을 처리하기만 하면 됩니다. verlet-system, simple-path 등을 참조하십시오.
• 진정한 모듈식 또는 작은 webGL 기능이 필요한 경우 앞으로 stackgl/glslify를 사용하고 있습니다. GL 상태를 재설정하는 한 ThreeJS 내에서도 작동할 수 있습니다. 예: https://www.npmjs.org/package/gl-sprite-text

내 새 프로젝트는 시작하고 실행하기 위해 npm에서 "3"을 사용하는 경향이 있습니다. ThreeJS가 릴리스 번호와 일치하는 버전 태그를 사용하여 공식적으로 npm에 빌드를 게시하면 정말 멋질 것입니다.

추신: 재사용 가능/모듈식 셰이더를 워크플로에 가져오는 데 관심이 있는 사용자에게:
https://gist.github.com/mattdesl/b04c90306ee0d2a412ab

내 iPhone에서 보낸

2014년 11월 20일 오전 7시 42분에 aaron [email protected]에서 다음과 같이 썼습니다.

@rasteiner https://github.com/stackgl/glslify 에 대해 알게 되어 매우 기쁠 수 있습니다. 이는 성장하는 http://stack.gl 제품군에서 비롯됩니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.

Browserify와 함께 Three.js를 사용 하는 방법을 찾고 있는 다른 사람들에게 도움이 되고 이 스레드를 우연히 발견한 경우, 제가 직접 설정한 방법은 browserify-shim 을 사용하는 것입니다.

_"당신은 때때로 a) 전역 변수를 전역으로 노출"_에 대한 README 섹션에 따라 Three.js에 대한 별도의 스크립트 태그를 포함하고 전역 THREE 변수를 노출하도록 구성했습니다.

그리고 나서 제가 스스로 해결해야 했던 부분은 ColladaLoader, OrbitControls 등과 같은 추가 기능을 포함하는 방법이었습니다. 저는 다음과 같이 했습니다.

package.json에서:

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

Browserify-shim-config.js:

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

그런 다음 내 자신의 스크립트인 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는 바이트에서도 수정할 때 전체 스크립트를 다시 작성해야 합니다. 한 번 browserify를 사용하여 THREE.js가 필요한 프로젝트를 패킹한 다음 경계를 구축하는 데 2초 이상이 걸리고 변경할 때마다 livereload를 차단합니다. 너무 답답합니다.

livereload 로 개발하는 동안 일반적으로

watchify는 나를 위해 작동하지 않습니다. 파일을 변경하고 저장할 때 watchify 및 beefy의 livereload는 이전/캐시된 버전을 제공합니다. 왜 이런 일이 발생하는지 모르겠습니다. 고맙게도 browserify는 이미 꽤 잘 작동합니다.

@ChiChou --noparse=three 로 브라우저화합니다. 이것은 내 컴퓨터에서 browserify 번들 단계를 1000ms에서 500ms로 낮추는데, 이는 즉각적인 피드백 느낌을 주기에 충분합니다.

@rasteiner three.js 상호 의존성에 대한 비공식 연구에 다시 한 번 감사드립니다. 그 방대한 deps 목록은 보기 흉한 코드이지만 실제로 그 추함은 있는 그대로 존재하며 보이지 않습니다. Browserify의 강점은 더러운 세탁물을 환기시키고 덜 엉킨 시스템을 추구해야 한다는 것입니다.

Three.js에는 객체를 가져와서 유형을 인식하고 해당 유형에 따라 다른 작업을 수행하는 곳이 많이 있습니다. 대부분의 경우 해당 유형 종속 코드는 유형 자체로 이동할 수 있으며 작업 중인 모든 가능한 유형을 이해할 필요가 없습니다.

다음은 WebGLRenderer 의 요약된 예입니다.

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

더 많은 형식이어야합니다

texture.processTexImage( _gl, mipmaps, otherData )

유형이 스스로를 처리하는 방법을 결정하게 하십시오. 이것은 또한 라이브러리 소비자가 우리가 생각하지 못한 새로운 텍스처 유형을 사용할 수 있도록 합니다. 이 구조는 상호 의존성을 줄여야 합니다.

브라우저화 아키텍처로 이동하는 것이 확실히 갈 길이라고 생각합니다. UMD 빌드를 사용하면 THREE.js를 더 쉽게 사용할 수 있습니다. 또한 WebGLRenderer를 여러 파일로 분할할 수 있습니다. 지금은 다소 단일하고 무섭게 보이기 때문입니다.

현재 여기로 옮기는 작업을 하고 있는 지점을 시작했습니다: https://github.com/coballast/three.js/tree/browserify-build-system

어떻게 생각하는지 알려주세요.

다음은 @coballast 의 변경 사항 입니다.

browserifyify.js 파일로 자동화된 변환 접근 방식을 취하고 있는 것 같습니다. 이것이 올바른 방법이라고 생각합니다.

우리 모두가 아직 많이 논의하지 않은 한 가지는 이 크고 끊임없이 변화하는 라이브러리를 브라우저화로 전환하는 최선의 방법입니다. 변경한 다음 PR을 열 수 있지만 즉시 구식이 됩니다. 이것이 자동화된 접근 방식의 매력입니다.

우리가 할 수 있다면:

• three.js src 변환 스크립트 제공(예: browserifyify.js )
• 변환 프로세스의 작동 방식을 설명하는 문서 제공
• 새 빌드 시스템의 작동 방식을 설명하는 문서 제공
• 변환 후 테스트 실행
• 병합 충돌을 일으킬 수 있는 기존 파일의 변경 사항을 포함하지 마십시오.

...그렇다면 우리는 이것을 가까운 미래에도 여전히 작동할 푸시 버튼 변환으로 바꿀 수 있습니다. 그 단순함은 이데올로기적 논쟁이 승리할 때 달성할 수 있는 그러한 대규모 프로젝트로의 근본적인 아키텍처 전환에 대한 이 꿈꾸는 개념을 가능하게 합니다.

@coballast 를 위해 src/Three.js가 동일하게 작동한다면 변경 사항을 제거하겠습니다.

참고: 되돌릴 뿐만 아니라 새 분기 또는 강제 푸시를 통해 분기 기록에서 해당 변경 사항을 제거하십시오.

@coballast 변환 유틸리티가 three.js 의 포크가 아니라 three.js 개발 디렉토리를 가리키는 외부 유틸리티이고 소스를 변환하는 것이 더 합리적인지 궁금합니다 three.js 파일을 만들고 빌드 스크립트를 추가하고 테스트를 실행합니다.

@kumavis src 디렉토리를 그대로 두는 데 동의합니다. 나는 유틸리티가 commonjs 코드로 중복 디렉토리를 작성하도록 해야 한다고 생각합니다. 그리고 거기에서 browserify 빌드를 테스트하고 실행하여 주요 작업을 시도하기 전에 모든 예제가 제대로 작동하는지 확인할 수 있습니다.

또한 여기에는 전체 코드베이스에서 일관된 스타일을 자동으로 확인하고 적용하는 정적 분석 항목을 작성할 수 있는 흥미로운 기회가 있습니다.

@coballast는 훌륭하게 들립니다.
자동화된 코드 재작성을 위한 풍부한 도구가 있습니다(예: escodegen ) . 의견 등을 유지하고 있는지 확인해야 합니다.
threejs-conversion-utility 리포지토리를 시작하시겠습니까?

@coballast 는 이 유틸리티에 대한 예리한 초점을 유지하는 것이 중요하다고 말했습니다.

@kumavis 완료한

@kumavis @mrdoob 여기 논의 중 일부는 npm을 통해 설치한 다음 browserify로 컴파일할 수 있는 여러 개별 모듈로 THREE를 분할하는 아이디어에 관한 것 같습니다. 나는 그 생각에 완전히 반대하지는 않지만, 그것은 별개의 문제가 되어야 한다고 생각합니다. 이 시점에서 내가 옹호하는 유일한 것은 THREE의 코드베이스를 내부적으로 관리하기 위해 browserify를 사용하는 것입니다. 이전하고 사용자에게 항상 하던 방식으로 작동하도록 한 다음 타당한 항목을 평가하십시오.

그 유틸리티의 출력이 무엇인지 궁금합니다 ^^

@coballast 링크 저장소는 이 시점에서 비어 있더라도 추적할 수 있습니다. 우리는 거기에서 구축할 수 있습니다.

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

코드가 엉망입니다. 곧 정리될 것입니다.

여기 우리가 간다! :로켓:

이제 browserify src를 생성하고 문제 없이 빌드할 상태의 유틸리티가 있습니다. 이 작업을 직접 수행하는 방법에 대한 지침으로 리포지토리를 업데이트하겠습니다. 이 시점에서 예제는 작동하지 않습니다. 이를 해결하기 위해 해결해야 할 몇 가지 문제가 있습니다. 누군가 소매를 걷어붙이고 돕고 싶다면 저장소에 추가하겠습니다.

@coballast 네, 문제를 TODO로 제출해 주세요. 저나 다른 사람들이 최대한 참여할 것입니다.

심각한 문제가 발생했습니다. #6241 참조

다음은 이것이 작동하기 위해 발생해야 하는 일에 대한 분석입니다. https://github.com/coballast/threejs-browserify-conversion-utility/issues/9#issuecomment -83147463

Browserify는 디자인으로 인해 최소한 전송이 중복됩니다. 이것은 사용 비용이 부풀려지고(데이터 계획이 있습니까?) 느립니다.

이에 대한 간단한 해결책은 하나가 아닌 두 개의 클라이언트 파일을 수반하는 라이브러리 코드에서 문서를 분리하는 것입니다. 이것은 클라이언트 측 js의 일반적인 관행입니다.

처음에 browserify에 결함이 있고 자체적으로 수정해야 하는 경우 threejs와 같은 것은 고사하고 개선해야 하는 이유를 거의 알 수 없습니다.

@spaesani 어쨌든 threejs에 대한 데이터를 다운로드해야 하기 때문입니다. threejs를 더 작은 모듈로 나누고 자동화된 빌드 시스템이 단일 앱에 필요한 것을 선택하도록 하면 실제로 대부분의 threejs 앱은 더 가벼워질 것입니다.

어떤 이유로 "라이브러리 코드에서 문서"를 분리하려는 경우에도 여전히 이 작업을 수행하고 지금처럼 미리 빌드된 버전을 사용할 수 있습니다. --standalone 및 --exclude 플래그를 사용하여

Browserify는 브라우저에서 검증된 모듈 정의 API(CommonJS)를 사용하는 방법일 뿐입니다. threejs 플러그인 개발을 크게 단순화하고 코드 명확성 및 생산성을 향상시켜 더 많은 사람들이 코드를 본질적으로 유지하면서 버전 관리 시스템을 통해 무결성을 유지하는 더 큰 생태계(npm)에 통합할 수 있습니다. stackgl family), 사람들이 원하지 않는 경우 CommonJS로 강제하지도 않습니다.

물론 단점이 있지만 언급한 단점은 아닙니다.

three.js 및 three.min.js는 프록시, 일반 모바일 솔루션 또는 캐싱 브라우저에 의해 전송(데이터)을 절약하기 위해 캐시될 수 있습니다.
문서 특정 코드로 threejs 코드를 선택하고 집계하는 순간 캐싱은 실현 가능하지 않습니다.
Browserify가 허용하는 경우