Выглядит очень хорошо!

Кстати, мы планируем в ближайшее время удалить THREE.GLTFLoader и переименовать GLTF2Loader → GLTFLoader *. Может быть хорошей идеей переименовать экспортера в GLTFExporter до того, как появится версия r87, чтобы избежать путаницы и чтобы не требовалось менять имя между выпусками. Ой, я пропустил то, что ты уже так назвал ... продолжай! 😆

* @mrdoob , какие-либо предпочтения относительно того, когда это должно произойти? ИМО, мы могли бы сделать это сейчас, если мы не хотим сохранить GLTFLoader в r87 только с предупреждением об устаревании и удалить его в r88?

Думаю, чем раньше, тем лучше. Пока новый GLTFLoader способен обнаруживать 1.0 и предупреждать пользователя, что мы поддерживаем только 2.0+.

IIRC мы можем обнаружить, увидев asset как я упоминал ранее.

IIRC мы можем обнаружить, увидев актив, как я упоминал ранее.

✅ Ага! https://github.com/mrdoob/three.js/pull/11864

Прохладный! Но я нашел небольшую ошибку. Сейчас занимаюсь пиаром. Давайте объединим, прежде чем переименовывать.

Можем ли мы указать в контрольном списке элементы, над которыми кто-то работает?

@takahirox конечно! люди могли просто писать здесь комментарии, а я мог бы обновить список и указать на PR, если что-то уже происходит

Следующее, над чем я буду работать, - это текстуры, чтобы преобразовать их в base64 вместо использования только URL-адреса.

Спасибо! Я хочу помочь сделать glTF экспортером. Я ищу, чем могу помочь в контрольном списке ...

Кстати, вы специально допустили две переменные WEBGL_CONSTANTS и THREE_TO_WEBGL global?

@takahirox круто!
Что касается двух переменных, я собираюсь обратиться к этому в следующем PR, чтобы сделать его частью WebGLUtils и просто импортировать. Не имеет смысла, что каждому, кому нужны эти константы, нужно каждый раз заново определять их.

@takahirox, кстати, не стесняйтесь, конечно, предлагать новинки в список! ;)

@fernandojsg Конечно! Что касается переменных, я хотел предложить переместить их куда-нибудь, если они намеренно объявлены глобальными, поэтому приятно знать, что вы это делаете.

Я хочу работать с общим буфером.

BufferViews: в настоящее время я создаю новый bufferView для каждого Accessor, это должно быть исправлено, чтобы использовать только один для этих атрибутов, которые имеют один и тот же componentType.

Причина, по которой один для атрибутов, которые имеют один и тот же componentType, а не один для всех атрибутов, предназначен для выравнивания данных, верно?

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#data -alignment

Круто, я только что добавил вас в список 👍 Да, в основном вы хотите использовать одно и то же представление буфера для компонента с тем же типом, например, если у вас есть позиция и нормальный, у вас будет два аксессуара VEC3, но они будут указывать в то же буферное представление. Это может быть отличной отправной точкой;)

Я имел в виду, что причина, по которой мы не разрешаем совместное использование представления буфера между разными типами компонентов (например, float и short), заключается в том, чтобы поддерживать хорошее выравнивание данных, правильно?

Я считаю, что вы можете хранить в одном буфере разные типы компонентов, если они имеют одинаковые target , например normal (Vec3) , position (Vec3) и uv (Vec2) может быть в том же представлении буфера, но indices нет. @donmccurdy не могли бы вы это подтвердить?

Ага, согласился. И как упоминается в этой спецификации glTF

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#data -alignment

Смещение средства доступа в bufferView (т. Е. Accessor.byteOffset) и смещение средства доступа в буфер (т. Е. Accessor.byteOffset + bufferView.byteOffset) должно быть кратным размеру типа компонента средства доступа.

Для простоты рекомендуется разделить представления буфера между разными componentType (= типами данных, такими как float и short, а не vec2 или vec3). Если мы разделим их между данными componentType разной длины, это будет более оптимизировано.

Кстати, есть ли какие-то особые причины, по которым текущий экспортер поддерживает только accessor.componentType float, uint и ushort? glTF 2.0 может обрабатывать char, uchar и short в дополнение к ним.

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#accessorcomponenttype -white_check_mark

@takahirox не совсем, я просто определил их сейчас, потому что они используются для типа атрибутов, которые мы поддерживаем прямо сейчас (позиции, нормали, цвета, uvs, индексы ...).
Следующим шагом, над которым я работаю, являются текстуры, поэтому нам понадобятся другие, например uchar

Хорошо, поэтому я сначала поработаю над accessor.componentType s, если вы еще не начали импл.

Почти готов, но мой пиар должен конфликтовать с # 11978.
Итак, я отправляю свой после объединения # 11978 и исправляю конфликт.

Вы бы добавили анимацию в список?

@takahirox конечно, было бы здорово добавить анимацию. Я просто не добавил его, потому что не был достаточно знаком с текущим состоянием функций анимации на three.js, но если вам захочется взять его на себя, это было бы здорово;)

Планируете ли вы поддерживать группы BufferGeometry?
Охватывают ли это спецификации GLTF, или это приведет к созданию новой сетки для каждой группы?
Об этом также необходимо позаботиться, поскольку материальным свойством Mesh является массив материалов.

@marcatec В спецификации glTF действительно есть различие между «сеткой» и «примитивом», что позволяет создавать группы BufferGeometry, каждая из которых может ссылаться на другой материал. В настоящее время THREE.GLTFLoader не оптимизирует загрузку примитивов - он создает отдельные сетки, но это можно реализовать.

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

Согласен, отличная работа!

Планируется ли добавить поддержку других материалов помимо StandardMaterial?

Спасибо!

@homerjam любые свойства материала, общие с MeshStandardMaterial, будут сохранены - так, например, MeshPhongMaterial с использованием map и normalMap будет экспортировать с этими текстурами нетронутыми, но когда вы импортируете его обратно в three.js, он будет MeshStandardMaterial. В настоящее время экспортер делает для этого простой переход на PBR.

Поддержка двустороннего обмена (экспорт Phong из GLTFExporter, загрузка Phong из GLTFLoader) потребует незавершенной работы над форматом glTF: https://github.com/KhronosGroup/glTF/pull/1150

baseColorTexture : Поддерживается (material.map), но для texCoord всегда установлено значение 0

@fernandojsg не могли бы вы пояснить, чего здесь не хватает? Поскольку .map всегда является первым набором UV в three.js, это звучит как правильный способ представить это в glTF?

Кроме того, я вычеркнул три пункта в списке. Рассуждения ниже:

• касательные
  
  
  
  • three.js вычисляет их только на GPU; добавление реализации только для экспортера звучит не идеально.
  
  
• редкие аксессуары
  
  
  
  • Я думаю, что это лучше всего оставить для постэкспортной оптимизации, как
  
  
• проверьте, соответствует ли материал glTF по умолчанию, и опустите его
  
  
  
  • кажется крайним случаем / беспорядком, не стесняйтесь реализовывать, если кто-то считает, что
  
  

Выполняя экспорт в GLB из редактора, я заметил, что alphaMap , roughnessMap и metalnessMap не экспортируются.

В # 13397 я сказал, что normalMap не экспортируется, но похоже, что я ошибался.

Экспортируя в GLB из редактора, я заметил, что alphaMap, RoughnessMap и metalnessMap не экспортируются.

Я поработаю над этим сегодня, если никто еще не начал.

@donmccurdy

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

Ощущение, как будто экспортер поддерживает редкие аксессоры для преобразования. Попробую позже.

@takahirox круто! вперед, продолжать!

Я не думаю, что alphaMap поддерживается в glTF 2.0.

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#material

Да, я этого боялся .... А как насчет metalnessMap и roughnessMap ?

Я сейчас над ними работаю!

13415

По поводу форматов изображений. glTF 2.0 поддерживает только файлы .png и .jpg в качестве внешних файлов изображений. Я рассматриваю, как обрабатывать файлы неподдерживаемого формата изображения (например, .bmp) в режиме, отличном от embedImages .

1. Конвертируйте в .png или .jpg и вставляйте
2. Плевать. Экспорт как исходных файлов изображений
3. Не экспортировать

Я предпочитаю 1. Есть мысли?

Вау, я действительно ценю ваши работы, ребята.

Надеюсь, что Multi-material meshes будет реализовано как можно скорее, потому что в большинстве 3D-моделей используются мультиматериалы.

1. Конвертируйте в .png или .jpg и вставляйте
2. Плевать. Экспорт как исходных файлов изображений
3. Не экспортировать

Я голосую за 3 и регистрирую предупреждение в консоли.

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

Согласен, для меня это проблема номер один, препятствующая использованию экспортера.

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

Как я уже говорил в другой ветке, я над этим работаю.

1. Конвертируйте в .png или .jpg и вставляйте
2. Плевать. Экспорт как исходных файлов изображений
3. Не экспортировать

Я голосую за 3 и регистрирую предупреждение в консоли

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

Причина, по которой я предпочитаю 1., заключалась в конвертации из других форматов в glTF. Некоторые (или многие) другие форматы не имеют ограничений формата изображения.

Экспортер переходит в режим embedImages . Я думаю, что добавление «используйте параметр embedImages, если вы хотите преобразовать» в предупреждение консоли, было бы неплохо.

Я бы тоже пошел на 3. Поскольку преобразование из других форматов может быть утомительным, вам в любом случае нужно будет отдавать предпочтение одним форматам по сравнению с другими. Вероятно, стоит сделать 3 прямо сейчас и подождать, чтобы увидеть, добавит ли gltf поддержку новых форматов текстур, таких как ktx или около того, и мы могли бы пересмотреть реализацию.

Как обсуждалось в https://github.com/mrdoob/three.js/pull/13415#issuecomment -369022383, было бы неплохо, если бы экспортер смог составить текстуру ambientRoughnessMetalness для пользователя. Возможно, лучше поместить этот код в ImageUtils .

Я обновил контрольный список последними изменениями. Я добавил @takahirox в multimaterial и возьму себе задачу составления изображений.
Я добавил также расширение material_unlit, хотя оно все еще находится в черновике, я считаю, что оно довольно близко к выпуску и не сильно изменится (/ cc @donmccurdy)

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

Как я уже говорил в другой ветке, я над этим работаю.

WIP ... (Мику имеет мульти-материал)

Что касается неподдерживаемых форматов изображений, давайте перейдем к 3.

@takahirox хорошо выглядит! 👍

Кстати, вы, ребята, заинтересованы в поддержке zip-архивов? .glTF + внешний .bin и текстуры подошли бы к другим инструментам разработки (возможно), но это сложно сделать без архива. Так что понадобится zip-архив. И мы можем уменьшить размер экспортируемого файла.

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

Разве это не то же самое, что gzip glb?

.glTF + внешний .bin и текстуры подошли бы к другим инструментам разработки (возможно)

Я надеюсь, что инструменты авторинга не потребуют отдельных файлов; мы призываем всех использовать GLB по умолчанию. Но проще отредактировать изображение, если оно не встроено.

Нет твердого мнения о том, хотим ли мы напрямую добавить эту функциональность в THREE.GLTFExporter ... но я почти думаю, что у нас не должно быть слишком много опций, которые могли бы быть пост-оптимизацией в glTF. Другой пример, Draco довольно сложен и требует нескольких внешних файлов, так что, может быть, лучше позволить специализированным инструментам glTF-to-glTF выполнять эту оптимизацию? Точно так же мы могли бы сделать glb-unpacker (противоположный http://glb-packer.glitch.me/), чтобы помочь людям распаковывать файлы из GLB в ZIP, если мы обнаружим, что он нужен людям.

С https://github.com/KhronosGroup/glTF/issues/1256 -

... изначальная цель gltf-pipeline - и, по сути, glTF в целом - сделать экспортеры настолько простыми, насколько это возможно, и перенести оптимизацию в общий инструмент. Это также, конечно, поможет с фрагментацией.

при этом, насколько я знаю, еще не существует glb-unpacker ...

@mrdoob

Я хотел, чтобы изображения текстур были внешними, а не .glTF против .glb.

@donmccurdy

Я продолжил обсуждение https://github.com/KhronosGroup/glTF/issues/1117 и согласен с поощрением встроенных файлов .glb + и конвейерного подхода. Один .glb хорошо подходит для передачи данных, особенно для Интернета, а конвейерный подход может сделать экспортеры и инструменты простыми и многоразовыми. (Мне тоже нравится конвейер команд UNIX / Linux!)

Так что я не думаю, что экспортеру сейчас нужна поддержка zip-архива. И, возможно, по той же причине ему также не нужны редкие аксессуары и поддержка Draco.

Что касается glb-unpacker, я, возможно, сделаю это в свободное время. Я думаю, что некоторым художникам нравятся внешние файлы .glTF +, потому что они читаются без каких-либо специальных инструментов для glTF. А иногда внешние файлы могут сократить время загрузки из-за параллельной загрузки файла, поэтому его можно использовать в целях оптимизации.

Что касается инструментов конвейера / оптимизации, я хочу отметить, что мы не хотим передавать огромные данные по сети. Пользователи хотят оптимизировать / сжать перед ~ преобразованием ~ передачей данных. Таким образом, веб-сервис оптимизации glTF иногда не работает для огромных данных, потому что пользователю нужно отправить огромный файл на сервер.

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

С этой точки зрения я хочу, чтобы инструмент мог работать где угодно, в браузере, на сервере, в CUI и т. Д., Чтобы он был более распространенным и пригодным для повторного использования. Мы не хотим создавать инструменты одного и того же назначения дважды или более для разных платформ. Итак, инструмент на основе node.js был бы хорош? Есть ли у команды glTF (pipeline) предложения? (Возможно, это обсуждение следует проводить в glTF, а не здесь.)

На всякий случай, в GLTFLoader бинарная поддержка реализована как расширение, но .glb находится в основной спецификации glTF 2.0, правильно?

На всякий случай, в GLTFLoader двоичная поддержка реализована как расширение, но .glb находится в основной спецификации glTF 2.0, правильно?

Да, это было расширение в glTF 1.0, и я просто никогда не перемещал и не переименовывал этот код после того, как он стал частью основной спецификации glTF 2.0.

С этой точки зрения я хочу, чтобы [инструменты оптимизации] могли работать где угодно, в браузере, на сервере, в CUI и т. Д., Чтобы они были более распространенными и пригодными для повторного использования. Итак, инструмент на основе node.js был бы хорош? Есть ли у команды glTF (pipeline) предложения? (Возможно, это обсуждение следует проводить в glTF, а не здесь.)

Стоит спросить о дорожной карте glTF-Pipeline ... не знаю, насколько общим они хотят, чтобы glTF-Pipeline был, или предназначен ли он в основном для использования с цезием, или это просто проблема ограниченного времени разработчика. Также актуальным выглядит

О, мне не хватало компиляции для WASM. Указание некоторых рекомендуемых платформ для разработчиков было бы полезно разработчикам оптимизации. Так что я бы предложил соответствующую ветку.

Я согласен с @donmccurdy, так как считаю, что эти оптимизации в конвейере могут существовать в другом репозитории, чем three.js, так что каждый может получить от них пользу. Мне все еще нужно проверить различия между инструментами gltf pipeline и toolkit, но я ожидаю, что в них будут включены такие функции.
Я также согласен с тем, что до тех пор, пока у нас будет WASM, исходный язык не будет иметь значения, но также верно и то, что если он написан на node.js, вероятно, многие из сообщества, работающего с 3D-движками, могли бы помочь улучшить их, поскольку прямо сейчас являются основной целью для этого формата файлов.

Я не уверен, что понимаю «оптимизацию перед преобразованием» ... существует несколько типов преобразований, которые конвейер может выполнять в модели, и оптимизация, вероятно, является наиболее распространенным типом преобразования?

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

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

Привет, народ

Я использую THREE.js GLTF Exporter для экспорта всей сцены кадра как объекта gltf.
Как я могу сделать теги a-animation, определенные в кадре, частью анимации в объекте gltf?

@donmccurdy @fernandojsg @mrdoob

Привет @siddhartpai - THREE.GLTFExporter преобразует только объекты THREE.AnimationClip в анимацию glTF, тогда как система анимации A-Frame использует TweenJS. Так что в настоящее время это невозможно. Возможно, вы захотите открыть проблему в A-Frame или A-Frame Inspector, которые также используют GLTFExporter , чтобы запросить это в качестве будущей функции.

Мультиматериальная подставка # 13536

Я только что заметил, что валидатор выдает ошибку для каждого нормального элемента в буфере, который не нормализован. например, если я сохраню неинициализированные значения, такие как [0,0,0], это вызовет эту ошибку.
Поскольку это ошибка, а не предупреждение / уведомление, я считаю, что ее необходимо исправить. Что вы думаете о нормализации нормальных элементов bufferview? Даже в этом случае следует ли использовать допустимый единичный вектор для значений, которые нельзя нормализовать, таких как [0,0,0]? / cc @donmccurdy

Похоже, что NORMAL нужно нормализовать.

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#meshes

НОРМАЛЬНЫЙ | «VEC3» | 5126 (ПЛАВАЯ) | Нормализованные нормали вершин XYZ

Согласен с обеспечением, потому что нормальный Three.js не имеет такого ограничения.

Да, но что делать, если у вас нет фактического нормального значения, например неиспользованного значения [0,0,0], просто создать действительное значение и все в порядке? скажем [1,0,0]. Поэтому мы должны изменить код просмотра буфера, чтобы определить, что мы анализируем обычный атрибут, и нормализовать каждый из них перед сохранением его в окне просмотра данных.

что делать, если у вас нет фактического нормального значения, например неиспользованного значения [0,0,0]

Хм .... заменить на действующий и отобразить предупреждение?

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

Я предпочитаю делать это в processMesh() потому что это будет проще, например

var originalNormal = geometry.attributes.normal;

if ( hasNonNormalizedValues( originalNormal ) ) {

    geometry.attributes.normal = createNormalizedAttribute( originalNormal );

}

processAccessorHere();

geometry.attributes.normal = originalNormal;

Если мы сделаем это в processBufferView() , код станет немного сложным, потому что нам нужно заботиться о том, распределяются ли данные между разными атрибутами, например положением и нормальным. (Я знаю, что это очень редкий вариант использования, но Three.js не ограничивает.)

Да, мне нравится такой подход, я боялся изменять нормали после экспорта, но все должно быть нормально, если мы сохраним ссылку и вернем их обратно после завершения. : +1: Не могли бы вы продвинуть пиар с этими изменениями? или хотите, чтобы я это сделал?

Хорошо, я сделаю. (Вы спешите это исправить?)

@takahirox круто, спасибо! но без спешки я просто смотрел состояние экспортера ^ _ ^

Хорошо, тогда я займусь ~ завтра ~ на этой неделе.

Правильно, glTF не позволяет опускать нормали на определенных вершинах, но не на других в одном примитиве. Нам нужно будет указать какое-то значение, удалить эти вершины или выдать ошибку.

Я бы предпочел упростить задачу для пользователя, поэтому я голосую за создание нового массива нормалей, нормализуя их и добавляя значение (0,1,0) для пустых.

Выглядит неплохо. Если для больших моделей это медленно, нам может понадобиться опция checkNormals или что-то в этом роде, чтобы пользователи, которым это не нужно, могли отказаться, а не сканировать каждую вершину.

Ага, я как раз собирался написать то же самое! : D

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

Я сначала сделаю пиар без этой возможности. Добавим, когда / при необходимости. Лично я считаю, что эта проверка не сильно замедляет.

Я сначала сделаю пиар без этой возможности. Добавим, когда / при необходимости. Лично я считаю, что эта проверка не сильно замедляет.

Я нормализовал все буферы при загрузке каждого штриха в a-painter, и это было довольно медленно

Даже если просто проверить, нормализованы ли они?

@takahirox, вам все

Хм, ладно. Буду оценивать с PR.

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

Отличная работа! ИМХО надо слить в core three.js, а не в "примеры".
Хотелось бы увидеть поддержку KHR_lights_punctual !

PR https://github.com/mrdoob/three.js/pull/15519 добавляет KHR_lights_punctual. :)

Я думаю, что эту проблему, вероятно, можно закрыть - остальные элементы менее критичны для удобства или оптимизации, и их можно отслеживать в другом месте:

• [] повторно использовать просмотры буфера
• [] автоматическое объединение текстур металла / шероховатости / ао

Привет, ребята, кто-нибудь знает, как я могу экспортировать сетку нестандартной формы, изменяя морфинг, применяя морфы и удаляя их из конечного объекта?
Как этот вопрос https://stackoverflow.com/questions/57423471/how-to-export-morph-changed-meshes-from-threejs-application
Заранее спасибо!

@ vini-guerrero Для получения помощи используйте форумы (https://discourse.threejs.org/) или Stack Overflow, а не вопросы GitHub.