Three.js: Утилиты: устаревшие программы экспорта (Blender, 3DS Max и Maya)

+1 за это - существование плохо обслуживаемых и устаревших экспортеров в репо - ненужная путаница для новичков, тем более, что, как указывает @ Mugen87 , теперь есть гораздо лучшие варианты.

Примечание: официальный экспортер GLTF Blender (https://github.com/KhronosGroup/glTF-Blender-Exporter) в настоящее время не поддерживает правильный экспорт анимации (в настоящее время поддерживается только 1 анимация на объект).
https://github.com/KhronosGroup/glTF-Blender-Exporter/issues/112

@Usnul, как это соотносится с экспортером Blender JSON в этом репо?

@looeee
Экспортер Blender JSON отлично экспортирует анимацию. Есть некоторые странные глюки с UV или нормалями вершин в определенных условиях, которых нет в экспортере GLTF, но это уже другая история.

Хорошо, я не использую Blender, поэтому не буду комментировать это дальше.

Однако по опыту могу сказать, что попытка использовать экспортер 3DS Max, который не обновлялся несколько лет, является бесконечной головной болью, и я бы решительно поддержал удаление его из репозитория в пользу формата FBX.
Почти все, что экспортируется программой экспорта 3DS Max FBX, теперь поддерживается FBXLoader, и, поскольку этот экспортер поддерживается AutoDesk, мы можем рассчитывать на его актуальность.

То же самое и с экспортером Maya FBX, хотя FBXLoader все еще нуждается в обновлении, чтобы должным образом поддерживать там точки поворота.

Насколько я помню, Blender не экспортирует анимацию, когда вы выбираете BufferGeometry . Определенно есть проблема с морфингом, см. # 10932. Кроме того, экспортер использует «старый» формат иерархии анимации, а не формат текущей анимационной системы.

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

Вероятно, есть сотни инструментов three.js, на которые мы могли бы ссылаться таким образом, но если мы не хотим убедиться, что они активно поддерживаются и работают правильно, я не думаю, что нам нужно включать здесь ссылки на них.

Поиск в Google по запросу «three.js revit exporter» все равно обнаруживает, что репо в порядке.

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

👍

наличие в репо плохо обслуживаемых и устаревших экспортеров - ненужная путаница для новичков

Я просто хочу выделить это утверждение, потому что считаю его очень важным для three.js . Когда пользователи сталкиваются с этими экспортерами, они ожидают, что инструменты просто работают. Но в большинстве случаев они запутываются и, возможно, создают плохое впечатление от всего проекта. Это не хорошо. 😢

Могу ли я, как невиновный пользователь, дать комментарий ...

Относительно Blender:
Если бы у three.js был собственный импортер формата .blend ,
очевидно, что в экспортере не было бы необходимости.

Никаких усилий по установке на стороне Блендера,
нет компиляции из API / структур блендера в javascript через код Python ...

Были приложены огромные усилия, чтобы написать экспортер JSON на python,
Интересно, почему вы, соавторы, не выбрали этот путь ...?

@wolfgangvonludwigsburg
На это довольно простой вопрос. Формат смешивания не очень близок к внутреннему представлению three.js, поэтому необходимо некоторое преобразование. Формат JSON для three.js очень близок к внутреннему представлению, поэтому преобразование из представления блендера в three.js выполняется в любом случае, независимо от того, назовете ли вы его Exporter или Loader. При этом .blend не является распространенным форматом передачи, ничто, кроме блендера, действительно не поддерживает его, поэтому наличие загрузчика для него удовлетворило бы довольно небольшую аудиторию, поскольку даже люди, которые используют блендер, часто также склонны использовать другое программное обеспечение, и .blend не является предпочтительным форматом обмена. Обычно это obj, fbx или какой-нибудь открытый стандарт вроде gltf или collada.

@wolfgangvonludwigsburg, если вы _were_ изучили создание загрузчика файлов .blend, это, вероятно, было бы хорошим местом для начала:

https://raginggazebo.com/parsing-blender-3d-files-blend-1-of-3/

Большое спасибо за ваши комментарии!

Но почему экспортер Blender JSON подвержен таким ошибкам ...
=> Это зависит от API Blender, написано на Python, должно понимать структуры данных Blender,
и компилируется в формат JSON, который three.js преобразуется во внутреннее содержимое ...

Очень много задач, которые все могут (и действительно делают!) Терпят неудачу, в основном при изменении версии Blender.
Что ж, я бы предпочел способ "прямой компиляции данных" ...

Что ж, я бы предпочел способ «прямой компиляции данных».

Это плохой подход. Загрузка файлов blend непосредственно в приложения - это неправильное использование. Вместо этого вам следует использовать формат файла, предназначенный для передачи данных и доставки активов. glTF - это первый стандартизированный формат, который фокусируется на этом аспекте с точки зрения приложения. Это одна из причин, почему я так много раз продвигаю glTF 😇. Это должно быть стандартом для всех будущих 3D-приложений.

Что ж, я бы предпочел способ "прямой компиляции данных" ...

К сожалению, при таком использовании .blend возникают более серьезные проблемы. Он хранит такие вещи, как история редактирования, текущее состояние пользовательского интерфейса Blender, данные надстройки Blender. Формат меняется по мере выхода новых релизов Blender. Размер файлов может быть очень большим, поэтому он никогда не будет хорошим выбором для высококачественных 3D-приложений. Лучший способ получить данные напрямую из Blender - использовать API Blender (как это делают экспортеры FBX и glTF), а не пытаться реконструировать внутренний формат Blender .blend .

К исходному вопросу я собираюсь пропустить добавление голосов за / против, поскольку я не очень знаком с рабочими процессами 3D-авторинга.

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

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

Я не возражал против использования формата Blender .blend в качестве общего формата обмена ,
но это может упростить сотрудничество между Blender и three.js ...

Я не могу оценить усилия, поддерживая экспортер Python + графический интерфейс в рамках Blender,
но я думаю, это легко может превратиться в ужас ... ;-)

@donmccurdy
Кстати, Wavefront .obj, 3D Studio .3ds также являются собственными форматами, которые широко используются ...

Кстати, Wavefront .obj, 3D Studio .3ds также являются собственными форматами, которые широко используются ...

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

3ds Max в .3ds находится в той же категории, что и в Blender .blend или Майи .mlt или Cinema4D - х .c4d . У каждого редактора есть свой внутренний формат, и эти форматы меняются вместе с программным обеспечением. Поддержание загрузчиков для частного внутреннего формата каждого инструмента моделирования намного сложнее и подвержено ошибкам, чем использование форматов экспорта, которые предоставили собственные разработчики редактора. Стоит отметить, что и 3DS, и Blender поставляются со встроенным экспортом FBX, поддерживаемым их авторами, и что Blender также будет иметь встроенный экспорт в glTF в будущей версии.

Последний бросок ...

У нас уже есть один инструмент моделирования, независимый экс / импортер: Collada,
но по каким-то причинам это кажется не очень приемлемым.

Желательно, чтобы я имел в виду такую ​​реализацию:
решение для загрузки, основанное на Google Protocol Buffers

https://developers.google.com/protocol-buffers/

Это

... не зависящий от языка, платформы, расширяемый механизм для сериализации структурированных данных - подумайте об XML, но меньше, быстрее и проще.

Поскольку векторные данные 2D / 3D, с которыми нам приходится иметь дело, не так уж и сложны по своей природе, разработка одной схемы файла данных Blender должна быть просто осуществимой ...

На самом деле в javascript есть парсер смешанных файлов 😁
https://github.com/Galactrax/js.blend

эээ, я получаю поддержку ... - спасибо mrdoob ;-))

САМОЕ самое большое (с точки зрения Terrabyte) приложение для 3D-моделей (Google Maps 3D) использует этот эффективный вид (protobufs) реализации ...

Идти по пути загрузки .blend может быть не очень разумно. Но на самом деле это не так уж и отличается от загрузки .dae и .fbx ...

Во всяком случае, я согласен с идеей осуждать экспортеров.
Однако я бы подождал, пока gltf станет немного более зрелым и протестированным. Лето 2018?

Я согласен также удалить этих экспортеров. Вы даже можете переместить их в другое репо, где они смогут RIP :)

Однако я бы подождал, пока gltf станет немного более зрелым и протестированным. Лето 2018?

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

• [] Blender поставляется со встроенным экспортом в glTF и поддержкой нескольких анимаций.
• [x] Улучшен рабочий процесс от Maya и 3DS Max до glTF, или просто дополнительное тестирование FBX2GLTF .
• [x] Обновления официального конвертера COLLADA2GLTF для glTF 2.0.

Возвращение к вопросу летом 2018 года звучит правильно.

Однако я бы подождал, пока gltf станет немного более зрелым и протестированным. Лето 2018?

Что касается экспортера Blender, я склонен согласиться. Однако я рекомендую немедленно удалить хотя бы программу экспорта 3DS Max, поскольку в FBX уже есть зрелая и гораздо лучшая альтернатива.

Однако я рекомендую немедленно удалить хотя бы программу экспорта 3DS Max, поскольку в FBX уже есть зрелая и гораздо лучшая альтернатива.

Мне нравится 👌

Хорошо, экспортера 3DS Max больше нет. Давайте вернемся к другим экспортерам (Blender и Maya) через несколько месяцев.

Я не думаю, что за это время что-то изменится в отношении экспортера Maya.

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

Хорошее предложение 👍.

Пока мы здесь, каков статус https://github.com/mrdoob/three.js/tree/dev/utils/converters/fbx ? Похоже, это можно было бы заменить скриптом node.js, таким как конвертер obj2three, просто используя THREE.FBXLoader и сериализуя в конце. На данный момент у конвертера есть много открытых проблем:

No animation support
Only Lambert and Phong materials are supported
Some camera properties are not converted correctly
Some light properties are not converted correctly
Some material properties are not converted correctly
Textures must be put in asset's folder, and use relative path in the material

Также конвертеры msgPack, UTF8 и CTM - их не трогали уже много лет.

Они еще кому-нибудь полезны?

@donmccurdy Боюсь, вы не можете использовать FBXLoader внутри скрипта node.js, поскольку у вас нет доступа к DOM. Все загрузчики, использующие TextureLoader , зависят от ImageLoader и, следовательно, от document . Мы будем получать ошибки времени выполнения, например ReferenceError: document is not defined . Та же проблема для объекта window , доступ к которому осуществляется из FileLoader .

В качестве временного обходного пути, возможно, мы могли бы переопределить ImageLoader и FileLoader в файле fbx2three.js ?

может быть, мы могли бы переопределить ImageLoader и FileLoader в файле fbx2three.js?

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

может быть, мы могли бы переопределить ImageLoader и FileLoader в файле fbx2three.js?

Хорошая идея: blush:

.3ds от 3DS Max находится в той же категории, что и .blend Blender, .mlt от Maya или .c4d от Cinema4D.

Это может быть не совсем так, .max больше похож на ту же категорию, .3ds довольно урезан.

Мне понравилось иметь экспортер 3ds max в качестве примера того, как написать экспортер, а также на maxscript. Не думаю, что мне когда-либо удавалось экспортировать правильное касательное пространство из 3ds max через fbx, с maxscript легко экспериментировать и брать то, что вам нужно.

Стоит ли размещать новое репо с соответствующими оговорками? Все это для примеров того, как написать экспортер, но если он не обслуживается и FBXLoader теперь более надежен, мы не хотим, чтобы люди считали это рекомендуемым способом переноса ресурсов из 3DS Max в three.js.

Да, во всяком случае, я голосую за новое репо.

Просто хотел добавить, прежде чем полностью отказаться от формата json: мы используем экспортер блендера для экспорта сцены, то есть настраиваем иерархию камеры и сцены с анимацией и настраиваемыми свойствами вместе с объектами-заполнителями, которые затем динамически заменяются во время выполнения реальными сетками (загруженными другими способами). Поскольку это «просто» json, очень легко проанализировать и изменить в js и делать подобные вещи. Я не уверен, например, glTF (по крайней мере, в его текущей форме) хорошо подходит в качестве формата сцены, поэтому надеюсь, что экспортер блендера и формат json останутся немного дольше

@pjoe Я ожидаю, что формат JSON и экспортер Blender с большей вероятностью

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

• настроить камеру
• иерархия сцены
• анимации (для нескольких действий Blender вам понадобится другой экспортер )
• настраиваемые свойства (выберите в параметрах «Экспорт дополнительных услуг»)
• «просто JSON» для материалов, метаданных и т. д. Данные сетки оптимизированы как отдельные двоичные данные

@donmccurdy должен признать, что у меня нет большого опыта работы с glTF (по крайней мере, пока) - хотя я пытался прочитать спецификацию :)

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

Из-за того короткого времени, которое я провел с блендером glTF exporter, он также казался довольно незрелым в то время (около двух месяцев назад). Очевидно, это можно исправить, помогая улучшить его :)

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

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

Обычно я обнаружил, что экспортер glTF Blender дает лучшие результаты, чем любой другой вывод Blender, но, пожалуйста, сообщайте об ошибках, если вы обнаружили определенные проблемы. :)

@donmccurdy согласился с тем, чтобы glTF оставался верным для транспорта / времени выполнения ... одна из замечательных особенностей этого заключается в том, что он не пытается соответствовать всем форматам (например, collada - не заставляйте меня начинать).

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

В качестве побочного примечания мы также используем json-загрузчик webpack, чтобы включить файл сцены в наш основной пакет, что упрощает работу с ним.

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

@looeee Мне любопытно, у вас есть новости по этому поводу 😊? Как вы думаете, можно ли сейчас удалить экспортера и вместо этого обратиться к FBX ?

Как вы думаете, можно ли сейчас удалить экспортера и вместо этого обратиться к FBX?

Я провел лишь небольшое количество тестов, планировал сделать больше, но у меня не было времени. Но я бы сказал, что да, мы должны удалить его и работать над тем, чтобы FBXLoader полностью поддерживал Maya.

Присоединяйтесь к нам как пользователь экспортера Blender: одним из преимуществ JSON является то, что его очень просто изменить после экспорта. Blender - это только часть нашей автоматизированной цепочки инструментов, и мы много обрабатываем экспортированный JSON, прежде чем он будет готов для использования в нашем веб-средстве просмотра. Наличие формата передачи, столь близкого к внутреннему формату threejs, является для нас большим плюсом.

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

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

Soft8Soft только что выпустила программу экспорта для 3ds Max на основе glTF . Так что это может быть хорошей альтернативой удаленному экспортеру JSON.

Спасибо @alexkowel , приятно это видеть (и поздравляю!). Если бы вы могли добавить ссылку на эту ветку, мы перечислим ее вместе с другими ресурсами glTF. 🙂

@dherben хорошие моменты, спасибо -

Что касается скорости синтаксического анализа, я думаю, вы найдете glTF еще быстрее. Существенная разница в том, что метаданные по-прежнему «просто JSON», тогда как большая часть полезной нагрузки (позиции вершин, данные анимации) находятся в блоке ArrayBuffer, который можно использовать для создания типизированного массива для конструкторов THREE.BufferAttribute . В полностью оптимизированном загрузчике (я не знаю, существует ли еще THREE.GLTFLoader) вам никогда не придется читать или копировать эти данные в JS.

Но что касается модификации данных как части конвейера, я согласен с тем, что, как вы сказали, проще работать с простым JSON. Существуют библиотеки на разных языках для работы с glTF, но инструментарий еще не очень развит.

Текущий статус этой проблемы:

Экспортеры:

• [X] Экспортер майя
• [X] Экспортер 3DS Max
• [X] Экспортер Blender
  
  
  
  • не собираюсь никуда прямо сейчас, может вернуться в будущем.
  
  
  • Удалено в мае 2018 г.
  
  

Конвертеры:

• [] FBX
  
  
  
  • упрощенная замена предлагается как https://github.com/mrdoob/three.js/pull/13013; нуждается в тестировании
  
  
• [] CTM (не обсуждается)
• [] utf8 (не обсуждается)
• [] obj2three (не обсуждается)

РЕДАКТИРОВАТЬ: Обновлено в мае 2018 г.

@donmccurdy Просто хотел вернуться после экспериментов с glTF Blender exporter и загрузчиком Three.js. Оказывается, он на самом деле неплохо работает в качестве формата сцены для нашего варианта использования. Что я сейчас делаю, так это загружаю экспортированный файл glTF в сцену Three.js, а затем манипулирую иерархией сцены Three.js (меняя местозаполнители динамически загружаемым материалом) перед выполнением первого рендеринга.

Вероятно, есть еще какие-то функции, которые я хотел бы видеть в экспортере glTF, попробую прокомментировать или сделать пиар :)

Вероятно, есть еще какие-то функции, которые я хотел бы видеть в экспортере glTF, попробую прокомментировать или сделать пиар :)

Замечательно, пожалуйста! 🙂

Экспортер Blender пока никуда не денется, возможно, вернется к нему в будущем.

Так кто-нибудь будет работать над текущими ошибками экспортера Blender? Я ожидаю, что ответ будет отрицательным. В таком случае мы должны так сказать.

Если до меня никто другой ... Я бы хотел хотя бы попытаться решить проблемы с ротацией. # 13130

Так кто-нибудь будет работать над текущими ошибками экспортера Blender? Я ожидаю, что ответ будет отрицательным.

Я не прочитал всю дискуссию, но свои два цента.

На прошлой неделе меня попросили помочь компании, у которой есть решение, использующее Three.js для доставки контента на постоянной выставке. Вывески с 3D-моделями, которые пользователи могут исследовать и с которыми можно взаимодействовать. Первоначальные разработчики, которые давно ушли, использовали формат JSON Three.js . Подготовить и внедрить новые модели (с условием, что изменение кода времени выполнения запрещено) - настоящий кошмар.

IMHO Three.js должен сосредоточиться на поддержке уже существующих, а также быстрорастущих форматов, таких как FBX и glTF . Приоритет тех форматов, которые могут содержать несколько бункеров УФ-данных (таким образом, НЕЛЬЗЯ поощрять любимый OBJ). Потом анимация. Я знаю, что надстройка экспорта Blender якобы поддерживает и то, и другое, но FBX тоже.

Представьте себе рабочий процесс, в котором все, что написано в Blender'е

1) WebGL
Очевидно, Three.js 😃

2) OpenGL 3.3+
сырье / Cinder

3) OpenGL ES 2.0 на RISC
Со смартфона на RaspberryPi

4) Игровые движки

5) Графические приложения в реальном времени, интегрированные с медиа-серверами (маскировка Hippo, D3)
Те, которые используют парни сценических визуальных эффектов.

Вместо того, чтобы использовать множество разных экспортеров для разных выходных данных, целью было бы использовать 1, максимум 2 формата. При написании OGL в первых 3 случаях ... нужно использовать один и тот же формат модели, вот и все. По последним двум пунктам FBX является королем (различные реализации COLLADA в разных пакетах затрудняют работу), и на самом деле модель не «раскрывается».
Я не критикую Three.js JSON Format или надстройку Blender (
Я просто хочу поделиться этим с точки зрения, когда нужно постоянно доставлять различные результаты в отрасли. Формат JSON Three.js не подходит для этого ландшафта, он излишний.

@kroko определенно согласен 👍

Я думаю, что ландшафт форматов начинает проясняться. Формат three.js json был создан, потому что в то время не было формата json. Определение формата файла было последним, чем я хотел заниматься, когда уже работал над движком рендеринга и API 😩

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

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

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

Всегда будет возможность экспорта в формате JSON из http://threejs.org/editor/

Закрыт на https://github.com/mrdoob/three.js/pull/14117.

Я предлагаю закрыть сейчас все открытые вопросы, связанные с экспортером Blender. Согласованный?

Я думаю, что кто-то может написать некоторую «официальную» документацию / конвейер для экспорта / импорта 3D-моделей (для основных и специальных функций), устранения общих неполадок и удаления или обновления всех устаревших документов и примеров. Например, пример с рыцарем очень сбивает с толку, учитывая, что у вас больше нет экспортера json в blender. Возможно, JSONLoader для 3D-моделей стоит оставить просто для ретро-совместимости, но мы должны это прочитать и т. Д.

@stmaccarelli здесь есть новая документация: https://threejs.org/docs/#manual/introduction/Loading -3D-models, но да, пожалуйста, дайте нам знать, что еще было бы полезно!

@donmccurdy Я думаю, что бумага плохая.
Прямо сейчас вся система 3D-импорта / анимации, учитывая сочетание документации, примеров и вещей, найденных в Интернете из разных эпох, сбивает с толку.

Основной документ системы анимации был бы в порядке, если бы ссылки на отдельные объекты были правильными.
Возьмем ссылку на AnimationClip. Я не уверен, что экспортирую morphTargets правильно, но здесь я прочитал:

_.CreateClipsFromMorphTargetSequences (name: String, morphTargetSequence: Array, fps: Number, noLoop: Boolean): Array
Возвращает массив новых AnimationClips, созданных из целевых последовательностей морфинга геометрии, пытаясь отсортировать имена морфированных целей в шаблоны на основе групп анимации, такие как «Walk_001, Walk_002, Run_001, Run_002 ...» _

проблема в том, что если я импортирую файл glTF, там нет массива morphTargetSequence ... кое-где хранятся объекты morphTargetSomething, но я не знаю, что и как использовать.

Я думаю, у нас должны быть документы, описывающие управление / рабочие процессы 3D-моделей с очень простыми примерами.
И ссылки на 3D-загрузчики должны соответствовать одному и тому же шаблону.
Скажем
1- простой импорт 3D модели
2- импорт материалов (со всеми особенностями, такими как различные карты, параметры карт, управление несколькими материалами и т. Д.)
3- импорт всей сцены (например, как перемещаться / управлять импортированными сценами, такими как из glTF)
4- импорт и управление скелетной анимацией (ями)
5- импорт и управление морфинговыми анимациями

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

Мы должны обновить примеры, и, хотя это невозможно, мы должны четко написать, что некоторые части устарели и что (как в примере с рыцарем ...)

_EG- если мы решим, что формат файла JSON для 3D-модели должен быть устаревшим, в пользу, скажем, glTF, не имеет смысла, что единственный пример анимации, который включает как скелетную анимацию, так и морфотаргеты, - это старый рыцарь, который использует Модель JSON из 10 версий назад, в которой хранится структура данных, которая больше не используется.

@stmaccarelli Не существует единого рекомендуемого сквозного рабочего процесса; Я думаю, что нам будет сложно предоставить это, учитывая разные уровни навыков, предпочтения бесплатных и платных инструментов моделирования и особые потребности.

Я не думаю, что вам обычно понадобится этот метод CreateClipsFromMorphTargetSequences . В приведенном выше документе не рассматриваются детали использования какого-либо конкретного загрузчика (как вы упомянули, они несовместимы), но в документации GLTFLoader есть -

loader.load('foo.glb', function(gltf) {
  const clips = gltf.clips;  // Array<THREE.AnimationClip>
  const model = gltf.scene; // THREE.Scene
  ...
});

В этом случае не имеет значения, являются ли клипы целями TRS, скинами или морфингом - вы можете воспроизводить все анимации одинаково. Я написал один возможный рабочий процесс с использованием Mixamo и Blender . Вот еще один пример использования Maya .

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

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

Это справедливый момент, и нам есть над чем работать.

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

Строго говоря, формат и структура данных JSON не являются устаревшими, и это по-прежнему вполне разумный способ [де] сериализации сцены, но с учетом этого. @mrdoob что вы думаете о нашей замене некоторых примеров анимации? Такие как:

animation / keyframes / json
animation / scene
animation / skinning / blending
animation / skinning / morph

что вы думаете о нашей замене некоторых примеров анимации?

+1 за это. Я голосую за замену хотя бы солдата из animation / skinning / blending a на более современную модель от Mixamo, например эту:

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

Размер модели будет около 9 МБ, в то время как текущая модель вместе со всеми связанными файлами составляет 71 МБ !!

За animation / skinning / morph мы могли бы использовать модель, с которой я тестировал морфинг-цели FBX:

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

Вот несколько примеров, которые стоит рассмотреть:

| скриншот | ссылка | размер |
| --- | --- | - |
| | ссылка | 6 МБ |
| | ссылка | 3 МБ |
| | ссылка | 5 МБ |
| | ссылка | 12 МБ |

Все они анимированы, корректно работают в three.js и, вероятно, могут быть сжаты или оптимизированы немного больше, чем загружаемая версия Sketchfab. У меня нет фальшивого персонажа с хорошими циклами бега / ходьбы, но рабочий процесс Mixamo-> glTF не так уж и плох.