Полная переделка системы материалов

[SNMetamorph]

Текущее устройство системы материалов имеет большое количество минусов.

1. Понятие материала намертво привязано к текстуре и её названию. Из этого вытекает ряд проблем:

Пример 1.1: на прикреплённой фотографии, зелёными галочками помечены модели, которые требуют уникальную текстуру. Красными галочками помечены модели, для которых можно было бы обойтись одной и той же текстурой, а в идеале вообще обойтись без текстуры. Но в текущей реализации, для КАЖДОЙ модели приходится делать уникальную текстуру (потому что материалы там разные)

В идеале, понятия текстур и материалов должны быть отделены друг от друга. То есть, модели/браши должны ссылаться не на какую-либо определённую текстуру, а на материал (как это реализовать - вопрос тоже дискуссионный). И уже в самом материале указаны все нужные текстуры, которые рендер будет использовать.

2. Для PBR модели освещения, вместо понятия roughness используется smoothness

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

3. Параметры smoothness/metalness/ambient occlusion/specular intensity хранятся в разных цветовых каналах одной текстуры

Да, с точки зрения экономии видеопамяти и дискового пространства - это хорошее решение, но для процесса создания контента, это крайне, крайне неудобно (приходится каждый канал текстуры сохранять в отдельный файл, что-то менять в этих файлах, и упаковывать всё обратно в одну текстуру). В идеале надо иметь возможность в описании материала задавать путь до roughness/metalness/AO/specular intencity текстур - это нужно для процесса создания контента. А когда весь необходимый контент уже создан, в описании материала указать путь до условной combined map, в которой уже упакованы все вышеупомянутые текстуры в нужные цветовые каналы. Также под вопросом схема упаковки нужных параметров в цветовые каналы текстуры. Например, зелёный канал в некоторых форматах сжатия упаковывается более качественно, так что в него имеет смысл паковать roughness, как наиболее вариабельный параметр (metalness, напротив, обычно редко имеет какие-то промежуточные значения помимо 0.0 и 1.0). Также для принятия этого решения имеет смысл оценить, унифицированы ли где-то и как-то подобные схемы упаковки PBR параметров в цветовые каналы текстур (см. MRAO, RMA, ORM).

4. Нет возможности горячей перезагрузки материалов и внутриигрового редактора материалов

В планах создать внутриигровой редактор материалов на базе ImGui. Помимо базового функционала изменения всяких настроек у материалов прямо налету, будет также функция перезагрузки описаний материалов из файлов прямо в игре. Также, должна быть возможность менять путь до карт нормалей/PBR/люма-текстур и так далее. Всё это крайне важные вещи, которые экономят огромное количество времени создателей контента.

5. В текущей системе материалов используется собственный текстовый формат

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

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

[SNMetamorph]

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

• Физические (описывают звуки попадания пули, звуки ходьбы для NPC/игроков, название типа партиклей, название группы декалей, которые будут применены при попадании). Полный их функциональный аналог из Source Engine называется surface props
• Визуальные (как раз этому виду и посвящен данный тред). В связи с этим всем, нужно ввести более ясную терминологию, в которой данные виды материалов будут явно разделены (во избежание путаницы). Также необходимо будет это всё хорошо продокументировать. Для физических материалов планируется использовать формат файла .pmat, а для визуальных .vmat

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

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

[SNMetamorph]

Дополнение к пункту 1.1

Привязка к материалу будет осуществляться через имя текстуры в WAD-файле или студиомодели. Например, в Source Engine можно напрямую выбрать нужный материал в VHE или в QC-файле. Но поскольку в движке с которым мы работаем, нет никакого понятия материала в принципе (есть только понятие текстуры), то мы вынуждены ссылаться на материалы через название текстур, примерно по такой схеме:

Для брашей:
materials/имя_wad_файла/имя_текстуры.vmat

Для студиомоделей:
materials/имя_mdl_файла/имя_текстуры.vmat
Но есть нюанс: должны ли мы игнорировать подпапки в названиях текстур студиомоделей? Такое тоже встречается.