Я принял решение отказаться от кутришной системы шейдеров, по нескольким причинам. Во первых оно малоинформаивное для левел-дизайнера, поскольку базируется на понимании функционала OpenGL, в области мультитекстуринга. К тому же подавляющее большинство настроек кутришных шейдеров, попросту неактуальны. Ну вот например вместо deformVertexes куда логичнее и надёжнее сделать настоящую анимацию у студиомодели. А вращение и деформация текстур может осуществляться прямо в GLSL-шейдере, так сказать с учётом реальных потребностей.
Во вторых, эта система плотно завязана на мультитекстуринг, что с учётом наличия GLSL-шейдеров будет попросту неактуально в новой системе.
Таким образом встал вопрос о разработке новой системы материалов, которая могла бы обеспечить левел-дизайнеру широкие возможности и низкий порог вхождения, т.е. в идеале, чтобы можно было работать даже на ощупь, без чтения документации. Разумеется, у меня есть набросок такой системы (пока что только на бумаге) и я вам её сейчас покажу. Ваша задача - придумать как улучшить мою концепцию (если вы считаете, что она в этом нуждается), либо предложить свою, более удобную, на ваш взгляд. В конечном итоге в ксаш-мод попадёт именно та концепция материалов\шейдеров, которая понравится большинству. Итак, поехали. Вот моя концепция:
Описание материалов является генеричной частью системы и не привязано к конкретным текстурам. Описание хранится в файле matdesc.txt. Вот пример такого файла (можете придумать свой вариант)
C++ Source Code:
1
"wood"
2
{
3
program_diffuse "glsl/generic_diffuse"// diffuse default program
4
program_light "glsl/generic_light"// diffuse light program
5
decals "shot_wood"// group of decals
6
gibs "aurora/gib_wood.aur"// spawn effects when bullet hit the material
7
density "10"// phys parameter - density of material
8
friction "0.9"// phys parameter - material friction
9
hitsound "shot_wood"
10
}
11
12
"glass"
13
{
14
program_diffuse "glsl/generic_glass"// diffuse default program
15
program_light ""// glass not required lighting
16
decals "shot_glass"// group of decals
17
gibs "aurora/gib_glass.aur"// spawn effects when bullet hit the material
18
density "15"// phys parameter - density of material
19
friction "0.7"// phys parameter - material friction
20
hitsound "shot_glass"
21
}
22
23
"metal"
24
{
25
program_diffuse "glsl/generic_diffuse"// diffuse default program
26
program_light "glsl/generic_light"// diffuse light program
27
decals "shot_metal"// group of decals
28
gibs "aurora/gib_metal.aur"// spawn effects when bullet hit the material
29
density "30"// phys parameter - density of material
30
friction "0.7"// phys parameter - material friction
31
hitsound "shot_metal"
32
}
33
34
"ground"
35
{
36
program_diffuse "glsl/terrain_diffuse"// diffuse default program
37
program_light "glsl/terrain_light"// diffuse light program
38
decals "shot_ground"// group of decals
39
gibs "aurora/gib_grnd.aur"// spawn effects when bullet hit the material
40
density "3"// phys parameter - density of material
41
friction "4.5"// phys parameter - material friction
42
hitsound "shot_grnd"
43
}
44
45
"skin"// e.g for studiomodels
46
{
47
program_diffuse "glsl/subsurf_diffuse"// diffuse program with subsurface scattering
48
program_light "glsl/subsurf_light"// diffuse light program
49
decals "shot_blood"// group of decals
50
gibs "aurora/gib_blood.aur"// spawn effects when bullet hit the material
51
density "4"// phys parameter - density of material
52
friction "1.8"// phys parameter - material friction
gibs "aurora/gib_glass.aur"// spawn effects when bullet hit the material
61
density "15"// phys parameter - density of material
62
friction "0.7"// phys parameter - material friction
63
hitsound "shot_glass"
64
}
65
66
"decal"
67
{
68
program_diffuse "glsl/generic_decal"// diffuse default program
69
program_light ""// decal not required lighting
70
}
71
72
"mirror"
73
{
74
program_diffuse "glsl/mirror"// diffuse default program
75
program_light "glsl/generic_light"// glass not required lighting
76
decals "shot_glass"// group of decals
77
gibs "aurora/gib_glass.aur"// spawn effects when bullet hit the material
78
density "15"// phys parameter - density of material
79
friction "0.7"// phys parameter - material friction
80
hitsound "shot_glass"
81
}
Надеюсь здесь всё понятно без комментариев. Основной упор делается на то, что пользователь сможет писать и подключать новые GLSL-шейдеры без модификации кода рендерера.
Теперь посмотрим, как выглядит система сопряжения материалов с реальными текстурами. Это у нас файлик materials.txt
C++ Source Code:
1
"BCRATE02"
2
{
3
material "wood"// get descripton from matdesc.txt
4
normalmap "materials/common/bcrate02_norm"// optional. otherwise loads by postfix "_norm"
5
glossmap "materials/common/bcrate02_gloss"// optional. otherwise loads by postfix "_gloss"
6
heightmap "materials/common/bcrate02_height"// optional. otherwise loads by postfix "_height"
heightmap "materials/terrains/terra1"// optional. otherwise loads by postfix "_height"
33
layer0 "materials/terrains/rocks"
34
layer1 "materials/terrains/sand"
35
layer2 "materials/terrains/grass"
36
grass "grass_small"// name of grass group
37
}
нормалмапу, глоссмапу и хейтмапу можно указывать явным образом или же положиться на постфикс _norm, _gloss, _height (ну то есть, чтобы движок сам сформировал имя и путь).
Layer - это слои террайна. Этот момент пока не очень хорошо продуман.
grass - имя группы травы. Группы трав пока не продуманы вообще.
группы декалей ориентировочно как в параное ну или близко к тому.
Концепция, как вы понимаете предварительная, возможно будет меняться и не раз. Вносите дополнения, предлагайте полностью другие концепции, вообщем вам слово.
И помните - вам потом с этим работать. Так что думайте сейчас.
Дядя Миша писал: Ну вот например вместо deformVertexes куда логичнее и надёжнее сделать настоящую анимацию у студиомодели.
Когда я говорил, что вместо фнук_ротатинга (недосягаемого для игрока) логичнее и надёжнее сделать настоящую анимацию у студиомодели (при этом компилятор моделей волатилы умел генерить простые анимации автоматически), все смеялись и крутили пальцем у виска. И говорили - "а кто будет эти анимации делать? Кто умеет их делать? Зачем нам делать модель, это ж из хаммера вылезать надо в какую-то милку?"
Думаете, я забыл? Я ничего и никому не забываю.
Добавлено 18-04-2014 в 15:37:
Кстати, сделай-ка анимацию "педерастов, ползущих по трубам" в любом редакторе. Только без читерства в виде какого-нибудь MaxScript.
thambs писал: а у меня одно пожелание: что бы можно было писать не только
Так создай тип материала, и присваивай его любой текстуре. Тот же OUT_... содержит весьма разношерстные текстуры. Но можно впринципе сделать препроцессор для таких случаев:
#OUT_
{
material "ground"
}
Хотя само слово material слишком длинное, можно и упростить
#OUT_ ("ground") или MYTEXTURE ("ground")
{
}
Кстати, насколько система чувствительна к регистру? И как обстоят дела с материалами студиомоделей и спрайтов?
__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!
XaeroX писал: Когда я говорил, что вместо фнук_ротатинга (недосягаемого для игрока) логичнее и надёжнее сделать настоящую анимацию у студиомодели
Какая связь с deformVertexes?
Я намекаю, что эта фишка деформирует только видимые полигоны, да еще и на CPU. Причём реально её использовали ровно в двух случаях - для раскачивания флагов и для иммитации движения партиклей (которых в ку3 таки не было).
Цитата:
XaeroX писал: Кстати, сделай-ка анимацию "педерастов, ползущих по трубам" в любом редакторе
Вот веришь-нет, я их только в ку3 и видел на паре карт. Больше этот эффект никуда не приткнешь, он просто нафиг не нужен.
Цитата:
thambs писал: со всей вытекающей автоматикой
Нет, такое опасно очень. Но дефолтные кейсы будут.
Цитата:
thambs писал: ты что ли хочешь автоматическое размещение динамичного света добавить?
Очевидно же, что шейдер считающий освещение с лайтмапой и освещение от проекционных источников - это два разных шейдера.
Две разных модели освещения.
Цитата:
FiEctro писал: Кстати, насколько система чувствительна к регистру?
Какая система? Я ни строчки кода не написал еще, я просто синтаксис придумал.
XaeroX писал: Я почему-то был уверен, что ты именно так и ответишь.
Чтобы это понять мне тоже понадобилось немало времени
Ну вот реально, возьмём ку3 - всё блестит, переливается, моргает, куда-то бежит. Возьмём любую другую игру на движке ку3 - ничего не моргает, не блестит, большинство шейдеров дефолтные. С таким подходом, действительно неважно как у нас вентилятор сделан - брашем или крутящейся текстуркой. Ну ок, давай подробно разберём все возможности ку3 шейдеров, чтобы наглядно убедиться, что сейчас они не имеют значения.
deformVertexes. Значения autosprite, text, bulge (по трубам которые), wave, normal, move. Autosprite - это чтобы еденичный полигон уровня превратить в спрайт, вкомпиленный в карту. Фларесы или там звезды\луну делать.
С успехом заменяется env_sprite. Просто в ку3 демонстративно отказались от привычных спрайтов по непонятным причинам. Text - я ни разу не видел, чтобы юзали. Эти, по трубам - тоже нигде не юзается, кроме самой кутри.
Только там вместо негеев по трубам какое-то зло ползало, дьявол что ли.
wave - из еденичного полигона делать флаги. Опять таки, непросто делать флаги на вертексной анимации, на скелетной никаких проблем. Normal - деформация по нормалям. Помоему для glowshell юзалось. Move - для симуляции партиклей. Дико тормозная вещь. Я видел как через нее делали дождь или снег. Уж лучше бы не делали. Халфовский дождь через лучи и то приятнее смотрелся.
Эффекты для стадий: восемь анимированных текстур без возможности переключения, ну несерьезно. В первокваке и то 10\10. Видео-текстуры.
В ксаш-моде они и так есть.
rgbGen. Параметры: wave, const, identity, entity, oneminusentity, vertex, exactVertex, lightingDiffuse, oneminusVertex. Волны - вот чисто для тех брашевых флагов. entity - аналог krenderTransColor. Наиболее часто употребляемые - vertex и lightingDiffuse. И то за счёт наличия лайтгрида.
Опять таки - в студиомодельках освещение применяется автоматически, можно поставить флаг фуллбрайт.
alphaGen опускаю, там тоже самое.
texgen - environment, lightmap, base, vector. Ну первый, это хром-текстуры, второй и третий вообще не должны забивать голову маппера, последний - для самых умных и как правило применялся к небу. Но им еденицы могли пользоваться.
texmod - turb, scale, scroll, stretch, transform, rotate и entityTranslate.
turb - аналог закрученной воды из халфы
scale - позволял растянуть текстуру, опять таки годилось только для неба.
scroll - неконтролируемая текстура куда-то скролится, конвейер в этом отношении удобнее.
stretch - растягивание через переодическую функцию. В основном только на кутришных картах и использовалось.
transform - опять таки для самых умных и применительно к небу, поскольку на обычном полигоне текстуру можно в редакторе вертеть.
rotate - кстати в халфе не работает толком, из-за отрицательных текс-кордов по умолчанию. Приходится текстуру наносить хитрым образом, чтобы оно наконец начало нормально вращаться. В ку3 координаты в диапазоне 0-1 и там этой проблемы нету.
entityTranslate - некий аналог конвейера из халфы, однако не юзается и даже не подключен толком.
Вообщем подводя итоги можно сказать, что оно нашло применение только в моде Жэки, который был уверен, что если всё моргает, светится, переливается и крутится, то мод автоматически становится хорошим.
Поэтому я полагаю, что система материалов должна в первую очередь обеспечить работу с бампом, параллаксом, зеркалами, вообщем более юзабельными настройками, нежели крутящиеся текстуры.
Хотя, повторюсь, я тоже пришел к этому соображению далеко не сразу, а буквально пару месяцев назад.
А, ну хорошо. Хозяин - барин.
Для тех, кому надо, чтобы всё блестело и переливалось - будет волатила. Я-то от шейдерной системы отказываться нипочём не намерен. Это после того, как я в джекхаммере сделал для них визуальный редактор?
а торнадо нормальное как то получится сделать? ясно ж, что что даже в несколько слоёв мэпперским способом оно как говно выглядеть так и будет, а если там как ни будь несколько текстур с разными скоростями закрутить-продеформировать, то может получиться как настоящий циклон. меня вот эти шейдеры все именно в таком применении интересуют.
Ну вообще-то GLSL представляет заведомо больше возможностей, нежели любые кутри шейдеры. Надеюсь это понятно. Моя самая главная идея в том, чтобы была возможность эти шейдеры подключать, не меняя ничего в коде.
Дядя Миша писал: Ну вообще-то GLSL представляет заведомо больше возможностей, нежели любые кутри шейдеры
GLSL - это ч0рный ящик. Ты целиком попадаешь в зависимость от видеодрайвера. Если шейдер ку3 рисует что-то неправильно, ты всегда можешь полезть в код и найти причину. А в случае с GLSL адекватная отладка невозможна. Не говоря уже о том, что все процессоры ведут себя примерно одинаково, а каждая отдельно взятая видимокарта - по-своему.
Всё очень классно! Может быть ещё сделать несколько файлов типа matdesc_de_dust2.txt для удобного деления. И ещё надо для звуков файлы, потому-что hitsound "shot_flesh" ничего не говорит о характеристиках.