HLFX.Ru Forum Страницы (2): [1] 2 »
Показать все 29 сообщений этой темы на одной странице

HLFX.Ru Forum (https://hlfx.ru/forum/index.php)
- XashXT (https://hlfx.ru/forum/forumdisplay.php?forumid=30)
-- Система материалов для нового рендерера (https://hlfx.ru/forum/showthread.php?threadid=4366)


Отправлено Дядя Миша 18-04-2014 в 07:59:

Система материалов для нового рендерера

Я принял решение отказаться от кутришной системы шейдеров, по нескольким причинам. Во первых оно малоинформаивное для левел-дизайнера, поскольку базируется на понимании функционала 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
53
  hitsound		"shot_flesh"
54
}
55
 
56
"light"
57
{
58
  program_diffuse	"glsl/generic_light"	// emitting surface
59
  decals		"shot_glass"		// group of decals
60
  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"
7
  detailmap		"gfx/detail/dt_wood"		// detail map always specified explicitly
8
  glossExp		"16"				// gloss exponent
9
  POMScale		"30"				// parallax height
10
  POMSteps		"25"				// parallax quality
11
  detailScale	"8 8"				// detail scale
12
}
13
 
14
"MIRROR"
15
{
16
  material		"mirror"				// get descripton from matdesc.txt
17
  normalmap		"materials/common/generic2_norm"	// optional.
18
  detailmap		"gfx/detail/dt_metal"		// detail map always specified explicitly
19
  detailScale	"8 8"				// detail scale
20
}
21
 
22
"GLASS_MED"
23
{
24
  material		"glass"				// get descripton from matdesc.txt
25
  detailmap		"gfx/detail/dt_glass"		// detail map always specified explicitly
26
  detailScale	"8 8"				// detail scale
27
}
28
 
29
"OUT_DIRT1"
30
{
31
  material		"ground"
32
  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 - имя группы травы. Группы трав пока не продуманы вообще.
группы декалей ориентировочно как в параное ну или близко к тому.

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

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 18-04-2014 в 08:37:

Цитата:
Дядя Миша писал:
Ну вот например вместо deformVertexes куда логичнее и надёжнее сделать настоящую анимацию у студиомодели.


Когда я говорил, что вместо фнук_ротатинга (недосягаемого для игрока) логичнее и надёжнее сделать настоящую анимацию у студиомодели (при этом компилятор моделей волатилы умел генерить простые анимации автоматически), все смеялись и крутили пальцем у виска. И говорили - "а кто будет эти анимации делать? Кто умеет их делать? Зачем нам делать модель, это ж из хаммера вылезать надо в какую-то милку?"
Думаете, я забыл? Я ничего и никому не забываю.

Добавлено 18-04-2014 в 15:37:

Кстати, сделай-ка анимацию "педерастов, ползущих по трубам" в любом редакторе. Только без читерства в виде какого-нибудь MaxScript.

__________________

xaerox on Vivino


Отправлено thambs 18-04-2014 в 12:01:

а у меня одно пожелание: что бы можно было писать не только

C++ Source Code:
"OUT_DIRT1"

но и
C++ Source Code:
"OUT_*"

со всей вытекающей автоматикой
C++ Source Code:
"light"

ты что ли хочешь автоматическое размещение динамичного света добавить?

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено FiEctro 18-04-2014 в 12:55:

Цитата:
thambs писал:
а у меня одно пожелание: что бы можно было писать не только


Так создай тип материала, и присваивай его любой текстуре. Тот же OUT_... содержит весьма разношерстные текстуры. Но можно впринципе сделать препроцессор для таких случаев:

#OUT_
{
material "ground"
}

Хотя само слово material слишком длинное, можно и упростить

#OUT_ ("ground") или MYTEXTURE ("ground")
{
}

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

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!


Отправлено Дядя Миша 18-04-2014 в 13:29:

Цитата:
XaeroX писал:
Когда я говорил, что вместо фнук_ротатинга (недосягаемого для игрока) логичнее и надёжнее сделать настоящую анимацию у студиомодели

Какая связь с deformVertexes?
Я намекаю, что эта фишка деформирует только видимые полигоны, да еще и на CPU. Причём реально её использовали ровно в двух случаях - для раскачивания флагов и для иммитации движения партиклей (которых в ку3 таки не было).
Цитата:
XaeroX писал:
Кстати, сделай-ка анимацию "педерастов, ползущих по трубам" в любом редакторе

Вот веришь-нет, я их только в ку3 и видел на паре карт. Больше этот эффект никуда не приткнешь, он просто нафиг не нужен.
Цитата:
thambs писал:
со всей вытекающей автоматикой

Нет, такое опасно очень. Но дефолтные кейсы будут.
Цитата:
thambs писал:
ты что ли хочешь автоматическое размещение динамичного света добавить?

Очевидно же, что шейдер считающий освещение с лайтмапой и освещение от проекционных источников - это два разных шейдера.
Две разных модели освещения.
Цитата:
FiEctro писал:
Кстати, насколько система чувствительна к регистру?

Какая система? Я ни строчки кода не написал еще, я просто синтаксис придумал.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 18-04-2014 в 13:35:

Цитата:
Дядя Миша писал:
Больше этот эффект никуда не приткнешь, он просто нафиг не нужен.

Я почему-то был уверен, что ты именно так и ответишь.
Ну да ладно.

Кстати, в Wolfram он был.

__________________

xaerox on Vivino


Отправлено Дядя Миша 18-04-2014 в 14:10:

Цитата:
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 - некий аналог конвейера из халфы, однако не юзается и даже не подключен толком.
Вообщем подводя итоги можно сказать, что оно нашло применение только в моде Жэки, который был уверен, что если всё моргает, светится, переливается и крутится, то мод автоматически становится хорошим.
Поэтому я полагаю, что система материалов должна в первую очередь обеспечить работу с бампом, параллаксом, зеркалами, вообщем более юзабельными настройками, нежели крутящиеся текстуры.
Хотя, повторюсь, я тоже пришел к этому соображению далеко не сразу, а буквально пару месяцев назад.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 18-04-2014 в 14:21:

А, ну хорошо. Хозяин - барин.
Для тех, кому надо, чтобы всё блестело и переливалось - будет волатила. Я-то от шейдерной системы отказываться нипочём не намерен. Это после того, как я в джекхаммере сделал для них визуальный редактор?

__________________

xaerox on Vivino


Отправлено thambs 18-04-2014 в 14:53:

Дядя Миша

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

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Дядя Миша 18-04-2014 в 15:00:

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

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 18-04-2014 в 15:59:

Цитата:
Дядя Миша писал:
Ну вообще-то GLSL представляет заведомо больше возможностей, нежели любые кутри шейдеры

GLSL - это ч0рный ящик. Ты целиком попадаешь в зависимость от видеодрайвера. Если шейдер ку3 рисует что-то неправильно, ты всегда можешь полезть в код и найти причину. А в случае с GLSL адекватная отладка невозможна. Не говоря уже о том, что все процессоры ведут себя примерно одинаково, а каждая отдельно взятая видимокарта - по-своему.

__________________

xaerox on Vivino


Отправлено Дядя Миша 20-04-2014 в 07:35:

А здесь вообще всё печально

Ни у кого нету соображений по теме. Ну ок, будете пользоваться тем, шо дадут.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено ILZM 20-04-2014 в 16:21:

Всё очень классно! Может быть ещё сделать несколько файлов типа matdesc_de_dust2.txt для удобного деления. И ещё надо для звуков файлы, потому-что hitsound "shot_flesh" ничего не говорит о характеристиках.


Отправлено KiQ 20-04-2014 в 17:27:

а для моделей та же система?

__________________
-Brain is dead-


Отправлено Дядя Миша 20-04-2014 в 18:32:

для моделей, брашей и декалей. А спрайты будут классически рендерится.
Ибо в изменениях не нуждаются.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Временная зона GMT. Текущее время 13:15. Страницы (2): [1] 2 »
Показать все 29 сообщений этой темы на одной странице

На основе vBulletin версии 2.3.0
Авторское право © Jelsoft Enterprises Limited 2000 - 2002.
Дизайн и программирование: Crystice Softworks © 2005 - 2024