Расположение файлов для преобразования
Чтобы правильно обработать актив, сервис конвертации должен уметь находить все входные файлы.
Они состоят из конвертируемого основного файла актива и, как правило, некоторых других файлов, на которые ссылаются пути в файле актива.
Запросу на преобразование актива присваиваются два параметра, которые определяют, как служба преобразования находит эти файлы: settings.inputLocation.blobPrefix (который является необязательным) и settings.inputLocation.relativeInputAssetPath.
Они полностью задокументированы на странице Преобразование REST API.
При размещении файлов важно отметить, что BlobPrefix определяет полный набор файлов, доступных сервису преобразования при обработке актива.
Примечание.
Служба будет скачивать все файлы в input.BlobPrefix. Убедитесь, что имена и пути файлов не превышают ограничения на длину пути в Windows, чтобы избежать проблем со службой.
Размещение файлов так, чтобы их можно было найти
Когда исходный актив использует внешние файлы, пути к этим файлам будут храниться внутри актива. Служба преобразования должна интерпретировать эти пути в файловой системе, отличной от исходной файловой системы ресурса. Если пути сохранены как относительные пути и относительное расположение между исходным активом и файлом, на который он ссылается, не изменилось, тогда сервису преобразования будет легко найти указанный файл.
Примечание.
Мы рекомендуем размещать файлы во входном контейнере, чтобы относительное расположение файлов было таким же, как и при создании ресурса.
Примечание.
Предпочитайте создавать активы, которые несут относительные пути. В руководстве по настройке материалов для 3ds Max приводится пример 3ds Max, показывающий, как обеспечить использование относительных путей в активе.
Поиск текстур
Из-за множества способов создания активов служба преобразования должна быть гибкой. В частности, он должен обрабатывать ситуации, когда пути в активе и расположение текстур не совпадают точно. Примером может служить создание ресурсов, содержащих абсолютные пути, поскольку эти пути никогда не будут соответствовать файловой системе, используемой службой преобразования. Чтобы справиться с этой ситуацией, среди прочего, мы используем наилучший подход к поиску текстур.
Алгоритм поиска текстур следующий: учитывая путь, хранящийся в активе, найдите самый длинный суффикс вложенного пути, который при использовании в качестве относительного пути от местоположения исходного ресурса нацелен на существующий файл. Если такой вложенный путь (включая весь путь) не нацелен на файл, текстура считается отсутствующей.
Рассмотрим следующую надуманную файловую систему:
G:\CONVERSION
├───Assets
│ │ myAsset.fbx
│ │ myTexture.png <- A
│ │
│ └───Textures
│ │ myTexture.png <- B
│ │
│ └───MyAssetTextures
│ myTexture.png <- C
│
└───Textures
│ myTexture.png <- D
│
└───MyAssetTextures
myTexture.png <- E
Если myAsset.fbx ссылается на текстуру с относительным путем ..\Textures\MyAssetTextures\myTexture.png, тогда служба преобразования будет использовать файл E. Фактически, он может использовать любой из файлов A, C и E, если они существуют, причем предпочтительным является файл E, поскольку он найдено с самым длинным суффиксом.
Файлы B и D никогда не будут использоваться, потому что Textures\myTexture.png не является частью какого-либо суффикса сохраненного пути.
Если ресурс вместо этого содержит пути H:\Foo\Bar\Textures\MyAssetTextures\myTexture.png или ..\..\..\Foo\Bar\Textures\MyAssetTextures\myTexture.png, тогда служба преобразования сможет найти файлы A и C, если они существуют (предпочитая C вместо A). Однако E нельзя найти таким образом, и файл придется переместить.
Это можно исправить, переместив папку "Текстуры" рядом с активом.
Примечание.
Если текстуры не найдены, возможное решение — убедиться, что актив является родственником некоторого поддерева, содержащего текстуры.