0x4E69676874466F78 commented 3 years ago

Пока напишу по-русски и сумбурно, это набросок, потом переделаю структуру и переведу, это в любом случае надо на двух языках. I will write in Russian and chaotically for now, this is a sketch, then I will redo the structure and translate it, in any case it is necessary in two languages.

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

Список задач

В скобках [] собственное оценочное суждение о приоритете.

[ ] Поддержка текстур DDS или KTX2 вплоть до BC7 [высокий]
[x] Структура файлов с перекрытием видимости [высокий]
[x] Чтение из ZIP-архива [низкий] В Xash есть поддержка PAK и ZIP.
[x] Metallic/Roughness workflow [высокий]
[ ] Specular/Glossiness workflow [средний]
[ ] Detail map [средний]
[ ] Displacement map [очень низкий]
[ ] SSS map [очень низкий]
[ ] EXR (OpenEXR) [средний]
[x] Формат материалов .mat [высокий]
- [x] замена WAD [высокий]
- [x] точечное применение к брашу в конкретной карте [низкий]
- [ ] "force_render_mode" [средний]
- [x] замена MDL [высокий]
- [ ] точечное применение к модели в конкретной карте [очень низкий]
- [x] замена SPR [высокий]
- [ ] точечное применение к спрайту в конкретной карте [очень низкий]
- [ ] "framerate_multiplier" [средний]
- [ ] "scale_multiplier" [высокий]
- [x] замена ENV [средний]
- [ ] точечное применение к окружению в конкретной карте [очень низкий]

"очень низкий" — что потенциально может понадобиться, но скорее всего вряд ли, либо просто хотелка. "низкий" — скорее всего понадобится, но можно обойтись. "средний" — можно обойтись, но придётся мириться с большими недостатками.

Наследие/Legacy

WAD, MDL, SPR для улучшенных текстур использовать не самая хорошая идея, с ними только лишние заморочки как в разработке так и артистам. Например у них обязательная палитра в 256 цветов и тот же Wally не умеет упаковывать больше 2048х2048 (возможно другие редакторы могут, не проверял). Можно конечно воспользоваться pngquant, но это всё потери качества и не везде вытянет. Тем не менее, старые форматы поддерживать стоит, если у текстуры нет замены, должен быть fallback в обычный рендер по палитре с прозрачностью из неё и т.п. короче не сломать совместимость.

Улучшенные текстуры

Предлагаю текстуры держать в DDS или KTX2 с поддержкой форматов от BC4 до BC7, тогда можно иметь хорошее сжатие и как бонус можно работать над мипмапами, сделав их более качественными чем обычно (банально добавить резкость). Улучшать текстуры можно в два прохода:

Увеличить разрешение текстуры через нейросети типа ERSGAN, RealERSGAN и т. п. подобрав правильные нейромодели под каждую текстуру, возможно доработать руками, особенно случаи и прозрачностью.
Через разнообразные инструменты достать из diffuse необходимые карты и/или дорисовать необходимую информацию. Доставатели: AwesomeBump (полное PBR, открытые исходники, но неудобный непонятный интерфейс доставляющий боль) ModLab (полное PBR, проприетарно, бесплатно, выглядит удобным) Materialize (полное PBR, открытые исходники, интерфейс не совсем удобный Substance B2M 3 (полное PBR, проприетарно, платно) Quixel nDo2 (только нормали, плагин к ФШ, хорошо достаёт нормали, уже больше не купить) ShaderMap (полное PBR, проприетарно, платно, не использовал) knald (полное PBR, проприетарно, платно, не использовал) Ещё вкопилку из старья которое я не использовал (чтобы не упоминали лишний раз): CrazyBump, MindTex, xNormal, PixPlant, njob. Рисователи: Substance Painter можно рисовать самому PBR карты (был ещё Quixel DDO, но его уже не купить). Substance Designer дизайнер процедурный карт. И их новые версии от Adobe. ArmorPaint открытые исходники (не использовал). Quixel mixer (не использовал).

Планирую отдельную статью в вики с описанием того как всё это сделать.

Структура файлов

Примечание: структура ещё сырая. vulkan_ убрал так как PBR материалы потенциально могут быть использованы в PrimeXT

valve/pbr_replacements/wadname.wad/
valve/pbr_replacements/maps/mapname/
valve/pbr_replacements/models/modelname/
valve/pbr_replacements/sprites/spritename/
valve/pbr_replacements/gfx/env/envname/

valve это имя мода. У движка HL есть особенность что можно в карте для того же CS использовать текстуры из WAD директории valve, они прописаны в карте, этот механизм надо учитывать и грузить pbr_replacements из других папок если потребуется. /wadname.wad/ папка ассоциированная с распакованным WAD файлом, для удобной замены существующих текстур новыми материалами. /maps/mapname/ материалы из этого каталога применяются к конкретной карте mapname.bsp, имеют приоритет над /wadname.wad/. Возможно потребуется перекрытие /models/modelname/, /sprites/spritename/, /gfx/env/envname если есть вхождение внутри /maps/mapname/, но на первом этапе это не нужно. /models/modelname/ материалы из этого каталога применяются к конкретной моделе modelname.mdl /sprites/spritename/ материалы из этого каталога применяются к конкретному спрайту spritename.spr /gfx/env/envname материалы из этого каталога применяются к конкретному окружению (небу) envname Внутри WAD и MDL файлов лежат имена текстур, эти имена используются внутри папок выше, только в силу того что у нас PBR файлов не один, а множество, формат именование файла: texname_typeTexture где texname имя исходной текстуры, а typeTexture это в случае Metallic/Roughness: basecolor, metal, roughness, normal; а в случае Specular/Glossiness: albedo, specular, glossiness, normal. Возможны ещё дополнительные текстуры для подповерхностного рассеивания (sss), для тесселяции (displacement). Прозрачность можно хранить в альфаканале у basecolor/albedo. Для жидких текстур параметры из палитры (см. #37) будут описаны в файле материала. Сам файл материала texname.mat.

Возможность хранить файлы в архивах

У Xash есть поддержка PAK, она должна работать и в случае pbr_replacements. Чтение из архива будет быстрее чем из распакованной структуры в ФС и проще распространять.

Материалы

Примечание: структура ультра сырая.

Общее

Чтобы заменить оригинальную текстуру материал должен внутри себя иметь настроенный параметр "replace_for". Для удобства лучше называть материал именем оригинальной текстуры, если это возможно. Явное определение лучше чем неявное в силу того что потом не потребуется изменение формата если вводить специфику замен материалов конкретных брашей на конкретных картах. Материалы позволяют заменять текстуры на всех картах (учитывая видимость файловой структуры), на конкретных брашах, на моделях (у моделей свой набор отдельных текстур), на спрайтах. Браши заменяются по их id и face_id, спрайты по entity_id, модели по entity_id и texture_name. Например можно на конкретной карте подменить в конкретном месте спрайт специальным искажающим шейдером. Материалы могут перекрывать режим отрисовки (Render Mode) на свой собственный, в силу того что каким-то шейдерным эффектам это не нужно.

Ограничения PBR

Желательно иметь оба подхода Metallic/Roughness и Specular/Glossiness так как оба имеют свои преимущества и недостатки, из важного:

The F0 for common dielectric materials is typically set to 0.04 (linear) 4% reflective. In the metal/roughness workflow, this value is hardcoded in the shader at this 4% value. A by product of using the metal/roughness workflow is that it can produce a white edge artifact as shown in figure 17. We are discussing the metallic workflow, but this issue also appears with the specular/glossiness workflow as well. However, it is not nearly as visible because the effect is reversed i.e. there is a black fringe instead of white as shown in figure 18 Подробнее здесь.

Хранение текстур

Есть два пути как можно работать с серыми картами материалов:

Держать карты в разных файлах как было написано выше.

Упаковать поканально, то есть одна текстура в красном канале, другая в зелёном, третья в синем, четвёртая в альфе. Это экономит память, но добавляет работы людям и усложняет шейдер. Если использовать этот подход нужно учитывать что в BC3 красный канал более артефачит, поэтому для нормалей обычно делают swizzling то есть перемещают его в альфаканал, BC5 это делает автоматически, но как понимаю не бесплатно, как в BC7 с этим пока ещё не понял.

Формат

Это общий пример того как может выглядеть описание материала, оно не полное. JSON для примера.

[
{
    "shader": "general-Metallic-Roughness-workflow.glsl",
    "for": "name_texture",
    "workflow": {
        "basecolor_map": "path",
        "normal_map": "path",
        "metal_map": "path",
        "roughness_map": "path",
        "detail_map": "path",
        "metalic": 0.5,
        "smoothness": 0.5,
        "normal_intensity": 0.5,
        "emission_color": { "R": 255, "G": 255, "B": 255 },
        "emission_intensity": 0.5,
    },
    "options": {
        "force_size": { "x": 1, "y": 1 },
        "force_offset": { "x": 0, "y": 0 },
        "force_render_mode": "normal",
    },
},
]

Для выбора подхода есть ещё вариант делать один шейдер, где внутри шейдера указывать какой подход (workflow) используется (выбирается режим, типа "workflow": WOKFLOW_MODE_METALLIC), вместо двух шейдеров как сейчас (general-Metallic-Roughness-workflow.glsl и general-Specular-Glossiness-workflow.glsl), но я не знаю как оптимальнее с точки зрения производительности и потребления памяти, чище кажется раздельно.

Спрайты

Спрайты тоже можно расширить — увеличить размер и частоту кадров (уплавнить через SVP и RIFE). Для увеличения размера и частоты надо ещё сами энтити патчить в карте, а точнее параметры framerate и scale у каждой. Для этого в материале спрайта указывается параметры "framerate_multiplier" "scale_multiplier", они задаются целочисленные, то есть было 10 кадров у спрайта, стало 20, значит множитель 2, сделали 60 кадров значит множитель 6, дальше этот "framerate_multiplier" множится на все энтити с этим именем спрайта к значению параметра framerate у энтити, так чтобы анимация была той же самой просто плавнее. У размера похожая логика, увеличили размер вдвое значит "scale_multiplier" 2 (если мы просто увеличим вдвое текстуру, то спрайт на карте вдвое большего размера станет). Спрайты хранятся как обычные текстуры, в случае с анимацией в конце постфикс _num где num это порядковый номер кадра. В материале указывается режим анимации. Материал может и не содержать анимацию вовсе, иметь несколько текстур и быть задан специальный шейдер с процедурной анимацией.

Окружение (и небо)

В оригинале окружение состоит из 6 отдельных текстур (каждая на сторону), формат: texnameside.tga (24-бит) или texnameside.bmp (8-бит). Где side принимает один из возможных вариантов: bk, dn, ft, lf, rt, up. Можно взять исходные текстуры, увеличить и попробовать сделать их в HDRI руками, банально задав разное свечение для неба, земли и солнца, сымитировав настоящий HDR. В таком случае формат может быть .HDR (RGBE/Radiance HDR) или .EXR (OpenEXR), в обоих случаях это один файл на все стороны, говорят с последним проще работать в плане редактирования и возможностей и думаю лучше его взять ибо готовых решений для последнего больше. Ещё можно хранить в DDS или KTX2 в формате сжатия BC6H который предназначен для HDR. Требуется более глубокое изучение вопроса в том как эффективно хранить HDR. Для каждого неба свой mat файл с параметрами ("tint_color", "lux", "rotation"). Таким образом через HDRI можно влиять на освещение карты (там где материал SKY) чтобы оно идеально ложилось под атмосферу окружения. Данный подход много где успешно применяется.

SNMetamorph commented 3 years ago

wadname.wad тупо аналог WAD файла, для совместимости и удобства замены существующих текстур.

Думаю, вместо этого лучше сделать папку pbr_replacements/wadname внутри которой уже будут текстуры с такими же именами, как в самом WAD-файле

0x4E69676874466F78 commented 3 years ago

@SNMetamorph

wadname.wad тупо аналог WAD файла, для совместимости и удобства замены существующих текстур.

Думаю, вместо этого лучше сделать папку pbr_replacements/wadname внутри которой уже будут текстуры с такими же именами, как в самом WAD-файле

Так это и подразумевается, внутри pbr_replacements/wadname.wad/ будут лежать текстуры из вада wadname.wad. А что касается убирания .wad из имени папки, дело в том что wadname без .wad потенциально может создать конфликтную ситуацию когда название WAD файла в каком-то из модов может оказаться одним из названием других папок (maps, models, sprites, gfx) что приведёт к замусориванию структуры или конфликту материалов что придётся изворачиваться. Далеко ходить не надо, valve/pbr_replacements/gfx/ уже пересекается с gfx.wad но это безобидное пересечение так как оно в плане шрифтов (но не неба-окружения) вроде повторяет valve/gfx/ но с другим может оказаться не так.

0x4E69676874466F78 commented 3 years ago

@SNMetamorph спс, переписал эту строчку чтобы не было разночтений.

0x4E69676874466F78 commented 3 years ago

Надо ещё подумать над тем как патчить энтити света, добавлять новые, в плане того где и как это описывать.

0x4E69676874466F78 commented 3 years ago

И решить вопрос чтобы можно было распространять данные об освещении отдельно от PBR-текстур чтобы можно было не качать жирный PAK/ZIP с текстурами если хочется поиграть с ванильными текстурами.

w23 commented 2 years ago

А detail map надо? Легко добавить теперь.

0x4E69676874466F78 commented 2 years ago

@w23 всё взвесив думаю сейчас нет, в самый последний момент можно если время останется. Самая крупная модификация использующая их Day of Defeat даже не имеет бранча сдк (я не нашёл). В контексте PBR для той же халфы по хорошему одной текстуры поверх basecolor мало, нужно всю пачку (с припиской _detail) чтобы были микроповерхности со своей реакцией на свет, но пока у нас 1280х720 этого даже разглядеть толком не получится. Лучше это время потратить на вынос UI на отдельный слой а то на HDR-патче текст выжигающий.

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

w23 / xash3d-fwgs

Варианты улучшения графики / Graphics enhancement variants #39

Список задач

Наследие/Legacy

Улучшенные текстуры

Структура файлов

Возможность хранить файлы в архивах

Материалы

Общее

Ограничения PBR

Хранение текстур

Формат

Спрайты

Окружение (и небо)