Скриптовые шейдеры

Редактируя любую модель, многие в свойствах поверхностей замечали графу shader, в которой указывается нечто вроде models/model или подобные. Как правило, эти шейдеры упакованы в shaders.xr и shaders_xrlc.xr, которые представляют собой своеобразную базу данных шейдеров, собранных по определенным шаблонам.

Но кроме этих баз данных есть еще и скриптовые шейдеры, которые имеют приоритет перед теми шейдерами, что упакованы в *.xr. Это файлы, имеющие расширение .s и лежащие в папках соответствующих рендеров. Вычислить правильное название шейдера в БД и шейдерного скрипта .s можно очень просто - для примера, если у нас в БД шейдер находится в model/selflight, то имя шейдера должно быть model_selflight.s, если details/blend, то скрипт шейдера будет, соответственно, details_blend.s . Не так уж сложно.

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

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

По некоторым причинам я считаю что для модостроителей шейдерные скрипты являются более предпочтительными, чем распространение своих шейдерных модов в виде модифицированной .xr-БД. Причины в основном две: Во-первых скриптовые шейдеры предоставляют бОльшие возможности для полета фантазии, а во-вторых распространение шейдерных модов в виде скриптовых шейдеров все же делает меньше вероятность конфликта модов, так как разные шейдеры будут в разных файлах, а не все вместе в одном хитром и трудноредактируемом, и, что самое плохое, - труднообъединяемом файле. Поэтому далее мы рассмотрим скриптовые шейдеры.

Что собой представляют шейдерные скрипты? Это обычные скрипты на lua, которые являются своеобразным языком для того чтобы объяснить движку, какие загружать текстуры и какие подключать шейдеры из наличествующих .ps и .vs файлов.

Для тех кто воспрял духом сразу скажу, что несмотря на то, что шейдерные скрипты написаны на языке, который используется в игровых скриптах, это все-таки не одно и то же. Во-первых шейдерные скрипты выполняются при загрузке уровня всего один раз (в фазу загрузки "загрузка шейдеров"), поэтому на отрисовку в реальном времени влиять неспособны, и кроме того, к игровым скриптам скриптовые шейдеры доступа не имеют.

Вот, для примера, содержимое простейшего скриптового шейдера:

function normal( shader, t_base, t_second, t_detail )

    shader:begin( "effects_gradient", "effects_gradient_p" )

end

Разберем его по косточкам:

• function normal - объявление стандартной функции шейдерного скрипта. В некоторых шейдерах есть еще функции l_spot, l_point и l_special аналогичного содержания, но явно просчитывающие поведение этого шейдера в условиях освещения

• shader - вероятнее всего идентификатор шейдера в игре, содержимое этой переменной обычно представляет собой текстовую строку вроде "models_selflight" или "models/selflight".
• t_base - путь к текстуре, которую следует выводить с помощью этого шейдера
• t_second, t_detail - пути к другим текстурам, пока назначение их неизвестно.

• shader:begin( "effects_gradient", "effects_gradient_p" ) - святая святых шейдера. Если точнее - создание объекта шейдера как такового.

effects_gradient - имя .vs файла используемого в этом шейдере

effects_gradient_p - имя .ps файла соответственно.

После этой строки могут быть такие строки (они необязательны)

• : blend ( true, blend.srcalpha, blend.one ) - обработка текстур, например, полупрозрачные текстуры без применения этой строки будут выглядеть непрозрачными черными в прозрачных местах. Эти методы блендинга соответствуют переключателю в сдк, где варианты ALPHA-ADD, BLEND, SET и так далее. На примере выше блендинг соответствует положению ALPHA-ADD.

true - может быть false - включение обработки текстур, то есть true - обработка включена, false, соответственно, выключена.

blend.srcalpha, blend.one - соответственно, методы блендинга, могут быть:

blend.one
blend.zero
null

Также вот таблица, по которой можно выбрать остальные параметры блендинга, выбирая в таблице по порядку слева направо:

		src		color
inv		dest		alpha

то есть:

blend.srccolor
blend.invsrccolor
blend.destcolor
blend.invdestcolor
blend.srcalpha
blend.invsrcalpha
blend.destalpha
blend.invdestalpha

где inv - инверсия, color - цвет, alpha - альфа (коэффициент прозрачности), src - параметр берется до шейдера, dest - параметр берется после шейдера.

• : sorting ( 3, false ) - порядок отрисовки поверхности по отношению к самому объекту, частью которого является поверхность.

3 - цифра порядка отрисовки, где 1 - за объектом, 2 - на уровне с объектом, 3 - спереди объекта (ближе к актору). Как правило, при тройке шейдируемая поверхность будет отрисовываться поверх всего, в том числе и оружия.

false - соответствует галочке "srict sorting" в сдк. Пока назначение неизвестно.

• : aref ( false, 2 ) - альфа-референс объекта - оператор, переключающий многобитную альфу текстуры в однобитную.

false - включение/выключение данной функции.

2 - сам альфа-референс объекта

• : zb ( false, false ) - манипуляции с z-буфером, где первый аргумент соответствует галке z-test в сдк, второй - галке z-write.

• : fog ( false ) - действие представляет собой превращение текстуры в черно-белую и применение к ней функции calc_fogging в common.h шейдеров соответствующего рендера.

• : emissive ( true ) - применяется в источниках освещения.

• : distort ( true ) - представляет из себя механизм искажений, аналогичный эффекту искажающегося воздуха в некоторых аномалиях, а также "линза" в главном меню над кнопками.

• : wmark (true) - используется в валлмарках

---

• shader : sampler( "s_base" ) - создание буфера для помещения туда текстуры. Аргумент представляет собой идентификатор, получаемый ps и vs шейдерами, где будет фигурировать как predefined-переменная s_base.

Перечисленные ниже параметры могут быть только ниже сэмплерной строки!

• : texture ( t_base ) - помещение в вышеобъявленный буфер текстуры. Аргумент этой ф-ции представляет собой путь к текстуре, так что вполне можно указать нечто вроде

: texture  ( "fx\\fx_sun" )

чтобы в буфер воткнуть текстуру gamedata/textures/fx/fx_sun.dds

• : clamp() - соответствует галке Texture Clamp в сдк. Википедия отвечает на этот вопрос весьма туманно.

• : project() - используется в шейдере отрисовки неточечного источника света, и предположительно используется для проектирвоания текстуры сэмплера на те объекты которые находятся в пределах сектора сферы.

• : wrap () - Википедия отвечает на этот вопрос не менее туманно, чем в примере выше.

Ниже представлены еще три оператора, используемые с сэмплером, назначение которых неизвестно.

• : f_linear ()

• : f_anisotropic ()

• : f_none ()

---

Также в папке с шейдерами лежат еще файлы .s (именно такого имени - точка и эс), которые являются для всех *.s-файлов своеобразными заголовочными файлами, функции из файла .s доступны из файлов *.s . На данный момент там имеются функции printf, и закомментированные во втором рендере ф-ции l_point и l_spot, которые отвечают за создание точечного и неточечного источников света соответственно.

Статья создана участником cjayho