Three.js: Примеры файлов, которые еще нужно преобразовать в модули

Поскольку файлы материалов узла уже являются модулями, их, вероятно, следует переместить из папки js / в папку jsm / . Затем нам просто нужно создать для них файлы машинописного текста.

файлы в папке lib /

Я ищу способ предоставить inflate в качестве модуля. Боюсь, что такие проблемы, как # 16602, будут часто появляться с некоторыми загрузчиками, такими как FBXLoader . К сожалению, похоже, что у zlib.js нет модульной версии. Можем ли мы использовать другую библиотеку?

Да, к сожалению, я думал, что нам придется это сделать. Я думаю, это просто стандартная функция надувания молнии, так что это не должно быть слишком сложно.

РЕДАКТИРОВАТЬ: Возможно, этот? https://github.com/zprodev/zlib.es

Кто-то упомянул, что они заставили его работать с FBXLoader . Однако это означает, что js FBXLoader и jsm FBXLoader будут иметь разные зависимости. Как мы можем с этим справиться?

Мы можем определить inflate как внешнюю зависимость FBXLoader в modularize.js . Таким образом, сценарий автоматически создает оператор импорта для соответствующего модуля в jsm/libs/ .

Изменить: Конечно, это работает так просто, если интерфейс модульной версии библиотеки похож на обычную версию ^^.

Попробую приступить к конвертации js файлов. Те, которые я написал, будут для меня проще ( ConvexObjectBreaker , GPUComputationRenderer , LightningStrike , LightningStorm , LDrawLoader ) Я могу сделать больше позже .

Итак, я начну с перемещения ConvexObjectBreaker и GPUComputationRenderer в js/misc (как указано в другом комментарии) и их преобразования, если вы согласны.

https://github.com/mrdoob/three.js/pull/16054 выполняется для nodes/ , добавлено примечание к OP.

@yomboprime Замечательно ! ^^

Я работаю над Cloth.js и это огромное количество глобальных переменных. Я могу преобразовать его в расширение Mesh и поместить в каталог objects / . Но прежде чем я это сделаю - действительно ли нам нужны два образца ткани?

https://threejs.org/examples/webgl_animation_cloth.html
https://threejs.org/examples/webgl_physics_cloth.html

Стоит ли конвертировать устаревшие файлы или нет?

- загрузчики / устарело /

• LegacyGLTFLoader.js
• LegacyJSONLoader.js

- vr / не рекомендуется /

• DaydreamController.js
• GearVRController.js

Стоит ли конвертировать устаревшие файлы или нет?

Я бы преобразовал их в конце, когда все остальное будет сделано.

Но прежде чем я это сделаю - действительно ли нам нужны два образца ткани?

Сохраним пример, поскольку он демонстрирует анимацию ткани без физического движка.

ConvexObjectBreaker и GPUComputationRenderer уже выполнены, я их пометил.

Я присваиваю себе geometries/LightningStrike.js и objects/LightningStorm.js

Изменить: я сделал эти два и отметил их в списке. Далее идет LDrawLoader.

/ ping @sunag сможете ли вы преобразовать загрузчик SEA3D и связанные файлы?

@looeee конечно. Я сделаю это и с NodeMaterialLoader.

Кстати: мы можем удалить EquirectangularToCubeGenerator из списка, поскольку @WestLangley недавно представил WebGLRenderTargetCube.fromEquirectangularTexture() (см. # 16671). Это означает, что EquirectangularToCubeGenerator устареет после того, как в примере кода будет использоваться новый интерфейс.

Мы можем удалить EquirectangularToCubeGenerator

Еще нет, пожалуйста. Существует множество возможностей кодирования и декодирования, а также множество поддерживаемых рабочих процессов. Это нетривиально. Новый метод еще не задокументирован.

Я просто хотел удалить его из списка дел, а не файл ^^

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

@looeee Я добавил вас в файлы CTMLoader, поскольку кажется, что вы уже работаете над этим.

Я добавил вас в файлы CTMLoader, так как кажется, что вы уже работаете над этим

На самом деле у меня не будет времени в ближайшие пару дней, так что ничего страшного, если это сделает кто-то другой. Я пока уберу свое имя.

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

Удаление библиотек Draco и Basis из списка на данный момент см. Https://github.com/mrdoob/three.js/pull/16754#issuecomment -500494943

За последние дни я преобразовал большинство примеров HTML. В следующем списке показаны открытые задачи:

• [x] webgl_materials_compile ( NodeMaterial )
• [x] webgl_materials_nodes ( NodeMaterial )
• [x] webgl_mirror_nodes ( NodeMaterial )
• [x] webgl_performance_nodes ( NodeMaterial )
• [x] webgl_postprocessing_nodes_pass ( NodeMaterial )
• [x] webgl_postprocessing_nodes ( NodeMaterial )
• [x] webgl_sprites_nodes ( NodeMaterial )

Примеры нодового материала можно решить, как только # 16054 будет готов.

https://github.com/mrdoob/three.js/pull/16834

@ Mugen87 Я открою PR до воскресенья, который вернет OBJLoader2 + Worker (поддерживаются jsm и стандартные рабочие). Пример MeshSpray и Parallels тогда не будет готов, так как требуемый код не был перенесен / переписан. Можно ли оставить эти два примера на старом коде до выпуска R107 или вы хотите удалить и повторно ввести эти два примера?

ТБХ, я думаю, что двух примеров для OBJLoader2 вполне достаточно. Один демонстрирует базовое использование, а другой - в контексте рабочего сценария. После миграции немодульная версия OBJ2Loader в каталоге js может быть удалена.

Хорошо, немодульные OBJLoader2 и LoaderSupport могут исчезнуть. После того, как новый код будет готов, можно предложить новый пример загрузки нескольких активов.

Вот несколько оставшихся файлов, которые нужно добавить в список. Некоторые из них могут не иметь смысла как модули es6 сами по себе, но как только мы перейдем к преобразованию всех файлов / jsm в / js, я думаю, будет иметь смысл хранить все поддерживаемые редактируемые версии примеров в одном каталоге ( /jsm ):

/ vr

• HelioWebXRPolyfill.js
• WebVR.js

/ за кадром

• jank.js
• offscreen.js
• scene.js

/ погрузчики

• ctm / CTMWorker.js

/ рендереры

• рендеринг / RayTracingWorking.js

см. https://github.com/mrdoob/three.js/issues/16688#issuecomment -501618684. Рабочие файлы можно просто переместить в каталог jsm .

Я бы пока не стал менять два других файла VR. Как следует из названия, HelioWebXRPolyfill - это просто полифил для WebXR API. WebVR.js похоже на WebGL.js не в пространстве имен THREE и я не уверен, что @mrdoob хочет это изменить.

WebVR.js, вероятно, даже не нужна немодульная версия. Будем работать над этим в этом цикле.

Мне очень хочется удалить загрузчик CTM. Кажется слишком сложным, чтобы иметь с ним дело, и я не уверен, что существует достаточно файлов, чтобы оно того стоило? Кроме того, в то время это был хороший вариант, но сейчас следует использовать GLTF.

@ Mugen87 Я согласен с тем, что многие файлы не нужно "модулировать", но, по крайней мере, все они должны быть перемещены (в конечном итоге) в одну и ту же папку хотя бы для единообразия. Я думаю, что будет немного запутать сочетание модулей, которые создаются и редактируются вручную в одних и тех же папках. Также можно загружать скрипт с помощью импорта, даже если он ничего не экспортирует, как в случае с полифилом:

import './examples/jsm/vr/HelioWebXRPolyfill.js';

Что касается пространства имен для таких файлов, как WebGL.js , с помощью Rollup можно было бы исключить этот файл (или набор файлов) из добавления в пространство имен THREE и вместо этого добавить что-то вроде window . Мои изменения в # 16920 могут быть легко изменены для поддержки этого.

Преобразование сейчас в основном сделано. Теперь мы можем переместить оставшиеся немодульные файлы (см. Https://github.com/mrdoob/three.js/issues/16688#issuecomment-506108218) в каталог JSM. Я бы также сделал это для остальных внешних библиотек (см. Https://github.com/mrdoob/three.js/issues/16688#issue-452345634).

Изменило мое решение. Я думаю, что лучше, чтобы в каталоге JSM были только модули. Остальные библиотеки и рабочие файлы могут оставаться в examples/js . Если мы в конечном итоге сгенерируем UMD через # 16920, в комментарии будет указано, что эти файлы созданы. Так будет легче увидеть, ведется ли файл вручную или нет.

Думаю, вопрос можно закрыть. Теперь нет необходимости конвертировать все библиотеки и рабочие скрипты в модули. Мы можем изменить это со временем, например, когда поставщик библиотеки предоставит версию ES6.

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