это довольно узел, чтобы распутать
http://jsbin.com/medezu/2/edit?html , js, вывод

@coballast , можете ли вы опубликовать код, который вы использовали для создания зависимости json?

Просто используйте предварительно скомпилированный файл three.min.js напрямую. Нет необходимости разбивать Three.js на отдельные файлы в Browserfy, вы просто усложняете себе жизнь без реальной пользы.

Я говорю по своему опыту, мы используем модуль npm для three.js, и он отлично работает. Мы просто упаковываем его в один файл и оборачиваем в модуль в стиле CommonJS. Этот подход будет работать для браузера, и многие люди уже делают это, как я понимаю.

Для этого варианта использования распутывать этот узел не требуется.

@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 имеют двусторонние связи со своим базовым классом.

Немного сложно увидеть, но Geometry s, похоже, имеют хорошие односторонние зависимости от базового класса.

С Light и Camera ситуация аналогична — это хорошо по отношению к их базовому классу, но зависимость Object3D _от них_ кажется ненужной.


Curve s Path s Line s кажется хорошим, но 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 @gero3 Думаю, мы сможем сделать это вообще без изменения API. Я поковыряюсь и посмотрю, что к чему.

что касается математики, я думаю, вы могли бы просто собрать все «блокноты» в одном месте. но я уверен, что не будет ни одного пригодного для использования графа 3js, в котором не было бы и Vector3, и Matrix4.

Если есть решение, которое не меняет производительность или API математической библиотеки, я только за.

@coballast не может удалить циклическую зависимость без изменения API, потому что оба предоставляют методы, использующие другой тип. Vector3 Matrix4

Что касается совместимости браузера, наше единственное требование — переместить создание экземпляров рабочих переменных вне времени определения класса (заставить их создавать экземпляры при первом запуске). Сделайте это ленивым , как это . Это не повлияет на API или производительность.

Я думаю, что такие изменения в порядке вещей.

@kumavis Ах! да. Хорошо, теперь я понимаю. Это достаточно легко.

Я полностью поддерживаю разделение THREE на более мелкие модули с требуемой структурой по следующим причинам:

1. ТРИ очень большие. Если бы пользователь мог требовать только то, что ему нужно, это могло бы сократить размеры сборки клиента. Например , react-bootstrap позволяет вам делать такие вещи, как var Alert = require('react-bootstrap/lib/Alert'); , которые не объединяют каждый модуль начальной загрузки.
2. Есть некоторые «плагины», такие как OrbitControls.js , которые изменяют сам глобальный объект THREE, помещая себя в THREE.OrbitControls . Это анти-шаблон в современных фреймворках javascript, потому что он требует присутствия THREE в глобальном пространстве имен в процессе сборки, а не для файлов, которые в нем нуждаются. THREE также делает это внутри, всегда модифицируя пространство имен THREE, что не идеально для включения определенных модулей THREE.

поставив себя на THREE.OrbitControls

но каждый фрагмент кода в 3js делает это?

@DelvarWorld написал:

Я полностью поддерживаю разделение THREE на более мелкие модули с требуемой структурой по следующим причинам:

Раньше я думал, что это хорошая идея, чтобы разбить его, но сейчас в ThreeJS есть простота. Он более удобен для новичков в 3D в том виде, в каком он есть сейчас, и это было приоритетом для команды разработчиков. Вы можете использовать ThreeJS, не нуждаясь в модульной системе (которых много, и не все они полностью совместимы).

Как и @makc , я также озадачен предложением @DelvarWorld не помещать вещи в пространство имен THREE.

Где / как они будут вместо этого?

Мне кажется хорошим шаблоном создать только один глобальный объект, ТРИ, в котором находятся все его части (и, возможно, некоторые расширения/плагины).

Я согласен с @DelvarWorld в том, что метод размещения на глобальном уровне вреден для здоровья кодовой базы - это своего рода тонкий аргумент, потому что размещение его на глобальном уровне само по себе не является проблемой, это скрытый граф зависимостей и другие приемы, возникающие из-за доступности файла global.

Но этот аргумент в основном ограничивается внутренней разработкой и структурой кода. Что касается доставки библиотеки в виде пакета статического кода, то размещение всех классов в глобальном THREE имеет для меня смысл.

Встречный аргумент заключается в том, что при десериализации json-сцены THREE.js записи могут просто перечислять свой класс в виде строки, которую можно извлечь из глобального, например: THREE[ obj.type ] . Это работает с классами, которых нет в стандартной библиотеке three.js, если вы определяете их в THREE перед десериализацией. Не уверен, как лучше заменить это поведение без глобального THREE .

Это работает с классами, которых нет в стандартной библиотеке three.js, если вы определяете их в THREE перед десериализацией. Не уверен, как лучше всего заменить это поведение без глобального THREE.

Вы можете сделать этот шаблон (или какой-то его вариант), если все является модулем:

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

В ES6 есть много изменений, касающихся модулей. В этот момент я бы пересмотрел модульность ThreeJS.

Встроенная версия three (файл javascript, который люди могут загрузить вручную) по-прежнему будет иметь все в пространстве имен three. вы можете сделать это с файлом точки входа для сборки:

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

и т. д., которые по-прежнему будут полезны новичкам и с которыми будет легко начать работу.

Для тех, кто использует три из npm и requirejs/browserify/webpack в современной сборке javascript, мы могли бы сделать что-то вроде

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

и т. д., что может сократить некоторые из трех размеров, встроенных в пакет размера клиента. Я могу ошибаться, потому что не знаю, сколько из трех является «ядром». Однако сейчас это невозможно, потому что в файле three не используются операторы require.

в любом случае современный шаблон требует модулей, и вместо того, чтобы весь ваш код модифицировал другую библиотеку (модифицируя глобальную ТРИ, плохо), ваш код является независимым и модульным и указывает, что ему требуется, с операторами require , например, исходный код React .

Я не думаю, что моя попытка привести полный аргумент в пользу использования синтаксиса require/module будет полезной, поскольку в Интернете есть много хороших ресурсов по этому поводу. Но плохо побуждать других изменять пространство имен THREE для добавления плагинов, таких как OrbitControls.

Просто имейте в виду, @DelvarWorld , что ES6 официально вводит модули в JavaScript с очень специфическим и отличным синтаксисом:

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

@bhouston о да, полностью, я не согласен с требованием импорта (импорт, вероятно, лучший выбор), просто поддерживаю шаблон модуля в целом.

@bhouston @DelvarWorld @kumavis Один из моих долгосрочных проектов — написать автоматический конвертер es5 -> es6, который может вмещать и преобразовывать модули commonjs/amd в es6, и, надеюсь, идентифицировать и переписать большое количество javascript с использованием конструкций es6, таких как классы/генераторы. и так далее. Можно использовать преобразование браузера, такое как es6ify, пока браузеры догоняют стандарт, чтобы подготовить код для использования. Переход THREE к браузеру только на внутреннем уровне — хороший первый шаг для подготовки его к вводу в такой инструмент.

Это не то, что я (видимо, очень плохо) пытался сделать. Я хочу удалить как можно больше этих циклических зависимостей, независимо от каких-либо проблем с модульностью, потому что я считаю, что это сделает THREE более стабильным, гибким и, вероятно, устранит множество ошибок в качестве приятного побочного эффекта.

@coballast https://github.com/mrdoob/three.js/pull/6252 был объединен, что должно сократить количество циклических отложений. Думаете, вы можете сгенерировать новый граф отложений? Может быть, сделать это утилитой в репозитории инструмента преобразования

следующее: создание временных переменных в Vector3 Matrix4 , определяемых лениво при первом использовании, а не во время определения

кто-нибудь хочет стать волонтером? должно быть быстро

График обновлен. http://jsbin.com/medezu/3/

Вот скриншот:

Я рад сообщить, что огромное количество циклов Object3Ds было устранено. Хорошая работа @kumavis!

вау, это та же кодовая база? сумасшедший

Будет работать над тем, чтобы сделать генерацию графов частью утилиты.

При рассмотрении только графа Shape и Geometry кажутся возможными деревьями классов, которые можно разгадать.

@coballast думаешь, ты справишься с этим?

создание временных переменных в Vector3 Matrix4, определяемых лениво при первом использовании, а не во время определения

это будет PR против вышестоящего dev , а не автоматическое изменение

Также я думаю, что мы можем понизить название проблемы с "Серьезные проблемы с циклическими зависимостями" на "циклические зависимости" - ситуация намного улучшилась!

@kumavis Конечно. Будет работать над этим, когда время позволит.

Вот текущее состояние очистки взаимозависимостей, как я его вижу:
(стрелки показывают соединения, которые при необходимости следует удалить )

• [х] Материалы
• [x] Геометрии
• [x] Object3D
• [х] Математика
• [х] Формы
  
  
  
  • [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 , в более общие утилиты. Но это не большая победа. Собираюсь отметить его как завершенный.

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. Интересно, сильно ли упростит код создание ленивого объекта vertices на BufferGeometry , который просматривает значения по мере их запроса. Не уверен насчет производительности.

В качестве альтернативы мы могли бы использовать Geometry.computeBoundingBox :
Geometry
BufferGeometry

Box3 является проблемным местом при запуске сборки browserify. См. примечания в coballast/threejs-browserify-conversion-utility#21.

@kumavis Не могли бы вы изложить рекомендуемое вами решение для работы с Box3/Geometry/BufferGeometry? Если быстро, то могу реализовать.

Я не могу смотреть на это прямо сейчас, но я бы начал с моего предложения выше использовать geo.computeBoundingBox как реализовано на Geometry и BufferGeometry вместо if/else здесь . Вместо этого box3.setFromObj должен вызвать geometry.computeBoundingBox , а затем установить параметры на основе созданного box3.

Это должно удалить конец Box3 -> BufferGeometry и Box3 -> Geometry круглых отпечатков. Дайте мне знать, если я что-то упустил.

Хм, может быть, получившийся код немного запутан, что на самом деле здесь имеет смысл? Box3.setFromObject не должно существовать, но это не вариант. Geo's должен уметь производить box3, у меня с этим проблем нет. Да, я думаю, что Box3.setFromObject должны запросить у геолокации ограничивающую рамку/экстенты, но, возможно, им следует попросить Object3D / Mesh ограничительную рамку/экстенты.

извините немного сумбурно. Дай мне знать, что ты думаешь.

Возможно релевантно: #6546

Без чего-то подобного невозможно анализировать эти динамические зависимости от скриптов загрузчика.

Судя по моим тестам, циклические зависимости не являются проблемой для commonJSification. С ними нужно правильно обращаться, и, как уже говорилось ранее в этой ветке, они делают граф зависимостей довольно беспорядочным, но они не мешают THREE.js работать в обычных средах JS (конечно, при преобразовании).

Я только что опубликовал полную версию commonjs на npm как three.cjs , используя три транспилятора commonjs.

Примечание: чтобы это сработало, мне пришлось вручную выбирать #6546 на мастере. Хотя динамические зависимости хорошо работают в node.js, они не могут работать в Browserify (или любом другом инструменте cjs для браузера), поскольку им необходимо выполнять статический анализ зависимостей.

Просмотрите доказательство: http://requirebin.com/?gist=b7fe528d8059a7403960

@kamicane FYI - вот где ТРИ были добавлены в качестве аргумента анонимной функции к 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 зависит только от Matrix4 из-за multiplyMatrices и getInverse , подробнее см. (https://github.com/mrdoob/three.js/ blob/dev/src/math/Vector3.js#L315)

@roomle-build Да, чувак, только потому, что он явно ссылается на конструктор 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 зависит от 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 (чтобы сохранить поверхность API Matrix4 такой же).

Я только что бегло просмотрел (не смотрел на случай 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 );

Когда все вместе объединяется, rollup творит чудеса и создает наиболее эффективный пакет.

Это то, что делают многие популярные библиотеки. На самом деле 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 не «подготовлен» для такого использования. В настоящее время все методы математического модуля прикреплены «как бы статически». Это также не позволяет агрегации обнаружить то, что действительно необходимо...

@roomle-build хм, так вы говорите, что свертывание может понять, действительно ли коду в той же области не нужна вся область, хорошо.

Вы говорите о переходе к функциональному подходу (функции принимают объекты), а не к объектно-ориентированному подходу (объект имеет функции-члены). Это реальная вещь, но, учитывая, что Three.JS полностью объектно-ориентирован, предложение такого типа изменений является довольно большой, и он сломал бы весь существующий код.

Я не уверен, что аргументы в пользу этого изменения настолько значительны на данный момент, чтобы оправдать отказ от обратной совместимости.

@makc не совсем. Это будет один большой модуль с множеством маленьких «вспомогательных» функций. Это также поможет при встряхивании деревьев и т. д. Математический модуль может выглядеть так:

Если это то, что предлагается, это должно быть описано правильно. Это изменение Three.JS от объектно-ориентированного стиля дизайна к функциональному дизайну.

@roomle-build хм, так вы говорите, что свертывание может понять, действительно ли коду в той же области не нужна вся область, хорошо.

yes rollup понимает, как все импорты соотносятся друг с другом, и выполняет встряхивание деревьев, устранение неработающего кода и т. д. Новые версии rollup также могут выполнять «фрагментацию» и много других приятных вещей. Но текущая структура проекта не использует все преимущества этих функций.

Вы говорите о переходе к функциональному подходу (функции принимают объекты), а не к объектно-ориентированному подходу (объект имеет функции-члены). Это реальная вещь, но, учитывая, что Three.JS полностью объектно-ориентирован, предложение такого типа изменений является довольно большой, и он сломал бы весь существующий код.

Я не думаю, что эти две парадигмы исключают друг друга. Я думаю, вы можете смешивать и сочетать эти две парадигмы. Я также не предлагаю перейти на функциональное программирование. Я просто хотел описать способ избавления от циклической зависимости. Вы также можете присоединить метод multiplyMatrices к объекту Math . Но если кто-то переписывает подобные вещи, имеет смысл подумать об использовании возможностей модулей ES6. Но, как я уже сказал, я не эксперт по кодовой базе Three.js, и это была просто мысль, как устранить циклическую зависимость. Я думаю, что Three.js — отличный проект с отличной кодовой базой, и я не хочу ворчать. Так что надеюсь, никто не обидится на мои комментарии 😉

Я не уверен, что мы должны обсуждать дизайнерские решения в выпуске. У вас есть место, где такие вещи подходят лучше?

Кстати, gl-matrix — это функциональная математическая библиотека: https://github.com/toji/gl-matrix/tree/master/src/gl-matrix .

@roomle-сборка

В настоящее время все методы математического модуля прикреплены «как бы статически».

Как же так?

@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 . Но, как я уже говорил, я не уверен, что нам нужно удалять циклические зависимости. Если будет принято решение не удалять их, я думаю, этот вопрос может быть закрыт 😃

После разрешения #19137 это можно закрыть 🎉.

@ Mugen87 вау, 5 лет! поздравляю с тем, что наконец попал в цель :fire: :clap:
Мне тогда было очень весело делать эти графики :smile_cat: