Скриптовые шейдеры — различия между версиями
Материал из S.T.A.L.K.E.R. Inside Wiki
(Отмена правки 13679, сделанной участником 91.217.2.224 (обс.)) |
|||
(не показаны 14 промежуточные версии 7 участников) | |||
Строка 1: | Строка 1: | ||
Редактируя любую модель, многие в свойствах поверхностей замечали графу shader, в которой указывается нечто вроде models/model или подобные. | Редактируя любую модель, многие в свойствах поверхностей замечали графу shader, в которой указывается нечто вроде models/model или подобные. | ||
− | Как правило эти шейдеры упакованы в shaders.xr и shaders_xrlc. | + | Как правило, эти шейдеры упакованы в '''shaders.xr''' и '''shaders_xrlc.x'''r, которые представляют собой своеобразную базу данных шейдеров, собранных по определенным шаблонам. |
− | Но кроме этих баз данных есть еще и скриптовые шейдеры, которые имеют приоритет перед теми шейдерами что упакованы в *.xr. Это файлы, имеющие расширение .s и лежащие в папках соответствующих рендеров. Вычислить правильное название шейдера в БД и шейдерного скрипта .s можно очень просто - для примера если у нас в БД шейдер находится в model/selflight, то имя шейдера должно быть model_selflight.s, если details/blend, то скрипт шейдера будет соответственно details_blend.s . Не так уж сложно. | + | Но кроме этих баз данных есть еще и скриптовые шейдеры, которые имеют приоритет перед теми шейдерами, что упакованы в *.xr. Это файлы, имеющие расширение .s и лежащие в папках соответствующих рендеров. Вычислить правильное название шейдера в БД и шейдерного скрипта '''.s''' можно очень просто - для примера, если у нас в БД шейдер находится в '''model/selflight''', то имя шейдера должно быть '''model_selflight.s''', если details/blend, то скрипт шейдера будет, соответственно, '''details_blend.s'''. Не так уж сложно. |
− | Вообще база данных с шейдерами была выдумана не потому что авторам сталкера очень нравилось плодить экземпляры труднораспарсиваемых форматов, а причина более банальна - чтобы увеличить скорость загрузки игры сэкономив за счет активности жесткого диска | + | Вообще база данных с шейдерами была выдумана не потому что авторам сталкера очень нравилось плодить экземпляры труднораспарсиваемых форматов, а причина более банальна - чтобы увеличить скорость загрузки игры, сэкономив за счет активности жесткого диска при открытии файлов скриптовых шейдеров в папке соответствующего рендера. Плюс к тому в этом случае уменьшается количество шейдерных файлов, что как минимум вдвое уменьшает вероятность ошибки - при условии двух рендеров эта экономия получается за счет тех шейдеров, которые являются общими для обоих рендеров. Плюс к тому вероятность ошибки еще более уменьшается тем, что базы данных редактируются в сдк, а сдк эти базы данных представляет в виде всевозможных галочек и полей ввода, поэтому ошибка может быть только во вводимых данных, но не в скриптовом коде шейдеров, который, вероятнее всего, генерируется во время загрузки игры. |
− | Скриптовые шейдеры используются же в основном только в тех случаях когда их код отличается для разных рендеров. | + | Скриптовые шейдеры используются же в основном только в тех случаях, когда их код отличается для разных рендеров. |
− | По некоторым причинам я считаю что для модостроителей шейдерные скрипты являются более предпочтительными, чем распространение своих шейдерных модов в виде модифицированной .xr-БД. Причины в основном две - | + | По некоторым причинам я считаю что для модостроителей шейдерные скрипты являются более предпочтительными, чем распространение своих шейдерных модов в виде модифицированной .xr-БД. Причины в основном две: Во-первых скриптовые шейдеры предоставляют бОльшие возможности для полета фантазии, а во-вторых распространение шейдерных модов в виде скриптовых шейдеров все же делает меньше вероятность конфликта модов, так как разные шейдеры будут в разных файлах, а не все вместе в одном хитром и трудноредактируемом, и, что самое плохое, - труднообъединяемом файле. Поэтому далее мы рассмотрим скриптовые шейдеры. |
− | Что собой представляют шейдерные скрипты? Это обычные скрипты на lua, | + | Что собой представляют шейдерные скрипты? Это обычные скрипты на lua, которые являются своеобразным языком для того чтобы объяснить движку, какие загружать текстуры и какие подключать шейдеры из наличествующих .ps и .vs файлов. |
− | : ''Для тех кто воспрял духом сразу скажу что несмотря на то, что шейдерные скрипты написаны на языке, который используется в игровых скриптах, это все-таки не одно и то же. Во первых шейдерные скрипты выполняются при загрузке уровня всего один раз (в фазу загрузки "загрузка шейдеров"), поэтому на отрисовку в реальном времени влиять неспособны, и кроме того к игровым скриптам скриптовые шейдеры доступа не имеют.'' | + | : ''Для тех кто воспрял духом сразу скажу, что несмотря на то, что шейдерные скрипты написаны на языке, который используется в игровых скриптах, это все-таки не одно и то же. Во-первых шейдерные скрипты выполняются при загрузке уровня всего один раз (в фазу загрузки "загрузка шейдеров"), поэтому на отрисовку в реальном времени влиять неспособны, и кроме того, к игровым скриптам скриптовые шейдеры доступа не имеют.'' |
− | Вот для примера содержимое простейшего скриптового шейдера: | + | Вот, для примера, содержимое простейшего скриптового шейдера: |
− | function normal( shader, t_base, t_second, t_detail ) | + | <lua>function normal( shader, t_base, t_second, t_detail ) |
− | + | ||
shader:begin( "effects_gradient", "effects_gradient_p" ) | shader:begin( "effects_gradient", "effects_gradient_p" ) | ||
− | + | end</lua> | |
− | end | + | |
Разберем его по косточкам: | Разберем его по косточкам: | ||
− | * '''function normal''' - объявление стандартной функции шейдерного скрипта. В некоторых шейдерах есть еще функции '''l_spot''', '''l_point''' | + | * '''function normal''' - объявление стандартной функции шейдерного скрипта. В некоторых шейдерах есть еще функции '''l_spot''', '''l_point''', '''l_special''' и '''normal_hq''' аналогичного содержания, но явно просчитывающие поведение этого шейдера в условиях освещения |
− | * '''shader''' - вероятнее всего идентификатор шейдера в игре, содержимое этой переменной представляет собой | + | * '''shader''' - вероятнее всего идентификатор шейдера в игре, содержимое этой переменной обычно представляет собой текстовую строку вроде "models_selflight" или "models/selflight". |
− | * '''t_base''' - путь к текстуре которую следует выводить с помощью этого шейдера | + | * '''t_base''' - путь к текстуре, которую следует выводить с помощью этого шейдера |
* '''t_second''', '''t_detail''' - пути к другим текстурам, пока назначение их неизвестно. | * '''t_second''', '''t_detail''' - пути к другим текстурам, пока назначение их неизвестно. | ||
Строка 38: | Строка 36: | ||
− | * ''': blend ( true, blend.srcalpha, blend.one )''' - | + | * ''': blend ( true, blend.srcalpha, blend.one )''' - настройка блендинга для текстур с альфой, например, полупрозрачные текстуры без применения этой строки будут выглядеть непрозрачными черными в прозрачных местах. Эти методы блендинга соответствуют переключателю в сдк, где варианты ALPHA-ADD, BLEND, SET и так далее. На примере выше блендинг соответствует положению ALPHA-ADD. |
− | :: '''true''' - может быть '''false''' - включение обработки текстур, | + | :: '''true''' - может быть '''false''' - включение обработки текстур, то есть true - обработка включена, false, соответственно, выключена. |
− | :: '''blend.srcalpha''', '''blend.one''' - соответственно методы блендинга, могут быть: | + | :: '''blend.srcalpha''', '''blend.one''' - соответственно, методы блендинга, могут быть: |
− | + | blend.one | |
− | + | blend.zero | |
− | + | null | |
− | + | Также вот таблица, по которой можно выбрать остальные параметры блендинга, выбирая в таблице по порядку слева направо: | |
− | + | <table style="border: 1px solid #666;" width="470px" height="60px"> | |
<tr> | <tr> | ||
− | <td> | + | <td> </td> |
<td bgcolor="#666" width="2px"></td> | <td bgcolor="#666" width="2px"></td> | ||
<td>src</td> | <td>src</td> | ||
Строка 62: | Строка 60: | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
− | <td> | + | <td>inv</td> |
<td bgcolor="#666" width="2px"></td> | <td bgcolor="#666" width="2px"></td> | ||
<td>dest</td> | <td>dest</td> | ||
Строка 70: | Строка 68: | ||
</table> | </table> | ||
− | + | то есть: | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
+ | blend.srccolor | ||
+ | blend.invsrccolor | ||
+ | blend.destcolor | ||
+ | blend.invdestcolor | ||
+ | blend.srcalpha | ||
+ | blend.invsrcalpha | ||
+ | blend.destalpha | ||
+ | blend.invdestalpha | ||
+ | : где '''inv''' - инверсия, '''color''' - цвет, '''alpha''' - альфа (коэффициент прозрачности), '''src''' - параметр берется до шейдера, '''dest''' - параметр берется после шейдера. | ||
* ''': sorting ( 3, false )''' - порядок отрисовки поверхности по отношению к самому объекту, частью которого является поверхность. | * ''': sorting ( 3, false )''' - порядок отрисовки поверхности по отношению к самому объекту, частью которого является поверхность. | ||
− | :: '''3''' - цифра порядка отрисовки, где 1 - за объектом, 2 - на уровне с объектом, 3 - спереди объекта (ближе к актору). Как правило при тройке шейдируемая поверхность будет отрисовываться поверх всего, в том числе и оружия. | + | :: '''3''' - цифра порядка отрисовки, где 1 - за объектом, 2 - на уровне с объектом, 3 - спереди объекта (ближе к актору). Как правило, при тройке шейдируемая поверхность будет отрисовываться поверх всего, в том числе и оружия. |
:: '''false''' - соответствует галочке "srict sorting" в сдк. Пока назначение неизвестно. | :: '''false''' - соответствует галочке "srict sorting" в сдк. Пока назначение неизвестно. | ||
− | * ''': aref ( false, 2 )''' - | + | * ''': aref ( false, 2 )''' - функция переключает режим тестирования пикселей по альфе. Первый аргумент - вкл/выкл, второй аргумент - значение альфы, используемое в сравнении альфы пикселей. Если пиксель проверку не прошел, он не будет отрисовываться. Как именно происходит проверка альфы, пока непонятно, функция проверки устанавливается где-то в движке. |
− | + | * ''': zb ( false, false )''' - устанавливает функцию сравнения пикселей при z-тесте и включает режим записи в z-буфер для текстуры. Первый аргумент - функция сравнения (false - D3DCMP_LESSEQUAL - пиксель проходит тест только, если его z меньше или равно текущему пикселю, true - D3DCMP_ALWAYS - пиксель всегда проходит тест). Второй аргумент - включение записи в z-буфер, тут вкл/выкл. | |
− | + | * ''': fog ( false )''' - отключает освещение текстуры и включает для нее FOG DirectX. | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | * ''': fog ( false )''' - | + | |
* ''': emissive ( true )''' - применяется в источниках освещения. | * ''': emissive ( true )''' - применяется в источниках освещения. | ||
* ''': distort ( true )''' - представляет из себя механизм искажений, аналогичный эффекту искажающегося воздуха в некоторых аномалиях, а также "линза" в главном меню над кнопками. | * ''': distort ( true )''' - представляет из себя механизм искажений, аналогичный эффекту искажающегося воздуха в некоторых аномалиях, а также "линза" в главном меню над кнопками. | ||
+ | |||
+ | * ''': wmark (true)''' - используется в валлмарках | ||
+ | |||
---- | ---- | ||
Строка 114: | Строка 110: | ||
− | * ''': texture ( t_base ) ''' - помещение в вышеобъявленный буфер текстуры. | + | * ''': texture ( t_base ) ''' - помещение в вышеобъявленный буфер текстуры. Аргумент этой ф-ции представляет собой путь к текстуре, так что вполне можно указать нечто вроде |
: texture ( "fx\\fx_sun" ) | : texture ( "fx\\fx_sun" ) | ||
Строка 121: | Строка 117: | ||
− | * ''': clamp()''' - | + | Следующие функции устанавливают один из режимов адресации текстуры. Режим адресации определяет способ обработки текстурных координат при выходе их за пределы диапазона [0.0,1.0] |
+ | * ''': clamp()''' - режим адресации D3DTADDRESS_CLAMP. Значения текстурных координат, выходящие за рамки [0.0,1.0] обрезаются до 0.0 и 1.0 соответственно. Соответствует галке Texture Clamp в сдк. | ||
− | * ''': | + | * ''': wrap ()''' - режим адресации D3DTADDRESS_WRAP. При выходе значений текстурных координат за пределы [0.0,1.0] от значений отнимается их целая часть. Другими словами, если у вас u,v получились [1.3, 2.5], в этом режиме семплирование текстуры будет происходит по координатам [0.3, 0.5]. |
− | * ''': | + | * ''': mirror ()''' - режим адресации D3DTADDRESS_MIRROR. При выходе значений текстурных координат за пределы [0.0,1.0] от значений отнимается их целая часть и остаток вычитается из 1.0. Если u,v получились [1.3, 2.6], в этом режиме семплирование текстуры будет происходит по координатам [0.7, 0.4]. |
− | * ''': | + | Функции установки фильтрации текстур: |
+ | |||
+ | * ''': f_none ()''' - точечная фильтрация (то есть по сути, нет фильтрации) | ||
+ | |||
+ | * ''': f_linear ()''' - линейная фильтрация | ||
+ | |||
+ | * ''': f_bilinear ()''' - билинейная фильтрация | ||
+ | |||
+ | * ''': f_trilinear ()''' - трилинейная фильтрация. На редкость бесполезная функция, потому что семплер по умолчанию создается с трилинейной фильтрацией | ||
+ | |||
+ | * ''': f_anisotropic ()''' - анизотропная фильтрация. | ||
+ | |||
+ | Помимо этих функций также присутствуют функции для "тонкой" настройки фильтрации: | ||
+ | Настройка magnification filter | ||
+ | |||
+ | * ''': fmag_none ()''' - без фильтрации | ||
+ | |||
+ | * ''': fmag_point ()''' - точечная фильтрация | ||
+ | |||
+ | * ''': fmag_linear ()''' - линейная фильтрация | ||
+ | |||
+ | Настройка minification filter | ||
+ | |||
+ | * ''': fmin_none ()''' - без фильтрации | ||
+ | |||
+ | * ''': fmin_point ()''' - точечная фильтрация | ||
+ | |||
+ | * ''': fmin_linear ()''' - линейная фильтрация | ||
+ | * ''': fmin_aniso ()''' - анизотропная фильтрация. | ||
− | + | Настройка mip filter | |
+ | * ''': fmip_none ()''' - без фильтрации | ||
− | * ''': | + | * ''': fmip_point ()''' - точечная фильтрация |
− | * ''': | + | * ''': fmip_linear ()''' - линейная фильтрация |
− | + | Разные функции: | |
+ | * ''': project()''' - функция выставляет флаг D3DTTFF_PROJECTED для преобразования текстурных координат перед растеризатором. При выставленном флаге все компоненты текстурных координат делятся на w-компоненту. Актуально только для ffp (R1, ps_1_x). | ||
---- | ---- | ||
Строка 146: | Строка 173: | ||
− | '''Статья создана участником cjayho''' | + | '''Статья создана участником cjayho, отредактировал ошибки Sергей][akaMoonlight''' |
[[Категория:Скрипты]] | [[Категория:Скрипты]] |
Текущая версия на 22:27, 24 октября 2014
Редактируя любую модель, многие в свойствах поверхностей замечали графу 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 и normal_hq аналогичного содержания, но явно просчитывающие поведение этого шейдера в условиях освещения
- 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 ) - функция переключает режим тестирования пикселей по альфе. Первый аргумент - вкл/выкл, второй аргумент - значение альфы, используемое в сравнении альфы пикселей. Если пиксель проверку не прошел, он не будет отрисовываться. Как именно происходит проверка альфы, пока непонятно, функция проверки устанавливается где-то в движке.
- : zb ( false, false ) - устанавливает функцию сравнения пикселей при z-тесте и включает режим записи в z-буфер для текстуры. Первый аргумент - функция сравнения (false - D3DCMP_LESSEQUAL - пиксель проходит тест только, если его z меньше или равно текущему пикселю, true - D3DCMP_ALWAYS - пиксель всегда проходит тест). Второй аргумент - включение записи в z-буфер, тут вкл/выкл.
- : fog ( false ) - отключает освещение текстуры и включает для нее FOG DirectX.
- : 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
Следующие функции устанавливают один из режимов адресации текстуры. Режим адресации определяет способ обработки текстурных координат при выходе их за пределы диапазона [0.0,1.0]
- : clamp() - режим адресации D3DTADDRESS_CLAMP. Значения текстурных координат, выходящие за рамки [0.0,1.0] обрезаются до 0.0 и 1.0 соответственно. Соответствует галке Texture Clamp в сдк.
- : wrap () - режим адресации D3DTADDRESS_WRAP. При выходе значений текстурных координат за пределы [0.0,1.0] от значений отнимается их целая часть. Другими словами, если у вас u,v получились [1.3, 2.5], в этом режиме семплирование текстуры будет происходит по координатам [0.3, 0.5].
- : mirror () - режим адресации D3DTADDRESS_MIRROR. При выходе значений текстурных координат за пределы [0.0,1.0] от значений отнимается их целая часть и остаток вычитается из 1.0. Если u,v получились [1.3, 2.6], в этом режиме семплирование текстуры будет происходит по координатам [0.7, 0.4].
Функции установки фильтрации текстур:
- : f_none () - точечная фильтрация (то есть по сути, нет фильтрации)
- : f_linear () - линейная фильтрация
- : f_bilinear () - билинейная фильтрация
- : f_trilinear () - трилинейная фильтрация. На редкость бесполезная функция, потому что семплер по умолчанию создается с трилинейной фильтрацией
- : f_anisotropic () - анизотропная фильтрация.
Помимо этих функций также присутствуют функции для "тонкой" настройки фильтрации: Настройка magnification filter
- : fmag_none () - без фильтрации
- : fmag_point () - точечная фильтрация
- : fmag_linear () - линейная фильтрация
Настройка minification filter
- : fmin_none () - без фильтрации
- : fmin_point () - точечная фильтрация
- : fmin_linear () - линейная фильтрация
- : fmin_aniso () - анизотропная фильтрация.
Настройка mip filter
- : fmip_none () - без фильтрации
- : fmip_point () - точечная фильтрация
- : fmip_linear () - линейная фильтрация
Разные функции:
- : project() - функция выставляет флаг D3DTTFF_PROJECTED для преобразования текстурных координат перед растеризатором. При выставленном флаге все компоненты текстурных координат делятся на w-компоненту. Актуально только для ffp (R1, ps_1_x).
Также в папке с шейдерами лежат еще файлы .s (именно такого имени - точка и эс), которые являются для всех *.s-файлов своеобразными заголовочными файлами, функции из файла .s доступны из файлов *.s . На данный момент там имеются функции printf, и закомментированные во втором рендере ф-ции l_point и l_spot, которые отвечают за создание точечного и неточечного источников света соответственно.
Статья создана участником cjayho, отредактировал ошибки Sергей][akaMoonlight