http://stalkerin.gameru.net/wiki/api.php?action=feedcontributions&feedformat=atom&user=80.93.126.66&*S.T.A.L.K.E.R. Inside Wiki - Вклад участника [ru]2026-04-29T21:05:43ZВклад участникаMediaWiki 1.22.6http://stalkerin.gameru.net/wiki/index.php?title=%D0%9A%D0%B0%D0%BA_%D0%BF%D0%B8%D1%81%D0%B0%D1%82%D1%8C_%D1%81%D0%BA%D1%80%D0%B8%D0%BF%D1%82%D1%8B,_%D0%BD%D0%B5_%D0%BF%D1%80%D0%B8%D0%B2%D0%BE%D0%B4%D1%8F%D1%89%D0%B8%D0%B5_%D0%BA_%D0%B2%D1%8B%D0%BB%D0%B5%D1%82%D0%B0%D0%BC_%D0%B8_%D0%B1%D0%BE%D1%8E_%D1%81%D0%B5%D0%B9%D0%B2%D0%BE%D0%B2_(%D1%87%D0%B0%D1%81%D1%82%D1%8C_2)Как писать скрипты, не приводящие к вылетам и бою сейвов (часть 2)2011-09-07T10:19:08Z<p>80.93.126.66: </p>
<hr />
<div>----<br />
<br />
[[Как писать скрипты, не приводящие к вылетам и бою сейвов|Начало в первой части статьи]]<br />
<br />
----<br />
<br />
<br />
= Как безопасно использовать коллбэки и таймерные события =<br />
<br />
В скриптовом движке есть удобный способ реакции на события - использование коллбэков - процедурных вызовов, привязанных к определённым событиям в жизни игрового объекта - получению повреждений, спавну, смерти и т.д. и т.п. Это hit_callback, death_callback из xr_motivator и многие другие... Все моддеры очень широко и совершенно спокойно пользуются ими, совершенно забывая при этом о таком важном факте, что это - обработки реального времени, как и таймерные события. Что это значит? А собственно вот что... Возьмём для примера коллбэк смерти неписей, мою головную боль последнего времени:<br />
<br />
<code>xr_motivator.script -<br />
function motivator_binder:death_callback(victim, who)</code><br />
<br />
Это функция обрабатывает смерть неписей. Когда вызывается этот коллбек он начинает по очереди вызывать внутренние функции, расположенные в других модулях. Они разрегистрируют умершего непися в гулагах, спавнят в него лут, обновляют статистику, отключают его от доп. схем логики и т.д.<br />
<br />
Так вот, обычно, когда в функциях возникает конфликт параметров, бесконечный цикл, попытка индексации nil и т.д., функция вылетает со стандартным логом. '''Но только не в случае, когда она находится внутри коллбэка. Если функция внутри него, то в случае возникновении в ней любой нештатной ситуации, коллбэк наглухо виснет.''' Это происходит из-за того, что функции вызываются строго друг за другом, и каждая из них вызывается только тогда, когда её предшественница вернула управление коллбэку. В случае с death_callback опознать такого непися очень просто - в его трупе окажется фонарик, КПК и возможно ещё немного разных "мусорных" вещей, что говорит о том, что обработка его смерти повисла не дойдя даже до спавна лута. В подобной ситуации можно быть на 100% уверенным, что труп этот не был корректно разрегистрирован, и игра всё ещё считает его живым неписем. Кроме того, зависший коллбэк не освобождает стек (а он у Луа-подсистемы единый на все скрипты), что '''в итоге приводит к вылетам игры с переполнением памяти (вот она, реальная причина этих "родных" вылетов).''' Но было бы слишком хорошо, если бы всё ограничивалось этим... однако тут всё намного хуже... такие "зависшие" коллбэки, особенно если их произошло несколько подряд, очень серьёзно влияют на работу а-лайфа. В лучшем случае они, забивая, стек, мешают нормально работать схемам логики, в худшем вызывают зависания самого а-лайфа (этот эффект, кстати, производят и сами трупы таких неписей, так как они, как мы помним, не разрегистрировались корректно). '''Основной итог таких событий - бой сейвов, сделанных после возникновения таких ситуаций.''' Если повис один коллбэк, то такие сейвы ещё через раз загружаются, если же несколько, и остановилась работа а-лайфа - всё, сейвы бьются наглухо и реанимации не подлежат.<br />
<br />
Поэтому, чтобы избежать такого развития событий, каждый раз, когда вы вносите в коллбэк новую функцию - проверьте её самым тщательным образом. Она не должна содержать никаких рекурсивных циклов, в ней обязательно должны быть проверки на валидность обрабатываемых объектов и значений, и обязательно должна быть обработка нештатных ситуаций - т.е. функция должна обязательно, в абсолютно любой ситуации вернуть управление коллбэку, так или иначе. В самом наихудшем случае - делайте как делали разработчики игры - вставляйте принудительный вылет на рабстол функцией abort - она позволяет передавать отладочное сообщение, и это всяко лучше чем незаметный бой сейвов. Если обработка оборвалась в самом начале, а ф-ция обязательно должна вернуть значение - заведите ей "безопасное" возвращаемое значение по-умолчанию, которое она будет выдавать, если всё пошло плохо. И никогда не пренебрегайте пошаговой отладкой коллбэков с выводом в лог, особенно когда пишете схемы логики - это критически важно для стабильности вашего мода.<br />
<br />
== Основные внутриигровые признаки зависания коллбэков типа hit_callback, death_callback ==<br />
<br />
1. В трупах попадаются фонарики, КПК, разный мусор и общий лут слишком богат.<br />
<br />
2. Частые вылеты во время интенсивных боёв с логами типа<br />
Sheduler tried to update object...<br />
smart_terrain:1145(1146)<br />
LUA: out of memory<br />
любой_модуль_логики:любая_cтрока - stack overflow<br />
<br />
3. Частые "родные" вылеты в момент смерти непися или попадания по нему<br />
<br />
4. Произвольно бьются сейвы во время сражений, выброса и других насыщенных действиями событий<br />
<br />
= Использование защищённого кода в LUA =<br />
<br />
Периодически случаются такие ситуации, когда мы можем получить вылет при проверке аргумента, и не можем его адекватно заизолировать с помощью предварительной проверки на валидность значения. Вот простой пример: когда я отлаживал '''death_callback''' неписей, я периодически сталкивался с тем, что обращение к методу '''smart_terrain_id()''' при смерти непися иногда вызывало вылет <br />
<br />
<code>smart_terrain:1143 "attempt to index a nil value"</code><br />
<br />
- хотя это свойство является родным методом объекта, и отсутствовать напрочь никак не может. В итоге я пришёл к выводу, что его просто иногда не успевает отработать движок, так как вылет этот проявлялся в основном в интенсивных боях и совершенно произвольно.<br />
<br />
Вот код, в котором происходил вылет:<br />
<br />
<code lua>function on_death( obj_id )<br />
-- printf( "on_death obj_id=%d", obj_id )<br />
<br />
local sim = alife()<br />
<br />
if sim then<br />
local obj = sim:object( obj_id )<br />
local strn_id = obj:smart_terrain_id() --- вылет происходит тут<br />
<br />
if strn_id ~= 65535 then<br />
sim:object( strn_id ).gulag:clear_dead(obj_id)<br />
end<br />
end<br />
end</code><br />
<br />
Это кусок родного кода из версии 1,0005 игры. Я долго пытался разными способами отсечь этот вылет, вводя предварительные проверки, однако это совершенно ничего не давало - вылет всё равно периодически случался, так как проверки эти сами его вызывали. Тогда я зарылся в документацию по Lua и обнаружил замечательную родную базовую функцию, введённую ещё с первых версий Lua, которой почему-то не пользовались ни разработчики игры, ни моддеры (хотя сама она в Lua сталкера присутствует, и работает отлично, без каких-либо нареканий). Вот она:<br />
<br />
'''pcall (f, arg1, ···)'''<br />
<br />
<blockquote>Вызывает функцию f с указанными через запятую аргументами в защищённом режиме. Это означает, что любая ошибка, даже критическая, внутри вызванной функции, не передаётся наружу - вызывавшей подсистеме. Вместо этого '''pcall''' перехватывает ошибку и возвращает код статуса. Первая возвращаемая переменная это сам код, (true или false) и если всё прошло хорошо, он равен true. В этом случае '''pcall''' сразу после статуса возвращает все результаты от работы защищённой им функции. Если же в защищённой функции произошла ошибка, то '''pcall''' вернёт false и затем сообщение об ошибке. (Обратите внимание, обработка ошибки присходит БЕЗ вылета! Вместо вылета вы получите вполне адекватную строку с ошибкой, которую можно вывести в лог для последующей обработки)</blockquote><br />
<br />
Я настоятельно советую пользоваться этой функцией в случаях, когда из коллбэков вызываются сложные комплексные обработки, вроде обработки из менеджера вооружений AI-пака. Это позволяет предотвратить как вылеты, так и зависания обработок, и в итоге позволяет хорошо стабилизировать игру.<br />
<br />
Возвращаясь к нашим смарттеррейнам... вот как в итоге я подавил вылет типа smart_terrain:1143 с помощью pcall:<br />
<br />
<code lua>--- эта функция пытается проверить св-во smart_terrain_id объекта. Именно её мы вызовем в защищённом режиме.<br />
function prot_smt_td(obj)<br />
if IsStalker(obj) or IsMonster(obj) then<br />
return obj:smart_terrain_id()<br />
else <br />
return 65535<br />
end<br />
end<br />
<br />
<br />
function on_death( obj_id )<br />
-- printf( "on_death obj_id=%d", obj_id )<br />
local sim = alife()<br />
if sim then<br />
local obj = sim:object( obj_id )<br />
if obj then<br />
local strn_id = 65535 --- предварительно проинитим переменную, на <br />
--- случай если у нас prot_smt_td выдаст ошибку<br />
local result, smt_id = pcall(prot_smt_td,obj) --- вызываем prot_smt_td в защищённом режиме <br />
--- и сразу присваиваем его вывод переменным<br />
if result then --- если pcall выдало true<br />
strn_id = smt_id --- тогда применяем полученное значение<br />
end<br />
--- если же обработка выдаст ошибку, то strn_id останется неизменным...<br />
if strn_id ~= 65535 then<br />
sim:object(strn_id).gulag:clear_dead(obj_id)<br />
end<br />
end<br />
end<br />
end</code><br />
<br />
В других местах это делается совершенно аналогично. Подробнее об этой и многих других функция для контроля кода, незаслуженно игнорируемых большинством моддеров, можно почитать тут: http://lua-users.org/wiki/FinalizedExceptions - на английском правда, но захотите - разберётесь, там всё просто. <br />
<br />
Настоятельно советую вам изучить работу кода в таких условиях и научиться его правильно применять - этим вы сильно облегчите жизнь как себе, так и тем, кто после вас будет рыться в вашем коде или импортировать его в свои разработки.<br />
<br />
= Скрытые критические проблемы в обработке вылетов игрой =<br />
<br />
Ведя на днях отладку, выяснил в чём проблема с периодическим боем сейвов и многими другими заморочками как в оригинале игры, так и во многих модах... дело, как выяснилось, далеко не всегда в кривых руках. Есть такая стандартная ф-ция '''abort''' - предназначенная для выкидывания из игры, если что-то пошло не так. И как оказалось, она срабатывает далеко не всегда. Выяснилось это следующим образом:<br />
<br />
В одном из логов нашего бета-тестера я увидел '''стандартное сообщение о вылете внутри рабочего лога'''... да-да, то самое которое '''FATAL ERROR''' и дальше по тексту. При этом игра у него НЕ вылетала, это сообщение об ошибке мы обнаружили позже, по случайности. Я заподозрил, что что-то не в порядке, и вставил внутрь этой ф-ции контрольную метку, кидавшую в консоль сообщение, в котором содержался паттерн сообщения об ошибке и само сообщение. Так вот, оказалось, что эта самая функция '''abort''' вызывается в игре с завидным постоянством (вы удивитесь насколько часто), когда возникают исключения в схемах логики, звука и т.д., но игра от этого вылетает на рабочий стол '''максимум только 3 раза из 10 вызовов'''. Вылет НЕ происходит обычно, когда функции передан паттерн ошибки, а остальные параметры пустые, такое бывает, и частенько. И если не сделать внутри этой функции особой метки для вывода в лог, как сделал это я, её вызовы проходят совершенно незаметно, и '''игра после критических ошибок продолжается как ни в чём ни бывало.''' А приводит это вот к чему... Внутри '''xr_logic''' в процедуре записи пстора (хранилища логики и флагов) неписей есть вызовы этого самого аборта в случае если на запись в пстор передана некорректная величина. Ну а так как аборт периодически вообще не срабатывает, то часто попадается ситуация, что неписям в пстор пишется полный ахтунг: куски кода из ОЗУ, всякая муть из лтх-ов, куски аллспавна, всё что угодно. Происходит это оттого, что кодер, писавший эту функцию ('''xr_logic.pstor_store(obj, varname, val)'''), явно и думать не думал что '''abort''' может не сработать. У него запись в пстор стояла после проверки, а не внутри неё (very bad idea), и если abort не срабатывал, игра писала в пстор мусор совершенно спокойно и незаметно для игрока. Потом вся эта хрень попадала прямо в сейвы. Вот проблемный код для наглядности:<br />
<br />
<code lua>function pstor_store(obj, varname, val)<br />
local npc_id = obj:id()<br />
if db.storage[npc_id].pstor == nil then<br />
db.storage[npc_id].pstor = {}<br />
end<br />
local tv = type(val)<br />
if not pstor_is_registered_type(tv) then<br />
abort("xr_logic: pstor_store: not registered type '%s' encountered", tv) --- вот тут мы должны если что вылететь<br />
end<br />
db.storage[npc_id].pstor[varname] = val -- а если не вылетели, всё, получим запись в пстор левой мути<br />
end</code><br />
<br />
Разумеется игра этим пстором в итоге давится, и сейвы сделанные после такой милой записи практически лопаются. Результат - "битые" (на самом деле подлежат реанимации) сейвы. Происходит это потому, что игра из сейва грузит неписям псторы сплошным чтением по словам, пока они не закончатся. В случае же если в псторе обнаруживается записанный ранее мусор, то обработка либо вылетает сразу, либо наглухо виснет, пытаясь запихать эдак с миллион слов в пстор особо отличившегося непися. Как вам например непись с размером пстора в 1697451 слова? В результате попытки его обработать игра просто на стадии синхронизации выжрала всю доступную ОЗУ и повисла. <br />
<br />
Решение этой проблемы оказалось достатоно простым: во-первых я предположил максимальный размер полезной части пстора неписей в 20 слов r_u32() (пока ориентировочно, я ещё уточняю эту величину), и соответственно сделал остановку цикла загрузки пстора для неписей через 20 итераций. Там же, где в цикле стояла проверка на валидность записываемых данных (кстати тоже с вылетом в случае провала проверки), я сделал так, что если параметр не относится к валидному типу данных, то запись параметра в пстор не производится совсем. Это необходимо для того, чтобы если вдруг в сейве обнаружится мусор, то он был бы просто отброшен обработкой. Практика показала, что в итоге такие неписи вполне адекватны и в дальнейшем никаких проблем не вызывают, так как начало их пстора, с нормальными данными, обычно не повреждается - мусор дописывается после них, а не вместо них. <br />
<br />
Ну и во-вторых модифицировал запись параметров в пстор, просто убрав запись под основание if-else так, чтобы если параметр неверен, он не записывался совсем. Теперь кстати, очень интересно, сохранились ли те же заморочки с ф-цией '''abort''' в Чистом Небе, и если да, то останутся ли в Зове Припяти?<br />
<br />
------------<br />
<br />
== Необходимые для стабилизации игры правки в модулях ==<br />
<br />
'''Эта правка предотвращает запись в пстор если не сработал аборт:'''<br />
<br />
''xr_logic.script''<br />
<br />
'''Было:'''<br />
<br />
<code lua>function pstor_store(obj, varname, val)<br />
local npc_id = obj:id()<br />
if db.storage[npc_id].pstor == nil then<br />
db.storage[npc_id].pstor = {}<br />
end<br />
local tv = type(val)<br />
if not pstor_is_registered_type(tv) then<br />
abort("xr_logic: pstor_store: not registered type '%s' encountered", tv)<br />
end<br />
db.storage[npc_id].pstor[varname] = val<br />
end</code><br />
<br />
'''Стало:'''<br />
<br />
<code lua>function pstor_store(obj, varname, val)<br />
if not obj then return end<br />
local npc_id = obj:id()<br />
if db.storage[npc_id].pstor == nil then<br />
db.storage[npc_id].pstor = {}<br />
end<br />
local tv = type(val)<br />
if not pstor_is_registered_type(tv) then<br />
dgblog("xr_logic: pstor_store: not registered type encountered - write in pstor_store cancelled")<br />
-- abort убран, так как один хрен не работает. Пусть тогда хотя бы в лог что-то валится.<br />
else<br />
db.storage[npc_id].pstor[varname] = val<br />
-- вот так и только так. Если значение не валидно, ничего не происходит.<br />
end <br />
end</code><br />
<br />
'''А эта правка выкинет из пстора весь мусор при загрузке сейва, если он как-то в него попал'''<br />
<br />
'''Было:'''<br />
<br />
<code lua>function pstor_load_all(obj, reader)<br />
local npc_id = obj:id()<br />
local pstor = db.storage[npc_id].pstor<br />
if not pstor then<br />
pstor = {}<br />
db.storage[npc_id].pstor = pstor<br />
end<br />
local ctr = reader:r_u32()<br />
for i = 1, ctr do<br />
local varname = reader:r_stringZ()<br />
local tn = reader:r_u8()<br />
if tn == pstor_number then<br />
pstor[varname] = reader:r_float()<br />
elseif tn == pstor_string then<br />
pstor[varname] = reader:r_stringZ()<br />
elseif tn == pstor_boolean then<br />
pstor[varname] = reader:r_bool()<br />
else<br />
abort("xr_logic: pstor_load_all: not registered type N %d encountered", tn)<br />
end<br />
printf("_bp: pstor_load_all: loaded [%s]='%s'", varname, utils.to_str(pstor[varname]))<br />
end<br />
end</code><br />
<br />
'''Стало:'''<br />
<br />
<code lua>function pstor_load_all(obj, reader)<br />
local npc_id = obj:id()<br />
local pstor = db.storage[npc_id].pstor<br />
if not pstor then<br />
pstor = {}<br />
db.storage[npc_id].pstor = pstor<br />
end<br />
local ctr = reader:r_u32()<br />
if tonumber(ctr) > 20 and tostring(obj:name()) ~= "single_player" and npc_id ~= db.actor:id() then<br />
-- максимум 20 итераций - это число ещё уточняется, возможно понадобится больше<br />
-- если у вас в пстор что-то свое пишется, ориентируйтесь на свои значения<br />
-- и обязательно убираем из проверки актора - у него очень толстый пстор, и к тому же<br />
-- если уж поврежденным будет его пстор, то тут точно уже ничего не поможет<br />
dgblog("ОБНАРУЖЕН ОБЪЕКТ С ПОВРЕЖДЕННЫМ PSTOR: "..tostring(obj:name())..<br />
" БУДЕТ ПРОИЗВЕДЕНА ПОПЫТКА ВОССТАНОВЛЕНИЯ")<br />
ctr = 20 <br />
end<br />
for i = 1, ctr do<br />
local varname = reader:r_stringZ()<br />
local tn = reader:r_u8()<br />
if tn == pstor_number then<br />
pstor[varname] = reader:r_float()<br />
elseif tn == pstor_string then<br />
pstor[varname] = reader:r_stringZ()<br />
elseif tn == pstor_boolean then<br />
pstor[varname] = reader:r_bool()<br />
else<br />
-- не надо пытаться вылетать - просто не пишем поврежденные данные<br />
-- при этом обязательно удалять саму переменную - в результате записи<br />
-- мусора в пстор одно только ее название может повесить загрузку<br />
pstor[varname] = nil<br />
end<br />
end<br />
end</code><br />
<br />
Эти примеры приведены для чистой игры. Единственное в чем не уверен пока, это в том, что максимум полезного размера - 20 слов. Возможно нужно выделить больше, это надо будет проверить ещё экспериментальным путем...<br />
<br />
Кроме этого, советую ещё внутрь ф-ции abort вставить отладочные метки, чтобы точно знать когда она вызывалась. Настоятельно советую сделать это даже если вы матёрый моддер со стажем - гарантирую, будете неприятно удивлены.<br />
<br />
Я это сделал вот так:<br />
<br />
''_g.script''<br />
<br />
<code lua>-- Крешнуть игру (после вывода сообщения об ошибке в лог)<br />
function abort(fmt, msg)<br />
local message = tostring(msg)<br />
dbglog("ERROR PATTERN: "..tostring(fmt))<br />
dbglog("ERROR REASON: "..message)<br />
local reason = string.format(fmt, message)<br />
assert("ERROR: " .. reason)<br />
printf("ERROR: " .. reason)<br />
dbglog("%s", reason)<br />
printf("%s")<br />
end</code><br />
<br />
По поводу частичной неработоспособности ф-ции '''abort''' я беседовал с Колмогором, и он пришёл к выводу, что видимо вылет игры должен был бы производиться при обработке функции '''printf("%s")''' - ей тут передаётся заведомо отсутствующий оператор и она по уму должна бы сразу крашить игру. Однако в релизе функция printf фактически не работает(она реализована в _g.script через вырезанную функцию log). В результате игра не крашится. Но что поделать, в итоге мне пришлось модифицировать его таким образом, чтобы вылет при его срабатывании был гарантирован:<br />
<br />
<code lua>-- Крешнуть игру (после вывода сообщения об ошибке в лог)<br />
function abort(fmt, msg)<br />
local message = tostring(msg)<br />
dbglog("ERROR PATTERN: "..tostring(fmt))<br />
dbglog("ERROR REASON: "..message)<br />
local reason = string.format(fmt, message)<br />
assert("ERROR: " .. reason)<br />
printf("ERROR: " .. reason)<br />
dbglog("%s", reason)<br />
printf("%s")<br />
local crash<br />
local ooops = 1/crash<br />
end</code><br />
<br />
Вылет происходит при попытке произвести арифметическую операцию с неинициализированной переменной crash.<br />
<br />
<br />
----<br />
<br />
<br />
<b>Дополнение от cjayho (ecb team):</b> Вообще крэшить игру ошибкой в скриптовом коде - далеко не самое очевидное решение. В windows-подобных системах статус, возвращаемый программой после ее выполнения, не имеет ни малейшего смысла, поэтому корректно ли мы выключим игру или некорректно - разницы не будет никакой. Поэтому есть смысл сделать крэш игры более очевидным и стопроцентно работающим способом: использовать консольную команду <b>quit</b>:<br />
<br />
<code lua>-- Крешнуть игру (после вывода сообщения об ошибке в лог)<br />
function abort(fmt, msg)<br />
local message = tostring(msg)<br />
dbglog("ERROR PATTERN: "..tostring(fmt))<br />
dbglog("ERROR REASON: "..message)<br />
local reason = string.format(fmt, message)<br />
assert("ERROR: " .. reason)<br />
printf("ERROR: " .. reason)<br />
dbglog("%s", reason)<br />
get_console:execute( 'quit' )<br />
end</code><br />
<br />
А для тех кто задается вопросом: <i>почему разработчики не сделали так изначально?</i> отвечу: вероятнее всего ошибка в скрипте была не очень очевидным заклинанием по призыву волшебного зеленого жука, которое после выпуска не-дебаг версии потеряло свой изначальный сакральный смысл.<br />
<br />
<br />
----<br />
<br />
<br />
== Лечение зависаний алайфа при смерти персонажей ==<br />
<br />
Недавно, отлаживая проблемы с зависанием алайфа, мне удалось найти причину этого периодически во всех модах всплывающего сбоя, приводящего к порче сейвов и сильно мешающего нормально играть. Сбой этот возникает при смерти некоторых NPC, обычно квестовых. В частности в моём случае изолировать и отладить это зависание удалось на Юрике, новичке со Свалке, учавствующем в сцене с гоп-стопом. Причина оказалась в обработке посмертной отрегистрации NPC из гулагов, причём сбой там был настоящей матрёшкой, составной из нескольких частей. Правок в итоге было совсем немного, но чтобы сделать их мне пришлось несколько часов распутывать клубок из кросс-вызовов между скриптами smart_terrain и xr_gulag. Итак, начнём с самого начала. Работая над OGSE 069 и 0691 я периодически сталкивался с зависаниями и вылетами в посмертных обработках неписей. Один из таких вылетов - всем хорошо знакомый вылет:<br />
<br />
<code>smart_terrain:1143 "attempt to index a nil value"</code><br />
<br />
Происходящий в функции '''smart_terrain.on_death( obj_id )''' - я тогда его заблокировал вызовом его внутри безопасного кода функцией '''pcall''', однако, как теперь выяснилось, этого оказалось недостаточно - баг тут состоит из нескольких частей, и этот вылет указывает только на одну из них. Вот исходный код:<br />
<br />
<code lua>function on_death( obj_id )<br />
-- printf( "on_death obj_id=%d", obj_id )<br />
<br />
local sim = alife()<br />
<br />
if sim then<br />
local obj = sim:object( obj_id )<br />
local strn_id = obj:smart_terrain_id() --- первый вылет/зависнаие алайфа происходит тут<br />
<br />
if strn_id ~= 65535 then<br />
sim:object( strn_id ).gulag:clear_dead(obj_id) -- а вот в этой обработке происходит зависание алайфа. Она очень комплексная, и её сложно распутывать.<br />
end<br />
end<br />
end</code><br />
<br />
Во-первых выяснилось, что изредка вызов '''obj:smart_terrain_id()''' вызывает зависание алайфа даже когда он производится изнутри защищённого кода. Тогда я решил избавиться от использования этой функции в данном месте совсем. После нескольких экспериментов выяснилось, что самым простым, быстрым и вылетобезопасным способом будет считать нетпакет существа в таблицу и выудить идентификатор смарттеррейна из неё. Для этого можно написать свою обработку, однако я, как весьма ленивый программист, не склонен изобретать велосипеды, поэтому я воспользовался уже проверенной у нас и активно используемой в OGSE библиотекой функций для работы с нетпакетами '''m_net_utils''' Артоса. Кроме того, я сразу сделал более безопасным вызов обработки на отрегистрацию в гулагах. Вот, собственно, что в итоге получилось:<br />
<br />
<code lua>function on_death( obj_id )<br />
-- printf( "on_death obj_id=%d", obj_id )<br />
local sim = alife()<br />
if sim then<br />
local obj = sim:object( obj_id )<br />
if (obj and obj.smart_terrain_id) then<br />
local strn_id = 65535 -- значение по умолчанию<br />
<br />
local t = nil -- сюда запихнём табличку из пакета<br />
if IsStalker(obj) then t = m_net_utils.get_stalker_data(obj) elseif IsMonster(obj) then t = m_net_utils.get_monster_data(obj) end <br />
-- вызываем парсинг пакета для неписей и монстров отдельно<br />
<br />
-- print_table_inlog(t)<br />
if t.smtrid then<br />
strn_id = tonumber(t.smtrid) -- получаем идентификатор смарта, если его нету даже в пакете, хрен с ним, будет 65535<br />
end<br />
<br />
if strn_id ~= 65535 then -- если сняли идентификатор, попробуем отрегать...<br />
local gulag = sim:object(strn_id)<br />
if gulag and gulag.gulag then -- ...но сначала выясним если вообще такой гулаг и инициализирован ли он<br />
sim:object(strn_id).gulag:clear_dead(obj_id)<br />
end<br />
end<br />
end<br />
end<br />
end</code><br />
<br />
При этом сделаю отсупление и предупрежу об одном очень странном сбое с которым я столкнулся редактируя эту функцию. Так вот, всё нормально работает только тогда когда у ф-ции этой есть строго определённая структура. '''Стоит только добавить пару строк, убрать закомментированную и сдвинуть пару условий, просто в тексте сдвинуть, не меняя внутренней логики, как игра начинает вылетать, причём ещё до загрузки сейва, при кэшировании (!) и с очень странными логами, хотя код написан синтаксически безупречно! Например с таким:'''<br />
<br />
<code>Description: xr_gulag:1035 value not found ObjectJobPathName[obj_id]</code><br />
<br />
'''Вернёшь строки на место, перестроишь текст - работает снова. Совершенная чертовщина, шаманил я над этой функцией около получаса, перестраивая текст таким образом чтобы игра нормально запускалась.''' Имейте это в виду когда в неё полезете и если что не пугайтесь если игра начнёт так вылетать - в этом случае пошаманьте немного над ней, меняя её форматирование. О причинах такого поведения я не могу даже догадываться - то ли движок её вызывает по смещению внутри файла вручную, то ли это какой-то баг Lua-парсера, но факт фактом.<br />
<br />
Итак, теперь проблема с получением идентификатора смарта разрешилась, однако алайф всё равно зависал! Простая трассировка показала, что теперь зависание происходило внутри обработки<br />
<br />
<code lua>sim:object(strn_id).gulag:clear_dead(obj_id)</code><br />
<br />
И мне пришлость распутывать её по частям, доискиваясь до причины. Обработка честно говоря мерзкая, размазана по smart_terrain и xr_gulag, при этом взаимные вызовы идут не менее десятка раз, в следующем стиле: ф-ция в смарте вызывает ф-цию в гулаге, которая вызывает фцию в смарте, которая обрабатывает параметр фцией в гулаге, который передётся ф-цией в логике, которая получает её из смарта. Нечто подобное. Опуская все нецензурные выражения, употребленные мной при трассировке, я лучше расскажу что собственно вышло в итоге. А в итоге я вышел вот на этот код в xr_gulag, именно в нём при отрегистрации некоторых мёртвых неписей происходит зависание алайфа:<br />
<br />
<code lua>-- освободить объект от работы и переинициализировать логику.<br />
-- если сталкер в онлайне и начал работу, то сбросить его схему поведения<br />
-- как будто он только что загрузился<br />
function gulag:free_obj_and_reinit( obj_id )<br />
self:free_obj(obj_id)<br />
<br />
local t = self.Object[obj_id]<br />
if t ~= nil and t ~= true and self.Object_begin_job[obj_id] then<br />
xr_logic.initialize_obj( t, nil, false, db.actor, self:get_stype( obj_id ) ) -- вот эта обработка вешает алайф<br />
end<br />
end</code><br />
<br />
Я, честно говоря, ни разу не понимаю, на кой чёрт нужно переконфигурировать схемы логики и выбирать из них активную '''трупу, который лежит себе спокойно и никого не трогает.''' Может быть в это есть некий высший смысл, или это было продиктовано неким аккуратизмом, однако одно я могу сказать однозначно - подобная переинициализация у некоторых трупов неписей приводит к глухому зависанию алайфа. При этом если для трупов эту обработку заблокировать, то трупы разрегистрируются вполне нормально и спокойно лежат с нетронутой логикой, не вызывая никаких проблем. Итоговый код после правок выглядит вот так:<br />
<br />
<code lua>-- освободить объект от работы и переинициализировать логику.<br />
-- если сталкер в онлайне и начал работу, то сбросить его схему поведения<br />
-- как будто он только что загрузился<br />
function gulag:free_obj_and_reinit( obj_id )<br />
self:free_obj(obj_id)<br />
local t = self.Object[obj_id]<br />
if t ~= nil and t ~= true and self.Object_begin_job[obj_id] then<br />
if check_game() then -- тут проверяется, запущена ли игра, если ли актор и жив ли он. Если да, делаем по новому.<br />
local s_obj = alife():object(obj_id) -- проверим есть ли у цели разрегистрации валидный серверный объект<br />
if s_obj and (IsStalker(s_obj) or IsMonster(s_obj)) and s_obj:alive() then -- если есть, он жив и сталкер или монстр<br />
xr_logic.initialize_obj( t, nil, false, db.actor, self:get_stype( obj_id ) ) -- только тогда инициализируем логику<br />
end<br />
else -- а если игра не запущена, то как раньше. Это нужно для того, чтобы обработка запуска игры нормально работала.<br />
xr_logic.initialize_obj( t, nil, false, db.actor, self:get_stype( obj_id ) )<br />
end<br />
end<br />
end<br />
<br />
-- Проверка, запущена ли игра<br />
function check_game()<br />
if level.present() and (db.actor ~= nil) and db.actor:alive() then<br />
return true<br />
end<br />
return false<br />
end<br />
</code><br />
<br />
После этих поправок зависания алайфа при смерти неписей удалось побороть окончательно. Решение с отрезанием реинита логики для трупов несколько грубовато, но честно говоря, у меня нет ни малейшего желания трассировать и разбирать на части функцию xr_logic.initialize_obj, выясняя, чем же ей так данный конкретный труп не приглянулся. Если хотите - займитесь, найдёте причину - дополните данную статью. Я же успокоился на том, что заблокировал баг, периодически убивающий людям игру, так как многие пользователи, игнорируя предупреждения, играют на одном-двух сейвах, а то и вовсе на квиксейвах всю игру.<br />
<br />
= Другие частые проблемы =<br />
<br />
Спустя некоторое время я обнаружил причины ещё нескольких часто встречающихся вылетов, и решил записать их описание сюда - эта информация наверняка ещё много кому пригодится.<br />
<br />
== Вылеты при удалении объектов из игры ==<br />
<br />
При использовании для удаления объектов родной движковой функции '''alife():release(alife():object(id), true)''' возможен целый ворох разнообразнейших вылетов, обычно - безлоговых, что сильно затрудняет их отладку. Вот из-за чего они возникают:<br />
<br />
1) Вылет при удалении непися или монстра, находящегося в онлайне.<br />
Решение: с помощью alife():release '''можно удалять только мёртвые объекты'''. Поэтому если вам нужно удалить с её помощью непися или монстра, который жив и находится в онлайне, его нужно убить любым доступным методом, хотя бы нанеся ему hit() с любым запредельным уроном по вкусу.<br />
<br />
2) Вылет при удалении оружия или артефакта.<br />
Решение: такая проблема часто встречается в случае если объект неудачно расположен или находится в руках у непися. Для того чтобы не произошло вылета, убедитесь что объект доступен как серверный перед удалением. Вот так:<br />
<br />
<code lua> local obj = alife():object(i)<br />
if obj then<br />
alife():release(obj, true)<br />
end</code><br />
<br />
Эту конструкцию вообще желательно использовать всегда, когда вы так удаляете объекты.<br />
<br />
3) Вылет при удалении аномалии.<br />
Решение: аномалии - очень капризные при подобном с ними обращении объекты. Они влияют на своё окружение, и если рядом с ними находится непись или монстр, то удаление такой аномалии приведёт к вылету игры. Чтобы этого не произошло, аномалию надо сначала выключить функцией '''disable_anomaly''', и удалять затем ТОЛЬКО тогда, когда она не будет занята влиянием на динамический объект. Для этого нужно получить список мобов на локации, и из их нетпакетов считать идентификаторы действующих на них рестрикторов. Если ваша аномалия будет в этом списке - удалять её нельзя. Дождитесь пока она освободится.<br />
<br />
== Вылет при открытии закладки "Контакты" в ПДА ==<br />
<br />
Простой безлоговый вылет при открытии закладки "Контакты". Встречался во всех крупных модах, и никто не знал как его излечить. А лечится он банально - '''его причина - дублирование идентификаторов секций в XML-файле, описывающем иконки неписей для закладки "Контакты"'''. Нужно всего лишь проверить этот файл на наличие дублированных идентификаторов и удалить их. Вылет пропадёт и никогда больше не будет встречаться.<br />
<br />
== Вылеты при вызове несуществующих функций из XML ==<br />
<br />
В ХML-файлах, используемых для описания инфопоршенов, для многих инфопоршенов прописаны действия, которые игра вызывает при взятии этого инфопоршена. Вот так примерно:<br />
<br />
<code xml><br />
<info_portion id="barman_document_have"><br />
<action>dialogs.set_actor_prebandit1</action><br />
<action>bar_spawn.bandits2</action><br />
<action>bar_spawn.bandits3</action><br />
<action>bar_spawn.bandit7</action><br />
<action>bar_spawn.bandit8</action><br />
</info_portion><br />
</code><br />
<br />
Так вот, если вы допустите опечатку в названии вызываемой функции или же случайно её удалите - игра будет стабильно вылетать без лога при взятии этого инфопоршена.<br />
<br />
== Повреждения сейвов на Радаре и других местах в модах, основанных на OGSM ==<br />
<br />
В оригинале ОГСМ и основанных на нём модах часто встречались проблемы с сохранениями на Радаре. Эту проблему долго не удавалось победить, пока наконец благодаря помощи Маландринуса не удалось выявить её первопричину. Как выяснилось, она очень проста - гражданские зомби в моде (монстры) имели в конфиге ту же пропись вида (параметр конфига specie), что и монолитовцы и зомбированные (неписи). И там и тут было проставлено "zombie", и так оно было ещё с оригинала. Как оказалось, так делать категорически нельзя. Дело в том, что у неписей есть такой функционал, как хитовая память - в ней какое-то время хранятся ссылки на атакующие объекты. У монстров тоже есть остатки этого функционала, но он неработоспособен, и использовать его нельзя. В случае же когда монстры и неписи попадают в один вид, в ситуации когда они находятся рядом в бою, хитовая память монстров автоматически получает от неписей того же вида распространяемую внутри вида информацию об атакующих - а хранить её монстрам нельзя. Если после создания такой ситуации сохраниться - сейв будет вызывать вылет при загрузке. То есть проще говоря, если в бою с монолитовцами рядом оказывались гражданские зомби - и игрок сохранял игру - сейв этот не загружался. Чтобы предотвратить эти проблемы, вполне достаточно создать для гражданских зомби свой отдельный вид, добавив его прописи в конфиг game_relations.<br />
<br />
== Застывания NPC после боя / лечения ранения в модах, использующих дополнительные схемы поведения ==<br />
<br />
Во многих модах, использующих дополнительные схемы поведения часто можно заметить NPC, которые после боя застывают, прицелившись в одну точку. Аналогично часто это встречается с вылеченными от ранения NPC - они встают и замирают намертво, до тех пор пока их не выведет из этого состояния атаковавший враг. Как правило сейв/загрузка этой проблемы не решают. В ходе работы над OGSE 0.6.9.3 мне удалось выяснить причину таких проблем и успешно её устранить. Причина проблемы заключается в том, что NPC управляются не только скриптовыми схемами, но и движком, и для переключения управления между одним и другим используется скрипт ''state_mgr'' - менеджер состояний. Его директивы имеют наивысший приоритет. Аналогичный же приоритет себе как правило назначают доп. схемы поведения, используя пропись эвалуатора в ''xr_motivatior.addCommonPrecondition(action)''. В итоге при выходе из движковой боевки или при переключении на движковый алайф (это происходит после излечения ранения) доп. схемы поведения вступают с менеджером состояний в конфликт, блокируя смену состояния NPC. Для того чтобы этого не происходило, '''необходимо во всех схемах поведения, использующих принудительное назначение состояния через функцию ''state_mgr.set_state'' сделать блокировку перехвата управления менеджером состояний''', добавив соответствующие прописи в биндер. Вот таким образом, как в этом примере - тут я правил биндер схемы лечения/самолечения ''xrs_medic'':<br />
<br />
<code lua><br />
function add_to_binder(object, ini, scheme, section, storage)<br />
local operators = {}<br />
local properties = {}<br />
<br />
local manager = object:motivation_action_manager()<br />
<br />
operators["medic"] = actid_medic<br />
operators["self_medic"] = actid_self_medic<br />
<br />
properties["medic"] = evid_medic<br />
properties["self_medic"] = evid_self_medic<br />
<br />
local state_mgr_to_idle_combat = xr_actions_id.state_mgr + 1 ---< Это переключение на движковую боевку, но оно тут не использовано<br />
local state_mgr_to_idle_alife = xr_actions_id.state_mgr + 2 ---< Это переключение на движковый алайф<br />
local state_mgr_to_idle_off = xr_actions_id.state_mgr + 3 ---< Это переключение в статичное состояние<br />
<br />
local zombi=object:character_community()=="zombied" or object:character_community()=="trader" or<br />
object:character_community()=="arena_enemy" or object:name()=="mil_stalker0012" or object:name()=="yantar_ecolog_general"<br />
<br />
if zombi then<br />
manager:add_evaluator (properties["medic"], property_evaluator_const(false))<br />
manager:add_evaluator (properties["self_medic"], property_evaluator_const(false))<br />
else<br />
manager:add_evaluator (properties["medic"], evaluator_medic("medic", storage))<br />
manager:add_evaluator (properties["self_medic"], evaluator_self_medic("self_medic", storage))<br />
end<br />
<br />
local action = action_medic (object,"medic", storage)<br />
action:add_precondition(world_property(stalker_ids.property_alive, true))<br />
action:add_precondition(world_property(xr_evaluators_id.sidor_wounded_base, false))<br />
action:add_precondition (world_property(properties["medic"], true))<br />
action:add_effect (world_property(properties["medic"], false))<br />
manager:add_action (operators["medic"], action)<br />
<br />
local action = action_self_medic (object,"self_medic", storage)<br />
action:add_precondition(world_property(stalker_ids.property_alive, true))<br />
action:add_precondition(world_property(stalker_ids.property_enemy,false)) <br />
action:add_precondition(world_property(xr_evaluators_id.sidor_wounded_base, false))<br />
action:add_precondition (world_property(properties["medic"], false))<br />
action:add_precondition (world_property(properties["self_medic"], true))<br />
action:add_effect (world_property(properties["self_medic"], false))<br />
manager:add_action (operators["self_medic"], action)<br />
<br />
action = manager:action (stalker_ids.action_alife_planner) <br />
action:add_precondition (world_property(properties["medic"], false))<br />
action:add_precondition (world_property(properties["self_medic"], false))<br />
<br />
action = manager:action(state_mgr_to_idle_alife)<br />
action:add_precondition (world_property(properties["self_medic"], false)) ---< Блокируем попытки переключиться на движковый алайф пока работает самолечение<br />
<br />
action = manager:action(state_mgr_to_idle_off)<br />
action:add_precondition (world_property(properties["self_medic"], false)) ---< Блокируем попытки переключиться статичное состояние пока работает самолечение<br />
<br />
end<br />
</code><br />
<br />
Вставка этих директив в биндеры всех схем, которые меняют состояния принудительно устраняет конфликты, и NPC больше не виснут при смене схем.<br />
<br />
== Зависания алайфа из-за ошибок в конфигах торговли ==<br />
<br />
Очень частая проблема у начинающих модостроителей. Обнаруживается боем сейвов в радиусе алайфа от торговца с некорректным конфигом. Обычно главная и единственная причина этой проблемы - наличие в секции ''buy_supplies'' секций, у которых не прописан один или оба параметра, или же наличие записей вида <br />
<br />
<code><br />
novice_outfit ;NO TRADE<br />
</code><br />
<br />
Запомните - в секции ''buy_supplies'' конфига торговли таких записей быть не должно вообще. Если вы хотите убрать вещь из общего ассортимента - удалите её строку из ''buy_supplies''.<br />
<br />
--[[Участник:Kamikazze|KamikaZze (OGSE Team)]] 11:04, 31 марта 2011 (UTC)<br />
<br />
----<br />
<br />
[[Как писать скрипты, не приводящие к вылетам и бою сейвов|Начало в первой части статьи]]<br />
<br />
----<br />
<br />
= Авторы =<br />
Статья создана: [[Участник:Kamikazze|Kamikazze]]<br />
<br />
[[Категория:Скрипты]]</div>80.93.126.66http://stalkerin.gameru.net/wiki/index.php?title=%D0%A1%D0%BA%D1%80%D0%B8%D0%BF%D1%82%D0%BE%D0%B2%D1%8B%D0%B5_%D1%88%D0%B5%D0%B9%D0%B4%D0%B5%D1%80%D1%8BСкриптовые шейдеры2011-04-17T21:27:37Z<p>80.93.126.66: </p>
<hr />
<div>Редактируя любую модель, многие в свойствах поверхностей замечали графу shader, в которой указывается нечто вроде models/model или подобные.<br />
Как правило эти шейдеры упакованы в shaders.xr и shaders_xrlc.xr, которые представляют собой своеобразную базу данных шейдеров, собранных по определенным шаблонам.<br />
<br />
Но кроме этих баз данных есть еще и скриптовые шейдеры, которые имеют приоритет перед теми шейдерами что упакованы в *.xr. Это файлы, имеющие расширение .s и лежащие в папках соответствующих рендеров. Вычислить правильное название шейдера в БД и шейдерного скрипта .s можно очень просто - для примера если у нас в БД шейдер находится в model/selflight, то имя шейдера должно быть model_selflight.s, если details/blend, то скрипт шейдера будет соответственно details_blend.s . Не так уж сложно.<br />
<br />
Вообще база данных с шейдерами была выдумана не потому что авторам сталкера очень нравилось плодить экземпляры труднораспарсиваемых форматов, а причина более банальна - чтобы увеличить скорость загрузки игры сэкономив за счет активности жесткого диска, при открытии файлов скриптовых шейдеров в папке соответствующего рендера. Плюс к тому, в этом случае уменьшается количество шейдерных файлов что как минимум вдвое уменьшает вероятность ошибки - при условии двух рендеров, эта экономия получается за счет тех шейдеров, которые являются общими для обоих рендеров. Плюс к тому вероятность ошибки еще более уменьшается тем, что базы данных редактируются в сдк, а сдк эти базы данных представляет в виде всевозможных галочек и полей ввода, поэтому ошибка может быть только во вводимых данных, но не в скриптовом коде шейдеров, который вероятнее всего генерируется во время загрузки игры.<br />
<br />
Скриптовые шейдеры используются же в основном только в тех случаях когда их код отличается для разных рендеров.<br />
<br />
По некоторым причинам я считаю что для модостроителей шейдерные скрипты являются более предпочтительными, чем распространение своих шейдерных модов в виде модифицированной .xr-БД. Причины в основном две - во первых скриптовые шейдеры предоставляют бОльшие возможности для полета фантазии :), а во вторых распространение шейдерных модов в виде скриптовых шейдеров все же делает меньше вероятность конфликта модов, так как разные шейдеры будут в разных файлах, а не все вместе в одном хитром и трудноредактируемом, и что самое плохое - трудно-объединяемом файле. Поэтому далее мы рассмотрим скриптовые шейдеры.<br />
<br />
Что собой представляют шейдерные скрипты? Это обычные скрипты на lua, и которые являются своеобразным языком для того чтобы объяснить движку, какие загружать текстуры и какие подключать шейдеры из наличествующих .ps и .vs файлов. <br />
<br />
: ''Для тех кто воспрял духом сразу скажу что несмотря на то, что шейдерные скрипты написаны на языке, который используется в игровых скриптах, это все-таки не одно и то же. Во первых шейдерные скрипты выполняются при загрузке уровня всего один раз (в фазу загрузки "загрузка шейдеров"), поэтому на отрисовку в реальном времени влиять неспособны, и кроме того к игровым скриптам скриптовые шейдеры доступа не имеют.''<br />
<br />
Вот для примера содержимое простейшего скриптового шейдера:<br />
<br />
function normal( shader, t_base, t_second, t_detail )<br />
<br />
shader:begin( "effects_gradient", "effects_gradient_p" )<br />
<br />
end<br />
<br />
Разберем его по косточкам:<br />
<br />
* '''function normal''' - объявление стандартной функции шейдерного скрипта. В некоторых шейдерах есть еще функции '''l_spot''', '''l_point''' и '''l_special''' аналогичного содержания, но явно просчитывающие поведение этого шейдера в условиях освещения<br />
<br />
* '''shader''' - вероятнее всего идентификатор шейдера в игре, содержимое этой переменной представляет собой вероятнее всего текстовую строку вроде "models_selflight" или "models/selflight".<br />
* '''t_base''' - путь к текстуре которую следует выводить с помощью этого шейдера<br />
* '''t_second''', '''t_detail''' - пути к другим текстурам, пока назначение их неизвестно.<br />
<br />
* '''shader:begin( "effects_gradient", "effects_gradient_p" )''' - святая святых шейдера. Если точнее - создание объекта шейдера как такового. <br />
:: '''effects_gradient''' - имя .vs файла используемого в этом шейдере<br />
:: '''effects_gradient_p''' - имя .ps файла соответственно.<br />
<br />
<br />
После этой строки могут быть такие строки (они необязательны)<br />
<br />
<br />
* ''': blend ( true, blend.srcalpha, blend.one )''' - обработка текстур, например полупрозрачные текстуры без применения этой строки будут выглядеть непрозрачными черными в прозрачных местах. Эти методы блендинга соответствуют переключателю в сдк, где варианты ALPHA-ADD, BLEND, SET и так далее. На примере выше блендинг соответствует положению ALPHA-ADD.<br />
<br />
:: '''true''' - может быть '''false''' - включение обработки текстур, тоесть true - обработка включена, false соответственно выключена.<br />
<br />
:: '''blend.srcalpha''', '''blend.one''' - соответственно методы блендинга, могут быть:<br />
<br />
blend.one<br />
blend.zero<br />
null<br />
<br />
Также вот таблица по которой можно выбрать остальные параметры блендинга, выбирая в таблице по порядку слева направо:<br />
<br />
<table style="border: 1px solid #666;" width="470px" height="60px"><br />
<tr><br />
<td>&nbsp;</td><br />
<td bgcolor="#666" width="2px"></td><br />
<td>src</td><br />
<td bgcolor="#666" width="2px"></td><br />
<td>color</td><br />
</tr><br />
<tr><br />
<td height="2px" bgcolor="#666" colspan="5"></td><br />
</tr><br />
<tr><br />
<td>inv</td><br />
<td bgcolor="#666" width="2px"></td><br />
<td>dest</td><br />
<td bgcolor="#666" width="2px"></td><br />
<td>alpha</td><br />
</tr><br />
</table><br />
<br />
то есть:<br />
<br />
blend.srccolor<br />
blend.invsrccolor<br />
blend.destcolor<br />
blend.invdestcolor<br />
blend.srcalpha<br />
blend.invsrcalpha<br />
blend.destalpha<br />
blend.invdestalpha<br />
<br />
: где '''inv''' - инверсия, '''color''' - цвет, '''alpha''' - альфа (коэффициент прозрачности), '''src''' - параметр берется до шейдера, '''dest''' - параметр берется после шейдера.<br />
<br />
* ''': sorting ( 3, false )''' - порядок отрисовки поверхности по отношению к самому объекту, частью которого является поверхность.<br />
<br />
:: '''3''' - цифра порядка отрисовки, где 1 - за объектом, 2 - на уровне с объектом, 3 - спереди объекта (ближе к актору). Как правило при тройке шейдируемая поверхность будет отрисовываться поверх всего, в том числе и оружия.<br />
<br />
:: '''false''' - соответствует галочке "srict sorting" в сдк. Пока назначение неизвестно.<br />
<br />
<br />
* ''': aref ( false, 2 )''' - альфа-референс объекта, оператор, переключающий многобитную альфу текстуры в однобитную.<br />
<br />
:: '''false''' - включение/выключение данной функции.<br />
<br />
:: '''2''' - сам альфа-референс объекта<br />
<br />
<br />
* ''': zb ( false, false )''' - манипуляции с z-буфером, где первый аргумент соответствует галке z-test в сдк, второй - галке z-write.<br />
<br />
* ''': fog ( false )''' - действие представляет собой превращение текстуры в черно-белую и применение к ней функции calc_fogging в common.h шейдеров соответствующего рендера.<br />
<br />
* ''': emissive ( true )''' - применяется в источниках освещения.<br />
<br />
* ''': distort ( true )''' - представляет из себя механизм искажений, аналогичный эффекту искажающегося воздуха в некоторых аномалиях, а также "линза" в главном меню над кнопками.<br />
<br />
* ''': wmark (true)''' - используется в валлмарках<br />
<br />
<br />
----<br />
<br />
<br />
* '''shader : sampler( "s_base" )''' - создание буфера для помещения туда текстуры. Аргумент представляет собой идентификатор, получаемый ps и vs шейдерами, где будет фигурировать как predefined-переменная s_base.<br />
<br />
<br />
''Перечисленные ниже параметры могут быть только ниже сэмплерной строки!''<br />
<br />
<br />
* ''': texture ( t_base ) ''' - помещение в вышеобъявленный буфер текстуры. аргумент этой ф-ции представляет собой путь к текстуре, так что вполне можно указать нечто вроде<br />
<br />
: texture ( "fx\\fx_sun" )<br />
<br />
чтобы в буфер воткнуть текстуру '''gamedata/textures/fx/fx_sun.dds'''<br />
<br />
<br />
* ''': clamp()''' - соответствует галке Texture Clamp в сдк. Википедия [http://en.wikipedia.org/wiki/Clamping_%28graphics%29 отвечает] на этот вопрос весьма туманно. <br />
<br />
* ''': project()''' - используется в шейдере отрисовки неточечного источника света, и предположительно используется для проектирвоания текстуры сэмплера на те объекты которые находятся в пределах сектора сферы.<br />
<br />
* ''': wrap ()''' - Википедия [http://en.wikipedia.org/wiki/Wrapping_%28graphics%29 отвечает] на этот вопрос не менее туманно чем в примере выше.<br />
<br />
<br />
Ниже представлены еще три оператора используемые с сэмплером, назначение которых неизвестно.<br />
<br />
<br />
* ''': f_linear ()'''<br />
<br />
* ''': f_anisotropic ()'''<br />
<br />
* ''': f_none ()'''<br />
<br />
<br />
----<br />
<br />
<br />
Также в папке с шейдерами лежат еще файлы .s (именно такого имени - точка и эс), которые являются для всех *.s-файлов своеобразными заголовочными файлами, функции из файла .s доступны из файлов *.s . На данный момент там имеются функции printf, и закомментированные во втором рендере ф-ции l_point и l_spot, которые отвечают за создание точечного и неточечного источников света соответственно.<br />
<br />
<br />
'''Статья создана участником cjayho'''<br />
<br />
[[Категория:Скрипты]]</div>80.93.126.66http://stalkerin.gameru.net/wiki/index.php?title=%D0%A1%D0%BA%D1%80%D0%B8%D0%BF%D1%82%D0%BE%D0%B2%D1%8B%D0%B5_%D1%88%D0%B5%D0%B9%D0%B4%D0%B5%D1%80%D1%8BСкриптовые шейдеры2011-04-15T00:46:33Z<p>80.93.126.66: </p>
<hr />
<div>Редактируя любую модель, многие в свойствах поверхностей замечали графу shader, в которой указывается нечто вроде models/model или подобные.<br />
Как правило эти шейдеры упакованы в shaders.xr и shaders_xrlc.xr, которые представляют собой своеобразную базу данных шейдеров, собранных по определенным шаблонам.<br />
<br />
Но кроме этих баз данных есть еще и скриптовые шейдеры, которые имеют приоритет перед теми шейдерами что упакованы в *.xr. Это файлы, имеющие расширение .s и лежащие в папках соответствующих рендеров. Вычислить правильное название шейдера в БД и шейдерного скрипта .s можно очень просто - для примера если у нас в БД шейдер находится в model/selflight, то имя шейдера должно быть model_selflight.s, если details/blend, то скрипт шейдера будет соответственно details_blend.s . Не так уж сложно.<br />
<br />
Вообще база данных с шейдерами была выдумана не потому что авторам сталкера очень нравилось плодить экземпляры труднораспарсиваемых форматов, а причина более банальна - чтобы увеличить скорость загрузки игры сэкономив за счет активности жесткого диска, при открытии файлов скриптовых шейдеров в папке соответствующего рендера. Плюс к тому, в этом случае уменьшается количество шейдерных файлов что как минимум вдвое уменьшает вероятность ошибки - при условии двух рендеров, эта экономия получается за счет тех шейдеров, которые являются общими для обоих рендеров. Плюс к тому вероятность ошибки еще более уменьшается тем, что базы данных редактируются в сдк, а сдк эти базы данных представляет в виде всевозможных галочек и полей ввода, поэтому ошибка может быть только во вводимых данных, но не в скриптовом коде шейдеров, который вероятнее всего генерируется во время загрузки игры.<br />
<br />
Скриптовые шейдеры используются же в основном только в тех случаях когда их код отличается для разных рендеров.<br />
<br />
По некоторым причинам я считаю что для модостроителей шейдерные скрипты являются более предпочтительными, чем распространение своих шейдерных модов в виде модифицированной .xr-БД. Причины в основном две - во первых скриптовые шейдеры предоставляют бОльшие возможности для полета фантазии :), а во вторых распространение шейдерных модов в виде скриптовых шейдеров все же делает меньше вероятность конфликта модов, так как разные шейдеры будут в разных файлах, а не все вместе в одном хитром и трудноредактируемом, и что самое плохое - трудно-объединяемом файле. Поэтому далее мы рассмотрим скриптовые шейдеры.<br />
<br />
Что собой представляют шейдерные скрипты? Это обычные скрипты на lua, и которые являются своеобразным языком для того чтобы объяснить движку, какие загружать текстуры и какие подключать шейдеры из наличествующих .ps и .vs файлов. <br />
<br />
: ''Для тех кто воспрял духом сразу скажу что несмотря на то, что шейдерные скрипты написаны на языке, который используется в игровых скриптах, это все-таки не одно и то же. Во первых шейдерные скрипты выполняются при загрузке уровня всего один раз (в фазу загрузки "загрузка шейдеров"), поэтому на отрисовку в реальном времени влиять неспособны, и кроме того к игровым скриптам скриптовые шейдеры доступа не имеют.''<br />
<br />
Вот для примера содержимое простейшего скриптового шейдера:<br />
<br />
function normal( shader, t_base, t_second, t_detail )<br />
<br />
shader:begin( "effects_gradient", "effects_gradient_p" )<br />
<br />
end<br />
<br />
Разберем его по косточкам:<br />
<br />
* '''function normal''' - объявление стандартной функции шейдерного скрипта. В некоторых шейдерах есть еще функции '''l_spot''', '''l_point''' и '''l_special''' аналогичного содержания, но явно просчитывающие поведение этого шейдера в условиях освещения<br />
<br />
* '''shader''' - вероятнее всего идентификатор шейдера в игре, содержимое этой переменной представляет собой вероятнее всего текстовую строку вроде "models_selflight" или "models/selflight".<br />
* '''t_base''' - путь к текстуре которую следует выводить с помощью этого шейдера<br />
* '''t_second''', '''t_detail''' - пути к другим текстурам, пока назначение их неизвестно.<br />
<br />
* '''shader:begin( "effects_gradient", "effects_gradient_p" )''' - святая святых шейдера. Если точнее - создание объекта шейдера как такового. <br />
:: '''effects_gradient''' - имя .vs файла используемого в этом шейдере<br />
:: '''effects_gradient_p''' - имя .ps файла соответственно.<br />
<br />
<br />
После этой строки могут быть такие строки (они необязательны)<br />
<br />
<br />
* ''': blend ( true, blend.srcalpha, blend.one )''' - обработка текстур, например полупрозрачные текстуры без применения этой строки будут выглядеть непрозрачными черными в прозрачных местах. Эти методы блендинга соответствуют переключателю в сдк, где варианты ALPHA-ADD, BLEND, SET и так далее. На примере выше блендинг соответствует положению ALPHA-ADD.<br />
<br />
:: '''true''' - может быть '''false''' - включение обработки текстур, тоесть true - обработка включена, false соответственно выключена.<br />
<br />
:: '''blend.srcalpha''', '''blend.one''' - соответственно методы блендинга, могут быть:<br />
<br />
blend.one<br />
blend.zero<br />
null<br />
<br />
Также вот таблица по которой можно выбрать остальные параметры блендинга, выбирая в таблице по порядку слева направо:<br />
<br />
<table style="border: 1px solid #666;" width="470px" height="60px"><br />
<tr><br />
<td>&nbsp;</td><br />
<td bgcolor="#666" width="2px"></td><br />
<td>src</td><br />
<td bgcolor="#666" width="2px"></td><br />
<td>color</td><br />
</tr><br />
<tr><br />
<td height="2px" bgcolor="#666" colspan="5"></td><br />
</tr><br />
<tr><br />
<td>inv</td><br />
<td bgcolor="#666" width="2px"></td><br />
<td>dest</td><br />
<td bgcolor="#666" width="2px"></td><br />
<td>alpha</td><br />
</tr><br />
</table><br />
<br />
то есть:<br />
<br />
blend.srccolor<br />
blend.invsrccolor<br />
blend.destcolor<br />
blend.invdestcolor<br />
blend.srcalpha<br />
blend.invsrcalpha<br />
blend.destalpha<br />
blend.invdestalpha<br />
<br />
: где '''inv''' - инверсия, '''color''' - цвет, '''alpha''' - альфа (коэффициент прозрачности), '''src''' - параметр берется до шейдера, '''dest''' - параметр берется после шейдера.<br />
<br />
* ''': sorting ( 3, false )''' - порядок отрисовки поверхности по отношению к самому объекту, частью которого является поверхность.<br />
<br />
:: '''3''' - цифра порядка отрисовки, где 1 - за объектом, 2 - на уровне с объектом, 3 - спереди объекта (ближе к актору). Как правило при тройке шейдируемая поверхность будет отрисовываться поверх всего, в том числе и оружия.<br />
<br />
:: '''false''' - соответствует галочке "srict sorting" в сдк. Пока назначение неизвестно.<br />
<br />
<br />
* ''': aref ( false, 2 )''' - альфа-референс объекта, оператор, переключающий многобитную альфу текстуры в однобитную.<br />
<br />
:: '''false''' - включение/выключение данной функции.<br />
<br />
:: '''2''' - сам альфа-референс объекта<br />
<br />
<br />
* ''': zb ( false, false )''' - манипуляции с z-буфером, где первый аргумент соответствует галке z-test в сдк, второй - галке z-write.<br />
<br />
* ''': fog ( false )''' - действие представляет собой превращение текстуры в черно-белую и применение к ней функции calc_fogging в common.h шейдеров соответствующего рендера.<br />
<br />
* ''': emissive ( true )''' - применяется в источниках освещения.<br />
<br />
* ''': distort ( true )''' - представляет из себя механизм искажений, аналогичный эффекту искажающегося воздуха в некоторых аномалиях, а также "линза" в главном меню над кнопками.<br />
<br />
----<br />
<br />
<br />
* '''shader : sampler( "s_base" )''' - создание буфера для помещения туда текстуры. Аргумент представляет собой идентификатор, получаемый ps и vs шейдерами, где будет фигурировать как predefined-переменная s_base.<br />
<br />
<br />
''Перечисленные ниже параметры могут быть только ниже сэмплерной строки!''<br />
<br />
<br />
* ''': texture ( t_base ) ''' - помещение в вышеобъявленный буфер текстуры. аргумент этой ф-ции представляет собой путь к текстуре, так что вполне можно указать нечто вроде<br />
<br />
: texture ( "fx\\fx_sun" )<br />
<br />
чтобы в буфер воткнуть текстуру '''gamedata/textures/fx/fx_sun.dds'''<br />
<br />
<br />
* ''': clamp()''' - соответствует галке Texture Clamp в сдк. Википедия [http://en.wikipedia.org/wiki/Clamping_%28graphics%29 отвечает] на этот вопрос весьма туманно. <br />
<br />
* ''': project()''' - используется в шейдере отрисовки неточечного источника света, и предположительно используется для проектирвоания текстуры сэмплера на те объекты которые находятся в пределах сектора сферы.<br />
<br />
* ''': wrap ()''' - Википедия [http://en.wikipedia.org/wiki/Wrapping_%28graphics%29 отвечает] на этот вопрос не менее туманно чем в примере выше.<br />
<br />
* ''': wmark (true)''' - используется в валлмарках<br />
<br />
<br />
Ниже представлены еще три оператора используемые с сэмплером, назначение которых неизвестно.<br />
<br />
<br />
* ''': f_linear ()'''<br />
<br />
* ''': f_anisotropic ()'''<br />
<br />
* ''': f_none ()'''<br />
<br />
<br />
----<br />
<br />
<br />
Также в папке с шейдерами лежат еще файлы .s (именно такого имени - точка и эс), которые являются для всех *.s-файлов своеобразными заголовочными файлами, функции из файла .s доступны из файлов *.s . На данный момент там имеются функции printf, и закомментированные во втором рендере ф-ции l_point и l_spot, которые отвечают за создание точечного и неточечного источников света соответственно.<br />
<br />
<br />
'''Статья создана участником cjayho'''<br />
<br />
[[Категория:Скрипты]]</div>80.93.126.66http://stalkerin.gameru.net/wiki/index.php?title=%D0%A1%D0%BA%D1%80%D0%B8%D0%BF%D1%82%D0%BE%D0%B2%D1%8B%D0%B5_%D1%88%D0%B5%D0%B9%D0%B4%D0%B5%D1%80%D1%8BСкриптовые шейдеры2011-04-15T00:46:16Z<p>80.93.126.66: </p>
<hr />
<div>Редактируя любую модель, многие в свойствах поверхностей замечали графу shader, в которой указывается нечто вроде models/model или подобные.<br />
Как правило эти шейдеры упакованы в shaders.xr и shaders_xrlc.xr, которые представляют собой своеобразную базу данных шейдеров, собранных по определенным шаблонам.<br />
<br />
Но кроме этих баз данных есть еще и скриптовые шейдеры, которые имеют приоритет перед теми шейдерами что упакованы в *.xr. Это файлы, имеющие расширение .s и лежащие в папках соответствующих рендеров. Вычислить правильное название шейдера в БД и шейдерного скрипта .s можно очень просто - для примера если у нас в БД шейдер находится в model/selflight, то имя шейдера должно быть model_selflight.s, если details/blend, то скрипт шейдера будет соответственно details_blend.s . Не так уж сложно.<br />
<br />
Вообще база данных с шейдерами была выдумана не потому что авторам сталкера очень нравилось плодить экземпляры труднораспарсиваемых форматов, а причина более банальна - чтобы увеличить скорость загрузки игры сэкономив за счет активности жесткого диска, при открытии файлов скриптовых шейдеров в папке соответствующего рендера. Плюс к тому, в этом случае уменьшается количество шейдерных файлов что как минимум вдвое уменьшает вероятность ошибки - при условии двух рендеров, эта экономия получается за счет тех шейдеров, которые являются общими для обоих рендеров. Плюс к тому вероятность ошибки еще более уменьшается тем, что базы данных редактируются в сдк, а сдк эти базы данных представляет в виде всевозможных галочек и полей ввода, поэтому ошибка может быть только во вводимых данных, но не в скриптовом коде шейдеров, который вероятнее всего генерируется во время загрузки игры.<br />
<br />
Скриптовые шейдеры используются же в основном только в тех случаях когда их код отличается для разных рендеров.<br />
<br />
По некоторым причинам я считаю что для модостроителей шейдерные скрипты являются более предпочтительными, чем распространение своих шейдерных модов в виде модифицированной .xr-БД. Причины в основном две - во первых скриптовые шейдеры предоставляют бОльшие возможности для полета фантазии :), а во вторых распространение шейдерных модов в виде скриптовых шейдеров все же делает меньше вероятность конфликта модов, так как разные шейдеры будут в разных файлах, а не все вместе в одном хитром и трудноредактируемом, и что самое плохое - трудно-объединяемом файле. Поэтому далее мы рассмотрим скриптовые шейдеры.<br />
<br />
Что собой представляют шейдерные скрипты? Это обычные скрипты на lua, и которые являются своеобразным языком для того чтобы объяснить движку, какие загружать текстуры и какие подключать шейдеры из наличествующих .ps и .vs файлов. <br />
<br />
: ''Для тех кто воспрял духом сразу скажу что несмотря на то, что шейдерные скрипты написаны на языке, который используется в игровых скриптах, это все-таки не одно и то же. Во первых шейдерные скрипты выполняются при загрузке уровня всего один раз (в фазу загрузки "загрузка шейдеров"), поэтому на отрисовку в реальном времени влиять неспособны, и кроме того к игровым скриптам скриптовые шейдеры доступа не имеют.''<br />
<br />
Вот для примера содержимое простейшего скриптового шейдера:<br />
<br />
function normal( shader, t_base, t_second, t_detail )<br />
<br />
shader:begin( "effects_gradient", "effects_gradient_p" )<br />
<br />
end<br />
<br />
Разберем его по косточкам:<br />
<br />
* '''function normal''' - объявление стандартной функции шейдерного скрипта. В некоторых шейдерах есть еще функции '''l_spot''', '''l_point''' и '''l_special''' аналогичного содержания, но явно просчитывающие поведение этого шейдера в условиях освещения<br />
<br />
* '''shader''' - вероятнее всего идентификатор шейдера в игре, содержимое этой переменной представляет собой вероятнее всего текстовую строку вроде "models_selflight" или "models/selflight".<br />
* '''t_base''' - путь к текстуре которую следует выводить с помощью этого шейдера<br />
* '''t_second''', '''t_detail''' - пути к другим текстурам, пока назначение их неизвестно.<br />
<br />
* '''shader:begin( "effects_gradient", "effects_gradient_p" )''' - святая святых шейдера. Если точнее - создание объекта шейдера как такового. <br />
:: '''effects_gradient''' - имя .vs файла используемого в этом шейдере<br />
:: '''effects_gradient_p''' - имя .ps файла соответственно.<br />
<br />
<br />
После этой строки могут быть такие строки (они необязательны)<br />
<br />
<br />
* ''': blend ( true, blend.srcalpha, blend.one )''' - обработка текстур, например полупрозрачные текстуры без применения этой строки будут выглядеть непрозрачными черными в прозрачных местах. Эти методы блендинга соответствуют переключателю в сдк, где варианты ALPHA-ADD, BLEND, SET и так далее. На примере выше блендинг соответствует положению ALPHA-ADD.<br />
<br />
:: '''true''' - может быть '''false''' - включение обработки текстур, тоесть true - обработка включена, false соответственно выключена.<br />
<br />
:: '''blend.srcalpha''', '''blend.one''' - соответственно методы блендинга, могут быть:<br />
<br />
blend.one<br />
blend.zero<br />
null<br />
<br />
:::: Также вот таблица по которой можно выбрать остальные параметры блендинга, выбирая в таблице по порядку слева направо:<br />
<br />
<table style="border: 1px solid #666;" width="470px" height="60px"><br />
<tr><br />
<td>&nbsp;</td><br />
<td bgcolor="#666" width="2px"></td><br />
<td>src</td><br />
<td bgcolor="#666" width="2px"></td><br />
<td>color</td><br />
</tr><br />
<tr><br />
<td height="2px" bgcolor="#666" colspan="5"></td><br />
</tr><br />
<tr><br />
<td>inv</td><br />
<td bgcolor="#666" width="2px"></td><br />
<td>dest</td><br />
<td bgcolor="#666" width="2px"></td><br />
<td>alpha</td><br />
</tr><br />
</table><br />
<br />
то есть:<br />
<br />
blend.srccolor<br />
blend.invsrccolor<br />
blend.destcolor<br />
blend.invdestcolor<br />
blend.srcalpha<br />
blend.invsrcalpha<br />
blend.destalpha<br />
blend.invdestalpha<br />
<br />
: где '''inv''' - инверсия, '''color''' - цвет, '''alpha''' - альфа (коэффициент прозрачности), '''src''' - параметр берется до шейдера, '''dest''' - параметр берется после шейдера.<br />
<br />
* ''': sorting ( 3, false )''' - порядок отрисовки поверхности по отношению к самому объекту, частью которого является поверхность.<br />
<br />
:: '''3''' - цифра порядка отрисовки, где 1 - за объектом, 2 - на уровне с объектом, 3 - спереди объекта (ближе к актору). Как правило при тройке шейдируемая поверхность будет отрисовываться поверх всего, в том числе и оружия.<br />
<br />
:: '''false''' - соответствует галочке "srict sorting" в сдк. Пока назначение неизвестно.<br />
<br />
<br />
* ''': aref ( false, 2 )''' - альфа-референс объекта, оператор, переключающий многобитную альфу текстуры в однобитную.<br />
<br />
:: '''false''' - включение/выключение данной функции.<br />
<br />
:: '''2''' - сам альфа-референс объекта<br />
<br />
<br />
* ''': zb ( false, false )''' - манипуляции с z-буфером, где первый аргумент соответствует галке z-test в сдк, второй - галке z-write.<br />
<br />
* ''': fog ( false )''' - действие представляет собой превращение текстуры в черно-белую и применение к ней функции calc_fogging в common.h шейдеров соответствующего рендера.<br />
<br />
* ''': emissive ( true )''' - применяется в источниках освещения.<br />
<br />
* ''': distort ( true )''' - представляет из себя механизм искажений, аналогичный эффекту искажающегося воздуха в некоторых аномалиях, а также "линза" в главном меню над кнопками.<br />
<br />
----<br />
<br />
<br />
* '''shader : sampler( "s_base" )''' - создание буфера для помещения туда текстуры. Аргумент представляет собой идентификатор, получаемый ps и vs шейдерами, где будет фигурировать как predefined-переменная s_base.<br />
<br />
<br />
''Перечисленные ниже параметры могут быть только ниже сэмплерной строки!''<br />
<br />
<br />
* ''': texture ( t_base ) ''' - помещение в вышеобъявленный буфер текстуры. аргумент этой ф-ции представляет собой путь к текстуре, так что вполне можно указать нечто вроде<br />
<br />
: texture ( "fx\\fx_sun" )<br />
<br />
чтобы в буфер воткнуть текстуру '''gamedata/textures/fx/fx_sun.dds'''<br />
<br />
<br />
* ''': clamp()''' - соответствует галке Texture Clamp в сдк. Википедия [http://en.wikipedia.org/wiki/Clamping_%28graphics%29 отвечает] на этот вопрос весьма туманно. <br />
<br />
* ''': project()''' - используется в шейдере отрисовки неточечного источника света, и предположительно используется для проектирвоания текстуры сэмплера на те объекты которые находятся в пределах сектора сферы.<br />
<br />
* ''': wrap ()''' - Википедия [http://en.wikipedia.org/wiki/Wrapping_%28graphics%29 отвечает] на этот вопрос не менее туманно чем в примере выше.<br />
<br />
* ''': wmark (true)''' - используется в валлмарках<br />
<br />
<br />
Ниже представлены еще три оператора используемые с сэмплером, назначение которых неизвестно.<br />
<br />
<br />
* ''': f_linear ()'''<br />
<br />
* ''': f_anisotropic ()'''<br />
<br />
* ''': f_none ()'''<br />
<br />
<br />
----<br />
<br />
<br />
Также в папке с шейдерами лежат еще файлы .s (именно такого имени - точка и эс), которые являются для всех *.s-файлов своеобразными заголовочными файлами, функции из файла .s доступны из файлов *.s . На данный момент там имеются функции printf, и закомментированные во втором рендере ф-ции l_point и l_spot, которые отвечают за создание точечного и неточечного источников света соответственно.<br />
<br />
<br />
'''Статья создана участником cjayho'''<br />
<br />
[[Категория:Скрипты]]</div>80.93.126.66http://stalkerin.gameru.net/wiki/index.php?title=%D0%A1%D0%BA%D1%80%D0%B8%D0%BF%D1%82%D0%BE%D0%B2%D1%8B%D0%B5_%D1%88%D0%B5%D0%B9%D0%B4%D0%B5%D1%80%D1%8BСкриптовые шейдеры2011-04-15T00:45:39Z<p>80.93.126.66: </p>
<hr />
<div>Редактируя любую модель, многие в свойствах поверхностей замечали графу shader, в которой указывается нечто вроде models/model или подобные.<br />
Как правило эти шейдеры упакованы в shaders.xr и shaders_xrlc.xr, которые представляют собой своеобразную базу данных шейдеров, собранных по определенным шаблонам.<br />
<br />
Но кроме этих баз данных есть еще и скриптовые шейдеры, которые имеют приоритет перед теми шейдерами что упакованы в *.xr. Это файлы, имеющие расширение .s и лежащие в папках соответствующих рендеров. Вычислить правильное название шейдера в БД и шейдерного скрипта .s можно очень просто - для примера если у нас в БД шейдер находится в model/selflight, то имя шейдера должно быть model_selflight.s, если details/blend, то скрипт шейдера будет соответственно details_blend.s . Не так уж сложно.<br />
<br />
Вообще база данных с шейдерами была выдумана не потому что авторам сталкера очень нравилось плодить экземпляры труднораспарсиваемых форматов, а причина более банальна - чтобы увеличить скорость загрузки игры сэкономив за счет активности жесткого диска, при открытии файлов скриптовых шейдеров в папке соответствующего рендера. Плюс к тому, в этом случае уменьшается количество шейдерных файлов что как минимум вдвое уменьшает вероятность ошибки - при условии двух рендеров, эта экономия получается за счет тех шейдеров, которые являются общими для обоих рендеров. Плюс к тому вероятность ошибки еще более уменьшается тем, что базы данных редактируются в сдк, а сдк эти базы данных представляет в виде всевозможных галочек и полей ввода, поэтому ошибка может быть только во вводимых данных, но не в скриптовом коде шейдеров, который вероятнее всего генерируется во время загрузки игры.<br />
<br />
Скриптовые шейдеры используются же в основном только в тех случаях когда их код отличается для разных рендеров.<br />
<br />
По некоторым причинам я считаю что для модостроителей шейдерные скрипты являются более предпочтительными, чем распространение своих шейдерных модов в виде модифицированной .xr-БД. Причины в основном две - во первых скриптовые шейдеры предоставляют бОльшие возможности для полета фантазии :), а во вторых распространение шейдерных модов в виде скриптовых шейдеров все же делает меньше вероятность конфликта модов, так как разные шейдеры будут в разных файлах, а не все вместе в одном хитром и трудноредактируемом, и что самое плохое - трудно-объединяемом файле. Поэтому далее мы рассмотрим скриптовые шейдеры.<br />
<br />
Что собой представляют шейдерные скрипты? Это обычные скрипты на lua, и которые являются своеобразным языком для того чтобы объяснить движку, какие загружать текстуры и какие подключать шейдеры из наличествующих .ps и .vs файлов. <br />
<br />
: ''Для тех кто воспрял духом сразу скажу что несмотря на то, что шейдерные скрипты написаны на языке, который используется в игровых скриптах, это все-таки не одно и то же. Во первых шейдерные скрипты выполняются при загрузке уровня всего один раз (в фазу загрузки "загрузка шейдеров"), поэтому на отрисовку в реальном времени влиять неспособны, и кроме того к игровым скриптам скриптовые шейдеры доступа не имеют.''<br />
<br />
Вот для примера содержимое простейшего скриптового шейдера:<br />
<br />
function normal( shader, t_base, t_second, t_detail )<br />
<br />
shader:begin( "effects_gradient", "effects_gradient_p" )<br />
<br />
end<br />
<br />
Разберем его по косточкам:<br />
<br />
* '''function normal''' - объявление стандартной функции шейдерного скрипта. В некоторых шейдерах есть еще функции '''l_spot''', '''l_point''' и '''l_special''' аналогичного содержания, но явно просчитывающие поведение этого шейдера в условиях освещения<br />
<br />
* '''shader''' - вероятнее всего идентификатор шейдера в игре, содержимое этой переменной представляет собой вероятнее всего текстовую строку вроде "models_selflight" или "models/selflight".<br />
* '''t_base''' - путь к текстуре которую следует выводить с помощью этого шейдера<br />
* '''t_second''', '''t_detail''' - пути к другим текстурам, пока назначение их неизвестно.<br />
<br />
* '''shader:begin( "effects_gradient", "effects_gradient_p" )''' - святая святых шейдера. Если точнее - создание объекта шейдера как такового. <br />
:: '''effects_gradient''' - имя .vs файла используемого в этом шейдере<br />
:: '''effects_gradient_p''' - имя .ps файла соответственно.<br />
<br />
<br />
После этой строки могут быть такие строки (они необязательны)<br />
<br />
<br />
* ''': blend ( true, blend.srcalpha, blend.one )''' - обработка текстур, например полупрозрачные текстуры без применения этой строки будут выглядеть непрозрачными черными в прозрачных местах. Эти методы блендинга соответствуют переключателю в сдк, где варианты ALPHA-ADD, BLEND, SET и так далее. На примере выше блендинг соответствует положению ALPHA-ADD.<br />
<br />
:: '''true''' - может быть '''false''' - включение обработки текстур, тоесть true - обработка включена, false соответственно выключена.<br />
<br />
:: '''blend.srcalpha''', '''blend.one''' - соответственно методы блендинга, могут быть:<br />
<br />
:::: blend.one<br />
:::: blend.zero<br />
:::: null<br />
<br />
:::: Также вот таблица по которой можно выбрать остальные параметры блендинга, выбирая в таблице по порядку слева направо:<br />
<br />
<table style="border: 1px solid #666;" width="470px" height="60px"><br />
<tr><br />
<td>&nbsp;</td><br />
<td bgcolor="#666" width="2px"></td><br />
<td>src</td><br />
<td bgcolor="#666" width="2px"></td><br />
<td>color</td><br />
</tr><br />
<tr><br />
<td height="2px" bgcolor="#666" colspan="5"></td><br />
</tr><br />
<tr><br />
<td>inv</td><br />
<td bgcolor="#666" width="2px"></td><br />
<td>dest</td><br />
<td bgcolor="#666" width="2px"></td><br />
<td>alpha</td><br />
</tr><br />
</table><br />
<br />
то есть:<br />
<br />
blend.srccolor<br />
blend.invsrccolor<br />
blend.destcolor<br />
blend.invdestcolor<br />
blend.srcalpha<br />
blend.invsrcalpha<br />
blend.destalpha<br />
blend.invdestalpha<br />
<br />
: где '''inv''' - инверсия, '''color''' - цвет, '''alpha''' - альфа (коэффициент прозрачности), '''src''' - параметр берется до шейдера, '''dest''' - параметр берется после шейдера.<br />
<br />
* ''': sorting ( 3, false )''' - порядок отрисовки поверхности по отношению к самому объекту, частью которого является поверхность.<br />
<br />
:: '''3''' - цифра порядка отрисовки, где 1 - за объектом, 2 - на уровне с объектом, 3 - спереди объекта (ближе к актору). Как правило при тройке шейдируемая поверхность будет отрисовываться поверх всего, в том числе и оружия.<br />
<br />
:: '''false''' - соответствует галочке "srict sorting" в сдк. Пока назначение неизвестно.<br />
<br />
<br />
* ''': aref ( false, 2 )''' - альфа-референс объекта, оператор, переключающий многобитную альфу текстуры в однобитную.<br />
<br />
:: '''false''' - включение/выключение данной функции.<br />
<br />
:: '''2''' - сам альфа-референс объекта<br />
<br />
<br />
* ''': zb ( false, false )''' - манипуляции с z-буфером, где первый аргумент соответствует галке z-test в сдк, второй - галке z-write.<br />
<br />
* ''': fog ( false )''' - действие представляет собой превращение текстуры в черно-белую и применение к ней функции calc_fogging в common.h шейдеров соответствующего рендера.<br />
<br />
* ''': emissive ( true )''' - применяется в источниках освещения.<br />
<br />
* ''': distort ( true )''' - представляет из себя механизм искажений, аналогичный эффекту искажающегося воздуха в некоторых аномалиях, а также "линза" в главном меню над кнопками.<br />
<br />
----<br />
<br />
<br />
* '''shader : sampler( "s_base" )''' - создание буфера для помещения туда текстуры. Аргумент представляет собой идентификатор, получаемый ps и vs шейдерами, где будет фигурировать как predefined-переменная s_base.<br />
<br />
<br />
''Перечисленные ниже параметры могут быть только ниже сэмплерной строки!''<br />
<br />
<br />
* ''': texture ( t_base ) ''' - помещение в вышеобъявленный буфер текстуры. аргумент этой ф-ции представляет собой путь к текстуре, так что вполне можно указать нечто вроде<br />
<br />
: texture ( "fx\\fx_sun" )<br />
<br />
чтобы в буфер воткнуть текстуру '''gamedata/textures/fx/fx_sun.dds'''<br />
<br />
<br />
* ''': clamp()''' - соответствует галке Texture Clamp в сдк. Википедия [http://en.wikipedia.org/wiki/Clamping_%28graphics%29 отвечает] на этот вопрос весьма туманно. <br />
<br />
* ''': project()''' - используется в шейдере отрисовки неточечного источника света, и предположительно используется для проектирвоания текстуры сэмплера на те объекты которые находятся в пределах сектора сферы.<br />
<br />
* ''': wrap ()''' - Википедия [http://en.wikipedia.org/wiki/Wrapping_%28graphics%29 отвечает] на этот вопрос не менее туманно чем в примере выше.<br />
<br />
* ''': wmark (true)''' - используется в валлмарках<br />
<br />
<br />
Ниже представлены еще три оператора используемые с сэмплером, назначение которых неизвестно.<br />
<br />
<br />
* ''': f_linear ()'''<br />
<br />
* ''': f_anisotropic ()'''<br />
<br />
* ''': f_none ()'''<br />
<br />
<br />
----<br />
<br />
<br />
Также в папке с шейдерами лежат еще файлы .s (именно такого имени - точка и эс), которые являются для всех *.s-файлов своеобразными заголовочными файлами, функции из файла .s доступны из файлов *.s . На данный момент там имеются функции printf, и закомментированные во втором рендере ф-ции l_point и l_spot, которые отвечают за создание точечного и неточечного источников света соответственно.<br />
<br />
<br />
'''Статья создана участником cjayho'''<br />
<br />
[[Категория:Скрипты]]</div>80.93.126.66http://stalkerin.gameru.net/wiki/index.php?title=%D0%A1%D0%BA%D1%80%D0%B8%D0%BF%D1%82%D0%BE%D0%B2%D1%8B%D0%B5_%D1%88%D0%B5%D0%B9%D0%B4%D0%B5%D1%80%D1%8BСкриптовые шейдеры2011-04-15T00:40:40Z<p>80.93.126.66: </p>
<hr />
<div>Редактируя любую модель, многие в свойствах поверхностей замечали графу shader, в которой указывается нечто вроде models/model или подобные.<br />
Как правило эти шейдеры упакованы в shaders.xr и shaders_xrlc.xr, которые представляют собой своеобразную базу данных шейдеров, собранных по определенным шаблонам.<br />
<br />
Но кроме этих баз данных есть еще и скриптовые шейдеры, которые имеют приоритет перед теми шейдерами что упакованы в *.xr. Это файлы, имеющие расширение .s и лежащие в папках соответствующих рендеров. Вычислить правильное название шейдера в БД и шейдерного скрипта .s можно очень просто - для примера если у нас в БД шейдер находится в model/selflight, то имя шейдера должно быть model_selflight.s, если details/blend, то скрипт шейдера будет соответственно details_blend.s . Не так уж сложно.<br />
<br />
Вообще база данных с шейдерами была выдумана не потому что авторам сталкера очень нравилось плодить экземпляры труднораспарсиваемых форматов, а причина более банальна - чтобы увеличить скорость загрузки игры сэкономив за счет активности жесткого диска, при открытии файлов скриптовых шейдеров в папке соответствующего рендера. Плюс к тому, в этом случае уменьшается количество шейдерных файлов что как минимум вдвое уменьшает вероятность ошибки - при условии двух рендеров, эта экономия получается за счет тех шейдеров, которые являются общими для обоих рендеров. Плюс к тому вероятность ошибки еще более уменьшается тем, что базы данных редактируются в сдк, а сдк эти базы данных представляет в виде всевозможных галочек и полей ввода, поэтому ошибка может быть только во вводимых данных, но не в скриптовом коде шейдеров, который вероятнее всего генерируется во время загрузки игры.<br />
<br />
Скриптовые шейдеры используются же в основном только в тех случаях когда их код отличается для разных рендеров.<br />
<br />
По некоторым причинам я считаю что для модостроителей шейдерные скрипты являются более предпочтительными, чем распространение своих шейдерных модов в виде модифицированной .xr-БД. Причины в основном две - во первых скриптовые шейдеры предоставляют бОльшие возможности для полета фантазии :), а во вторых распространение шейдерных модов в виде скриптовых шейдеров все же делает меньше вероятность конфликта модов, так как разные шейдеры будут в разных файлах, а не все вместе в одном хитром и трудноредактируемом, и что самое плохое - трудно-объединяемом файле. Поэтому далее мы рассмотрим скриптовые шейдеры.<br />
<br />
Что собой представляют шейдерные скрипты? Это обычные скрипты на lua, и которые являются своеобразным языком для того чтобы объяснить движку, какие загружать текстуры и какие подключать шейдеры из наличествующих .ps и .vs файлов. <br />
<br />
: ''Для тех кто воспрял духом сразу скажу что несмотря на то, что шейдерные скрипты написаны на языке, который используется в игровых скриптах, это все-таки не одно и то же. Во первых шейдерные скрипты выполняются при загрузке уровня всего один раз (в фазу загрузки "загрузка шейдеров"), поэтому на отрисовку в реальном времени влиять неспособны, и кроме того к игровым скриптам скриптовые шейдеры доступа не имеют.''<br />
<br />
Вот для примера содержимое простейшего скриптового шейдера:<br />
<br />
function normal( shader, t_base, t_second, t_detail )<br />
<br />
shader:begin( "effects_gradient", "effects_gradient_p" )<br />
<br />
end<br />
<br />
Разберем его по косточкам:<br />
<br />
* '''function normal''' - объявление стандартной функции шейдерного скрипта. В некоторых шейдерах есть еще функции '''l_spot''', '''l_point''' и '''l_special''' аналогичного содержания, но явно просчитывающие поведение этого шейдера в условиях освещения<br />
<br />
* '''shader''' - вероятнее всего идентификатор шейдера в игре, содержимое этой переменной представляет собой вероятнее всего текстовую строку вроде "models_selflight" или "models/selflight".<br />
* '''t_base''' - путь к текстуре которую следует выводить с помощью этого шейдера<br />
* '''t_second''', '''t_detail''' - пути к другим текстурам, пока назначение их неизвестно.<br />
<br />
* '''shader:begin( "effects_gradient", "effects_gradient_p" )''' - святая святых шейдера. Если точнее - создание объекта шейдера как такового. <br />
:: '''effects_gradient''' - имя .vs файла используемого в этом шейдере<br />
:: '''effects_gradient_p''' - имя .ps файла соответственно.<br />
<br />
<br />
После этой строки могут быть такие строки (они необязательны)<br />
<br />
<br />
* ''': blend ( true, blend.srcalpha, blend.one )''' - обработка текстур, например полупрозрачные текстуры без применения этой строки будут выглядеть непрозрачными черными в прозрачных местах. Эти методы блендинга соответствуют переключателю в сдк, где варианты ALPHA-ADD, BLEND, SET и так далее. На примере выше блендинг соответствует положению ALPHA-ADD.<br />
<br />
:: '''true''' - может быть '''false''' - включение обработки текстур, тоесть true - обработка включена, false соответственно выключена.<br />
<br />
:: '''blend.srcalpha''', '''blend.one''' - соответственно методы блендинга, могут быть:<br />
<br />
:::: blend.one<br />
:::: blend.zero<br />
:::: null<br />
<br />
:::: Также вот таблица по которой можно выбрать остальные параметры блендинга, выбирая в таблице по порядку слева направо:<br />
<br />
::::<table style="border: 1px solid #666;" width="470px" height="60px"><br />
<tr><br />
<td>&nbsp;</td><br />
<td bgcolor="#666" width="2px"></td><br />
<td>src</td><br />
<td bgcolor="#666" width="2px"></td><br />
<td>color</td><br />
</tr><br />
<tr><br />
<td height="2px" bgcolor="#666" colspan="5"></td><br />
</tr><br />
<tr><br />
<td>inv</td><br />
<td bgcolor="#666" width="2px"></td><br />
<td>dest</td><br />
<td bgcolor="#666" width="2px"></td><br />
<td>alpha</td><br />
</tr><br />
</table><br />
<br />
то есть:<br />
<br />
blend.srccolor<br />
blend.invsrccolor<br />
blend.destcolor<br />
blend.invdestcolor<br />
blend.srcalpha<br />
blend.invsrcalpha<br />
blend.destalpha<br />
blend.invdestalpha<br />
<br />
<br />
<br />
* ''': sorting ( 3, false )''' - порядок отрисовки поверхности по отношению к самому объекту, частью которого является поверхность.<br />
<br />
:: '''3''' - цифра порядка отрисовки, где 1 - за объектом, 2 - на уровне с объектом, 3 - спереди объекта (ближе к актору). Как правило при тройке шейдируемая поверхность будет отрисовываться поверх всего, в том числе и оружия.<br />
<br />
:: '''false''' - соответствует галочке "srict sorting" в сдк. Пока назначение неизвестно.<br />
<br />
<br />
* ''': aref ( false, 2 )''' - альфа-референс объекта, оператор, переключающий многобитную альфу текстуры в однобитную.<br />
<br />
:: '''false''' - включение/выключение данной функции.<br />
<br />
:: '''2''' - сам альфа-референс объекта<br />
<br />
<br />
* ''': zb ( false, false )''' - манипуляции с z-буфером, где первый аргумент соответствует галке z-test в сдк, второй - галке z-write.<br />
<br />
* ''': fog ( false )''' - действие представляет собой превращение текстуры в черно-белую и применение к ней функции calc_fogging в common.h шейдеров соответствующего рендера.<br />
<br />
* ''': emissive ( true )''' - применяется в источниках освещения.<br />
<br />
* ''': distort ( true )''' - представляет из себя механизм искажений, аналогичный эффекту искажающегося воздуха в некоторых аномалиях, а также "линза" в главном меню над кнопками.<br />
<br />
----<br />
<br />
<br />
* '''shader : sampler( "s_base" )''' - создание буфера для помещения туда текстуры. Аргумент представляет собой идентификатор, получаемый ps и vs шейдерами, где будет фигурировать как predefined-переменная s_base.<br />
<br />
<br />
''Перечисленные ниже параметры могут быть только ниже сэмплерной строки!''<br />
<br />
<br />
* ''': texture ( t_base ) ''' - помещение в вышеобъявленный буфер текстуры. аргумент этой ф-ции представляет собой путь к текстуре, так что вполне можно указать нечто вроде<br />
<br />
: texture ( "fx\\fx_sun" )<br />
<br />
чтобы в буфер воткнуть текстуру '''gamedata/textures/fx/fx_sun.dds'''<br />
<br />
<br />
* ''': clamp()''' - соответствует галке Texture Clamp в сдк. Википедия [http://en.wikipedia.org/wiki/Clamping_%28graphics%29 отвечает] на этот вопрос весьма туманно. <br />
<br />
* ''': project()''' - используется в шейдере отрисовки неточечного источника света, и предположительно используется для проектирвоания текстуры сэмплера на те объекты которые находятся в пределах сектора сферы.<br />
<br />
* ''': wrap ()''' - Википедия [http://en.wikipedia.org/wiki/Wrapping_%28graphics%29 отвечает] на этот вопрос не менее туманно чем в примере выше.<br />
<br />
* ''': wmark (true)''' - используется в валлмарках<br />
<br />
<br />
Ниже представлены еще три оператора используемые с сэмплером, назначение которых неизвестно.<br />
<br />
<br />
* ''': f_linear ()'''<br />
<br />
* ''': f_anisotropic ()'''<br />
<br />
* ''': f_none ()'''<br />
<br />
<br />
----<br />
<br />
<br />
Также в папке с шейдерами лежат еще файлы .s (именно такого имени - точка и эс), которые являются для всех *.s-файлов своеобразными заголовочными файлами, функции из файла .s доступны из файлов *.s . На данный момент там имеются функции printf, и закомментированные во втором рендере ф-ции l_point и l_spot, которые отвечают за создание точечного и неточечного источников света соответственно.<br />
<br />
<br />
'''Статья создана участником cjayho'''<br />
<br />
[[Категория:Скрипты]]</div>80.93.126.66http://stalkerin.gameru.net/wiki/index.php?title=%D0%A1%D0%BA%D1%80%D0%B8%D0%BF%D1%82%D0%BE%D0%B2%D1%8B%D0%B5_%D1%88%D0%B5%D0%B9%D0%B4%D0%B5%D1%80%D1%8BСкриптовые шейдеры2011-04-15T00:39:57Z<p>80.93.126.66: </p>
<hr />
<div>Редактируя любую модель, многие в свойствах поверхностей замечали графу shader, в которой указывается нечто вроде models/model или подобные.<br />
Как правило эти шейдеры упакованы в shaders.xr и shaders_xrlc.xr, которые представляют собой своеобразную базу данных шейдеров, собранных по определенным шаблонам.<br />
<br />
Но кроме этих баз данных есть еще и скриптовые шейдеры, которые имеют приоритет перед теми шейдерами что упакованы в *.xr. Это файлы, имеющие расширение .s и лежащие в папках соответствующих рендеров. Вычислить правильное название шейдера в БД и шейдерного скрипта .s можно очень просто - для примера если у нас в БД шейдер находится в model/selflight, то имя шейдера должно быть model_selflight.s, если details/blend, то скрипт шейдера будет соответственно details_blend.s . Не так уж сложно.<br />
<br />
Вообще база данных с шейдерами была выдумана не потому что авторам сталкера очень нравилось плодить экземпляры труднораспарсиваемых форматов, а причина более банальна - чтобы увеличить скорость загрузки игры сэкономив за счет активности жесткого диска, при открытии файлов скриптовых шейдеров в папке соответствующего рендера. Плюс к тому, в этом случае уменьшается количество шейдерных файлов что как минимум вдвое уменьшает вероятность ошибки - при условии двух рендеров, эта экономия получается за счет тех шейдеров, которые являются общими для обоих рендеров. Плюс к тому вероятность ошибки еще более уменьшается тем, что базы данных редактируются в сдк, а сдк эти базы данных представляет в виде всевозможных галочек и полей ввода, поэтому ошибка может быть только во вводимых данных, но не в скриптовом коде шейдеров, который вероятнее всего генерируется во время загрузки игры.<br />
<br />
Скриптовые шейдеры используются же в основном только в тех случаях когда их код отличается для разных рендеров.<br />
<br />
По некоторым причинам я считаю что для модостроителей шейдерные скрипты являются более предпочтительными, чем распространение своих шейдерных модов в виде модифицированной .xr-БД. Причины в основном две - во первых скриптовые шейдеры предоставляют бОльшие возможности для полета фантазии :), а во вторых распространение шейдерных модов в виде скриптовых шейдеров все же делает меньше вероятность конфликта модов, так как разные шейдеры будут в разных файлах, а не все вместе в одном хитром и трудноредактируемом, и что самое плохое - трудно-объединяемом файле. Поэтому далее мы рассмотрим скриптовые шейдеры.<br />
<br />
Что собой представляют шейдерные скрипты? Это обычные скрипты на lua, и которые являются своеобразным языком для того чтобы объяснить движку, какие загружать текстуры и какие подключать шейдеры из наличествующих .ps и .vs файлов. <br />
<br />
: ''Для тех кто воспрял духом сразу скажу что несмотря на то, что шейдерные скрипты написаны на языке, который используется в игровых скриптах, это все-таки не одно и то же. Во первых шейдерные скрипты выполняются при загрузке уровня всего один раз (в фазу загрузки "загрузка шейдеров"), поэтому на отрисовку в реальном времени влиять неспособны, и кроме того к игровым скриптам скриптовые шейдеры доступа не имеют.''<br />
<br />
Вот для примера содержимое простейшего скриптового шейдера:<br />
<br />
function normal( shader, t_base, t_second, t_detail )<br />
<br />
shader:begin( "effects_gradient", "effects_gradient_p" )<br />
<br />
end<br />
<br />
Разберем его по косточкам:<br />
<br />
* '''function normal''' - объявление стандартной функции шейдерного скрипта. В некоторых шейдерах есть еще функции '''l_spot''', '''l_point''' и '''l_special''' аналогичного содержания, но явно просчитывающие поведение этого шейдера в условиях освещения<br />
<br />
* '''shader''' - вероятнее всего идентификатор шейдера в игре, содержимое этой переменной представляет собой вероятнее всего текстовую строку вроде "models_selflight" или "models/selflight".<br />
* '''t_base''' - путь к текстуре которую следует выводить с помощью этого шейдера<br />
* '''t_second''', '''t_detail''' - пути к другим текстурам, пока назначение их неизвестно.<br />
<br />
* '''shader:begin( "effects_gradient", "effects_gradient_p" )''' - святая святых шейдера. Если точнее - создание объекта шейдера как такового. <br />
:: '''effects_gradient''' - имя .vs файла используемого в этом шейдере<br />
:: '''effects_gradient_p''' - имя .ps файла соответственно.<br />
<br />
<br />
После этой строки могут быть такие строки (они необязательны)<br />
<br />
<br />
* ''': blend ( true, blend.srcalpha, blend.one )''' - обработка текстур, например полупрозрачные текстуры без применения этой строки будут выглядеть непрозрачными черными в прозрачных местах. Эти методы блендинга соответствуют переключателю в сдк, где варианты ALPHA-ADD, BLEND, SET и так далее. На примере выше блендинг соответствует положению ALPHA-ADD.<br />
<br />
:: '''true''' - может быть '''false''' - включение обработки текстур, тоесть true - обработка включена, false соответственно выключена.<br />
<br />
:: '''blend.srcalpha''', '''blend.one''' - соответственно методы блендинга, могут быть:<br />
<br />
:::: blend.one<br />
:::: blend.zero<br />
:::: null<br />
<br />
:::: Также вот таблица по которой можно выбрать остальные параметры блендинга, выбирая в таблице по порядку слева направо:<br />
<br />
::::<table style="border: 1px solid #666;" width="470px" height="60px"><br />
<tr><br />
<td>inv</td><br />
<td bgcolor="#666" width="2px"></td><br />
<td>src</td><br />
<td bgcolor="#666" width="2px"></td><br />
<td>color</td><br />
</tr><br />
<tr><br />
<td height="2px" bgcolor="#666" colspan="5"></td><br />
</tr><br />
<tr><br />
<td>&nbsp;</td><br />
<td bgcolor="#666" width="2px"></td><br />
<td>dest</td><br />
<td bgcolor="#666" width="2px"></td><br />
<td>alpha</td><br />
</tr><br />
</table><br />
<br />
то есть:<br />
<br />
blend.srccolor<br />
blend.invsrccolor<br />
blend.destcolor<br />
blend.invdestcolor<br />
blend.srcalpha<br />
blend.invsrcalpha<br />
blend.destalpha<br />
blend.invdestalpha<br />
<br />
<br />
<br />
* ''': sorting ( 3, false )''' - порядок отрисовки поверхности по отношению к самому объекту, частью которого является поверхность.<br />
<br />
:: '''3''' - цифра порядка отрисовки, где 1 - за объектом, 2 - на уровне с объектом, 3 - спереди объекта (ближе к актору). Как правило при тройке шейдируемая поверхность будет отрисовываться поверх всего, в том числе и оружия.<br />
<br />
:: '''false''' - соответствует галочке "srict sorting" в сдк. Пока назначение неизвестно.<br />
<br />
<br />
* ''': aref ( false, 2 )''' - альфа-референс объекта, оператор, переключающий многобитную альфу текстуры в однобитную.<br />
<br />
:: '''false''' - включение/выключение данной функции.<br />
<br />
:: '''2''' - сам альфа-референс объекта<br />
<br />
<br />
* ''': zb ( false, false )''' - манипуляции с z-буфером, где первый аргумент соответствует галке z-test в сдк, второй - галке z-write.<br />
<br />
* ''': fog ( false )''' - действие представляет собой превращение текстуры в черно-белую и применение к ней функции calc_fogging в common.h шейдеров соответствующего рендера.<br />
<br />
* ''': emissive ( true )''' - применяется в источниках освещения.<br />
<br />
* ''': distort ( true )''' - представляет из себя механизм искажений, аналогичный эффекту искажающегося воздуха в некоторых аномалиях, а также "линза" в главном меню над кнопками.<br />
<br />
----<br />
<br />
<br />
* '''shader : sampler( "s_base" )''' - создание буфера для помещения туда текстуры. Аргумент представляет собой идентификатор, получаемый ps и vs шейдерами, где будет фигурировать как predefined-переменная s_base.<br />
<br />
<br />
''Перечисленные ниже параметры могут быть только ниже сэмплерной строки!''<br />
<br />
<br />
* ''': texture ( t_base ) ''' - помещение в вышеобъявленный буфер текстуры. аргумент этой ф-ции представляет собой путь к текстуре, так что вполне можно указать нечто вроде<br />
<br />
: texture ( "fx\\fx_sun" )<br />
<br />
чтобы в буфер воткнуть текстуру '''gamedata/textures/fx/fx_sun.dds'''<br />
<br />
<br />
* ''': clamp()''' - соответствует галке Texture Clamp в сдк. Википедия [http://en.wikipedia.org/wiki/Clamping_%28graphics%29 отвечает] на этот вопрос весьма туманно. <br />
<br />
* ''': project()''' - используется в шейдере отрисовки неточечного источника света, и предположительно используется для проектирвоания текстуры сэмплера на те объекты которые находятся в пределах сектора сферы.<br />
<br />
* ''': wrap ()''' - Википедия [http://en.wikipedia.org/wiki/Wrapping_%28graphics%29 отвечает] на этот вопрос не менее туманно чем в примере выше.<br />
<br />
* ''': wmark (true)''' - используется в валлмарках<br />
<br />
<br />
Ниже представлены еще три оператора используемые с сэмплером, назначение которых неизвестно.<br />
<br />
<br />
* ''': f_linear ()'''<br />
<br />
* ''': f_anisotropic ()'''<br />
<br />
* ''': f_none ()'''<br />
<br />
<br />
----<br />
<br />
<br />
Также в папке с шейдерами лежат еще файлы .s (именно такого имени - точка и эс), которые являются для всех *.s-файлов своеобразными заголовочными файлами, функции из файла .s доступны из файлов *.s . На данный момент там имеются функции printf, и закомментированные во втором рендере ф-ции l_point и l_spot, которые отвечают за создание точечного и неточечного источников света соответственно.<br />
<br />
<br />
'''Статья создана участником cjayho'''<br />
<br />
[[Категория:Скрипты]]</div>80.93.126.66http://stalkerin.gameru.net/wiki/index.php?title=%D0%A1%D0%BA%D1%80%D0%B8%D0%BF%D1%82%D0%BE%D0%B2%D1%8B%D0%B5_%D1%88%D0%B5%D0%B9%D0%B4%D0%B5%D1%80%D1%8BСкриптовые шейдеры2011-04-15T00:39:39Z<p>80.93.126.66: </p>
<hr />
<div>Редактируя любую модель, многие в свойствах поверхностей замечали графу shader, в которой указывается нечто вроде models/model или подобные.<br />
Как правило эти шейдеры упакованы в shaders.xr и shaders_xrlc.xr, которые представляют собой своеобразную базу данных шейдеров, собранных по определенным шаблонам.<br />
<br />
Но кроме этих баз данных есть еще и скриптовые шейдеры, которые имеют приоритет перед теми шейдерами что упакованы в *.xr. Это файлы, имеющие расширение .s и лежащие в папках соответствующих рендеров. Вычислить правильное название шейдера в БД и шейдерного скрипта .s можно очень просто - для примера если у нас в БД шейдер находится в model/selflight, то имя шейдера должно быть model_selflight.s, если details/blend, то скрипт шейдера будет соответственно details_blend.s . Не так уж сложно.<br />
<br />
Вообще база данных с шейдерами была выдумана не потому что авторам сталкера очень нравилось плодить экземпляры труднораспарсиваемых форматов, а причина более банальна - чтобы увеличить скорость загрузки игры сэкономив за счет активности жесткого диска, при открытии файлов скриптовых шейдеров в папке соответствующего рендера. Плюс к тому, в этом случае уменьшается количество шейдерных файлов что как минимум вдвое уменьшает вероятность ошибки - при условии двух рендеров, эта экономия получается за счет тех шейдеров, которые являются общими для обоих рендеров. Плюс к тому вероятность ошибки еще более уменьшается тем, что базы данных редактируются в сдк, а сдк эти базы данных представляет в виде всевозможных галочек и полей ввода, поэтому ошибка может быть только во вводимых данных, но не в скриптовом коде шейдеров, который вероятнее всего генерируется во время загрузки игры.<br />
<br />
Скриптовые шейдеры используются же в основном только в тех случаях когда их код отличается для разных рендеров.<br />
<br />
По некоторым причинам я считаю что для модостроителей шейдерные скрипты являются более предпочтительными, чем распространение своих шейдерных модов в виде модифицированной .xr-БД. Причины в основном две - во первых скриптовые шейдеры предоставляют бОльшие возможности для полета фантазии :), а во вторых распространение шейдерных модов в виде скриптовых шейдеров все же делает меньше вероятность конфликта модов, так как разные шейдеры будут в разных файлах, а не все вместе в одном хитром и трудноредактируемом, и что самое плохое - трудно-объединяемом файле. Поэтому далее мы рассмотрим скриптовые шейдеры.<br />
<br />
Что собой представляют шейдерные скрипты? Это обычные скрипты на lua, и которые являются своеобразным языком для того чтобы объяснить движку, какие загружать текстуры и какие подключать шейдеры из наличествующих .ps и .vs файлов. <br />
<br />
: ''Для тех кто воспрял духом сразу скажу что несмотря на то, что шейдерные скрипты написаны на языке, который используется в игровых скриптах, это все-таки не одно и то же. Во первых шейдерные скрипты выполняются при загрузке уровня всего один раз (в фазу загрузки "загрузка шейдеров"), поэтому на отрисовку в реальном времени влиять неспособны, и кроме того к игровым скриптам скриптовые шейдеры доступа не имеют.''<br />
<br />
Вот для примера содержимое простейшего скриптового шейдера:<br />
<br />
function normal( shader, t_base, t_second, t_detail )<br />
<br />
shader:begin( "effects_gradient", "effects_gradient_p" )<br />
<br />
end<br />
<br />
Разберем его по косточкам:<br />
<br />
* '''function normal''' - объявление стандартной функции шейдерного скрипта. В некоторых шейдерах есть еще функции '''l_spot''', '''l_point''' и '''l_special''' аналогичного содержания, но явно просчитывающие поведение этого шейдера в условиях освещения<br />
<br />
* '''shader''' - вероятнее всего идентификатор шейдера в игре, содержимое этой переменной представляет собой вероятнее всего текстовую строку вроде "models_selflight" или "models/selflight".<br />
* '''t_base''' - путь к текстуре которую следует выводить с помощью этого шейдера<br />
* '''t_second''', '''t_detail''' - пути к другим текстурам, пока назначение их неизвестно.<br />
<br />
* '''shader:begin( "effects_gradient", "effects_gradient_p" )''' - святая святых шейдера. Если точнее - создание объекта шейдера как такового. <br />
:: '''effects_gradient''' - имя .vs файла используемого в этом шейдере<br />
:: '''effects_gradient_p''' - имя .ps файла соответственно.<br />
<br />
<br />
После этой строки могут быть такие строки (они необязательны)<br />
<br />
<br />
* ''': blend ( true, blend.srcalpha, blend.one )''' - обработка текстур, например полупрозрачные текстуры без применения этой строки будут выглядеть непрозрачными черными в прозрачных местах. Эти методы блендинга соответствуют переключателю в сдк, где варианты ALPHA-ADD, BLEND, SET и так далее. На примере выше блендинг соответствует положению ALPHA-ADD.<br />
<br />
:: '''true''' - может быть '''false''' - включение обработки текстур, тоесть true - обработка включена, false соответственно выключена.<br />
<br />
:: '''blend.srcalpha''', '''blend.one''' - соответственно методы блендинга, могут быть:<br />
<br />
:::: blend.one<br />
:::: blend.zero<br />
:::: null<br />
<br />
:::: Также вот таблица по которой можно выбрать остальные параметры блендинга, выбирая в таблице по порядку слева направо:<br />
<br />
::::<table style="border: 1px solid #666;" width="470px" height="60px"><br />
<tr><br />
<td>inv</td><br />
<td bgcolor="#666" width="2px"></td><br />
<td>src</td><br />
<td bgcolor="#666" width="2px"></td><br />
<td>color</td><br />
</tr><br />
<tr><br />
<td height="2px" bgcolor="#666" colspan="5"></td><br />
</tr><br />
<tr><br />
<td>&nbsp;</td><br />
<td bgcolor="#666" width="2px"></td><br />
<td>dest</td><br />
<td bgcolor="#666" width="2px"></td><br />
<td>alpha</td><br />
</tr><br />
</table><br />
<br />
то есть:<br />
<br />
blend.srccolor<br />
blend.invsrccolor<br />
blend.destcolor<br />
blend.invdestcolor<br />
blend.srcalpha<br />
blend.invsrcalpha<br />
blend.destalpha<br />
blend.invdestalpha<br />
<br />
<br />
<br />
* ''': sorting ( 3, false )''' - порядок отрисовки поверхности по отношению к самому объекту, частью которого является поверхность.<br />
<br />
:: '''3''' - цифра порядка отрисовки, где 1 - за объектом, 2 - на уровне с объектом, 3 - спереди объекта (ближе к актору). Как правило при тройке шейдируемая поверхность будет отрисовываться поверх всего, в том числе и оружия.<br />
<br />
:: '''false''' - соответствует галочке "srict sorting" в сдк. Пока назначение неизвестно.<br />
<br />
<br />
* ''': aref ( false, 2 )''' - альфа-референс объекта, оператор, переключающий многобитную альфу текстуры в однобитную.<br />
<br />
:: '''false''' - включение/выключение данной функции.<br />
<br />
:: '''2''' - сам альфа-референс объекта<br />
<br />
<br />
* ''': zb ( false, false )''' - манипуляции с z-буфером, где первый аргумент соответствует галке z-test в сдк, второй - галке z-write.<br />
<br />
* ''': fog ( false )''' - действие представляет собой превращение текстуры в черно-белую и применение к ней функции calc_fogging в common.h шейдеров соответствующего рендера.<br />
<br />
* ''': emissive ( true )''' - применяется в источниках освещения.<br />
<br />
* ''': distort ( true )''' - представляет из себя механизм искажений, аналогичный эффекту искажающегося воздуха в некоторых аномалиях, а также "линза" в главном меню над кнопками.<br />
<br />
----<br />
<br />
<br />
* '''shader : sampler( "s_base" )''' - создание буфера для помещения туда текстуры. Аргумент представляет собой идентификатор, получаемый ps и vs шейдерами, где будет фигурировать как predefined-переменная s_base.<br />
<br />
<br />
''Перечисленные ниже параметры могут быть только ниже сэмплерной строки!''<br />
<br />
<br />
* ''': texture ( t_base ) ''' - помещение в вышеобъявленный буфер текстуры. аргумент этой ф-ции представляет собой путь к текстуре, так что вполне можно указать нечто вроде<br />
<br />
: texture ( "fx\\fx_sun" )<br />
<br />
чтобы в буфер воткнуть текстуру '''gamedata/textures/fx/fx_sun.dds'''<br />
<br />
<br />
* ''': clamp()''' - соответствует галке Texture Clamp в сдк. Википедия [http://en.wikipedia.org/wiki/Clamping_%28graphics%29 отвечает] на этот вопрос весьма туманно. <br />
<br />
* ''': project()''' - используется в шейдере отрисовки неточечного источника света, и предположительно используется для проектирвоания текстуры сэмплера на те объекты которые находятся в пределах сектора сферы.<br />
<br />
* ''': wrap ()''' - Википедия [http://en.wikipedia.org/wiki/Wrapping_%28graphics%29 отвечает] на этот вопрос не менее туманно чем в примере выше.<br />
<br />
* ''': wmark (true)''' - используется в валлмарках<br />
<br />
<br />
Ниже представлены еще три оператора используемые с сэмплером, назначение которых неизвестно.<br />
<br />
<br />
* ''': f_linear ()'''<br />
<br />
* ''': f_anisotropic ()'''<br />
<br />
* ''': f_none ()'''<br />
<br />
<br />
----<br />
<br />
<br />
Также в папке с шейдерами лежат еще файлы .s (именно такого имени - точка и эс), которые являются для всех *.s-файлов своеобразными заголовочными файлами, функции из файла .s доступны из файлов *.s . На данный момент там имеются функции printf, и закомментированные во втором рендере ф-ции l_point и l_spot, которые отвечают за создание точечного и неточечного источников света соответственно.<br />
<br />
<br />
'''Статья создана участником cjayho'''<br />
<br />
[[Категория:Скрипты]]</div>80.93.126.66http://stalkerin.gameru.net/wiki/index.php?title=%D0%A1%D0%BA%D1%80%D0%B8%D0%BF%D1%82%D0%BE%D0%B2%D1%8B%D0%B5_%D1%88%D0%B5%D0%B9%D0%B4%D0%B5%D1%80%D1%8BСкриптовые шейдеры2011-04-15T00:39:11Z<p>80.93.126.66: </p>
<hr />
<div>Редактируя любую модель, многие в свойствах поверхностей замечали графу shader, в которой указывается нечто вроде models/model или подобные.<br />
Как правило эти шейдеры упакованы в shaders.xr и shaders_xrlc.xr, которые представляют собой своеобразную базу данных шейдеров, собранных по определенным шаблонам.<br />
<br />
Но кроме этих баз данных есть еще и скриптовые шейдеры, которые имеют приоритет перед теми шейдерами что упакованы в *.xr. Это файлы, имеющие расширение .s и лежащие в папках соответствующих рендеров. Вычислить правильное название шейдера в БД и шейдерного скрипта .s можно очень просто - для примера если у нас в БД шейдер находится в model/selflight, то имя шейдера должно быть model_selflight.s, если details/blend, то скрипт шейдера будет соответственно details_blend.s . Не так уж сложно.<br />
<br />
Вообще база данных с шейдерами была выдумана не потому что авторам сталкера очень нравилось плодить экземпляры труднораспарсиваемых форматов, а причина более банальна - чтобы увеличить скорость загрузки игры сэкономив за счет активности жесткого диска, при открытии файлов скриптовых шейдеров в папке соответствующего рендера. Плюс к тому, в этом случае уменьшается количество шейдерных файлов что как минимум вдвое уменьшает вероятность ошибки - при условии двух рендеров, эта экономия получается за счет тех шейдеров, которые являются общими для обоих рендеров. Плюс к тому вероятность ошибки еще более уменьшается тем, что базы данных редактируются в сдк, а сдк эти базы данных представляет в виде всевозможных галочек и полей ввода, поэтому ошибка может быть только во вводимых данных, но не в скриптовом коде шейдеров, который вероятнее всего генерируется во время загрузки игры.<br />
<br />
Скриптовые шейдеры используются же в основном только в тех случаях когда их код отличается для разных рендеров.<br />
<br />
По некоторым причинам я считаю что для модостроителей шейдерные скрипты являются более предпочтительными, чем распространение своих шейдерных модов в виде модифицированной .xr-БД. Причины в основном две - во первых скриптовые шейдеры предоставляют бОльшие возможности для полета фантазии :), а во вторых распространение шейдерных модов в виде скриптовых шейдеров все же делает меньше вероятность конфликта модов, так как разные шейдеры будут в разных файлах, а не все вместе в одном хитром и трудноредактируемом, и что самое плохое - трудно-объединяемом файле. Поэтому далее мы рассмотрим скриптовые шейдеры.<br />
<br />
Что собой представляют шейдерные скрипты? Это обычные скрипты на lua, и которые являются своеобразным языком для того чтобы объяснить движку, какие загружать текстуры и какие подключать шейдеры из наличествующих .ps и .vs файлов. <br />
<br />
: ''Для тех кто воспрял духом сразу скажу что несмотря на то, что шейдерные скрипты написаны на языке, который используется в игровых скриптах, это все-таки не одно и то же. Во первых шейдерные скрипты выполняются при загрузке уровня всего один раз (в фазу загрузки "загрузка шейдеров"), поэтому на отрисовку в реальном времени влиять неспособны, и кроме того к игровым скриптам скриптовые шейдеры доступа не имеют.''<br />
<br />
Вот для примера содержимое простейшего скриптового шейдера:<br />
<br />
function normal( shader, t_base, t_second, t_detail )<br />
<br />
shader:begin( "effects_gradient", "effects_gradient_p" )<br />
<br />
end<br />
<br />
Разберем его по косточкам:<br />
<br />
* '''function normal''' - объявление стандартной функции шейдерного скрипта. В некоторых шейдерах есть еще функции '''l_spot''', '''l_point''' и '''l_special''' аналогичного содержания, но явно просчитывающие поведение этого шейдера в условиях освещения<br />
<br />
* '''shader''' - вероятнее всего идентификатор шейдера в игре, содержимое этой переменной представляет собой вероятнее всего текстовую строку вроде "models_selflight" или "models/selflight".<br />
* '''t_base''' - путь к текстуре которую следует выводить с помощью этого шейдера<br />
* '''t_second''', '''t_detail''' - пути к другим текстурам, пока назначение их неизвестно.<br />
<br />
* '''shader:begin( "effects_gradient", "effects_gradient_p" )''' - святая святых шейдера. Если точнее - создание объекта шейдера как такового. <br />
:: '''effects_gradient''' - имя .vs файла используемого в этом шейдере<br />
:: '''effects_gradient_p''' - имя .ps файла соответственно.<br />
<br />
<br />
После этой строки могут быть такие строки (они необязательны)<br />
<br />
<br />
* ''': blend ( true, blend.srcalpha, blend.one )''' - обработка текстур, например полупрозрачные текстуры без применения этой строки будут выглядеть непрозрачными черными в прозрачных местах. Эти методы блендинга соответствуют переключателю в сдк, где варианты ALPHA-ADD, BLEND, SET и так далее. На примере выше блендинг соответствует положению ALPHA-ADD.<br />
<br />
:: '''true''' - может быть '''false''' - включение обработки текстур, тоесть true - обработка включена, false соответственно выключена.<br />
<br />
:: '''blend.srcalpha''', '''blend.one''' - соответственно методы блендинга, могут быть:<br />
<br />
:::: blend.one<br />
:::: blend.zero<br />
:::: null<br />
<br />
:::: Также вот таблица по которой можно выбрать остальные параметры блендинга, выбирая в таблице по порядку слева направо:<br />
<br />
::::<table style="border: 1px solid #666;" width="470px" height="60px"><br />
<tr><br />
<td>inv</td><br />
<td bgcolor="#666" width="2px"></td><br />
<td>src</td><br />
<td bgcolor="#666" width="2px"></td><br />
<td>color</td><br />
</tr><br />
<tr><br />
<td height="2px" bgcolor="#666" colspan="5"></td><br />
</tr><br />
<tr><br />
<td>&nbsp;</td><br />
<td bgcolor="#666" width="2px"></td><br />
<td>dest</td><br />
<td bgcolor="#666" width="2px"></td><br />
<td>alpha</td><br />
</tr><br />
</table><br />
<br />
::: то есть:<br />
<br />
::: blend.srccolor<br />
::: blend.invsrccolor<br />
::: blend.destcolor<br />
::: blend.invdestcolor<br />
::: blend.srcalpha<br />
::: blend.invsrcalpha<br />
::: blend.destalpha<br />
::: blend.invdestalpha<br />
<br />
<br />
<br />
* ''': sorting ( 3, false )''' - порядок отрисовки поверхности по отношению к самому объекту, частью которого является поверхность.<br />
<br />
:: '''3''' - цифра порядка отрисовки, где 1 - за объектом, 2 - на уровне с объектом, 3 - спереди объекта (ближе к актору). Как правило при тройке шейдируемая поверхность будет отрисовываться поверх всего, в том числе и оружия.<br />
<br />
:: '''false''' - соответствует галочке "srict sorting" в сдк. Пока назначение неизвестно.<br />
<br />
<br />
* ''': aref ( false, 2 )''' - альфа-референс объекта, оператор, переключающий многобитную альфу текстуры в однобитную.<br />
<br />
:: '''false''' - включение/выключение данной функции.<br />
<br />
:: '''2''' - сам альфа-референс объекта<br />
<br />
<br />
* ''': zb ( false, false )''' - манипуляции с z-буфером, где первый аргумент соответствует галке z-test в сдк, второй - галке z-write.<br />
<br />
* ''': fog ( false )''' - действие представляет собой превращение текстуры в черно-белую и применение к ней функции calc_fogging в common.h шейдеров соответствующего рендера.<br />
<br />
* ''': emissive ( true )''' - применяется в источниках освещения.<br />
<br />
* ''': distort ( true )''' - представляет из себя механизм искажений, аналогичный эффекту искажающегося воздуха в некоторых аномалиях, а также "линза" в главном меню над кнопками.<br />
<br />
----<br />
<br />
<br />
* '''shader : sampler( "s_base" )''' - создание буфера для помещения туда текстуры. Аргумент представляет собой идентификатор, получаемый ps и vs шейдерами, где будет фигурировать как predefined-переменная s_base.<br />
<br />
<br />
''Перечисленные ниже параметры могут быть только ниже сэмплерной строки!''<br />
<br />
<br />
* ''': texture ( t_base ) ''' - помещение в вышеобъявленный буфер текстуры. аргумент этой ф-ции представляет собой путь к текстуре, так что вполне можно указать нечто вроде<br />
<br />
: texture ( "fx\\fx_sun" )<br />
<br />
чтобы в буфер воткнуть текстуру '''gamedata/textures/fx/fx_sun.dds'''<br />
<br />
<br />
* ''': clamp()''' - соответствует галке Texture Clamp в сдк. Википедия [http://en.wikipedia.org/wiki/Clamping_%28graphics%29 отвечает] на этот вопрос весьма туманно. <br />
<br />
* ''': project()''' - используется в шейдере отрисовки неточечного источника света, и предположительно используется для проектирвоания текстуры сэмплера на те объекты которые находятся в пределах сектора сферы.<br />
<br />
* ''': wrap ()''' - Википедия [http://en.wikipedia.org/wiki/Wrapping_%28graphics%29 отвечает] на этот вопрос не менее туманно чем в примере выше.<br />
<br />
* ''': wmark (true)''' - используется в валлмарках<br />
<br />
<br />
Ниже представлены еще три оператора используемые с сэмплером, назначение которых неизвестно.<br />
<br />
<br />
* ''': f_linear ()'''<br />
<br />
* ''': f_anisotropic ()'''<br />
<br />
* ''': f_none ()'''<br />
<br />
<br />
----<br />
<br />
<br />
Также в папке с шейдерами лежат еще файлы .s (именно такого имени - точка и эс), которые являются для всех *.s-файлов своеобразными заголовочными файлами, функции из файла .s доступны из файлов *.s . На данный момент там имеются функции printf, и закомментированные во втором рендере ф-ции l_point и l_spot, которые отвечают за создание точечного и неточечного источников света соответственно.<br />
<br />
<br />
'''Статья создана участником cjayho'''<br />
<br />
[[Категория:Скрипты]]</div>80.93.126.66http://stalkerin.gameru.net/wiki/index.php?title=%D0%A1%D0%BA%D1%80%D0%B8%D0%BF%D1%82%D0%BE%D0%B2%D1%8B%D0%B5_%D1%88%D0%B5%D0%B9%D0%B4%D0%B5%D1%80%D1%8BСкриптовые шейдеры2011-04-15T00:38:32Z<p>80.93.126.66: </p>
<hr />
<div>Редактируя любую модель, многие в свойствах поверхностей замечали графу shader, в которой указывается нечто вроде models/model или подобные.<br />
Как правило эти шейдеры упакованы в shaders.xr и shaders_xrlc.xr, которые представляют собой своеобразную базу данных шейдеров, собранных по определенным шаблонам.<br />
<br />
Но кроме этих баз данных есть еще и скриптовые шейдеры, которые имеют приоритет перед теми шейдерами что упакованы в *.xr. Это файлы, имеющие расширение .s и лежащие в папках соответствующих рендеров. Вычислить правильное название шейдера в БД и шейдерного скрипта .s можно очень просто - для примера если у нас в БД шейдер находится в model/selflight, то имя шейдера должно быть model_selflight.s, если details/blend, то скрипт шейдера будет соответственно details_blend.s . Не так уж сложно.<br />
<br />
Вообще база данных с шейдерами была выдумана не потому что авторам сталкера очень нравилось плодить экземпляры труднораспарсиваемых форматов, а причина более банальна - чтобы увеличить скорость загрузки игры сэкономив за счет активности жесткого диска, при открытии файлов скриптовых шейдеров в папке соответствующего рендера. Плюс к тому, в этом случае уменьшается количество шейдерных файлов что как минимум вдвое уменьшает вероятность ошибки - при условии двух рендеров, эта экономия получается за счет тех шейдеров, которые являются общими для обоих рендеров. Плюс к тому вероятность ошибки еще более уменьшается тем, что базы данных редактируются в сдк, а сдк эти базы данных представляет в виде всевозможных галочек и полей ввода, поэтому ошибка может быть только во вводимых данных, но не в скриптовом коде шейдеров, который вероятнее всего генерируется во время загрузки игры.<br />
<br />
Скриптовые шейдеры используются же в основном только в тех случаях когда их код отличается для разных рендеров.<br />
<br />
По некоторым причинам я считаю что для модостроителей шейдерные скрипты являются более предпочтительными, чем распространение своих шейдерных модов в виде модифицированной .xr-БД. Причины в основном две - во первых скриптовые шейдеры предоставляют бОльшие возможности для полета фантазии :), а во вторых распространение шейдерных модов в виде скриптовых шейдеров все же делает меньше вероятность конфликта модов, так как разные шейдеры будут в разных файлах, а не все вместе в одном хитром и трудноредактируемом, и что самое плохое - трудно-объединяемом файле. Поэтому далее мы рассмотрим скриптовые шейдеры.<br />
<br />
Что собой представляют шейдерные скрипты? Это обычные скрипты на lua, и которые являются своеобразным языком для того чтобы объяснить движку, какие загружать текстуры и какие подключать шейдеры из наличествующих .ps и .vs файлов. <br />
<br />
: ''Для тех кто воспрял духом сразу скажу что несмотря на то, что шейдерные скрипты написаны на языке, который используется в игровых скриптах, это все-таки не одно и то же. Во первых шейдерные скрипты выполняются при загрузке уровня всего один раз (в фазу загрузки "загрузка шейдеров"), поэтому на отрисовку в реальном времени влиять неспособны, и кроме того к игровым скриптам скриптовые шейдеры доступа не имеют.''<br />
<br />
Вот для примера содержимое простейшего скриптового шейдера:<br />
<br />
function normal( shader, t_base, t_second, t_detail )<br />
<br />
shader:begin( "effects_gradient", "effects_gradient_p" )<br />
<br />
end<br />
<br />
Разберем его по косточкам:<br />
<br />
* '''function normal''' - объявление стандартной функции шейдерного скрипта. В некоторых шейдерах есть еще функции '''l_spot''', '''l_point''' и '''l_special''' аналогичного содержания, но явно просчитывающие поведение этого шейдера в условиях освещения<br />
<br />
* '''shader''' - вероятнее всего идентификатор шейдера в игре, содержимое этой переменной представляет собой вероятнее всего текстовую строку вроде "models_selflight" или "models/selflight".<br />
* '''t_base''' - путь к текстуре которую следует выводить с помощью этого шейдера<br />
* '''t_second''', '''t_detail''' - пути к другим текстурам, пока назначение их неизвестно.<br />
<br />
* '''shader:begin( "effects_gradient", "effects_gradient_p" )''' - святая святых шейдера. Если точнее - создание объекта шейдера как такового. <br />
:: '''effects_gradient''' - имя .vs файла используемого в этом шейдере<br />
:: '''effects_gradient_p''' - имя .ps файла соответственно.<br />
<br />
<br />
После этой строки могут быть такие строки (они необязательны)<br />
<br />
<br />
* ''': blend ( true, blend.srcalpha, blend.one )''' - обработка текстур, например полупрозрачные текстуры без применения этой строки будут выглядеть непрозрачными черными в прозрачных местах. Эти методы блендинга соответствуют переключателю в сдк, где варианты ALPHA-ADD, BLEND, SET и так далее. На примере выше блендинг соответствует положению ALPHA-ADD.<br />
<br />
:: '''true''' - может быть '''false''' - включение обработки текстур, тоесть true - обработка включена, false соответственно выключена.<br />
<br />
:: '''blend.srcalpha''', '''blend.one''' - соответственно методы блендинга, могут быть:<br />
<br />
:::: blend.one<br />
:::: blend.zero<br />
:::: null<br />
<br />
::: Также вот таблица по которой можно выбрать остальные параметры блендинга, выбирая в таблице по порядку слева направо:<br />
<br />
::::<table style="border: 1px solid #666;" width="470px" height="60px"><br />
<tr><br />
<td>inv</td><br />
<td bgcolor="#666" width="2px"></td><br />
<td>src</td><br />
<td bgcolor="#666" width="2px"></td><br />
<td>color</td><br />
</tr><br />
<tr><br />
<td height="2px" bgcolor="#666" colspan="5"></td><br />
</tr><br />
<tr><br />
<td>&nbsp;</td><br />
<td bgcolor="#666" width="2px"></td><br />
<td>dest</td><br />
<td bgcolor="#666" width="2px"></td><br />
<td>alpha</td><br />
</tr><br />
</table><br />
<br />
:::: то есть:<br />
<br />
:::: blend.srccolor<br />
:::: blend.invsrccolor<br />
:::: blend.destcolor<br />
:::: blend.invdestcolor<br />
:::: blend.srcalpha<br />
:::: blend.invsrcalpha<br />
:::: blend.destalpha<br />
:::: blend.invdestalpha<br />
<br />
<br />
<br />
* ''': sorting ( 3, false )''' - порядок отрисовки поверхности по отношению к самому объекту, частью которого является поверхность.<br />
<br />
:: '''3''' - цифра порядка отрисовки, где 1 - за объектом, 2 - на уровне с объектом, 3 - спереди объекта (ближе к актору). Как правило при тройке шейдируемая поверхность будет отрисовываться поверх всего, в том числе и оружия.<br />
<br />
:: '''false''' - соответствует галочке "srict sorting" в сдк. Пока назначение неизвестно.<br />
<br />
<br />
* ''': aref ( false, 2 )''' - альфа-референс объекта, оператор, переключающий многобитную альфу текстуры в однобитную.<br />
<br />
:: '''false''' - включение/выключение данной функции.<br />
<br />
:: '''2''' - сам альфа-референс объекта<br />
<br />
<br />
* ''': zb ( false, false )''' - манипуляции с z-буфером, где первый аргумент соответствует галке z-test в сдк, второй - галке z-write.<br />
<br />
* ''': fog ( false )''' - действие представляет собой превращение текстуры в черно-белую и применение к ней функции calc_fogging в common.h шейдеров соответствующего рендера.<br />
<br />
* ''': emissive ( true )''' - применяется в источниках освещения.<br />
<br />
* ''': distort ( true )''' - представляет из себя механизм искажений, аналогичный эффекту искажающегося воздуха в некоторых аномалиях, а также "линза" в главном меню над кнопками.<br />
<br />
----<br />
<br />
<br />
* '''shader : sampler( "s_base" )''' - создание буфера для помещения туда текстуры. Аргумент представляет собой идентификатор, получаемый ps и vs шейдерами, где будет фигурировать как predefined-переменная s_base.<br />
<br />
<br />
''Перечисленные ниже параметры могут быть только ниже сэмплерной строки!''<br />
<br />
<br />
* ''': texture ( t_base ) ''' - помещение в вышеобъявленный буфер текстуры. аргумент этой ф-ции представляет собой путь к текстуре, так что вполне можно указать нечто вроде<br />
<br />
: texture ( "fx\\fx_sun" )<br />
<br />
чтобы в буфер воткнуть текстуру '''gamedata/textures/fx/fx_sun.dds'''<br />
<br />
<br />
* ''': clamp()''' - соответствует галке Texture Clamp в сдк. Википедия [http://en.wikipedia.org/wiki/Clamping_%28graphics%29 отвечает] на этот вопрос весьма туманно. <br />
<br />
* ''': project()''' - используется в шейдере отрисовки неточечного источника света, и предположительно используется для проектирвоания текстуры сэмплера на те объекты которые находятся в пределах сектора сферы.<br />
<br />
* ''': wrap ()''' - Википедия [http://en.wikipedia.org/wiki/Wrapping_%28graphics%29 отвечает] на этот вопрос не менее туманно чем в примере выше.<br />
<br />
* ''': wmark (true)''' - используется в валлмарках<br />
<br />
<br />
Ниже представлены еще три оператора используемые с сэмплером, назначение которых неизвестно.<br />
<br />
<br />
* ''': f_linear ()'''<br />
<br />
* ''': f_anisotropic ()'''<br />
<br />
* ''': f_none ()'''<br />
<br />
<br />
----<br />
<br />
<br />
Также в папке с шейдерами лежат еще файлы .s (именно такого имени - точка и эс), которые являются для всех *.s-файлов своеобразными заголовочными файлами, функции из файла .s доступны из файлов *.s . На данный момент там имеются функции printf, и закомментированные во втором рендере ф-ции l_point и l_spot, которые отвечают за создание точечного и неточечного источников света соответственно.<br />
<br />
<br />
'''Статья создана участником cjayho'''<br />
<br />
[[Категория:Скрипты]]</div>80.93.126.66http://stalkerin.gameru.net/wiki/index.php?title=%D0%A1%D0%BA%D1%80%D0%B8%D0%BF%D1%82%D0%BE%D0%B2%D1%8B%D0%B5_%D1%88%D0%B5%D0%B9%D0%B4%D0%B5%D1%80%D1%8BСкриптовые шейдеры2011-04-14T11:22:02Z<p>80.93.126.66: </p>
<hr />
<div>Редактируя любую модель, многие в свойствах поверхностей замечали графу shader, в которой указывается нечто вроде models/model или подобные.<br />
Как правило эти шейдеры упакованы в shaders.xr и shaders_xrlc.xr, которые представляют собой своеобразную базу данных шейдеров, собранных по определенным шаблонам.<br />
<br />
Но кроме этих баз данных есть еще и скриптовые шейдеры, которые имеют приоритет перед теми шейдерами что упакованы в *.xr. Это файлы, имеющие расширение .s и лежащие в папках соответствующих рендеров. Вычислить правильное название шейдера в БД и шейдерного скрипта .s можно очень просто - для примера если у нас в БД шейдер находится в model/selflight, то имя шейдера должно быть model_selflight.s, если details/blend, то скрипт шейдера будет соответственно details_blend.s . Не так уж сложно.<br />
<br />
Вообще база данных с шейдерами была выдумана не потому что авторам сталкера очень нравилось плодить экземпляры труднораспарсиваемых форматов, а причина более банальна - чтобы увеличить скорость загрузки игры сэкономив за счет активности жесткого диска, при открытии файлов скриптовых шейдеров в папке соответствующего рендера. Плюс к тому, в этом случае уменьшается количество шейдерных файлов что как минимум вдвое уменьшает вероятность ошибки - при условии двух рендеров, эта экономия получается за счет тех шейдеров, которые являются общими для обоих рендеров. Плюс к тому вероятность ошибки еще более уменьшается тем, что базы данных редактируются в сдк, а сдк эти базы данных представляет в виде всевозможных галочек и полей ввода, поэтому ошибка может быть только во вводимых данных, но не в скриптовом коде шейдеров, который вероятнее всего генерируется во время загрузки игры.<br />
<br />
Скриптовые шейдеры используются же в основном только в тех случаях когда их код отличается для разных рендеров.<br />
<br />
По некоторым причинам я считаю что для модостроителей шейдерные скрипты являются более предпочтительными, чем распространение своих шейдерных модов в виде модифицированной .xr-БД. Причины в основном две - во первых скриптовые шейдеры предоставляют бОльшие возможности для полета фантазии :), а во вторых распространение шейдерных модов в виде скриптовых шейдеров все же делает меньше вероятность конфликта модов, так как разные шейдеры будут в разных файлах, а не все вместе в одном хитром и трудноредактируемом, и что самое плохое - трудно-объединяемом файле. Поэтому далее мы рассмотрим скриптовые шейдеры.<br />
<br />
Что собой представляют шейдерные скрипты? Это обычные скрипты на lua, и которые являются своеобразным языком для того чтобы объяснить движку, какие загружать текстуры и какие подключать шейдеры из наличествующих .ps и .vs файлов. <br />
<br />
: ''Для тех кто воспрял духом сразу скажу что несмотря на то, что шейдерные скрипты написаны на языке, который используется в игровых скриптах, это все-таки не одно и то же. Во первых шейдерные скрипты выполняются при загрузке уровня всего один раз (в фазу загрузки "загрузка шейдеров"), поэтому на отрисовку в реальном времени влиять неспособны, и кроме того к игровым скриптам скриптовые шейдеры доступа не имеют.''<br />
<br />
Вот для примера содержимое простейшего скриптового шейдера:<br />
<br />
function normal( shader, t_base, t_second, t_detail )<br />
<br />
shader:begin( "effects_gradient", "effects_gradient_p" )<br />
<br />
end<br />
<br />
Разберем его по косточкам:<br />
<br />
* '''function normal''' - объявление стандартной функции шейдерного скрипта. В некоторых шейдерах есть еще функции '''l_spot''', '''l_point''' и '''l_special''' аналогичного содержания, но явно просчитывающие поведение этого шейдера в условиях освещения<br />
<br />
* '''shader''' - вероятнее всего идентификатор шейдера в игре, содержимое этой переменной представляет собой вероятнее всего текстовую строку вроде "models_selflight" или "models/selflight".<br />
* '''t_base''' - путь к текстуре которую следует выводить с помощью этого шейдера<br />
* '''t_second''', '''t_detail''' - пути к другим текстурам, пока назначение их неизвестно.<br />
<br />
* '''shader:begin( "effects_gradient", "effects_gradient_p" )''' - святая святых шейдера. Если точнее - создание объекта шейдера как такового. <br />
:: '''effects_gradient''' - имя .vs файла используемого в этом шейдере<br />
:: '''effects_gradient_p''' - имя .ps файла соответственно.<br />
<br />
<br />
После этой строки могут быть такие строки (они необязательны)<br />
<br />
<br />
* ''': blend ( true, blend.srcalpha, blend.one )''' - обработка текстур, например полупрозрачные текстуры без применения этой строки будут выглядеть непрозрачными черными в прозрачных местах. Эти методы блендинга соответствуют переключателю в сдк, где варианты ALPHA-ADD, BLEND, SET и так далее. На примере выше блендинг соответствует положению ALPHA-ADD.<br />
<br />
:: '''true''' - может быть '''false''' - включение обработки текстур, тоесть true - обработка включена, false соответственно выключена.<br />
<br />
:: '''blend.srcalpha''', '''blend.one''' - соответственно методы блендинга, могут быть:<br />
<br />
:::: blend.one<br />
:::: blend.zero<br />
:::: blend.srcalpha<br />
:::: blend.invsrcalpha<br />
:::: blend.srccolor<br />
:::: blend.destcolor<br />
:::: null<br />
<br />
::: Вероятнее всего также существуют директивы<br />
<br />
:::: blend.destalpha<br />
:::: blend.invdestalpha<br />
:::: blend.invsrccolor<br />
:::: blend.invdestcolor.<br />
<br />
* ''': sorting ( 3, false )''' - порядок отрисовки поверхности по отношению к самому объекту, частью которого является поверхность.<br />
<br />
:: '''3''' - цифра порядка отрисовки, где 1 - за объектом, 2 - на уровне с объектом, 3 - спереди объекта (ближе к актору). Как правило при тройке шейдируемая поверхность будет отрисовываться поверх всего, в том числе и оружия.<br />
<br />
:: '''false''' - соответствует галочке "srict sorting" в сдк. Пока назначение неизвестно.<br />
<br />
<br />
* ''': aref ( false, 2 )''' - альфа-референс объекта, оператор, переключающий многобитную альфу текстуры в однобитную.<br />
<br />
:: '''false''' - включение/выключение данной функции.<br />
<br />
:: '''2''' - сам альфа-референс объекта<br />
<br />
<br />
* ''': zb ( false, false )''' - манипуляции с z-буфером, где первый аргумент соответствует галке z-test в сдк, второй - галке z-write.<br />
<br />
* ''': fog ( false )''' - действие представляет собой превращение текстуры в черно-белую и применение к ней функции calc_fogging в common.h шейдеров соответствующего рендера.<br />
<br />
* ''': emissive ( true )''' - применяется в источниках освещения.<br />
<br />
* ''': distort ( true )''' - представляет из себя механизм искажений, аналогичный эффекту искажающегося воздуха в некоторых аномалиях, а также "линза" в главном меню над кнопками.<br />
<br />
----<br />
<br />
<br />
* '''shader : sampler( "s_base" )''' - создание буфера для помещения туда текстуры. Аргумент представляет собой идентификатор, получаемый ps и vs шейдерами, где будет фигурировать как predefined-переменная s_base.<br />
<br />
<br />
''Перечисленные ниже параметры могут быть только ниже сэмплерной строки!''<br />
<br />
<br />
* ''': texture ( t_base ) ''' - помещение в вышеобъявленный буфер текстуры. аргумент этой ф-ции представляет собой путь к текстуре, так что вполне можно указать нечто вроде<br />
<br />
: texture ( "fx\\fx_sun" )<br />
<br />
чтобы в буфер воткнуть текстуру '''gamedata/textures/fx/fx_sun.dds'''<br />
<br />
<br />
* ''': clamp()''' - соответствует галке Texture Clamp в сдк. Википедия [http://en.wikipedia.org/wiki/Clamping_%28graphics%29 отвечает] на этот вопрос весьма туманно. <br />
<br />
* ''': project()''' - используется в шейдере отрисовки неточечного источника света, и предположительно используется для проектирвоания текстуры сэмплера на те объекты которые находятся в пределах сектора сферы.<br />
<br />
* ''': wrap ()''' - Википедия [http://en.wikipedia.org/wiki/Wrapping_%28graphics%29 отвечает] на этот вопрос не менее туманно чем в примере выше.<br />
<br />
* ''': wmark (true)''' - используется в валлмарках<br />
<br />
<br />
Ниже представлены еще три оператора используемые с сэмплером, назначение которых неизвестно.<br />
<br />
<br />
* ''': f_linear ()'''<br />
<br />
* ''': f_anisotropic ()'''<br />
<br />
* ''': f_none ()'''<br />
<br />
<br />
----<br />
<br />
<br />
Также в папке с шейдерами лежат еще файлы .s (именно такого имени - точка и эс), которые являются для всех *.s-файлов своеобразными заголовочными файлами, функции из файла .s доступны из файлов *.s . На данный момент там имеются функции printf, и закомментированные во втором рендере ф-ции l_point и l_spot, которые отвечают за создание точечного и неточечного источников света соответственно.<br />
<br />
<br />
'''Статья создана участником cjayho'''<br />
<br />
[[Категория:Скрипты]]</div>80.93.126.66http://stalkerin.gameru.net/wiki/index.php?title=%D0%A1%D0%BA%D1%80%D0%B8%D0%BF%D1%82%D0%BE%D0%B2%D1%8B%D0%B5_%D1%88%D0%B5%D0%B9%D0%B4%D0%B5%D1%80%D1%8BСкриптовые шейдеры2011-04-14T11:21:01Z<p>80.93.126.66: </p>
<hr />
<div>Редактируя любую модель, многие в свойствах поверхностей замечали графу shader, в которой указывается нечто вроде models/model или подобные.<br />
Как правило эти шейдеры упакованы в shaders.xr и shaders_xrlc.xr, которые представляют собой своеобразную базу данных шейдеров, собранных по определенным шаблонам.<br />
<br />
Но кроме этих баз данных есть еще и скриптовые шейдеры, которые имеют приоритет перед теми шейдерами что упакованы в *.xr. Это файлы, имеющие расширение .s и лежащие в папках соответствующих рендеров. Вычислить правильное название шейдера в БД и шейдерного скрипта .s можно очень просто - для примера если у нас в БД шейдер находится в model/selflight, то имя шейдера должно быть model_selflight.s, если details/blend, то скрипт шейдера будет соответственно details_blend.s . Не так уж сложно.<br />
<br />
Вообще база данных с шейдерами была выдумана не потому что авторам сталкера очень нравилось плодить экземпляры труднораспарсиваемых форматов, а причина более банальна - чтобы увеличить скорость загрузки игры сэкономив за счет активности жесткого диска, при открытии файлов скриптовых шейдеров в папке соответствующего рендера. Плюс к тому, в этом случае уменьшается количество шейдерных файлов что как минимум вдвое уменьшает вероятность ошибки - при условии двух рендеров, эта экономия получается за счет тех шейдеров, которые являются общими для обоих рендеров. Плюс к тому вероятность ошибки еще более уменьшается тем, что базы данных редактируются в сдк, а сдк эти базы данных представляет в виде всевозможных галочек и полей ввода, поэтому ошибка может быть только во вводимых данных, но не в скриптовом коде шейдеров, который вероятнее всего генерируется во время загрузки игры.<br />
<br />
Скриптовые шейдеры используются же в основном только в тех случаях когда их код отличается для разных рендеров.<br />
<br />
По некоторым причинам я считаю что для модостроителей шейдерные скрипты являются более предпочтительными, чем распространение своих шейдерных модов в виде модифицированной .xr-БД. Причины в основном две - во первых скриптовые шейдеры предоставляют бОльшие возможности для полета фантазии :), а во вторых распространение шейдерных модов в виде скриптовых шейдеров все же делает меньше вероятность конфликта модов, так как разные шейдеры будут в разных файлах, а не все вместе в одном хитром и трудноредактируемом, и что самое плохое - трудно-объединяемом файле. Поэтому далее мы рассмотрим скриптовые шейдеры.<br />
<br />
Что собой представляют шейдерные скрипты? Это обычные скрипты на lua, и которые являются своеобразным языком для того чтобы объяснить движку, какие загружать текстуры и какие подключать шейдеры из наличествующих .ps и .vs файлов. <br />
<br />
: ''Для тех кто воспрял духом сразу скажу что несмотря на то, что шейдерные скрипты написаны на языке, который используется в игровых скриптах, это все-таки не одно и то же. Во первых шейдерные скрипты выполняются при загрузке уровня всего один раз (в фазу загрузки "загрузка шейдеров"), поэтому на отрисовку в реальном времени влиять неспособны, и кроме того к игровым скриптам скриптовые шейдеры доступа не имеют.''<br />
<br />
Вот для примера содержимое простейшего скриптового шейдера:<br />
<br />
function normal( shader, t_base, t_second, t_detail )<br />
<br />
shader:begin( "effects_gradient", "effects_gradient_p" )<br />
<br />
end<br />
<br />
Разберем его по косточкам:<br />
<br />
* '''function normal''' - объявление стандартной функции шейдерного скрипта. В некоторых шейдерах есть еще функции '''l_spot''', '''l_point''' и '''l_special''' аналогичного содержания, но явно просчитывающие поведение этого шейдера в условиях освещения<br />
<br />
* '''shader''' - вероятнее всего идентификатор шейдера в игре, содержимое этой переменной представляет собой вероятнее всего текстовую строку вроде "models_selflight" или "models/selflight".<br />
* '''t_base''' - путь к текстуре которую следует выводить с помощью этого шейдера<br />
* '''t_second''', '''t_detail''' - пути к другим текстурам, пока назначение их неизвестно.<br />
<br />
* '''shader:begin( "effects_gradient", "effects_gradient_p" )''' - святая святых шейдера. Если точнее - создание объекта шейдера как такового. <br />
:: '''effects_gradient''' - имя .vs файла используемого в этом шейдере<br />
:: '''effects_gradient_p''' - имя .ps файла соответственно.<br />
<br />
<br />
После этой строки могут быть такие строки (они необязательны)<br />
<br />
<br />
* ''': blend ( true, blend.srcalpha, blend.one )''' - обработка текстур, например полупрозрачные текстуры без применения этой строки будут выглядеть непрозрачными черными в прозрачных местах. Эти методы блендинга соответствуют переключателю в сдк, где варианты ALPHA-ADD, BLEND, SET и так далее. На примере выше блендинг соответствует положению ALPHA-ADD.<br />
<br />
:: '''true''' - может быть '''false''' - включение обработки текстур, тоесть true - обработка включена, false соответственно выключена.<br />
<br />
:: '''blend.srcalpha''', '''blend.one''' - соответственно методы блендинга, могут быть:<br />
<br />
:::: blend.one<br />
:::: blend.zero<br />
:::: blend.srcalpha<br />
:::: blend.invsrcalpha<br />
:::: blend.srccolor<br />
:::: blend.destcolor<br />
:::: null<br />
<br />
::: Вероятнее всего также существуют директивы<br />
<br />
:::: blend.destalpha<br />
:::: blend.invdestalpha<br />
:::: blend.invsrccolor<br />
:::: blend.invdestcolor.<br />
<br />
* ''': sorting ( 3, false )''' - порядок отрисовки поверхности по отношению к самому объекту, частью которого является поверхность.<br />
<br />
:: '''3''' - цифра порядка отрисовки, где 1 - за объектом, 2 - на уровне с объектом, 3 - спереди объекта (ближе к актору). Как правило при тройке шейдируемая поверхность будет отрисовываться поверх всего, в том числе и оружия.<br />
<br />
:: '''false''' - соответствует галочке "srict sorting" в сдк. Пока назначение неизвестно.<br />
<br />
<br />
* ''': aref ( false, 2 )''' - альфа-референс объекта, оператор, переключающий многобитную альфу текстуры в однобитную.<br />
<br />
:: '''false''' - включение/выключение данной функции.<br />
<br />
:: '''2''' - сам альфа-референс объекта<br />
<br />
<br />
* ''': zb ( false, false )''' - манипуляции с z-буфером, где первый аргумент соответствует галке z-test в сдк, второй - галке z-write.<br />
<br />
* ''': fog ( false )''' - действие представляет собой превращение текстуры в черно-белую и применение к ней функции calc_fogging в common.h шейдеров соответствующего рендера.<br />
<br />
* ''': emissive ( true )''' - применяется в источниках освещения.<br />
<br />
* ''': distort ( true )''' - представляет из себя механизм искажений, аналогичный эффекту искажающегося воздуха в некоторых аномалиях, а также "линза" в главном меню над кнопками.<br />
<br />
----<br />
<br />
<br />
* '''shader : sampler( "s_base" )''' - создание буфера для помещения туда текстуры. Аргумент представляет собой идентификатор, получаемый ps и vs шейдерами, где будет фигурировать как predefined-переменная s_base.<br />
<br />
<br />
''Перечисленные ниже параметры могут быть только ниже сэмплерной строки!''<br />
<br />
<br />
* ''': texture ( t_base ) ''' - помещение в вышеобъявленный буфер текстуры. аргумент этой ф-ции представляет собой путь к текстуре, так что вполне можно указать нечто вроде<br />
<br />
: texture ( "fx\\fx_sun" )<br />
<br />
чтобы в буфер воткнуть текстуру '''gamedata/textures/fx/fx_sun.dds'''<br />
<br />
<br />
* ''': clamp()''' - соответствует галке Texture Clamp в сдк. Википедия [http://en.wikipedia.org/wiki/Clamping_%28graphics%29 отвечает] на этот вопрос весьма туманно. <br />
<br />
* ''': project()''' - используется в шейдере отрисовки неточечного источника света, и предположительно используется для проектирвоания текстуры сэмплера на те объекты которые находятся в пределах сектора сферы.<br />
<br />
* ''': wrap ()''' - Википедия [http://en.wikipedia.org/wiki/Wrapping_%28graphics%29 отвечает] на этот вопрос не менее туманно чем в примере выше.<br />
<br />
<br />
Ниже представлены еще четыре оператора используемые с сэмплером, назначение которых неизвестно.<br />
<br />
<br />
* ''': f_linear ()'''<br />
<br />
* ''': f_anisotropic ()'''<br />
<br />
* ''': f_none ()'''<br />
<br />
* ''': wmark (true)''' - используется в валлмарках<br />
<br />
----<br />
<br />
<br />
Также в папке с шейдерами лежат еще файлы .s (именно такого имени - точка и эс), которые являются для всех *.s-файлов своеобразными заголовочными файлами, функции из файла .s доступны из файлов *.s . На данный момент там имеются функции printf, и закомментированные во втором рендере ф-ции l_point и l_spot, которые отвечают за создание точечного и неточечного источников света соответственно.<br />
<br />
<br />
'''Статья создана участником cjayho'''<br />
<br />
[[Категория:Скрипты]]</div>80.93.126.66http://stalkerin.gameru.net/wiki/index.php?title=%D0%A1%D0%BA%D1%80%D0%B8%D0%BF%D1%82%D0%BE%D0%B2%D1%8B%D0%B5_%D1%88%D0%B5%D0%B9%D0%B4%D0%B5%D1%80%D1%8BСкриптовые шейдеры2011-04-14T11:16:36Z<p>80.93.126.66: </p>
<hr />
<div>Редактируя любую модель, многие в свойствах поверхностей замечали графу shader, в которой указывается нечто вроде models/model или подобные.<br />
Как правило эти шейдеры упакованы в shaders.xr и shaders_xrlc.xr, которые представляют собой своеобразную базу данных шейдеров, собранных по определенным шаблонам.<br />
<br />
Но кроме этих баз данных есть еще и скриптовые шейдеры, которые имеют приоритет перед теми шейдерами что упакованы в *.xr. Это файлы, имеющие расширение .s и лежащие в папках соответствующих рендеров. Вычислить правильное название шейдера в БД и шейдерного скрипта .s можно очень просто - для примера если у нас в БД шейдер находится в model/selflight, то имя шейдера должно быть model_selflight.s, если details/blend, то скрипт шейдера будет соответственно details_blend.s . Не так уж сложно.<br />
<br />
Вообще база данных с шейдерами была выдумана не потому что авторам сталкера очень нравилось плодить экземпляры труднораспарсиваемых форматов, а причина более банальна - чтобы увеличить скорость загрузки игры сэкономив за счет активности жесткого диска, при открытии файлов скриптовых шейдеров в папке соответствующего рендера. Плюс к тому, в этом случае уменьшается количество шейдерных файлов что как минимум вдвое уменьшает вероятность ошибки - при условии двух рендеров, эта экономия получается за счет тех шейдеров, которые являются общими для обоих рендеров. Плюс к тому вероятность ошибки еще более уменьшается тем, что базы данных редактируются в сдк, а сдк эти базы данных представляет в виде всевозможных галочек и полей ввода, поэтому ошибка может быть только во вводимых данных, но не в скриптовом коде шейдеров, который вероятнее всего генерируется во время загрузки игры.<br />
<br />
Скриптовые шейдеры используются же в основном только в тех случаях когда их код отличается для разных рендеров.<br />
<br />
По некоторым причинам я считаю что для модостроителей шейдерные скрипты являются более предпочтительными, чем распространение своих шейдерных модов в виде модифицированной .xr-БД. Причины в основном две - во первых скриптовые шейдеры предоставляют бОльшие возможности для полета фантазии :), а во вторых распространение шейдерных модов в виде скриптовых шейдеров все же делает меньше вероятность конфликта модов, так как разные шейдеры будут в разных файлах, а не все вместе в одном хитром и трудноредактируемом, и что самое плохое - трудно-объединяемом файле. Поэтому далее мы рассмотрим скриптовые шейдеры.<br />
<br />
Что собой представляют шейдерные скрипты? Это обычные скрипты на lua, и которые являются своеобразным языком для того чтобы объяснить движку, какие загружать текстуры и какие подключать шейдеры из наличествующих .ps и .vs файлов. <br />
<br />
: ''Для тех кто воспрял духом сразу скажу что несмотря на то, что шейдерные скрипты написаны на языке, который используется в игровых скриптах, это все-таки не одно и то же. Во первых шейдерные скрипты выполняются при загрузке уровня всего один раз (в фазу загрузки "загрузка шейдеров"), поэтому на отрисовку в реальном времени влиять неспособны, и кроме того к игровым скриптам скриптовые шейдеры доступа не имеют.''<br />
<br />
Вот для примера содержимое простейшего скриптового шейдера:<br />
<br />
function normal( shader, t_base, t_second, t_detail )<br />
<br />
shader:begin( "effects_gradient", "effects_gradient_p" )<br />
<br />
end<br />
<br />
Разберем его по косточкам:<br />
<br />
* '''function normal''' - объявление стандартной функции шейдерного скрипта. В некоторых шейдерах есть еще функции '''l_spot''', '''l_point''' и '''l_special''' аналогичного содержания, но явно просчитывающие поведение этого шейдера в условиях освещения<br />
<br />
* '''shader''' - вероятнее всего идентификатор шейдера в игре, содержимое этой переменной представляет собой вероятнее всего текстовую строку вроде "models_selflight" или "models/selflight".<br />
* '''t_base''' - путь к текстуре которую следует выводить с помощью этого шейдера<br />
* '''t_second''', '''t_detail''' - пути к другим текстурам, пока назначение их неизвестно.<br />
<br />
* '''shader:begin( "effects_gradient", "effects_gradient_p" )''' - святая святых шейдера. Если точнее - создание объекта шейдера как такового. <br />
:: '''effects_gradient''' - имя .vs файла используемого в этом шейдере<br />
:: '''effects_gradient_p''' - имя .ps файла соответственно.<br />
<br />
<br />
После этой строки могут быть такие строки (они необязательны)<br />
<br />
<br />
* ''': blend ( true, blend.srcalpha, blend.one )''' - обработка текстур, например полупрозрачные текстуры без применения этой строки будут выглядеть непрозрачными черными в прозрачных местах. Эти методы блендинга соответствуют переключателю в сдк, где варианты ALPHA-ADD, BLEND, SET и так далее. На примере выше блендинг соответствует положению ALPHA-ADD.<br />
<br />
:: '''true''' - может быть '''false''' - включение обработки текстур, тоесть true - обработка включена, false соответственно выключена.<br />
<br />
:: '''blend.srcalpha''', '''blend.one''' - соответственно методы блендинга, могут быть:<br />
<br />
:::: blend.one<br />
:::: blend.zero<br />
:::: blend.srcalpha<br />
:::: blend.invsrcalpha<br />
:::: blend.srccolor<br />
:::: blend.destcolor<br />
:::: null<br />
<br />
::: Вероятнее всего также существуют директивы<br />
<br />
:::: blend.destalpha<br />
:::: blend.invdestalpha<br />
:::: blend.invsrccolor<br />
:::: blend.invdestcolor.<br />
<br />
* ''': sorting ( 3, false )''' - порядок отрисовки поверхности по отношению к самому объекту, частью которого является поверхность.<br />
<br />
:: '''3''' - цифра порядка отрисовки, где 1 - за объектом, 2 - на уровне с объектом, 3 - спереди объекта (ближе к актору). Как правило при тройке шейдируемая поверхность будет отрисовываться поверх всего, в том числе и оружия.<br />
<br />
:: '''false''' - соответствует галочке "srict sorting" в сдк. Пока назначение неизвестно.<br />
<br />
<br />
* ''': aref ( false, 2 )''' - альфа-референс объекта, оператор, переключающий многобитную альфу текстуры в однобитную.<br />
<br />
:: '''false''' - включение/выключение данной функции.<br />
<br />
:: '''2''' - сам альфа-референс объекта<br />
<br />
<br />
* ''': zb ( false, false )''' - манипуляции с z-буфером, где первый аргумент соответствует галке z-test в сдк, второй - галке z-write.<br />
<br />
* ''': fog ( false )''' - действие представляет собой превращение текстуры в черно-белую и применение к ней функции calc_fogging в common.h шейдеров соответствующего рендера.<br />
<br />
* ''': emissive ( true )''' - применяется в источниках освещения.<br />
<br />
* ''': distort ( true )''' - представляет из себя механизм искажений, аналогичный эффекту искажающегося воздуха в некоторых аномалиях, а также "линза" в главном меню над кнопками.<br />
<br />
----<br />
<br />
<br />
* '''shader : sampler( "s_base" )''' - создание буфера для помещения туда текстуры. Аргумент представляет собой идентификатор, получаемый ps и vs шейдерами, где будет фигурировать как predefined-переменная s_base.<br />
<br />
<br />
''Перечисленные ниже параметры могут быть только ниже сэмплерной строки!''<br />
<br />
<br />
* ''': texture ( t_base ) ''' - помещение в вышеобъявленный буфер текстуры. аргумент этой ф-ции представляет собой путь к текстуре, так что вполне можно указать нечто вроде<br />
<br />
: texture ( "fx\\fx_sun" )<br />
<br />
чтобы в буфер воткнуть текстуру '''gamedata/textures/fx/fx_sun.dds'''<br />
<br />
<br />
* ''': clamp()''' - соответствует галке Texture Clamp в сдк. Википедия [http://en.wikipedia.org/wiki/Clamping_%28graphics%29 отвечает] на этот вопрос весьма туманно. <br />
<br />
* ''': project()''' - используется в шейдере отрисовки неточечного источника света, и предположительно используется для проектирвоания текстуры сэмплера на те объекты которые находятся в пределах сектора сферы.<br />
<br />
* ''': wrap ()''' - Википедия [http://en.wikipedia.org/wiki/Wrapping_%28graphics%29 отвечает] на этот вопрос не менее туманно чем в примере выше.<br />
<br />
Ниже представлены еще два оператора используемые с сэмплером, назначение которых неизвестно.<br />
<br />
<br />
* ''': f_linear ()'''<br />
<br />
* ''': f_anisotropic ()'''<br />
<br />
* ''': f_none ()'''<br />
<br />
* ''': wmark (true)''' - используется в валлмарках<br />
----<br />
<br />
<br />
Также в папке с шейдерами лежат еще файлы .s (именно такого имени - точка и эс), которые являются для всех *.s-файлов своеобразными заголовочными файлами, функции из файла .s доступны из файлов *.s . На данный момент там имеются функции printf, и закомментированные во втором рендере ф-ции l_point и l_spot, которые отвечают за создание точечного и неточечного источников света соответственно.<br />
<br />
<br />
'''Статья создана участником cjayho'''<br />
<br />
[[Категория:Скрипты]]</div>80.93.126.66http://stalkerin.gameru.net/wiki/index.php?title=%D0%A1%D0%BA%D1%80%D0%B8%D0%BF%D1%82%D0%BE%D0%B2%D1%8B%D0%B5_%D1%88%D0%B5%D0%B9%D0%B4%D0%B5%D1%80%D1%8BСкриптовые шейдеры2011-04-01T00:29:27Z<p>80.93.126.66: </p>
<hr />
<div>Редактируя любую модель, многие в свойствах поверхностей замечали графу shader, в которой указывается нечто вроде models/model или подобные.<br />
Как правило эти шейдеры упакованы в shaders.xr и shaders_xrlc.xr, которые представляют собой своеобразную базу данных шейдеров, собранных по определенным шаблонам.<br />
<br />
Но кроме этих баз данных есть еще и скриптовые шейдеры, которые имеют приоритет перед теми шейдерами что упакованы в *.xr. Это файлы, имеющие расширение .s и лежащие в папках соответствующих рендеров. Вычислить правильное название шейдера в БД и шейдерного скрипта .s можно очень просто - для примера если у нас в БД шейдер находится в model/selflight, то имя шейдера должно быть model_selflight.s, если details/blend, то скрипт шейдера будет соответственно details_blend.s . Не так уж сложно.<br />
<br />
Вообще база данных с шейдерами была выдумана не потому что авторам сталкера очень нравилось плодить экземпляры труднораспарсиваемых форматов, а причина более банальна - чтобы увеличить скорость загрузки игры сэкономив за счет активности жесткого диска, при открытии файлов скриптовых шейдеров в папке соответствующего рендера. Плюс к тому, в этом случае уменьшается количество шейдерных файлов что как минимум вдвое уменьшает вероятность ошибки - при условии двух рендеров, эта экономия получается за счет тех шейдеров, которые являются общими для обоих рендеров. Плюс к тому вероятность ошибки еще более уменьшается тем, что базы данных редактируются в сдк, а сдк эти базы данных представляет в виде всевозможных галочек и полей ввода, поэтому ошибка может быть только во вводимых данных, но не в скриптовом коде шейдеров, который вероятнее всего генерируется во время загрузки игры.<br />
<br />
Скриптовые шейдеры используются же в основном только в тех случаях когда их код отличается для разных рендеров.<br />
<br />
По некоторым причинам я считаю что для модостроителей шейдерные скрипты являются более предпочтительными, чем распространение своих шейдерных модов в виде модифицированной .xr-БД. Причины в основном две - во первых скриптовые шейдеры предоставляют бОльшие возможности для полета фантазии :), а во вторых распространение шейдерных модов в виде скриптовых шейдеров все же делает меньше вероятность конфликта модов, так как разные шейдеры будут в разных файлах, а не все вместе в одном хитром и трудноредактируемом, и что самое плохое - трудно-объединяемом файле. Поэтому далее мы рассмотрим скриптовые шейдеры.<br />
<br />
Что собой представляют шейдерные скрипты? Это обычные скрипты на lua, и которые являются своеобразным языком для того чтобы объяснить движку, какие загружать текстуры и какие подключать шейдеры из наличествующих .ps и .vs файлов. <br />
<br />
: ''Для тех кто воспрял духом сразу скажу что несмотря на то, что шейдерные скрипты написаны на языке, который используется в игровых скриптах, это все-таки не одно и то же. Во первых шейдерные скрипты выполняются при загрузке уровня всего один раз (в фазу загрузки "загрузка шейдеров"), поэтому на отрисовку в реальном времени влиять неспособны, и кроме того к игровым скриптам скриптовые шейдеры доступа не имеют.''<br />
<br />
Вот для примера содержимое простейшего скриптового шейдера:<br />
<br />
function normal( shader, t_base, t_second, t_detail )<br />
<br />
shader:begin( "effects_gradient", "effects_gradient_p" )<br />
<br />
end<br />
<br />
Разберем его по косточкам:<br />
<br />
* '''function normal''' - объявление стандартной функции шейдерного скрипта. В некоторых шейдерах есть еще функции '''l_spot''', '''l_point''' и '''l_special''' аналогичного содержания, но явно просчитывающие поведение этого шейдера в условиях освещения<br />
<br />
* '''shader''' - вероятнее всего идентификатор шейдера в игре, содержимое этой переменной представляет собой вероятнее всего текстовую строку вроде "models_selflight" или "models/selflight".<br />
* '''t_base''' - путь к текстуре которую следует выводить с помощью этого шейдера<br />
* '''t_second''', '''t_detail''' - пути к другим текстурам, пока назначение их неизвестно.<br />
<br />
* '''shader:begin( "effects_gradient", "effects_gradient_p" )''' - святая святых шейдера. Если точнее - создание объекта шейдера как такового. <br />
:: '''effects_gradient''' - имя .vs файла используемого в этом шейдере<br />
:: '''effects_gradient_p''' - имя .ps файла соответственно.<br />
<br />
<br />
После этой строки могут быть такие строки (они необязательны)<br />
<br />
<br />
* ''': blend ( true, blend.srcalpha, blend.one )''' - обработка текстур, например полупрозрачные текстуры без применения этой строки будут выглядеть непрозрачными черными в прозрачных местах. Эти методы блендинга соответствуют переключателю в сдк, где варианты ALPHA-ADD, BLEND, SET и так далее. На примере выше блендинг соответствует положению ALPHA-ADD.<br />
<br />
:: '''true''' - может быть '''false''' - включение обработки текстур, тоесть true - обработка включена, false соответственно выключена.<br />
<br />
:: '''blend.srcalpha''', '''blend.one''' - соответственно методы блендинга, могут быть blend.one, blend.zero, blend.srcalpha, blend.invsrcalpha, blend.srccolor, blend.destcolor и null<br />
<br />
<br />
* ''': sorting ( 3, false )''' - порядок отрисовки поверхности по отношению к самому объекту, частью которого является поверхность.<br />
<br />
:: '''3''' - цифра порядка отрисовки, где 1 - за объектом, 2 - на уровне с объектом, 3 - спереди объекта (ближе к актору). Как правило при тройке шейдируемая поверхность будет отрисовываться поверх всего, в том числе и оружия.<br />
<br />
:: '''false''' - соответствует галочке "srict sorting" в сдк. Пока назначение неизвестно.<br />
<br />
<br />
* ''': aref ( false, 2 )''' - альфа-референс объекта, оператор, переключающий многобитную альфу текстуры в однобитную.<br />
<br />
:: '''false''' - включение/выключение данной функции.<br />
<br />
:: '''2''' - сам альфа-референс объекта<br />
<br />
<br />
* ''': zb ( false, false )''' - манипуляции с z-буфером, где первый аргумент соответствует галке z-test в сдк, второй - галке z-write.<br />
<br />
* ''': fog ( false )''' - действие представляет собой превращение текстуры в черно-белую и применение к ней функции calc_fogging в common.h шейдеров соответствующего рендера.<br />
<br />
* ''': emissive ( true )''' - применяется в источниках освещения.<br />
<br />
* ''': distort ( true )''' - представляет из себя механизм искажений, аналогичный эффекту искажающегося воздуха в некоторых аномалиях, а также "линза" в главном меню над кнопками.<br />
<br />
----<br />
<br />
<br />
* '''shader : sampler( "s_base" )''' - создание буфера для помещения туда текстуры. Аргумент представляет собой идентификатор, получаемый ps и vs шейдерами, где будет фигурировать как predefined-переменная s_base.<br />
<br />
<br />
''Перечисленные ниже параметры могут быть только ниже сэмплерной строки!''<br />
<br />
<br />
* ''': texture ( t_base ) ''' - помещение в вышеобъявленный буфер текстуры. аргумент этой ф-ции представляет собой путь к текстуре, так что вполне можно указать нечто вроде<br />
<br />
: texture ( "fx\\fx_sun" )<br />
<br />
чтобы в буфер воткнуть текстуру '''gamedata/textures/fx/fx_sun.dds'''<br />
<br />
<br />
* ''': clamp()''' - соответствует галке Texture Clamp в сдк. Википедия [http://en.wikipedia.org/wiki/Clamping_%28graphics%29 отвечает] на этот вопрос весьма туманно. <br />
<br />
* ''': project()''' - используется в шейдере отрисовки неточечного источника света, и предположительно используется для проектирвоания текстуры сэмплера на те объекты которые находятся в пределах сектора сферы.<br />
<br />
* ''': wrap ()''' - Википедия [http://en.wikipedia.org/wiki/Wrapping_%28graphics%29 отвечает] на этот вопрос не менее туманно чем в примере выше.<br />
<br />
Ниже представлены еще два оператора используемые с сэмплером, назначение которых неизвестно.<br />
<br />
<br />
* ''': f_linear ()'''<br />
<br />
* ''': f_anisotropic ()'''<br />
<br />
* ''': f_none ()'''<br />
<br />
* ''': wmark (true)''' - используется в валлмарках<br />
----<br />
<br />
<br />
Также в папке с шейдерами лежат еще файлы .s (именно такого имени - точка и эс), которые являются для всех *.s-файлов своеобразными заголовочными файлами, функции из файла .s доступны из файлов *.s . На данный момент там имеются функции printf, и закомментированные во втором рендере ф-ции l_point и l_spot, которые отвечают за создание точечного и неточечного источников света соответственно.<br />
<br />
<br />
'''Статья создана участником cjayho'''<br />
<br />
[[Категория:Скрипты]]</div>80.93.126.66http://stalkerin.gameru.net/wiki/index.php?title=%D0%A1%D0%BA%D1%80%D0%B8%D0%BF%D1%82%D0%BE%D0%B2%D1%8B%D0%B5_%D1%88%D0%B5%D0%B9%D0%B4%D0%B5%D1%80%D1%8BСкриптовые шейдеры2011-04-01T00:28:31Z<p>80.93.126.66: </p>
<hr />
<div>Редактируя любую модель, многие в свойствах поверхностей замечали графу shader, в которой указывается нечто вроде models/model или подобные.<br />
Как правило эти шейдеры упакованы в shaders.xr и shaders_xrlc.xr, которые представляют собой своеобразную базу данных шейдеров, собранных по определенным шаблонам.<br />
<br />
Но кроме этих баз данных есть еще и скриптовые шейдеры, которые имеют приоритет перед теми шейдерами что упакованы в *.xr. Это файлы, имеющие расширение .s и лежащие в папках соответствующих рендеров. Вычислить правильное название шейдера в БД и шейдерного скрипта .s можно очень просто - для примера если у нас в БД шейдер находится в model/selflight, то имя шейдера должно быть model_selflight.s, если details/blend, то скрипт шейдера будет соответственно details_blend.s . Не так уж сложно.<br />
<br />
Вообще база данных с шейдерами была выдумана не потому что авторам сталкера очень нравилось плодить экземпляры труднораспарсиваемых форматов, а причина более банальна - чтобы увеличить скорость загрузки игры сэкономив за счет активности жесткого диска, при открытии файлов скриптовых шейдеров в папке соответствующего рендера. Плюс к тому, в этом случае уменьшается количество шейдерных файлов что как минимум вдвое уменьшает вероятность ошибки - при условии двух рендеров, эта экономия получается за счет тех шейдеров, которые являются общими для обоих рендеров. Плюс к тому вероятность ошибки еще более уменьшается тем, что базы данных редактируются в сдк, а сдк эти базы данных представляет в виде всевозможных галочек и полей ввода, поэтому ошибка может быть только во вводимых данных, но не в скриптовом коде шейдеров, который вероятнее всего генерируется во время загрузки игры.<br />
<br />
Скриптовые шейдеры используются же в основном только в тех случаях когда их код отличается для разных рендеров.<br />
<br />
По некоторым причинам я считаю что для модостроителей шейдерные скрипты являются более предпочтительными, чем распространение своих шейдерных модов в виде модифицированной .xr-БД. Причины в основном две - во первых скриптовые шейдеры предоставляют бОльшие возможности для полета фантазии :), а во вторых распространение шейдерных модов в виде скриптовых шейдеров все же делает меньше вероятность конфликта модов, так как разные шейдеры будут в разных файлах, а не все вместе в одном хитром и трудноредактируемом, и что самое плохое - трудно-объединяемом файле. Поэтому далее мы рассмотрим скриптовые шейдеры.<br />
<br />
Что собой представляют шейдерные скрипты? Это обычные скрипты на lua, и которые являются своеобразным языком для того чтобы объяснить движку, какие загружать текстуры и какие подключать шейдеры из наличествующих .ps и .vs файлов. <br />
<br />
: ''Для тех кто воспрял духом сразу скажу что несмотря на то, что шейдерные скрипты написаны на языке, который используется в игровых скриптах, это все-таки не одно и то же. Во первых шейдерные скрипты выполняются при загрузке уровня всего один раз (в фазу загрузки "загрузка шейдеров"), поэтому на отрисовку в реальном времени влиять неспособны, и кроме того к игровым скриптам скриптовые шейдеры доступа не имеют.''<br />
<br />
Вот для примера содержимое простейшего скриптового шейдера:<br />
<br />
function normal( shader, t_base, t_second, t_detail )<br />
<br />
shader:begin( "effects_gradient", "effects_gradient_p" )<br />
<br />
end<br />
<br />
Разберем его по косточкам:<br />
<br />
* '''function normal''' - объявление стандартной функции шейдерного скрипта. В некоторых шейдерах есть еще функции '''l_spot''', '''l_point''' и '''l_special''' аналогичного содержания, но явно просчитывающие поведение этого шейдера в условиях освещения<br />
<br />
* '''shader''' - вероятнее всего идентификатор шейдера в игре, содержимое этой переменной представляет собой вероятнее всего текстовую строку вроде "models_selflight" или "models/selflight".<br />
* '''t_base''' - путь к текстуре которую следует выводить с помощью этого шейдера<br />
* '''t_second''', '''t_detail''' - пути к другим текстурам, пока назначение их неизвестно.<br />
<br />
* '''shader:begin( "effects_gradient", "effects_gradient_p" )''' - святая святых шейдера. Если точнее - создание объекта шейдера как такового. <br />
:: '''effects_gradient''' - имя .vs файла используемого в этом шейдере<br />
:: '''effects_gradient_p''' - имя .ps файла соответственно.<br />
<br />
<br />
После этой строки могут быть такие строки (они необязательны)<br />
<br />
<br />
* ''': blend ( true, blend.srcalpha, blend.one )''' - обработка текстур, например полупрозрачные текстуры без применения этой строки будут выглядеть непрозрачными черными в прозрачных местах. Эти методы блендинга соответствуют переключателю в сдк, где варианты ALPHA-ADD, BLEND, SET и так далее. На примере выше блендинг соответствует положению ALPHA-ADD.<br />
<br />
:: '''true''' - может быть '''false''' - включение обработки текстур, тоесть true - обработка включена, false соответственно выключена.<br />
<br />
:: '''blend.srcalpha''', '''blend.one''' - соответственно методы блендинга, могут быть blend.one, blend.zero, blend.srcalpha, blend.invsrcalpha, blend.srccolor и null<br />
<br />
<br />
* ''': sorting ( 3, false )''' - порядок отрисовки поверхности по отношению к самому объекту, частью которого является поверхность.<br />
<br />
:: '''3''' - цифра порядка отрисовки, где 1 - за объектом, 2 - на уровне с объектом, 3 - спереди объекта (ближе к актору). Как правило при тройке шейдируемая поверхность будет отрисовываться поверх всего, в том числе и оружия.<br />
<br />
:: '''false''' - соответствует галочке "srict sorting" в сдк. Пока назначение неизвестно.<br />
<br />
<br />
* ''': aref ( false, 2 )''' - альфа-референс объекта, оператор, переключающий многобитную альфу текстуры в однобитную.<br />
<br />
:: '''false''' - включение/выключение данной функции.<br />
<br />
:: '''2''' - сам альфа-референс объекта<br />
<br />
<br />
* ''': zb ( false, false )''' - манипуляции с z-буфером, где первый аргумент соответствует галке z-test в сдк, второй - галке z-write.<br />
<br />
* ''': fog ( false )''' - действие представляет собой превращение текстуры в черно-белую и применение к ней функции calc_fogging в common.h шейдеров соответствующего рендера.<br />
<br />
* ''': emissive ( true )''' - применяется в источниках освещения.<br />
<br />
* ''': distort ( true )''' - представляет из себя механизм искажений, аналогичный эффекту искажающегося воздуха в некоторых аномалиях, а также "линза" в главном меню над кнопками.<br />
<br />
----<br />
<br />
<br />
* '''shader : sampler( "s_base" )''' - создание буфера для помещения туда текстуры. Аргумент представляет собой идентификатор, получаемый ps и vs шейдерами, где будет фигурировать как predefined-переменная s_base.<br />
<br />
<br />
''Перечисленные ниже параметры могут быть только ниже сэмплерной строки!''<br />
<br />
<br />
* ''': texture ( t_base ) ''' - помещение в вышеобъявленный буфер текстуры. аргумент этой ф-ции представляет собой путь к текстуре, так что вполне можно указать нечто вроде<br />
<br />
: texture ( "fx\\fx_sun" )<br />
<br />
чтобы в буфер воткнуть текстуру '''gamedata/textures/fx/fx_sun.dds'''<br />
<br />
<br />
* ''': clamp()''' - соответствует галке Texture Clamp в сдк. Википедия [http://en.wikipedia.org/wiki/Clamping_%28graphics%29 отвечает] на этот вопрос весьма туманно. <br />
<br />
* ''': project()''' - используется в шейдере отрисовки неточечного источника света, и предположительно используется для проектирвоания текстуры сэмплера на те объекты которые находятся в пределах сектора сферы.<br />
<br />
* ''': wrap ()''' - Википедия [http://en.wikipedia.org/wiki/Wrapping_%28graphics%29 отвечает] на этот вопрос не менее туманно чем в примере выше.<br />
<br />
Ниже представлены еще два оператора используемые с сэмплером, назначение которых неизвестно.<br />
<br />
<br />
* ''': f_linear ()'''<br />
<br />
* ''': f_anisotropic ()'''<br />
<br />
* ''': f_none ()'''<br />
<br />
* ''': wmark (true)''' - используется в валлмарках<br />
----<br />
<br />
<br />
Также в папке с шейдерами лежат еще файлы .s (именно такого имени - точка и эс), которые являются для всех *.s-файлов своеобразными заголовочными файлами, функции из файла .s доступны из файлов *.s . На данный момент там имеются функции printf, и закомментированные во втором рендере ф-ции l_point и l_spot, которые отвечают за создание точечного и неточечного источников света соответственно.<br />
<br />
<br />
'''Статья создана участником cjayho'''<br />
<br />
[[Категория:Скрипты]]</div>80.93.126.66http://stalkerin.gameru.net/wiki/index.php?title=%D0%A1%D0%BA%D1%80%D0%B8%D0%BF%D1%82%D0%BE%D0%B2%D1%8B%D0%B5_%D1%88%D0%B5%D0%B9%D0%B4%D0%B5%D1%80%D1%8BСкриптовые шейдеры2011-04-01T00:23:24Z<p>80.93.126.66: </p>
<hr />
<div>Редактируя любую модель, многие в свойствах поверхностей замечали графу shader, в которой указывается нечто вроде models/model или подобные.<br />
Как правило эти шейдеры упакованы в shaders.xr и shaders_xrlc.xr, которые представляют собой своеобразную базу данных шейдеров, собранных по определенным шаблонам.<br />
<br />
Но кроме этих баз данных есть еще и скриптовые шейдеры, которые имеют приоритет перед теми шейдерами что упакованы в *.xr. Это файлы, имеющие расширение .s и лежащие в папках соответствующих рендеров. Вычислить правильное название шейдера в БД и шейдерного скрипта .s можно очень просто - для примера если у нас в БД шейдер находится в model/selflight, то имя шейдера должно быть model_selflight.s, если details/blend, то скрипт шейдера будет соответственно details_blend.s . Не так уж сложно.<br />
<br />
Вообще база данных с шейдерами была выдумана не потому что авторам сталкера очень нравилось плодить экземпляры труднораспарсиваемых форматов, а причина более банальна - чтобы увеличить скорость загрузки игры сэкономив за счет активности жесткого диска, при открытии файлов скриптовых шейдеров в папке соответствующего рендера. Плюс к тому, в этом случае уменьшается количество шейдерных файлов что как минимум вдвое уменьшает вероятность ошибки - при условии двух рендеров, эта экономия получается за счет тех шейдеров, которые являются общими для обоих рендеров. Плюс к тому вероятность ошибки еще более уменьшается тем, что базы данных редактируются в сдк, а сдк эти базы данных представляет в виде всевозможных галочек и полей ввода, поэтому ошибка может быть только во вводимых данных, но не в скриптовом коде шейдеров, который вероятнее всего генерируется во время загрузки игры.<br />
<br />
Скриптовые шейдеры используются же в основном только в тех случаях когда их код отличается для разных рендеров.<br />
<br />
По некоторым причинам я считаю что для модостроителей шейдерные скрипты являются более предпочтительными, чем распространение своих шейдерных модов в виде модифицированной .xr-БД. Причины в основном две - во первых скриптовые шейдеры предоставляют бОльшие возможности для полета фантазии :), а во вторых распространение шейдерных модов в виде скриптовых шейдеров все же делает меньше вероятность конфликта модов, так как разные шейдеры будут в разных файлах, а не все вместе в одном хитром и трудноредактируемом, и что самое плохое - трудно-объединяемом файле. Поэтому далее мы рассмотрим скриптовые шейдеры.<br />
<br />
Что собой представляют шейдерные скрипты? Это обычные скрипты на lua, и которые являются своеобразным языком для того чтобы объяснить движку, какие загружать текстуры и какие подключать шейдеры из наличествующих .ps и .vs файлов. <br />
<br />
: ''Для тех кто воспрял духом сразу скажу что несмотря на то, что шейдерные скрипты написаны на языке, который используется в игровых скриптах, это все-таки не одно и то же. Во первых шейдерные скрипты выполняются при загрузке уровня всего один раз (в фазу загрузки "загрузка шейдеров"), поэтому на отрисовку в реальном времени влиять неспособны, и кроме того к игровым скриптам скриптовые шейдеры доступа не имеют.''<br />
<br />
Вот для примера содержимое простейшего скриптового шейдера:<br />
<br />
function normal( shader, t_base, t_second, t_detail )<br />
<br />
shader:begin( "effects_gradient", "effects_gradient_p" )<br />
<br />
end<br />
<br />
Разберем его по косточкам:<br />
<br />
* '''function normal''' - объявление стандартной функции шейдерного скрипта. В некоторых шейдерах есть еще функции '''l_spot''', '''l_point''' и '''l_special''' аналогичного содержания, но явно просчитывающие поведение этого шейдера в условиях освещения<br />
<br />
* '''shader''' - вероятнее всего идентификатор шейдера в игре, содержимое этой переменной представляет собой вероятнее всего текстовую строку вроде "models_selflight" или "models/selflight".<br />
* '''t_base''' - путь к текстуре которую следует выводить с помощью этого шейдера<br />
* '''t_second''', '''t_detail''' - пути к другим текстурам, пока назначение их неизвестно.<br />
<br />
* '''shader:begin( "effects_gradient", "effects_gradient_p" )''' - святая святых шейдера. Если точнее - создание объекта шейдера как такового. <br />
:: '''effects_gradient''' - имя .vs файла используемого в этом шейдере<br />
:: '''effects_gradient_p''' - имя .ps файла соответственно.<br />
<br />
<br />
После этой строки могут быть такие строки (они необязательны)<br />
<br />
<br />
* ''': blend ( true, blend.srcalpha, blend.one )''' - обработка текстур, например полупрозрачные текстуры без применения этой строки будут выглядеть непрозрачными черными в прозрачных местах. Эти методы блендинга соответствуют переключателю в сдк, где варианты ALPHA-ADD, BLEND, SET и так далее. На примере выше блендинг соответствует положению ALPHA-ADD.<br />
<br />
:: '''true''' - может быть '''false''' - включение обработки текстур, тоесть true - обработка включена, false соответственно выключена.<br />
<br />
:: '''blend.srcalpha''', '''blend.one''' - соответственно методы блендинга, могут быть blend.one, blend.zero, blend.srcalpha, blend.invsrcalpha, blend.srccolor и null<br />
<br />
<br />
* ''': sorting ( 3, false )''' - порядок отрисовки поверхности по отношению к самому объекту, частью которого является поверхность.<br />
<br />
:: '''3''' - цифра порядка отрисовки, где 1 - за объектом, 2 - на уровне с объектом, 3 - спереди объекта (ближе к актору). Как правило при тройке шейдируемая поверхность будет отрисовываться поверх всего, в том числе и оружия.<br />
<br />
:: '''false''' - соответствует галочке "srict sorting" в сдк. Пока назначение неизвестно.<br />
<br />
<br />
* ''': aref ( false, 2 )''' - альфа-референс объекта, оператор, переключающий многобитную альфу текстуры в однобитную.<br />
<br />
:: '''false''' - включение/выключение данной функции.<br />
<br />
:: '''2''' - сам альфа-референс объекта<br />
<br />
<br />
* ''': zb ( false, false )''' - манипуляции с z-буфером, где первый аргумент соответствует галке z-test в сдк, второй - галке z-write.<br />
<br />
* ''': fog ( false )''' - действие представляет собой превращение текстуры в черно-белую и применение к ней функции calc_fogging в common.h шейдеров соответствующего рендера.<br />
<br />
* ''': emissive ( true )''' - применяется в источниках освещения.<br />
<br />
* ''': distort ( true )''' - представляет из себя механизм искажений, аналогичный эффекту искажающегося воздуха в некоторых аномалиях, а также "линза" в главном меню над кнопками.<br />
<br />
----<br />
<br />
<br />
* '''shader : sampler( "s_base" )''' - создание буфера для помещения туда текстуры. Аргумент представляет собой идентификатор, получаемый ps и vs шейдерами, где будет фигурировать как predefined-переменная s_base.<br />
<br />
<br />
''Перечисленные ниже параметры могут быть только ниже сэмплерной строки!''<br />
<br />
<br />
* ''': texture ( t_base ) ''' - помещение в вышеобъявленный буфер текстуры. аргумент этой ф-ции представляет собой путь к текстуре, так что вполне можно указать нечто вроде<br />
<br />
: texture ( "fx\\fx_sun" )<br />
<br />
чтобы в буфер воткнуть текстуру '''gamedata/textures/fx/fx_sun.dds'''<br />
<br />
<br />
* ''': clamp()''' - соответствует галке Texture Clamp в сдк. Википедия [http://en.wikipedia.org/wiki/Clamping_%28graphics%29 отвечает] на этот вопрос весьма туманно. <br />
<br />
* ''': project()''' - используется в шейдере отрисовки неточечного источника света, и предположительно используется для проектирвоания текстуры сэмплера на те объекты которые находятся в пределах сектора сферы.<br />
<br />
* ''': wrap ()''' - Википедия [http://en.wikipedia.org/wiki/Wrapping_%28graphics%29 отвечает] на этот вопрос не менее туманно чем в примере выше.<br />
<br />
Ниже представлены еще два оператора используемые с сэмплером, назначение которых неизвестно.<br />
<br />
<br />
* ''': f_linear ()'''<br />
<br />
* ''': f_anisotropic ()'''<br />
<br />
* ''': f_none ()'''<br />
<br />
----<br />
<br />
<br />
Также в папке с шейдерами лежат еще файлы .s (именно такого имени - точка и эс), которые являются для всех *.s-файлов своеобразными заголовочными файлами, функции из файла .s доступны из файлов *.s . На данный момент там имеются функции printf, и закомментированные во втором рендере ф-ции l_point и l_spot, которые отвечают за создание точечного и неточечного источников света соответственно.<br />
<br />
<br />
'''Статья создана участником cjayho'''<br />
<br />
[[Категория:Скрипты]]</div>80.93.126.66http://stalkerin.gameru.net/wiki/index.php?title=%D0%A1%D0%BA%D1%80%D0%B8%D0%BF%D1%82%D0%BE%D0%B2%D1%8B%D0%B5_%D1%88%D0%B5%D0%B9%D0%B4%D0%B5%D1%80%D1%8BСкриптовые шейдеры2011-03-31T22:18:05Z<p>80.93.126.66: </p>
<hr />
<div>Редактируя любую модель, многие в свойствах поверхностей замечали графу shader, в которой указывается нечто вроде models/model или подобные.<br />
Как правило эти шейдеры упакованы в shaders.xr и shaders_xrlc.xr, которые представляют собой своеобразную базу данных шейдеров, собранных по определенным шаблонам.<br />
<br />
Но кроме этих баз данных есть еще и скриптовые шейдеры, которые имеют приоритет перед теми шейдерами что упакованы в *.xr. Это файлы, имеющие расширение .s и лежащие в папках соответствующих рендеров. Вычислить правильное название шейдера в БД и шейдерного скрипта .s можно очень просто - для примера если у нас в БД шейдер находится в model/selflight, то имя шейдера должно быть model_selflight.s, если details/blend, то скрипт шейдера будет соответственно details_blend.s . Не так уж сложно.<br />
<br />
Вообще база данных с шейдерами была выдумана не потому что авторам сталкера очень нравилось плодить экземпляры труднораспарсиваемых форматов, а причина более банальна - чтобы увеличить скорость загрузки игры сэкономив за счет активности жесткого диска, при открытии файлов скриптовых шейдеров в папке соответствующего рендера. Плюс к тому, в этом случае уменьшается количество шейдерных файлов что как минимум вдвое уменьшает вероятность ошибки - при условии двух рендеров, эта экономия получается за счет тех шейдеров, которые являются общими для обоих рендеров. Плюс к тому вероятность ошибки еще более уменьшается тем, что базы данных редактируются в сдк, а сдк эти базы данных представляет в виде всевозможных галочек и полей ввода, поэтому ошибка может быть только во вводимых данных, но не в скриптовом коде шейдеров, который вероятнее всего генерируется во время загрузки игры.<br />
<br />
Скриптовые шейдеры используются же в основном только в тех случаях когда их код отличается для разных рендеров.<br />
<br />
По некоторым причинам я считаю что для модостроителей шейдерные скрипты являются более предпочтительными, чем распространение своих шейдерных модов в виде модифицированной .xr-БД. Причины в основном две - во первых скриптовые шейдеры предоставляют бОльшие возможности для полета фантазии :), а во вторых распространение шейдерных модов в виде скриптовых шейдеров все же делает меньше вероятность конфликта модов, так как разные шейдеры будут в разных файлах, а не все вместе в одном хитром и трудноредактируемом, и что самое плохое - трудно-объединяемом файле. Поэтому далее мы рассмотрим скриптовые шейдеры.<br />
<br />
Что собой представляют шейдерные скрипты? Это обычные скрипты на lua, и которые являются своеобразным языком для того чтобы объяснить движку, какие загружать текстуры и какие подключать шейдеры из наличествующих .ps и .vs файлов. <br />
<br />
: ''Для тех кто воспрял духом сразу скажу что несмотря на то, что шейдерные скрипты написаны на языке, который используется в игровых скриптах, это все-таки не одно и то же. Во первых шейдерные скрипты выполняются при загрузке уровня всего один раз (в фазу загрузки "загрузка шейдеров"), поэтому на отрисовку в реальном времени влиять неспособны, и кроме того к игровым скриптам скриптовые шейдеры доступа не имеют.''<br />
<br />
Вот для примера содержимое простейшего скриптового шейдера:<br />
<br />
function normal( shader, t_base, t_second, t_detail )<br />
<br />
shader:begin( "effects_gradient", "effects_gradient_p" )<br />
<br />
end<br />
<br />
Разберем его по косточкам:<br />
<br />
* '''function normal''' - объявление стандартной функции шейдерного скрипта. В некоторых шейдерах есть еще функции '''l_spot''', '''l_point''' и '''l_special''' аналогичного содержания, но явно просчитывающие поведение этого шейдера в условиях освещения<br />
<br />
* '''shader''' - вероятнее всего идентификатор шейдера в игре, содержимое этой переменной представляет собой вероятнее всего текстовую строку вроде "models_selflight" или "models/selflight".<br />
* '''t_base''' - путь к текстуре которую следует выводить с помощью этого шейдера<br />
* '''t_second''', '''t_detail''' - пути к другим текстурам, пока назначение их неизвестно.<br />
<br />
* '''shader:begin( "effects_gradient", "effects_gradient_p" )''' - святая святых шейдера. Если точнее - создание объекта шейдера как такового. <br />
:: '''effects_gradient''' - имя .vs файла используемого в этом шейдере<br />
:: '''effects_gradient_p''' - имя .ps файла соответственно.<br />
<br />
<br />
После этой строки могут быть такие строки (они необязательны)<br />
<br />
<br />
* ''': blend ( true, blend.srcalpha, blend.one )''' - обработка текстур, например полупрозрачные текстуры без применения этой строки будут выглядеть непрозрачными черными в прозрачных местах. Эти методы блендинга соответствуют переключателю в сдк, где варианты ALPHA-ADD, BLEND, SET и так далее. На примере выше блендинг соответствует положению ALPHA-ADD.<br />
<br />
:: '''true''' - может быть '''false''' - включение обработки текстур, тоесть true - обработка включена, false соответственно выключена.<br />
<br />
:: '''blend.srcalpha''', '''blend.one''' - соответственно методы блендинга, могут быть blend.one, blend.zero, blend.srcalpha, blend.invsrcalpha, blend.srccolor и null<br />
<br />
<br />
* ''': sorting ( 3, false )''' - порядок отрисовки поверхности по отношению к самому объекту, частью которого является поверхность.<br />
<br />
:: '''3''' - цифра порядка отрисовки, где 1 - за объектом, 2 - на уровне с объектом, 3 - спереди объекта (ближе к актору). Как правило при тройке шейдируемая поверхность будет отрисовываться поверх всего, в том числе и оружия.<br />
<br />
:: '''false''' - соответствует галочке "srict sorting" в сдк. Пока назначение неизвестно.<br />
<br />
<br />
* ''': aref ( false, 2 )''' - альфа-референс объекта, оператор, переключающий многобитную альфу текстуры в однобитную.<br />
<br />
:: '''false''' - включение/выключение данной функции.<br />
<br />
:: '''2''' - сам альфа-референс объекта<br />
<br />
<br />
* ''': zb ( false, false )''' - манипуляции с z-буфером, где первый аргумент соответствует галке z-test в сдк, второй - галке z-write.<br />
<br />
* ''': fog ( false )''' - действие представляет собой превращение текстуры в черно-белую и применение к ней функции calc_fogging в common.h шейдеров соответствующего рендера.<br />
<br />
* ''': emissive ( true )''' - применяется в источниках освещения.<br />
<br />
* ''': distort ( true )''' - представляет из себя механизм искажений, аналогичный эффекту искажающегося воздуха в некоторых аномалиях, а также "линза" в главном меню над кнопками.<br />
<br />
----<br />
<br />
<br />
* '''shader : sampler( "s_base" )''' - создание буфера для помещения туда текстуры. Аргумент представляет собой идентификатор, получаемый ps и vs шейдерами, где будет фигурировать как predefined-переменная s_base.<br />
<br />
<br />
''Перечисленные ниже параметры могут быть только ниже сэмплерной строки!''<br />
<br />
<br />
* ''': texture ( t_base ) ''' - помещение в вышеобъявленный буфер текстуры. аргумент этой ф-ции представляет собой путь к текстуре, так что вполне можно указать нечто вроде<br />
<br />
: texture ( "fx\\fx_sun" )<br />
<br />
чтобы в буфер воткнуть текстуру '''gamedata/textures/fx/fx_sun.dds'''<br />
<br />
<br />
* ''': clamp()''' - соответствует галке Texture Clamp в сдк. Википедия [http://en.wikipedia.org/wiki/Clamping_%28graphics%29 отвечает] на этот вопрос весьма туманно. <br />
<br />
* ''': project()''' - используется в шейдере отрисовки неточечного источника света, и предположительно используется для проектирвоания текстуры сэмплера на те объекты которые находятся в пределах сектора сферы.<br />
<br />
* ''': wrap ()''' - Википедия [http://en.wikipedia.org/wiki/Wrapping_%28graphics%29 отвечает] на этот вопрос не менее туманно чем в примере выше.<br />
<br />
Ниже представлены еще два оператора используемые с сэмплером, назначение которых неизвестно.<br />
<br />
<br />
* ''': f_linear ()'''<br />
<br />
* ''': f_anisotropic ()'''<br />
<br />
<br />
----<br />
<br />
<br />
Также в папке с шейдерами лежат еще файлы .s (именно такого имени - точка и эс), которые являются для всех *.s-файлов своеобразными заголовочными файлами, функции из файла .s доступны из файлов *.s . На данный момент там имеются функции printf, и закомментированные во втором рендере ф-ции l_point и l_spot, которые отвечают за создание точечного и неточечного источников света соответственно.<br />
<br />
<br />
'''Статья создана участником cjayho'''<br />
<br />
[[Категория:Скрипты]]</div>80.93.126.66http://stalkerin.gameru.net/wiki/index.php?title=%D0%A1%D0%BA%D1%80%D0%B8%D0%BF%D1%82%D0%BE%D0%B2%D1%8B%D0%B5_%D1%88%D0%B5%D0%B9%D0%B4%D0%B5%D1%80%D1%8BСкриптовые шейдеры2011-01-17T16:19:51Z<p>80.93.126.66: </p>
<hr />
<div>Редактируя любую модель, многие в свойствах поверхностей замечали графу shader, в которой указывается нечто вроде models/model или подобные.<br />
Как правило эти шейдеры упакованы в shaders.xr и shaders_xrlc.xr, которые представляют собой своеобразную базу данных шейдеров, собранных по определенным шаблонам.<br />
<br />
Но кроме этих баз данных есть еще и скриптовые шейдеры, которые имеют приоритет перед теми шейдерами что упакованы в *.xr. Это файлы, имеющие расширение .s и лежащие в папках соответствующих рендеров. Вычислить правильное название шейдера в БД и шейдерного скрипта .s можно очень просто - для примера если у нас в БД шейдер находится в model/selflight, то имя шейдера должно быть model_selflight.s, если details/blend, то скрипт шейдера будет соответственно details_blend.s . Не так уж сложно.<br />
<br />
Вообще база данных с шейдерами была выдумана не потому что авторам сталкера очень нравилось плодить экземпляры труднораспарсиваемых форматов, а причина более банальна - чтобы увеличить скорость загрузки игры сэкономив за счет активности жесткого диска, при открытии файлов скриптовых шейдеров в папке соответствующего рендера. Плюс к тому, в этом случае уменьшается количество шейдерных файлов что как минимум вдвое уменьшает вероятность ошибки - при условии двух рендеров, эта экономия получается за счет тех шейдеров, которые являются общими для обоих рендеров. Плюс к тому вероятность ошибки еще более уменьшается тем, что базы данных редактируются в сдк, а сдк эти базы данных представляет в виде всевозможных галочек и полей ввода, поэтому ошибка может быть только во вводимых данных, но не в скриптовом коде шейдеров, который вероятнее всего генерируется во время загрузки игры.<br />
<br />
Скриптовые шейдеры используются же в основном только в тех случаях когда их код отличается для разных рендеров.<br />
<br />
По некоторым причинам я считаю что для модостроителей шейдерные скрипты являются более предпочтительными, чем распространение своих шейдерных модов в виде модифицированной .xr-БД. Причины в основном две - во первых скриптовые шейдеры предоставляют бОльшие возможности для полета фантазии :), а во вторых распространение шейдерных модов в виде скриптовых шейдеров все же делает меньше вероятность конфликта модов, так как разные шейдеры будут в разных файлах, а не все вместе в одном хитром и трудноредактируемом, и что самое плохое - трудно-объединяемом файле. Поэтому далее мы рассмотрим скриптовые шейдеры.<br />
<br />
Что собой представляют шейдерные скрипты? Это обычные скрипты на lua, и которые являются своеобразным языком для того чтобы объяснить движку, какие загружать текстуры и какие подключать шейдеры из наличествующих .ps и .vs файлов. <br />
<br />
: ''Для тех кто воспрял духом сразу скажу что несмотря на то, что шейдерные скрипты написаны на языке, который используется в игровых скриптах, это все-таки не одно и то же. Во первых шейдерные скрипты выполняются при загрузке уровня всего один раз (в фазу загрузки "загрузка шейдеров"), поэтому на отрисовку в реальном времени влиять неспособны, и кроме того к игровым скриптам скриптовые шейдеры доступа не имеют.''<br />
<br />
Вот для примера содержимое простейшего скриптового шейдера:<br />
<br />
function normal( shader, t_base, t_second, t_detail )<br />
<br />
shader:begin( "effects_gradient", "effects_gradient_p" )<br />
<br />
end<br />
<br />
Разберем его по косточкам:<br />
<br />
* '''function normal''' - объявление стандартной функции шейдерного скрипта. В некоторых шейдерах есть еще функции '''l_spot''', '''l_point''' и '''l_special''' аналогичного содержания, но явно просчитывающие поведение этого шейдера в условиях освещения<br />
<br />
* '''shader''' - вероятнее всего идентификатор шейдера в игре, содержимое этой переменной представляет собой вероятнее всего текстовую строку вроде "models_selflight" или "models/selflight".<br />
* '''t_base''' - путь к текстуре которую следует выводить с помощью этого шейдера<br />
* '''t_second''', '''t_detail''' - пути к другим текстурам, пока назначение их неизвестно.<br />
<br />
* '''shader:begin( "effects_gradient", "effects_gradient_p" )''' - святая святых шейдера. Если точнее - создание объекта шейдера как такового. <br />
:: '''effects_gradient''' - имя .vs файла используемого в этом шейдере<br />
:: '''effects_gradient_p''' - имя .ps файла соответственно.<br />
<br />
<br />
После этой строки могут быть такие строки (они необязательны)<br />
<br />
<br />
* ''': blend ( true, blend.srcalpha, blend.one )''' - обработка текстур, например полупрозрачные текстуры без применения этой строки будут выглядеть непрозрачными черными в прозрачных местах. Эти методы блендинга соответствуют переключателю в сдк, где варианты ALPHA-ADD, BLEND, SET и так далее. На примере выше блендинг соответствует положению ALPHA-ADD.<br />
<br />
:: '''true''' - может быть '''false''' - включение обработки текстур, тоесть true - обработка включена, false соответственно выключена.<br />
<br />
:: '''blend.srcalpha''', '''blend.one''' - соответственно методы блендинга, могут быть blend.one, blend.zero, blend.srcalpha, blend.invsrcalpha и null<br />
<br />
<br />
* ''': sorting ( 3, false )''' - порядок отрисовки поверхности по отношению к самому объекту, частью которого является поверхность.<br />
<br />
:: '''3''' - цифра порядка отрисовки, где 1 - за объектом, 2 - на уровне с объектом, 3 - спереди объекта (ближе к актору). Как правило при тройке шейдируемая поверхность будет отрисовываться поверх всего, в том числе и оружия.<br />
<br />
:: '''false''' - соответствует галочке "srict sorting" в сдк. Пока назначение неизвестно.<br />
<br />
<br />
* ''': aref ( false, 2 )''' - альфа-референс объекта, оператор, переключающий многобитную альфу текстуры в однобитную.<br />
<br />
:: '''false''' - включение/выключение данной функции.<br />
<br />
:: '''2''' - сам альфа-референс объекта<br />
<br />
<br />
* ''': zb ( false, false )''' - манипуляции с z-буфером, где первый аргумент соответствует галке z-test в сдк, второй - галке z-write.<br />
<br />
* ''': fog ( false )''' - действие представляет собой превращение текстуры в черно-белую и применение к ней функции calc_fogging в common.h шейдеров соответствующего рендера.<br />
<br />
* ''': emissive ( true )''' - применяется в источниках освещения.<br />
<br />
* ''': distort ( true )''' - представляет из себя механизм искажений, аналогичный эффекту искажающегося воздуха в некоторых аномалиях, а также "линза" в главном меню над кнопками.<br />
<br />
----<br />
<br />
<br />
* '''shader : sampler( "s_base" )''' - создание буфера для помещения туда текстуры. Аргумент представляет собой идентификатор, получаемый ps и vs шейдерами, где будет фигурировать как predefined-переменная s_base.<br />
<br />
<br />
''Перечисленные ниже параметры могут быть только ниже сэмплерной строки!''<br />
<br />
<br />
* ''': texture ( t_base ) ''' - помещение в вышеобъявленный буфер текстуры. аргумент этой ф-ции представляет собой путь к текстуре, так что вполне можно указать нечто вроде<br />
<br />
: texture ( "fx\\fx_sun" )<br />
<br />
чтобы в буфер воткнуть текстуру '''gamedata/textures/fx/fx_sun.dds'''<br />
<br />
<br />
* ''': clamp()''' - соответствует галке Texture Clamp в сдк. Википедия [http://en.wikipedia.org/wiki/Clamping_%28graphics%29 отвечает] на этот вопрос весьма туманно. <br />
<br />
* ''': project()''' - используется в шейдере отрисовки неточечного источника света, и предположительно используется для проектирвоания текстуры сэмплера на те объекты которые находятся в пределах сектора сферы.<br />
<br />
* ''': wrap ()''' - Википедия [http://en.wikipedia.org/wiki/Wrapping_%28graphics%29 отвечает] на этот вопрос не менее туманно чем в примере выше.<br />
<br />
Ниже представлены еще два оператора используемые с сэмплером, назначение которых неизвестно.<br />
<br />
<br />
* ''': f_linear ()'''<br />
<br />
* ''': f_anisotropic ()'''<br />
<br />
<br />
----<br />
<br />
<br />
Также в папке с шейдерами лежат еще файлы .s (именно такого имени - точка и эс), которые являются для всех *.s-файлов своеобразными заголовочными файлами, функции из файла .s доступны из файлов *.s . На данный момент там имеются функции printf, и закомментированные во втором рендере ф-ции l_point и l_spot, которые отвечают за создание точечного и неточечного источников света соответственно.<br />
<br />
<br />
'''Статья создана участником cjayho'''<br />
<br />
[[Категория:Скрипты]]</div>80.93.126.66http://stalkerin.gameru.net/wiki/index.php?title=%D0%A1%D0%BA%D1%80%D0%B8%D0%BF%D1%82%D0%BE%D0%B2%D1%8B%D0%B5_%D1%88%D0%B5%D0%B9%D0%B4%D0%B5%D1%80%D1%8BСкриптовые шейдеры2011-01-17T16:17:06Z<p>80.93.126.66: </p>
<hr />
<div>Редактируя любую модель, многие в свойствах поверхностей замечали графу shader, в которой указывается нечто вроде models/model или подобные.<br />
Как правило эти шейдеры упакованы в shaders.xr и shaders_xrlc.xr, которые представляют собой своеобразную базу данных шейдеров, собранных по определенным шаблонам.<br />
<br />
Но кроме этих баз данных есть еще и скриптовые шейдеры, которые имеют приоритет перед теми шейдерами что упакованы в *.xr. Это файлы, имеющие расширение .s и лежащие в папках соответствующих рендеров. Вычислить правильное название шейдера в БД и шейдерного скрипта .s можно очень просто - для примера если у нас в БД шейдер находится в model/selflight, то имя шейдера должно быть model_selflight.s, если details/blend, то скрипт шейдера будет соответственно details_blend.s . Не так уж сложно.<br />
<br />
Вообще база данных с шейдерами была выдумана не потому что авторам сталкера очень нравилось плодить экземпляры труднораспарсиваемых форматов, а причина более банальна - чтобы увеличить скорость загрузки игры сэкономив за счет активности жесткого диска, при открытии файлов скриптовых шейдеров в папке соответствующего рендера. Плюс к тому, в этом случае уменьшается количество шейдерных файлов что как минимум вдвое уменьшает вероятность ошибки - при условии двух рендеров, эта экономия получается за счет тех шейдеров, которые являются общими для обоих рендеров. Плюс к тому вероятность ошибки еще более уменьшается тем, что базы данных редактируются в сдк, а сдк эти базы данных представляет в виде всевозможных галочек и полей ввода, поэтому ошибка может быть только во вводимых данных, но не в скриптовом коде шейдеров, который вероятнее всего генерируется во время загрузки игры.<br />
<br />
Скриптовые шейдеры используются же в основном только в тех случаях когда их код отличается для разных рендеров.<br />
<br />
По некоторым причинам я считаю что для модостроителей шейдерные скрипты являются более предпочтительными, чем распространение своих шейдерных модов в виде модифицированной .xr-БД. Причины в основном две - во первых скриптовые шейдеры предоставляют бОльшие возможности для полета фантазии :), а во вторых распространение шейдерных модов в виде скриптовых шейдеров все же делает меньше вероятность конфликта модов, так как разные шейдеры будут в разных файлах, а не все вместе в одном хитром и трудноредактируемом, и что самое плохое - трудно-объединяемом файле. Поэтому далее мы рассмотрим скриптовые шейдеры.<br />
<br />
Что собой представляют шейдерные скрипты? Это обычные скрипты на lua, и которые являются своеобразным языком для того чтобы объяснить движку, какие загружать текстуры и какие подключать шейдеры из наличествующих .ps и .vs файлов. <br />
<br />
: ''Для тех кто воспрял духом сразу скажу что несмотря на то, что шейдерные скрипты написаны на языке, который используется в игровых скриптах, это все-таки не одно и то же. Во первых шейдерные скрипты выполняются при загрузке уровня всего один раз (в фазу загрузки "загрузка шейдеров"), поэтому на отрисовку в реальном времени влиять неспособны, и кроме того к игровым скриптам скриптовые шейдеры доступа не имеют.''<br />
<br />
Вот для примера содержимое простейшего скриптового шейдера:<br />
<br />
function normal( shader, t_base, t_second, t_detail )<br />
<br />
shader:begin( "effects_gradient", "effects_gradient_p" )<br />
<br />
end<br />
<br />
Разберем его по косточкам:<br />
<br />
* '''function normal''' - объявление стандартной функции шейдерного скрипта. В некоторых шейдерах есть еще функции '''l_spot''', '''l_point''' и '''l_special''' аналогичного содержания, но явно просчитывающие поведение этого шейдера в условиях освещения<br />
<br />
* '''shader''' - вероятнее всего идентификатор шейдера в игре, содержимое этой переменной представляет собой вероятнее всего текстовую строку вроде "models_selflight" или "models/selflight".<br />
* '''t_base''' - путь к текстуре которую следует выводить с помощью этого шейдера<br />
* '''t_second''', '''t_detail''' - пути к другим текстурам, пока назначение их неизвестно.<br />
<br />
* '''shader:begin( "effects_gradient", "effects_gradient_p" )''' - святая святых шейдера. Если точнее - создание объекта шейдера как такового. <br />
:: '''effects_gradient''' - имя .vs файла используемого в этом шейдере<br />
:: '''effects_gradient_p''' - имя .ps файла соответственно.<br />
<br />
<br />
После этой строки могут быть такие строки (они необязательны)<br />
<br />
<br />
* ''': blend ( true, blend.srcalpha, blend.one )''' - обработка текстур, например полупрозрачные текстуры без применения этой строки будут выглядеть непрозрачными черными в прозрачных местах. Эти методы блендинга соответствуют переключателю в сдк, где варианты ALPHA-ADD, BLEND, SET и так далее. На примере выше блендинг соответствует положению ALPHA-ADD.<br />
<br />
:: '''true''' - может быть '''false''' - включение обработки текстур, тоесть true - обработка включена, false соответственно выключена.<br />
<br />
:: '''blend.srcalpha''', '''blend.one''' - соответственно методы блендинга, могут быть blend.one, blend.zero, blend.srcalpha, blend.invsrcalpha и null<br />
<br />
<br />
* ''': sorting ( 3, false )''' - порядок отрисовки поверхности по отношению к самому объекту, частью которого является поверхность.<br />
<br />
:: '''3''' - цифра порядка отрисовки, где 1 - за объектом, 2 - на уровне с объектом, 3 - спереди объекта (ближе к актору). Как правило при тройке шейдируемая поверхность будет отрисовываться поверх всего, в том числе и оружия.<br />
<br />
:: '''false''' - соответствует галочке "srict sorting" в сдк. Пока назначение неизвестно.<br />
<br />
<br />
* ''': aref ( false, 2 )''' - альфа-референс объекта, оператор, переключающий многобитную альфу текстуры в однобитную.<br />
<br />
:: '''false''' - включение/выключение данной функции.<br />
<br />
:: '''2''' - сам альфа-референс объекта<br />
<br />
<br />
* ''': zb ( false, false )''' - манипуляции с z-буфером, где первый аргумент соответствует галке z-test в сдк, второй - галке z-write.<br />
<br />
* ''': fog ( false )''' - действие представляет собой превращение текстуры в черно-белую и применение к ней функции calc_fogging в common.h шейдеров соответствующего рендера.<br />
<br />
* ''': emissive ( true )''' - применяется в источниках освещения.<br />
<br />
* ''': distort ( true )''' - представляет из себя механизм искажений, аналогичный эффекту искажающегося воздуха в некоторых аномалиях, а также "линза" в главном меню над кнопками.<br />
<br />
----<br />
<br />
<br />
* '''shader : sampler( "s_base" )''' - создание буфера для помещения туда текстуры. Аргумент представляет собой идентификатор, получаемый ps и vs шейдерами, где будет фигурировать как predefined-переменная s_base.<br />
<br />
<br />
''Перечисленные ниже параметры могут быть только ниже сэмплерной строки!''<br />
<br />
<br />
* ''': texture ( t_base ) ''' - помещение в вышеобъявленный буфер текстуры. аргумент этой ф-ции представляет собой путь к текстуре, так что вполне можно указать нечто вроде<br />
<br />
: texture ( "fx\\fx_sun" )<br />
<br />
чтобы в буфер воткнуть текстуру '''gamedata/textures/fx/fx_sun.dds'''<br />
<br />
<br />
* ''': clamp()''' - соответствует галке Texture Clamp в сдк. Википедия [http://en.wikipedia.org/wiki/Clamping_%28graphics%29 отвечает] на этот вопрос весьма туманно. Но по псевдокоду становится понятно что это ограничение минимального и максимального значения цвета определенными границами, то есть если число цвета меньше или больше соответствующей границы то выходное значение будет равно значению соответствующей границы.<br />
<br />
* ''': project()''' - используется в шейдере отрисовки неточечного источника света, и предположительно используется для проектирвоания текстуры сэмплера на те объекты которые находятся в пределах сектора сферы.<br />
<br />
* ''': wrap ()''' - Википедия [http://en.wikipedia.org/wiki/Wrapping_%28graphics%29 отвечает] на этот вопрос не менее туманно чем в примере выше, но так же по псевдокоду становится понятно что шкала приращения значений разворачивается в обратную сторону, и если на входе значение 255, то на выходе 0, если 200 - на выходе 55. и так далее - если на входе 0 то на выходе 255.<br />
<br />
Ниже представлены еще два оператора используемые с сэмплером, назначение которых неизвестно.<br />
<br />
<br />
* ''': f_linear ()'''<br />
<br />
* ''': f_anisotropic ()'''<br />
<br />
<br />
----<br />
<br />
<br />
Также в папке с шейдерами лежат еще файлы .s (именно такого имени - точка и эс), которые являются для всех *.s-файлов своеобразными заголовочными файлами, функции из файла .s доступны из файлов *.s . На данный момент там имеются функции printf, и закомментированные во втором рендере ф-ции l_point и l_spot, которые отвечают за создание точечного и неточечного источников света соответственно.<br />
<br />
<br />
'''Статья создана участником cjayho'''<br />
<br />
[[Категория:Скрипты]]</div>80.93.126.66http://stalkerin.gameru.net/wiki/index.php?title=%D0%A1%D0%BA%D1%80%D0%B8%D0%BF%D1%82%D0%BE%D0%B2%D1%8B%D0%B5_%D1%88%D0%B5%D0%B9%D0%B4%D0%B5%D1%80%D1%8BСкриптовые шейдеры2011-01-17T16:16:10Z<p>80.93.126.66: </p>
<hr />
<div>Редактируя любую модель, многие в свойствах поверхностей замечали графу shader, в которой указывается нечто вроде models/model или подобные.<br />
Как правило эти шейдеры упакованы в shaders.xr и shaders_xrlc.xr, которые представляют собой своеобразную базу данных шейдеров, собранных по определенным шаблонам.<br />
<br />
Но кроме этих баз данных есть еще и скриптовые шейдеры, которые имеют приоритет перед теми шейдерами что упакованы в *.xr. Это файлы, имеющие расширение .s и лежащие в папках соответствующих рендеров. Вычислить правильное название шейдера в БД и шейдерного скрипта .s можно очень просто - для примера если у нас в БД шейдер находится в model/selflight, то имя шейдера должно быть model_selflight.s, если details/blend, то скрипт шейдера будет соответственно details_blend.s . Не так уж сложно.<br />
<br />
Вообще база данных с шейдерами была выдумана не потому что авторам сталкера очень нравилось плодить экземпляры труднораспарсиваемых форматов, а причина более банальна - чтобы увеличить скорость загрузки игры сэкономив за счет активности жесткого диска, при открытии файлов скриптовых шейдеров в папке соответствующего рендера. Плюс к тому, в этом случае уменьшается количество шейдерных файлов что как минимум вдвое уменьшает вероятность ошибки - при условии двух рендеров, эта экономия получается за счет тех шейдеров, которые являются общими для обоих рендеров. Плюс к тому вероятность ошибки еще более уменьшается тем, что базы данных редактируются в сдк, а сдк эти базы данных представляет в виде всевозможных галочек и полей ввода, поэтому ошибка может быть только во вводимых данных, но не в скриптовом коде шейдеров, который вероятнее всего генерируется во время загрузки игры.<br />
<br />
Скриптовые шейдеры используются же в основном только в тех случаях когда их код отличается для разных рендеров.<br />
<br />
По некоторым причинам я считаю что для модостроителей шейдерные скрипты являются более предпочтительными, чем распространение своих шейдерных модов в виде модифицированной .xr-БД. Причины в основном две - во первых скриптовые шейдеры предоставляют бОльшие возможности для полета фантазии :), а во вторых распространение шейдерных модов в виде скриптовых шейдеров все же делает меньше вероятность конфликта модов, так как разные шейдеры будут в разных файлах, а не все вместе в одном хитром и трудноредактируемом, и что самое плохое - трудно-объединяемом файле. Поэтому далее мы рассмотрим скриптовые шейдеры.<br />
<br />
Что собой представляют шейдерные скрипты? Это обычные скрипты на lua, и которые являются своеобразным языком для того чтобы объяснить движку, какие загружать текстуры и какие подключать шейдеры из наличествующих .ps и .vs файлов. <br />
<br />
: ''Для тех кто воспрял духом сразу скажу что несмотря на то, что шейдерные скрипты написаны на языке, который используется в игровых скриптах, это все-таки не одно и то же. Во первых шейдерные скрипты выполняются при загрузке уровня всего один раз (в фазу загрузки "загрузка шейдеров"), поэтому на отрисовку в реальном времени влиять неспособны, и кроме того к игровым скриптам скриптовые шейдеры доступа не имеют.''<br />
<br />
Вот для примера содержимое простейшего скриптового шейдера:<br />
<br />
function normal( shader, t_base, t_second, t_detail )<br />
<br />
shader:begin( "effects_gradient", "effects_gradient_p" )<br />
<br />
end<br />
<br />
Разберем его по косточкам:<br />
<br />
* '''function normal''' - объявление стандартной функции шейдерного скрипта. В некоторых шейдерах есть еще функции '''l_spot''', '''l_point''' и '''l_special''' аналогичного содержания, но явно просчитывающие поведение этого шейдера в условиях освещения<br />
<br />
* '''shader''' - вероятнее всего идентификатор шейдера в игре, содержимое этой переменной представляет собой вероятнее всего текстовую строку вроде "models_selflight" или "models/selflight".<br />
* '''t_base''' - путь к текстуре которую следует выводить с помощью этого шейдера<br />
* '''t_second''', '''t_detail''' - пути к другим текстурам, пока назначение их неизвестно.<br />
<br />
* '''shader:begin( "effects_gradient", "effects_gradient_p" )''' - святая святых шейдера. Если точнее - создание объекта шейдера как такового. <br />
:: '''effects_gradient''' - имя .vs файла используемого в этом шейдере<br />
:: '''effects_gradient_p''' - имя .ps файла соответственно.<br />
<br />
<br />
После этой строки могут быть такие строки (они необязательны)<br />
<br />
<br />
* ''': blend ( true, blend.srcalpha, blend.one )''' - обработка текстур, например полупрозрачные текстуры без применения этой строки будут выглядеть непрозрачными черными в прозрачных местах. Эти методы блендинга соответствуют переключателю в сдк, где варианты ALPHA-ADD, BLEND, SET и так далее. На примере выше блендинг соответствует положению ALPHA-ADD.<br />
<br />
:: '''true''' - может быть '''false''' - включение обработки текстур, тоесть true - обработка включена, false соответственно выключена.<br />
<br />
:: '''blend.srcalpha''', '''blend.one''' - соответственно методы блендинга, могут быть blend.one, blend.zero, blend.srcalpha, blend.invsrcalpha и null<br />
<br />
<br />
* ''': sorting ( 3, false )''' - порядок отрисовки поверхности по отношению к самому объекту, частью которого является поверхность.<br />
<br />
:: '''3''' - цифра порядка отрисовки, где 1 - за объектом, 2 - на уровне с объектом, 3 - спереди объекта (ближе к актору). Как правило при тройке шейдируемая поверхность будет отрисовываться поверх всего, в том числе и оружия.<br />
<br />
:: '''false''' - соответствует галочке "srict sorting" в сдк. Пока назначение неизвестно.<br />
<br />
<br />
* ''': aref ( false, 2 )''' - альфа-референс объекта, оператор, переключающий многобитную альфу текстуры в однобитную.<br />
<br />
:: '''false''' - включение/выключение данной функции.<br />
<br />
:: '''2''' - сам альфа-референс объекта<br />
<br />
<br />
* ''': zb ( false, false )''' - манипуляции с z-буфером, где первый аргумент соответствует галке z-test в сдк, второй - галке z-write.<br />
<br />
* ''': fog ( false )''' - действие представляет собой превращение текстуры в черно-белую и применение к ней функции calc_fogging в common.h шейдеров соответствующего рендера.<br />
<br />
* ''': emissive ( true )''' - применяется в источниках освещения.<br />
<br />
* ''': distort ( true )''' - представляет из себя механизм искажений, аналогичный эффекту искажающегося воздуха в некоторых аномалиях, а также "линза" в главном меню над кнопками.<br />
<br />
----<br />
<br />
<br />
* '''shader : sampler( "s_base" )''' - создание буфера для помещения туда текстуры. Аргумент представляет собой идентификатор, получаемый ps и vs шейдерами, где будет фигурировать как predefined-переменная s_base.<br />
<br />
<br />
''Перечисленные ниже параметры могут быть только ниже сэмплерной строки!''<br />
<br />
<br />
* ''': texture ( t_base ) ''' - помещение в вышеобъявленный буфер текстуры. аргумент этой ф-ции представляет собой путь к текстуре, так что вполне можно указать нечто вроде<br />
<br />
: texture ( "fx\\fx_sun" )<br />
<br />
чтобы в буфер воткнуть текстуру '''gamedata/textures/fx/fx_sun.dds'''<br />
<br />
<br />
* ''': clamp()''' - соответствует галке Texture Clamp в сдк. Википедия [http://en.wikipedia.org/wiki/Clamping_%28graphics%29 отвечает] на этот вопрос весьма туманно. Но по псевдокоду становится понятно что это ограничение минимального и максимального значения цвета определенными границами, то есть если число цвета меньше или больше соответствующей границы то выходное значение будет равно значению соответствующей границы.<br />
<br />
* ''': project()''' - используется в шейдере отрисовки неточечного источника света, и предположительно используется для проектирвоания текстуры сэмплера на те объекты которые находятся в пределах сектора сферы.<br />
<br />
* ''': wrap ()''' - Википедия [http://en.wikipedia.org/wiki/Wrapping_%28graphics%29 отвечает] на этот вопрос не менее туманно чем в примере выше, но так же по псевдокоду становится понятно что шкала приращения значений разворачивается в обратную сторону, и если на входе значение 255, то на выходе 0, если 200 - на выходе 55. и так далее - если на входе 0 то на выходе 255.<br />
<br />
Ниже представлены еще три оператора используемые с сэмплером, назначение которых неизвестно.<br />
<br />
<br />
* ''': f_linear ()'''<br />
<br />
* ''': f_anisotropic ()'''<br />
<br />
<br />
----<br />
<br />
<br />
Также в папке с шейдерами лежат еще файлы .s (именно такого имени - точка и эс), которые являются для всех *.s-файлов своеобразными заголовочными файлами, функции из файла .s доступны из файлов *.s . На данный момент там имеются функции printf, и закомментированные во втором рендере ф-ции l_point и l_spot, которые отвечают за создание точечного и неточечного источников света соответственно.<br />
<br />
<br />
'''Статья создана участником cjayho'''<br />
<br />
[[Категория:Скрипты]]</div>80.93.126.66http://stalkerin.gameru.net/wiki/index.php?title=%D0%A1%D0%BA%D1%80%D0%B8%D0%BF%D1%82%D0%BE%D0%B2%D1%8B%D0%B5_%D1%88%D0%B5%D0%B9%D0%B4%D0%B5%D1%80%D1%8BСкриптовые шейдеры2011-01-17T16:13:58Z<p>80.93.126.66: </p>
<hr />
<div>Редактируя любую модель, многие в свойствах поверхностей замечали графу shader, в которой указывается нечто вроде models/model или подобные.<br />
Как правило эти шейдеры упакованы в shaders.xr и shaders_xrlc.xr, которые представляют собой своеобразную базу данных шейдеров, собранных по определенным шаблонам.<br />
<br />
Но кроме этих баз данных есть еще и скриптовые шейдеры, которые имеют приоритет перед теми шейдерами что упакованы в *.xr. Это файлы, имеющие расширение .s и лежащие в папках соответствующих рендеров. Вычислить правильное название шейдера в БД и шейдерного скрипта .s можно очень просто - для примера если у нас в БД шейдер находится в model/selflight, то имя шейдера должно быть model_selflight.s, если details/blend, то скрипт шейдера будет соответственно details_blend.s . Не так уж сложно.<br />
<br />
Вообще база данных с шейдерами была выдумана не потому что авторам сталкера очень нравилось плодить экземпляры труднораспарсиваемых форматов, а причина более банальна - чтобы увеличить скорость загрузки игры сэкономив за счет активности жесткого диска, при открытии файлов скриптовых шейдеров в папке соответствующего рендера. Плюс к тому, в этом случае уменьшается количество шейдерных файлов что как минимум вдвое уменьшает вероятность ошибки - при условии двух рендеров, эта экономия получается за счет тех шейдеров, которые являются общими для обоих рендеров. Плюс к тому вероятность ошибки еще более уменьшается тем, что базы данных редактируются в сдк, а сдк эти базы данных представляет в виде всевозможных галочек и полей ввода, поэтому ошибка может быть только во вводимых данных, но не в скриптовом коде шейдеров, который вероятнее всего генерируется во время загрузки игры.<br />
<br />
Скриптовые шейдеры используются же в основном только в тех случаях когда их код отличается для разных рендеров.<br />
<br />
По некоторым причинам я считаю что для модостроителей шейдерные скрипты являются более предпочтительными, чем распространение своих шейдерных модов в виде модифицированной .xr-БД. Причины в основном две - во первых скриптовые шейдеры предоставляют бОльшие возможности для полета фантазии :), а во вторых распространение шейдерных модов в виде скриптовых шейдеров все же делает меньше вероятность конфликта модов, так как разные шейдеры будут в разных файлах, а не все вместе в одном хитром и трудноредактируемом, и что самое плохое - трудно-объединяемом файле. Поэтому далее мы рассмотрим скриптовые шейдеры.<br />
<br />
Что собой представляют шейдерные скрипты? Это обычные скрипты на lua, и которые являются своеобразным языком для того чтобы объяснить движку, какие загружать текстуры и какие подключать шейдеры из наличествующих .ps и .vs файлов. <br />
<br />
: ''Для тех кто воспрял духом сразу скажу что несмотря на то, что шейдерные скрипты написаны на языке, который используется в игровых скриптах, это все-таки не одно и то же. Во первых шейдерные скрипты выполняются при загрузке уровня всего один раз (в фазу загрузки "загрузка шейдеров"), поэтому на отрисовку в реальном времени влиять неспособны, и кроме того к игровым скриптам скриптовые шейдеры доступа не имеют.''<br />
<br />
Вот для примера содержимое простейшего скриптового шейдера:<br />
<br />
function normal( shader, t_base, t_second, t_detail )<br />
<br />
shader:begin( "effects_gradient", "effects_gradient_p" )<br />
<br />
end<br />
<br />
Разберем его по косточкам:<br />
<br />
* '''function normal''' - объявление стандартной функции шейдерного скрипта. В некоторых шейдерах есть еще функции '''l_spot''', '''l_point''' и '''l_special''' аналогичного содержания, но явно просчитывающие поведение этого шейдера в условиях освещения<br />
<br />
* '''shader''' - вероятнее всего идентификатор шейдера в игре, содержимое этой переменной представляет собой вероятнее всего текстовую строку вроде "models_selflight" или "models/selflight".<br />
* '''t_base''' - путь к текстуре которую следует выводить с помощью этого шейдера<br />
* '''t_second''', '''t_detail''' - пути к другим текстурам, пока назначение их неизвестно.<br />
<br />
* '''shader:begin( "effects_gradient", "effects_gradient_p" )''' - святая святых шейдера. Если точнее - создание объекта шейдера как такового. <br />
:: '''effects_gradient''' - имя .vs файла используемого в этом шейдере<br />
:: '''effects_gradient_p''' - имя .ps файла соответственно.<br />
<br />
<br />
После этой строки могут быть такие строки (они необязательны)<br />
<br />
<br />
* ''': blend ( true, blend.srcalpha, blend.one )''' - обработка текстур, например полупрозрачные текстуры без применения этой строки будут выглядеть непрозрачными черными в прозрачных местах. Эти методы блендинга соответствуют переключателю в сдк, где варианты ALPHA-ADD, BLEND, SET и так далее. На примере выше блендинг соответствует положению ALPHA-ADD.<br />
<br />
:: '''true''' - может быть '''false''' - включение обработки текстур, тоесть true - обработка включена, false соответственно выключена.<br />
<br />
:: '''blend.srcalpha''', '''blend.one''' - соответственно методы блендинга, могут быть blend.one, blend.zero, blend.srcalpha, blend.invsrcalpha и null<br />
<br />
<br />
* ''': sorting ( 3, false )''' - порядок отрисовки поверхности по отношению к самому объекту, частью которого является поверхность.<br />
<br />
:: '''3''' - цифра порядка отрисовки, где 1 - за объектом, 2 - на уровне с объектом, 3 - спереди объекта (ближе к актору). Как правило при тройке шейдируемая поверхность будет отрисовываться поверх всего, в том числе и оружия.<br />
<br />
:: '''false''' - соответствует галочке "srict sorting" в сдк. Пока назначение неизвестно.<br />
<br />
<br />
* ''': aref ( false, 2 )''' - альфа-референс объекта, оператор, переключающий многобитную альфу текстуры в однобитную.<br />
<br />
:: '''false''' - включение/выключение данной функции.<br />
<br />
:: '''2''' - сам альфа-референс объекта<br />
<br />
<br />
* ''': zb ( false, false )''' - манипуляции с z-буфером, где первый аргумент соответствует галке z-test в сдк, второй - галке z-write.<br />
<br />
* ''': fog ( false )''' - действие представляет собой превращение текстуры в черно-белую и применение к ней функции calc_fogging в common.h шейдеров соответствующего рендера.<br />
<br />
* ''': emissive ( true )''' - применяется в источниках освещения.<br />
<br />
* ''': distort ( true )''' - представляет из себя механизм искажений, аналогичный эффекту искажающегося воздуха в некоторых аномалиях, а также "линза" в главном меню над кнопками.<br />
<br />
----<br />
<br />
<br />
* '''shader : sampler( "s_base" )''' - создание буфера для помещения туда текстуры. Аргумент представляет собой идентификатор, получаемый ps и vs шейдерами, где будет фигурировать как predefined-переменная s_base.<br />
<br />
<br />
''Перечисленные ниже параметры могут быть только ниже сэмплерной строки!''<br />
<br />
<br />
* ''': texture ( t_base ) ''' - помещение в вышеобъявленный буфер текстуры. аргумент этой ф-ции представляет собой путь к текстуре, так что вполне можно указать нечто вроде<br />
<br />
: texture ( "fx\\fx_sun" )<br />
<br />
чтобы в буфер воткнуть текстуру '''gamedata/textures/fx/fx_sun.dds'''<br />
<br />
<br />
* ''': clamp()''' - соответствует галке Texture Clamp в сдк. Википедия [http://en.wikipedia.org/wiki/Clamping_%28graphics%29 отвечает] на этот вопрос весьма туманно. Но по псевдокоду становится понятно что это ограничение минимального и максимального значения цвета определенными границами, то есть если число цвета меньше или больше соответствующей границы то выходное значение будет равно значению соответствующей границы.<br />
<br />
* ''': project()''' - используется в шейдере отрисовки неточечного источника света, и предположительно используется для проектирвоания текстуры сэмплера на те объекты которые находятся в пределах сектора сферы.<br />
<br />
* ''': wrap ()''' - Википедия [http://en.wikipedia.org/wiki/Clamping_%28graphics%29 отвечает] на этот вопрос не менее туманно чем в примере выше, но так же по псевдокоду становится понятно что шкала приращения значений разворачивается в обратную сторону, и если на входе значение 255, то на выходе 0, если 200 - на выходе 55. и так далее - если на входе 0 то на выходе 255.<br />
<br />
Ниже представлены еще три оператора используемые с сэмплером, назначение которых неизвестно.<br />
<br />
<br />
* ''': f_linear ()'''<br />
<br />
* ''': f_anisotropic ()'''<br />
<br />
<br />
----<br />
<br />
<br />
Также в папке с шейдерами лежат еще файлы .s (именно такого имени - точка и эс), которые являются для всех *.s-файлов своеобразными заголовочными файлами, функции из файла .s доступны из файлов *.s . На данный момент там имеются функции printf, и закомментированные во втором рендере ф-ции l_point и l_spot, которые отвечают за создание точечного и неточечного источников света соответственно.<br />
<br />
<br />
'''Статья создана участником cjayho'''<br />
<br />
[[Категория:Скрипты]]</div>80.93.126.66http://stalkerin.gameru.net/wiki/index.php?title=%D0%A1%D0%BA%D1%80%D0%B8%D0%BF%D1%82%D0%BE%D0%B2%D1%8B%D0%B5_%D1%88%D0%B5%D0%B9%D0%B4%D0%B5%D1%80%D1%8BСкриптовые шейдеры2011-01-17T16:13:02Z<p>80.93.126.66: </p>
<hr />
<div>Редактируя любую модель, многие в свойствах поверхностей замечали графу shader, в которой указывается нечто вроде models/model или подобные.<br />
Как правило эти шейдеры упакованы в shaders.xr и shaders_xrlc.xr, которые представляют собой своеобразную базу данных шейдеров, собранных по определенным шаблонам.<br />
<br />
Но кроме этих баз данных есть еще и скриптовые шейдеры, которые имеют приоритет перед теми шейдерами что упакованы в *.xr. Это файлы, имеющие расширение .s и лежащие в папках соответствующих рендеров. Вычислить правильное название шейдера в БД и шейдерного скрипта .s можно очень просто - для примера если у нас в БД шейдер находится в model/selflight, то имя шейдера должно быть model_selflight.s, если details/blend, то скрипт шейдера будет соответственно details_blend.s . Не так уж сложно.<br />
<br />
Вообще база данных с шейдерами была выдумана не потому что авторам сталкера очень нравилось плодить экземпляры труднораспарсиваемых форматов, а причина более банальна - чтобы увеличить скорость загрузки игры сэкономив за счет активности жесткого диска, при открытии файлов скриптовых шейдеров в папке соответствующего рендера. Плюс к тому, в этом случае уменьшается количество шейдерных файлов что как минимум вдвое уменьшает вероятность ошибки - при условии двух рендеров, эта экономия получается за счет тех шейдеров, которые являются общими для обоих рендеров. Плюс к тому вероятность ошибки еще более уменьшается тем, что базы данных редактируются в сдк, а сдк эти базы данных представляет в виде всевозможных галочек и полей ввода, поэтому ошибка может быть только во вводимых данных, но не в скриптовом коде шейдеров, который вероятнее всего генерируется во время загрузки игры.<br />
<br />
Скриптовые шейдеры используются же в основном только в тех случаях когда их код отличается для разных рендеров.<br />
<br />
По некоторым причинам я считаю что для модостроителей шейдерные скрипты являются более предпочтительными, чем распространение своих шейдерных модов в виде модифицированной .xr-БД. Причины в основном две - во первых скриптовые шейдеры предоставляют бОльшие возможности для полета фантазии :), а во вторых распространение шейдерных модов в виде скриптовых шейдеров все же делает меньше вероятность конфликта модов, так как разные шейдеры будут в разных файлах, а не все вместе в одном хитром и трудноредактируемом, и что самое плохое - трудно-объединяемом файле. Поэтому далее мы рассмотрим скриптовые шейдеры.<br />
<br />
Что собой представляют шейдерные скрипты? Это обычные скрипты на lua, и которые являются своеобразным языком для того чтобы объяснить движку, какие загружать текстуры и какие подключать шейдеры из наличествующих .ps и .vs файлов. <br />
<br />
: ''Для тех кто воспрял духом сразу скажу что несмотря на то, что шейдерные скрипты написаны на языке, который используется в игровых скриптах, это все-таки не одно и то же. Во первых шейдерные скрипты выполняются при загрузке уровня всего один раз (в фазу загрузки "загрузка шейдеров"), поэтому на отрисовку в реальном времени влиять неспособны, и кроме того к игровым скриптам скриптовые шейдеры доступа не имеют.''<br />
<br />
Вот для примера содержимое простейшего скриптового шейдера:<br />
<br />
function normal( shader, t_base, t_second, t_detail )<br />
<br />
shader:begin( "effects_gradient", "effects_gradient_p" )<br />
<br />
end<br />
<br />
Разберем его по косточкам:<br />
<br />
* '''function normal''' - объявление стандартной функции шейдерного скрипта. В некоторых шейдерах есть еще функции '''l_spot''', '''l_point''' и '''l_special''' аналогичного содержания, но явно просчитывающие поведение этого шейдера в условиях освещения<br />
<br />
* '''shader''' - вероятнее всего идентификатор шейдера в игре, содержимое этой переменной представляет собой вероятнее всего текстовую строку вроде "models_selflight" или "models/selflight".<br />
* '''t_base''' - путь к текстуре которую следует выводить с помощью этого шейдера<br />
* '''t_second''', '''t_detail''' - пути к другим текстурам, пока назначение их неизвестно.<br />
<br />
* '''shader:begin( "effects_gradient", "effects_gradient_p" )''' - святая святых шейдера. Если точнее - создание объекта шейдера как такового. <br />
:: '''effects_gradient''' - имя .vs файла используемого в этом шейдере<br />
:: '''effects_gradient_p''' - имя .ps файла соответственно.<br />
<br />
<br />
После этой строки могут быть такие строки (они необязательны)<br />
<br />
<br />
* ''': blend ( true, blend.srcalpha, blend.one )''' - обработка текстур, например полупрозрачные текстуры без применения этой строки будут выглядеть непрозрачными черными в прозрачных местах. Эти методы блендинга соответствуют переключателю в сдк, где варианты ALPHA-ADD, BLEND, SET и так далее. На примере выше блендинг соответствует положению ALPHA-ADD.<br />
<br />
:: '''true''' - может быть '''false''' - включение обработки текстур, тоесть true - обработка включена, false соответственно выключена.<br />
<br />
:: '''blend.srcalpha''', '''blend.one''' - соответственно методы блендинга, могут быть blend.one, blend.zero, blend.srcalpha, blend.invsrcalpha и null<br />
<br />
<br />
* ''': sorting ( 3, false )''' - порядок отрисовки поверхности по отношению к самому объекту, частью которого является поверхность.<br />
<br />
:: '''3''' - цифра порядка отрисовки, где 1 - за объектом, 2 - на уровне с объектом, 3 - спереди объекта (ближе к актору). Как правило при тройке шейдируемая поверхность будет отрисовываться поверх всего, в том числе и оружия.<br />
<br />
:: '''false''' - соответствует галочке "srict sorting" в сдк. Пока назначение неизвестно.<br />
<br />
<br />
* ''': aref ( false, 2 )''' - альфа-референс объекта, оператор, переключающий многобитную альфу текстуры в однобитную.<br />
<br />
:: '''false''' - включение/выключение данной функции.<br />
<br />
:: '''2''' - сам альфа-референс объекта<br />
<br />
<br />
* ''': zb ( false, false )''' - манипуляции с z-буфером, где первый аргумент соответствует галке z-test в сдк, второй - галке z-write.<br />
<br />
* ''': fog ( false )''' - действие представляет собой превращение текстуры в черно-белую и применение к ней функции calc_fogging в common.h шейдеров соответствующего рендера.<br />
<br />
* ''': emissive ( true )''' - применяется в источниках освещения.<br />
<br />
* ''': distort ( true )''' - представляет из себя механизм искажений, аналогичный эффекту искажающегося воздуха в некоторых аномалиях, а также "линза" в главном меню над кнопками.<br />
<br />
----<br />
<br />
<br />
* '''shader : sampler( "s_base" )''' - создание буфера для помещения туда текстуры. Аргумент представляет собой идентификатор, получаемый ps и vs шейдерами, где будет фигурировать как predefined-переменная s_base.<br />
<br />
<br />
''Перечисленные ниже параметры могут быть только ниже сэмплерной строки!''<br />
<br />
<br />
* ''': texture ( t_base ) ''' - помещение в вышеобъявленный буфер текстуры. аргумент этой ф-ции представляет собой путь к текстуре, так что вполне можно указать нечто вроде<br />
<br />
: texture ( "fx\\fx_sun" )<br />
<br />
чтобы в буфер воткнуть текстуру '''gamedata/textures/fx/fx_sun.dds'''<br />
<br />
<br />
* ''': clamp()''' - соответствует галке Texture Clamp в сдк. Википедия [http://en.wikipedia.org/wiki/Clamping_%28graphics%29 отвечает] на этот вопрос весьма туманно. Но по псевдокоду становится понятно что это ограничение минимального и максимального значения цвета определенными границами, то есть если число цвета меньше или больше соответствующей границы то выходное значение будет равно значению соответствующей границе.<br />
<br />
* ''': project()''' - используется в шейдере отрисовки неточечного источника света, и предположительно используется для проектирвоания текстуры сэмплера на те объекты которые находятся в пределах сектора сферы.<br />
<br />
* ''': wrap ()''' - Википедия [http://en.wikipedia.org/wiki/Clamping_%28graphics%29 отвечает] на этот вопрос не менее туманно чем в примере выше, но так же по псевдокоду становится понятно что шкала приращения значений разворачивается в обратную сторону, и если на входе значение 255, то на выходе 0, если 200 - на выходе 55. и так далее - если на входе 0 то на выходе 255.<br />
<br />
Ниже представлены еще три оператора используемые с сэмплером, назначение которых неизвестно.<br />
<br />
<br />
* ''': f_linear ()'''<br />
<br />
* ''': f_anisotropic ()'''<br />
<br />
<br />
----<br />
<br />
<br />
Также в папке с шейдерами лежат еще файлы .s (именно такого имени - точка и эс), которые являются для всех *.s-файлов своеобразными заголовочными файлами, функции из файла .s доступны из файлов *.s . На данный момент там имеются функции printf, и закомментированные во втором рендере ф-ции l_point и l_spot, которые отвечают за создание точечного и неточечного источников света соответственно.<br />
<br />
<br />
'''Статья создана участником cjayho'''<br />
<br />
[[Категория:Скрипты]]</div>80.93.126.66http://stalkerin.gameru.net/wiki/index.php?title=%D0%A1%D0%BA%D1%80%D0%B8%D0%BF%D1%82%D0%BE%D0%B2%D1%8B%D0%B5_%D1%88%D0%B5%D0%B9%D0%B4%D0%B5%D1%80%D1%8BСкриптовые шейдеры2010-12-14T22:25:03Z<p>80.93.126.66: </p>
<hr />
<div>Редактируя любую модель, многие в свойствах поверхностей замечали графу shader, в которой указывается нечто вроде models/model или подобные.<br />
Как правило эти шейдеры упакованы в shaders.xr и shaders_xrlc.xr, которые представляют собой своеобразную базу данных шейдеров, собранных по определенным шаблонам.<br />
<br />
Но кроме этих баз данных есть еще и скриптовые шейдеры, которые имеют приоритет перед теми шейдерами что упакованы в *.xr. Это файлы, имеющие расширение .s и лежащие в папках соответствующих рендеров. Вычислить правильное название шейдера в БД и шейдерного скрипта .s можно очень просто - для примера если у нас в БД шейдер находится в model/selflight, то имя шейдера должно быть model_selflight.s, если details/blend, то скрипт шейдера будет соответственно details_blend.s . Не так уж сложно.<br />
<br />
Вообще база данных с шейдерами была выдумана не потому что авторам сталкера очень нравилось плодить экземпляры труднораспарсиваемых форматов, а причина более банальна - чтобы увеличить скорость загрузки игры сэкономив за счет активности жесткого диска, при открытии файлов скриптовых шейдеров в папке соответствующего рендера. Плюс к тому, в этом случае уменьшается количество шейдерных файлов что как минимум вдвое уменьшает вероятность ошибки - при условии двух рендеров, эта экономия получается за счет тех шейдеров, которые являются общими для обоих рендеров. Плюс к тому вероятность ошибки еще более уменьшается тем, что базы данных редактируются в сдк, а сдк эти базы данных представляет в виде всевозможных галочек и полей ввода, поэтому ошибка может быть только во вводимых данных, но не в скриптовом коде шейдеров, который вероятнее всего генерируется во время загрузки игры.<br />
<br />
Скриптовые шейдеры используются же в основном только в тех случаях когда их код отличается для разных рендеров.<br />
<br />
По некоторым причинам я считаю что для модостроителей шейдерные скрипты являются более предпочтительными, чем распространение своих шейдерных модов в виде модифицированной .xr-БД. Причины в основном две - во первых скриптовые шейдеры предоставляют бОльшие возможности для полета фантазии :), а во вторых распространение шейдерных модов в виде скриптовых шейдеров все же делает меньше вероятность конфликта модов, так как разные шейдеры будут в разных файлах, а не все вместе в одном хитром и трудноредактируемом, и что самое плохое - трудно-объединяемом файле. Поэтому далее мы рассмотрим скриптовые шейдеры.<br />
<br />
Что собой представляют шейдерные скрипты? Это обычные скрипты на lua, и которые являются своеобразным языком для того чтобы объяснить движку, какие загружать текстуры и какие подключать шейдеры из наличествующих .ps и .vs файлов. <br />
<br />
: ''Для тех кто воспрял духом сразу скажу что несмотря на то, что шейдерные скрипты написаны на языке, который используется в игровых скриптах, это все-таки не одно и то же. Во первых шейдерные скрипты выполняются при загрузке уровня всего один раз (в фазу загрузки "загрузка шейдеров"), поэтому на отрисовку в реальном времени влиять неспособны, и кроме того к игровым скриптам скриптовые шейдеры доступа не имеют.''<br />
<br />
Вот для примера содержимое простейшего скриптового шейдера:<br />
<br />
function normal( shader, t_base, t_second, t_detail )<br />
<br />
shader:begin( "effects_gradient", "effects_gradient_p" )<br />
<br />
end<br />
<br />
Разберем его по косточкам:<br />
<br />
* '''function normal''' - объявление стандартной функции шейдерного скрипта. В некоторых шейдерах есть еще функции '''l_spot''', '''l_point''' и '''l_special''' аналогичного содержания, но явно просчитывающие поведение этого шейдера в условиях освещения<br />
<br />
* '''shader''' - вероятнее всего идентификатор шейдера в игре, содержимое этой переменной представляет собой вероятнее всего текстовую строку вроде "models_selflight" или "models/selflight".<br />
* '''t_base''' - путь к текстуре которую следует выводить с помощью этого шейдера<br />
* '''t_second''', '''t_detail''' - пути к другим текстурам, пока назначение их неизвестно.<br />
<br />
* '''shader:begin( "effects_gradient", "effects_gradient_p" )''' - святая святых шейдера. Если точнее - создание объекта шейдера как такового. <br />
:: '''effects_gradient''' - имя .vs файла используемого в этом шейдере<br />
:: '''effects_gradient_p''' - имя .ps файла соответственно.<br />
<br />
<br />
После этой строки могут быть такие строки (они необязательны)<br />
<br />
<br />
* ''': blend ( true, blend.srcalpha, blend.one )''' - обработка текстур, например полупрозрачные текстуры без применения этой строки будут выглядеть непрозрачными черными в прозрачных местах. Эти методы блендинга соответствуют переключателю в сдк, где варианты ALPHA-ADD, BLEND, SET и так далее. На примере выше блендинг соответствует положению ALPHA-ADD.<br />
<br />
:: '''true''' - может быть '''false''' - включение обработки текстур, тоесть true - обработка включена, false соответственно выключена.<br />
<br />
:: '''blend.srcalpha''', '''blend.one''' - соответственно методы блендинга, могут быть blend.one, blend.zero, blend.srcalpha, blend.invsrcalpha и null<br />
<br />
<br />
* ''': sorting ( 3, false )''' - порядок отрисовки поверхности по отношению к самому объекту, частью которого является поверхность.<br />
<br />
:: '''3''' - цифра порядка отрисовки, где 1 - за объектом, 2 - на уровне с объектом, 3 - спереди объекта (ближе к актору). Как правило при тройке шейдируемая поверхность будет отрисовываться поверх всего, в том числе и оружия.<br />
<br />
:: '''false''' - соответствует галочке "srict sorting" в сдк. Пока назначение неизвестно.<br />
<br />
<br />
* ''': aref ( false, 2 )''' - альфа-референс объекта, оператор, переключающий многобитную альфу текстуры в однобитную.<br />
<br />
:: '''false''' - включение/выключение данной функции.<br />
<br />
:: '''2''' - сам альфа-референс объекта<br />
<br />
<br />
* ''': zb ( false, false )''' - манипуляции с z-буфером, где первый аргумент соответствует галке z-test в сдк, второй - галке z-write.<br />
<br />
* ''': fog ( false )''' - действие представляет собой превращение текстуры в черно-белую и применение к ней функции calc_fogging в common.h шейдеров соответствующего рендера.<br />
<br />
* ''': emissive ( true )''' - применяется в источниках освещения.<br />
<br />
* ''': distort ( true )''' - представляет из себя механизм искажений, аналогичный эффекту искажающегося воздуха в некоторых аномалиях, а также "линза" в главном меню над кнопками.<br />
<br />
----<br />
<br />
<br />
* '''shader : sampler( "s_base" )''' - создание буфера для помещения туда текстуры. Аргумент представляет собой идентификатор, получаемый ps и vs шейдерами, где будет фигурировать как predefined-переменная s_base.<br />
<br />
<br />
''Перечисленные ниже параметры могут быть только ниже сэмплерной строки!''<br />
<br />
<br />
* ''': texture ( t_base ) ''' - помещение в вышеобъявленный буфер текстуры. аргумент этой ф-ции представляет собой путь к текстуре, так что вполне можно указать нечто вроде<br />
<br />
: texture ( "fx\\fx_sun" )<br />
<br />
чтобы в буфер воткнуть текстуру '''gamedata/textures/fx/fx_sun.dds'''<br />
<br />
<br />
* ''': clamp()''' - соответствует галке Texture Clamp в сдк. Что это такое - точно сказать не могу, Википедия [http://en.wikipedia.org/wiki/Clamping_%28graphics%29 отвечает] на этот вопрос весьма туманно.<br />
<br />
* ''': project()''' - используется в шейдере отрисовки неточечного источника света, и предположительно используется для проектирвоания текстуры сэмплера на те объекты которые находятся в пределах сектора сферы.<br />
<br />
<br />
Ниже представлены еще три оператора используемые с сэмплером, назначение которых неизвестно.<br />
<br />
<br />
* ''': f_linear ()'''<br />
<br />
* ''': wrap ()'''<br />
<br />
* ''': f_anisotropic ()'''<br />
<br />
<br />
----<br />
<br />
<br />
Также в папке с шейдерами лежат еще файлы .s (именно такого имени - точка и эс), которые являются для всех *.s-файлов своеобразными заголовочными файлами, функции из файла .s доступны из файлов *.s . На данный момент там имеются функции printf, и закомментированные во втором рендере ф-ции l_point и l_spot, которые отвечают за создание точечного и неточечного источников света соответственно.<br />
<br />
<br />
'''Статья создана участником cjayho'''</div>80.93.126.66http://stalkerin.gameru.net/wiki/index.php?title=%D0%A1%D0%BA%D1%80%D0%B8%D0%BF%D1%82%D0%BE%D0%B2%D1%8B%D0%B5_%D1%88%D0%B5%D0%B9%D0%B4%D0%B5%D1%80%D1%8BСкриптовые шейдеры2010-12-14T22:15:42Z<p>80.93.126.66: </p>
<hr />
<div>Редактируя любую модель, многие в свойствах поверхностей замечали графу shader, в которой указывается нечто вроде models/model или подобные.<br />
Как правило эти шейдеры упакованы в shaders.xr и shaders_xrlc.xr, которые представляют собой своеобразную базу данных шейдеров, собранных по определенным шаблонам.<br />
<br />
Но кроме этих баз данных есть еще и скриптовые шейдеры, которые имеют приоритет перед теми шейдерами что упакованы в *.xr. Это файлы, имеющие расширение .s и лежащие в папках соответствующих рендеров. Вычислить правильное название шейдера в БД и шейдерного скрипта .s можно очень просто - для примера если у нас в БД шейдер находится в model/selflight, то имя шейдера должно быть model_selflight.s, если details/blend, то скрипт шейдера будет соответственно details_blend.s . Не так уж сложно.<br />
<br />
Вообще база данных с шейдерами была выдумана не потому что авторам сталкера очень нравилось плодить экземпляры труднораспарсиваемых форматов, а причина более банальна - чтобы увеличить скорость загрузки игры сэкономив за счет активности жесткого диска, при открытии файлов скриптовых шейдеров в папке соответствующего рендера. Плюс к тому, в этом случае уменьшается количество шейдерных файлов что как минимум вдвое уменьшает вероятность ошибки - при условии двух рендеров, эта экономия получается за счет тех шейдеров, которые являются общими для обоих рендеров. Плюс к тому вероятность ошибки еще более уменьшается тем, что базы данных редактируются в сдк, а сдк эти базы данных представляет в виде всевозможных галочек и полей ввода, поэтому ошибка может быть только во вводимых данных, но не в скриптовом коде шейдеров, который вероятнее всего генерируется во время загрузки игры.<br />
<br />
Скриптовые шейдеры используются же в основном только в тех случаях когда их код отличается для разных рендеров.<br />
<br />
По некоторым причинам я считаю что для модостроителей шейдерные скрипты являются более предпочтительными, чем распространение своих шейдерных модов в виде модифицированной .xr-БД. Причины в основном две - во первых скриптовые шейдеры предоставляют бОльшие возможности для полета фантазии :), а во вторых распространение шейдерных модов в виде скриптовых шейдеров все же делает меньше вероятность конфликта модов, так как разные шейдеры будут в разных файлах, а не все вместе в одном хитром и трудноредактируемом, и что самое плохое - трудно-объединяемом файле. Поэтому далее мы рассмотрим скриптовые шейдеры.<br />
<br />
Что собой представляют шейдерные скрипты? Это обычные скрипты на lua, и которые являются своеобразным языком для того чтобы объяснить движку, какие загружать текстуры и какие подключать шейдеры из наличествующих .ps и .vs файлов. <br />
<br />
: ''Для тех кто воспрял духом сразу скажу что несмотря на то, что шейдерные скрипты написаны на языке, который используется в игровых скриптах, это все-таки не одно и то же. Во первых шейдерные скрипты выполняются при загрузке уровня всего один раз (в фазу загрузки "загрузка шейдеров"), поэтому на отрисовку в реальном времени влиять неспособны, и кроме того к игровым скриптам скриптовые шейдеры доступа не имеют.''<br />
<br />
Вот для примера содержимое простейшего скриптового шейдера:<br />
<br />
function normal( shader, t_base, t_second, t_detail )<br />
<br />
shader:begin( "effects_gradient", "effects_gradient_p" )<br />
<br />
end<br />
<br />
Разберем его по косточкам:<br />
<br />
* '''function normal''' - объявление стандартной функции шейдерного скрипта. В некоторых шейдерах есть еще функция '''l_special''' аналогичного содержания, но явно просчитывающая поведение этого шейдера в условиях освещения (пока на данный момент неизвестно какого именно)<br />
<br />
* '''shader''' - вероятнее всего идентификатор шейдера в игре, содержимое этой переменной представляет собой вероятнее всего текстовую строку вроде "models_selflight" или "models/selflight".<br />
* '''t_base''' - путь к текстуре которую следует выводить с помощью этого шейдера<br />
* '''t_second''', '''t_detail''' - пути к другим текстурам, пока назначение их неизвестно.<br />
<br />
* '''shader:begin( "effects_gradient", "effects_gradient_p" )''' - святая святых шейдера. Если точнее - создание объекта шейдера как такового. <br />
:: '''effects_gradient''' - имя .vs файла используемого в этом шейдере<br />
:: '''effects_gradient_p''' - имя .ps файла соответственно.<br />
<br />
<br />
После этой строки могут быть такие строки (они необязательны)<br />
<br />
<br />
* ''': blend ( true, blend.srcalpha, blend.one )''' - обработка текстур, например полупрозрачные текстуры без применения этой строки будут выглядеть непрозрачными черными в прозрачных местах. Эти методы блендинга соответствуют переключателю в сдк, где варианты ALPHA-ADD, BLEND, SET и так далее. На примере выше блендинг соответствует положению ALPHA-ADD.<br />
<br />
:: '''true''' - может быть '''false''' - включение обработки текстур, тоесть true - обработка включена, false соответственно выключена.<br />
<br />
:: '''blend.srcalpha''', '''blend.one''' - соответственно методы блендинга, могут быть blend.one, blend.zero, blend.srcalpha, blend.invsrcalpha и null<br />
<br />
<br />
* ''': sorting ( 3, false )''' - порядок отрисовки поверхности по отношению к самому объекту, частью которого является поверхность.<br />
<br />
:: '''3''' - цифра порядка отрисовки, где 1 - за объектом, 2 - на уровне с объектом, 3 - спереди объекта (ближе к актору). Как правило при тройке шейдируемая поверхность будет отрисовываться поверх всего, в том числе и оружия.<br />
<br />
:: '''false''' - соответствует галочке "srict sorting" в сдк. Пока назначение неизвестно.<br />
<br />
<br />
* ''': aref ( false, 2 )''' - альфа-референс объекта, оператор, переключающий многобитную альфу текстуры в однобитную.<br />
<br />
:: '''false''' - включение/выключение данной функции.<br />
<br />
:: '''2''' - сам альфа-референс объекта<br />
<br />
<br />
* ''': zb ( false, false )''' - манипуляции с z-буфером, где первый аргумент соответствует галке z-test в сдк, второй - галке z-write.<br />
<br />
* ''': fog ( false )''' - действие представляет собой превращение текстуры в черно-белую и применение к ней функции calc_fogging в common.h шейдеров соответствующего рендера.<br />
<br />
* ''': emissive ( true )''' - применяется в источниках освещения.<br />
<br />
* ''': distort ( true )''' - представляет из себя механизм искажений, аналогичный эффекту искажающегося воздуха в некоторых аномалиях, а также "линза" в главном меню над кнопками.<br />
<br />
----<br />
<br />
<br />
* '''shader : sampler( "s_base" )''' - создание буфера для помещения туда текстуры. Аргумент представляет собой идентификатор, получаемый ps и vs шейдерами, где будет фигурировать как predefined-переменная s_base.<br />
<br />
<br />
''Перечисленные ниже параметры могут быть только ниже сэмплерной строки!''<br />
<br />
<br />
* ''': texture ( t_base ) ''' - помещение в вышеобъявленный буфер текстуры. аргумент этой ф-ции представляет собой путь к текстуре, так что вполне можно указать нечто вроде<br />
<br />
: texture ( "fx\\fx_sun" )<br />
<br />
чтобы в буфер воткнуть текстуру '''gamedata/textures/fx/fx_sun.dds'''<br />
<br />
<br />
* ''': clamp()''' - соответствует галке Texture Clamp в сдк. Что это такое - точно сказать не могу, Википедия [http://en.wikipedia.org/wiki/Clamping_%28graphics%29 отвечает] на этот вопрос весьма туманно.<br />
<br />
* ''': project()''' - используется в шейдере отрисовки неточечного источника света, и предположительно используется для проектирвоания текстуры сэмплера на те объекты которые находятся в пределах сектора сферы.<br />
<br />
<br />
Ниже представлены еще три оператора используемые с сэмплером, назначение которых неизвестно.<br />
<br />
<br />
* ''': f_linear ()'''<br />
<br />
* ''': wrap ()'''<br />
<br />
* ''': f_anisotropic ()'''<br />
<br />
<br />
----<br />
<br />
<br />
Также в папке с шейдерами лежат еще файлы .s (именно такого имени - точка и эс), которые являются для всех *.s-файлов своеобразными заголовочными файлами, функции из файла .s доступны из файлов *.s . На данный момент там имеются функции printf, и закомментированные во втором рендере ф-ции l_point и l_spot, которые отвечают за создание точечного и неточечного источников света соответственно.<br />
<br />
<br />
'''Статья создана участником cjayho'''</div>80.93.126.66http://stalkerin.gameru.net/wiki/index.php?title=%D0%A1%D0%BA%D1%80%D0%B8%D0%BF%D1%82%D0%BE%D0%B2%D1%8B%D0%B5_%D1%88%D0%B5%D0%B9%D0%B4%D0%B5%D1%80%D1%8BСкриптовые шейдеры2010-12-14T22:15:04Z<p>80.93.126.66: </p>
<hr />
<div>Редактируя любую модель, многие в свойствах поверхностей замечали графу shader, в которой указывается нечто вроде models/model или подобные.<br />
Как правило эти шейдеры упакованы в shaders.xr и shaders_xrlc.xr, которые представляют собой своеобразную базу данных шейдеров, собранных по определенным шаблонам.<br />
<br />
Но кроме этих баз данных есть еще и скриптовые шейдеры, которые имеют приоритет перед теми шейдерами что упакованы в *.xr. Это файлы, имеющие расширение .s и лежащие в папках соответствующих рендеров. Вычислить правильное название шейдера в БД и шейдерного скрипта .s можно очень просто - для примера если у нас в БД шейдер находится в model/selflight, то имя шейдера должно быть model_selflight.s, если details/blend, то скрипт шейдера будет соответственно details_blend.s . Не так уж сложно.<br />
<br />
Вообще база данных с шейдерами была выдумана не потому что авторам сталкера очень нравилось плодить экземпляры труднораспарсиваемых форматов, а причина более банальна - чтобы увеличить скорость загрузки игры сэкономив за счет активности жесткого диска, при открытии файлов скриптовых шейдеров в папке соответствующего рендера. Плюс к тому, в этом случае уменьшается количество шейдерных файлов что как минимум вдвое уменьшает вероятность ошибки - при условии двух рендеров, эта экономия получается за счет тех шейдеров, которые являются общими для обоих рендеров. Плюс к тому вероятность ошибки еще более уменьшается тем, что базы данных редактируются в сдк, а сдк эти базы данных представляет в виде всевозможных галочек и полей ввода, поэтому ошибка может быть только во вводимых данных, но не в скриптовом коде шейдеров, который вероятнее всего генерируется во время загрузки игры.<br />
<br />
Скриптовые шейдеры используются же в основном только в тех случаях когда их код отличается для разных рендеров.<br />
<br />
По некоторым причинам я считаю что для модостроителей шейдерные скрипты являются более предпочтительными, чем распространение своих шейдерных модов в виде модифицированной .xr-БД. Причины в основном две - во первых скриптовые шейдеры предоставляют бОльшие возможности для полета фантазии :), а во вторых распространение шейдерных модов в виде скриптовых шейдеров все же делает меньше вероятность конфликта модов, так как разные шейдеры будут в разных файлах, а не все вместе в одном хитром и трудноредактируемом, и что самое плохое - трудно-объединяемом файле. Поэтому далее мы рассмотрим скриптовые шейдеры.<br />
<br />
Что собой представляют шейдерные скрипты? Это обычные скрипты на lua, и которые являются своеобразным языком для того чтобы объяснить движку, какие загружать текстуры и какие подключать шейдеры из наличествующих .ps и .vs файлов. <br />
<br />
: ''Для тех кто воспрял духом сразу скажу что несмотря на то, что шейдерные скрипты написаны на языке, который используется в игровых скриптах, это все-таки не одно и то же. Во первых шейдерные скрипты выполняются при загрузке уровня всего один раз (в фазу загрузки "загрузка шейдеров"), поэтому на отрисовку в реальном времени влиять неспособны, и кроме того к игровым скриптам скриптовые шейдеры доступа не имеют.''<br />
<br />
Вот для примера содержимое простейшего скриптового шейдера:<br />
<br />
function normal( shader, t_base, t_second, t_detail )<br />
<br />
shader:begin( "effects_gradient", "effects_gradient_p" )<br />
<br />
end<br />
<br />
Разберем его по косточкам:<br />
<br />
* '''function normal''' - объявление стандартной функции шейдерного скрипта. В некоторых шейдерах есть еще функция '''l_special''' аналогичного содержания, но явно просчитывающая поведение этого шейдера в условиях освещения (пока на данный момент неизвестно какого именно)<br />
<br />
* '''shader''' - вероятнее всего идентификатор шейдера в игре, содержимое этой переменной представляет собой вероятнее всего текстовую строку вроде "models_selflight" или "models/selflight".<br />
* '''t_base''' - путь к текстуре которую следует выводить с помощью этого шейдера<br />
* '''t_second''', '''t_detail''' - пути к другим текстурам, пока назначение их неизвестно.<br />
<br />
* '''shader:begin( "effects_gradient", "effects_gradient_p" )''' - святая святых шейдера. Если точнее - создание объекта шейдера как такового. <br />
:: '''effects_gradient''' - имя .vs файла используемого в этом шейдере<br />
:: '''effects_gradient_p''' - имя .ps файла соответственно.<br />
<br />
<br />
После этой строки могут быть такие строки (они необязательны)<br />
<br />
<br />
* ''': blend ( true, blend.srcalpha, blend.one )''' - обработка текстур, например полупрозрачные текстуры без применения этой строки будут выглядеть непрозрачными черными в прозрачных местах. Эти методы блендинга соответствуют переключателю в сдк, где варианты ALPHA-ADD, BLEND, SET и так далее. На примере выше блендинг соответствует положению ALPHA-ADD.<br />
<br />
:: '''true''' - может быть '''false''' - включение обработки текстур, тоесть true - обработка включена, false соответственно выключена.<br />
<br />
:: '''blend.srcalpha''', '''blend.one''' - соответственно методы блендинга, могут быть blend.one, blend.zero, blend.srcalpha, blend.invsrcalpha и null<br />
<br />
<br />
* ''': sorting ( 3, false )''' - порядок отрисовки поверхности по отношению к самому объекту, частью которого является поверхность.<br />
<br />
:: '''3''' - цифра порядка отрисовки, где 1 - за объектом, 2 - на уровне с объектом, 3 - спереди объекта (ближе к актору). Как правило при тройке шейдируемая поверхность будет отрисовываться поверх всего, в том числе и оружия.<br />
<br />
:: '''false''' - соответствует галочке "srict sorting" в сдк. Пока назначение неизвестно.<br />
<br />
<br />
* ''': aref ( false, 2 )''' - альфа-референс объекта, оператор, переключающий многобитную альфу текстуры в однобитную.<br />
<br />
:: '''false''' - включение/выключение данной функции.<br />
<br />
:: '''2''' - сам альфа-референс объекта<br />
<br />
<br />
* ''': zb ( false, false )''' - манипуляции с z-буфером, где первый аргумент соответствует галке z-test в сдк, второй - галке z-write.<br />
<br />
* ''': fog ( false )''' - действие представляет собой превращение текстуры в черно-белую и применение к ней функции calc_fogging в common.h шейдеров соответствующего рендера.<br />
<br />
* ''': emissive ( true )''' - применяется в источниках освещения.<br />
<br />
* ''': distort ( true )''' - представляет из себя механизм искажений, аналогичный эффекту искажающегося воздуха в некоторых аномалиях, а также "линза" в главном меню над кнопками.<br />
<br />
----<br />
<br />
<br />
* '''shader : sampler( "s_base" )''' - создание буфера для помещения туда текстуры. Аргумент представляет собой идентификатор, получаемый ps и vs шейдерами, где будет фигурировать как predefined-переменная s_base.<br />
<br />
<br />
''Перечисленные ниже параметры могут быть только ниже сэмплерной строки!''<br />
<br />
<br />
* ''': texture ( t_base ) ''' - помещение в вышеобъявленный буфер текстуры. аргумент этой ф-ции представляет собой путь к текстуре, так что вполне можно указать нечто вроде<br />
<br />
: texture ( "fx\\fx_sun" )<br />
<br />
чтобы в буфер воткнуть текстуру '''gamedata/textures/fx/fx_sun.dds'''<br />
<br />
<br />
* ''': clamp()''' - соответствует галке Texture Clamp в сдк. Что это такое - точно сказать не могу, Википедия [http://en.wikipedia.org/wiki/Clamping_%28graphics%29 отвечает] на этот вопрос весьма туманно.<br />
<br />
* ''': project()''' - используется в шейдере отрисовки неточечного источника света, и предположительно используется для проектирвоания текстуры сэмплера на те объекты которые находятся в пределах сектора сферы.<br />
<br />
<br />
Ниже представлены еще три оператора используемые с сэмплером, назначение которых неизвестно.<br />
<br />
<br />
* ''': f_linear ()'''<br />
<br />
* ''': wrap ()'''<br />
<br />
* ''': f_anisotropic ()'''<br />
<br />
<br />
----<br />
<br />
<br />
Также в папке с шейдерами лежат еще файлы .s (именно такого имени - точка и эс), которые являются для всех *.s-файлов своеобразными заголовочными файлами, функции из файла .s доступны из файлов *.s . На данный момент там имеются функции printf, и закомментированные во втором рендере ф-ции l_point и l_spot, которые отвечают за создание точечного и неточечного источников света соответственно.</div>80.93.126.66http://stalkerin.gameru.net/wiki/index.php?title=%D0%A1%D0%BA%D1%80%D0%B8%D0%BF%D1%82%D0%BE%D0%B2%D1%8B%D0%B5_%D1%88%D0%B5%D0%B9%D0%B4%D0%B5%D1%80%D1%8BСкриптовые шейдеры2010-12-14T22:14:47Z<p>80.93.126.66: </p>
<hr />
<div>Редактируя любую модель, многие в свойствах поверхностей замечали графу shader, в которой указывается нечто вроде models/model или подобные.<br />
Как правило эти шейдеры упакованы в shaders.xr и shaders_xrlc.xr, которые представляют собой своеобразную базу данных шейдеров, собранных по определенным шаблонам.<br />
<br />
Но кроме этих баз данных есть еще и скриптовые шейдеры, которые имеют приоритет перед теми шейдерами что упакованы в *.xr. Это файлы, имеющие расширение .s и лежащие в папках соответствующих рендеров. Вычислить правильное название шейдера в БД и шейдерного скрипта .s можно очень просто - для примера если у нас в БД шейдер находится в model/selflight, то имя шейдера должно быть model_selflight.s, если details/blend, то скрипт шейдера будет соответственно details_blend.s . Не так уж сложно.<br />
<br />
Вообще база данных с шейдерами была выдумана не потому что авторам сталкера очень нравилось плодить экземпляры труднораспарсиваемых форматов, а причина более банальна - чтобы увеличить скорость загрузки игры сэкономив за счет активности жесткого диска, при открытии файлов скриптовых шейдеров в папке соответствующего рендера. Плюс к тому, в этом случае уменьшается количество шейдерных файлов что как минимум вдвое уменьшает вероятность ошибки - при условии двух рендеров, эта экономия получается за счет тех шейдеров, которые являются общими для обоих рендеров. Плюс к тому вероятность ошибки еще более уменьшается тем, что базы данных редактируются в сдк, а сдк эти базы данных представляет в виде всевозможных галочек и полей ввода, поэтому ошибка может быть только во вводимых данных, но не в скриптовом коде шейдеров, который вероятнее всего генерируется во время загрузки игры.<br />
<br />
Скриптовые шейдеры используются же в основном только в тех случаях когда их код отличается для разных рендеров.<br />
<br />
По некоторым причинам я считаю что для модостроителей шейдерные скрипты являются более предпочтительными, чем распространение своих шейдерных модов в виде модифицированной .xr-БД. Причины в основном две - во первых скриптовые шейдеры предоставляют бОльшие возможности для полета фантазии :), а во вторых распространение шейдерных модов в виде скриптовых шейдеров все же делает меньше вероятность конфликта модов, так как разные шейдеры будут в разных файлах, а не все вместе в одном хитром и трудноредактируемом, и что самое плохое - трудно-объединяемом файле. Поэтому далее мы рассмотрим скриптовые шейдеры.<br />
<br />
Что собой представляют шейдерные скрипты? Это обычные скрипты на lua, и которые являются своеобразным языком для того чтобы объяснить движку, какие загружать текстуры и какие подключать шейдеры из наличествующих .ps и .vs файлов. <br />
<br />
: ''Для тех кто воспрял духом сразу скажу что несмотря на то, что шейдерные скрипты написаны на языке, который используется в игровых скриптах, это все-таки не одно и то же. Во первых шейдерные скрипты выполняются при загрузке уровня всего один раз (в фазу загрузки "загрузка шейдеров"), поэтому на отрисовку в реальном времени влиять неспособны, и кроме того к игровым скриптам скриптовые шейдеры доступа не имеют.''<br />
<br />
Вот для примера содержимое простейшего скриптового шейдера:<br />
<br />
function normal( shader, t_base, t_second, t_detail )<br />
<br />
shader:begin( "effects_gradient", "effects_gradient_p" )<br />
<br />
end<br />
<br />
Разберем его по косточкам:<br />
<br />
* '''function normal''' - объявление стандартной функции шейдерного скрипта. В некоторых шейдерах есть еще функция '''l_special''' аналогичного содержания, но явно просчитывающая поведение этого шейдера в условиях освещения (пока на данный момент неизвестно какого именно)<br />
<br />
* '''shader''' - вероятнее всего идентификатор шейдера в игре, содержимое этой переменной представляет собой вероятнее всего текстовую строку вроде "models_selflight" или "models/selflight".<br />
* '''t_base''' - путь к текстуре которую следует выводить с помощью этого шейдера<br />
* '''t_second''', '''t_detail''' - пути к другим текстурам, пока назначение их неизвестно.<br />
<br />
* '''shader:begin( "effects_gradient", "effects_gradient_p" )''' - святая святых шейдера. Если точнее - создание объекта шейдера как такового. <br />
:: '''effects_gradient''' - имя .vs файла используемого в этом шейдере<br />
:: '''effects_gradient_p''' - имя .ps файла соответственно.<br />
<br />
<br />
После этой строки могут быть такие строки (они необязательны)<br />
<br />
<br />
* ''': blend ( true, blend.srcalpha, blend.one )''' - обработка текстур, например полупрозрачные текстуры без применения этой строки будут выглядеть непрозрачными черными в прозрачных местах. Эти методы блендинга соответствуют переключателю в сдк, где варианты ALPHA-ADD, BLEND, SET и так далее. На примере выше блендинг соответствует положению ALPHA-ADD.<br />
<br />
:: '''true''' - может быть '''false''' - включение обработки текстур, тоесть true - обработка включена, false соответственно выключена.<br />
<br />
:: '''blend.srcalpha''', '''blend.one''' - соответственно методы блендинга, могут быть blend.one, blend.zero, blend.srcalpha, blend.invsrcalpha и null<br />
<br />
<br />
* ''': sorting ( 3, false )''' - порядок отрисовки поверхности по отношению к самому объекту, частью которого является поверхность.<br />
<br />
:: '''3''' - цифра порядка отрисовки, где 1 - за объектом, 2 - на уровне с объектом, 3 - спереди объекта (ближе к актору). Как правило при тройке шейдируемая поверхность будет отрисовываться поверх всего, в том числе и оружия.<br />
<br />
:: '''false''' - соответствует галочке "srict sorting" в сдк. Пока назначение неизвестно.<br />
<br />
<br />
* ''': aref ( false, 2 )''' - альфа-референс объекта, оператор, переключающий многобитную альфу текстуры в однобитную.<br />
<br />
:: '''false''' - включение/выключение данной функции.<br />
<br />
:: '''2''' - сам альфа-референс объекта<br />
<br />
<br />
* ''': zb ( false, false )''' - манипуляции с z-буфером, где первый аргумент соответствует галке z-test в сдк, второй - галке z-write.<br />
<br />
* ''': fog ( false )''' - действие представляет собой превращение текстуры в черно-белую и применение к ней функции calc_fogging в common.h шейдеров соответствующего рендера.<br />
<br />
* ''': emissive ( true )''' - применяется в источниках освещения.<br />
<br />
* ''': distort (true)''' - представляет из себя механизм искажений, аналогичный эффекту искажающегося воздуха в некоторых аномалиях, а также "линза" в главном меню над кнопками.<br />
<br />
----<br />
<br />
<br />
* '''shader : sampler( "s_base" )''' - создание буфера для помещения туда текстуры. Аргумент представляет собой идентификатор, получаемый ps и vs шейдерами, где будет фигурировать как predefined-переменная s_base.<br />
<br />
<br />
''Перечисленные ниже параметры могут быть только ниже сэмплерной строки!''<br />
<br />
<br />
* ''': texture ( t_base ) ''' - помещение в вышеобъявленный буфер текстуры. аргумент этой ф-ции представляет собой путь к текстуре, так что вполне можно указать нечто вроде<br />
<br />
: texture ( "fx\\fx_sun" )<br />
<br />
чтобы в буфер воткнуть текстуру '''gamedata/textures/fx/fx_sun.dds'''<br />
<br />
<br />
* ''': clamp()''' - соответствует галке Texture Clamp в сдк. Что это такое - точно сказать не могу, Википедия [http://en.wikipedia.org/wiki/Clamping_%28graphics%29 отвечает] на этот вопрос весьма туманно.<br />
<br />
* ''': project()''' - используется в шейдере отрисовки неточечного источника света, и предположительно используется для проектирвоания текстуры сэмплера на те объекты которые находятся в пределах сектора сферы.<br />
<br />
<br />
Ниже представлены еще три оператора используемые с сэмплером, назначение которых неизвестно.<br />
<br />
<br />
* ''': f_linear ()'''<br />
<br />
* ''': wrap ()'''<br />
<br />
* ''': f_anisotropic ()'''<br />
<br />
<br />
----<br />
<br />
<br />
Также в папке с шейдерами лежат еще файлы .s (именно такого имени - точка и эс), которые являются для всех *.s-файлов своеобразными заголовочными файлами, функции из файла .s доступны из файлов *.s . На данный момент там имеются функции printf, и закомментированные во втором рендере ф-ции l_point и l_spot, которые отвечают за создание точечного и неточечного источников света соответственно.</div>80.93.126.66http://stalkerin.gameru.net/wiki/index.php?title=%D0%A1%D0%BA%D1%80%D0%B8%D0%BF%D1%82%D0%BE%D0%B2%D1%8B%D0%B5_%D1%88%D0%B5%D0%B9%D0%B4%D0%B5%D1%80%D1%8BСкриптовые шейдеры2010-12-14T22:10:36Z<p>80.93.126.66: </p>
<hr />
<div>Редактируя любую модель, многие в свойствах поверхностей замечали графу shader, в которой указывается нечто вроде models/model или подобные.<br />
Как правило эти шейдеры упакованы в shaders.xr и shaders_xrlc.xr, которые представляют собой своеобразную базу данных шейдеров, собранных по определенным шаблонам.<br />
<br />
Но кроме этих баз данных есть еще и скриптовые шейдеры, которые имеют приоритет перед теми шейдерами что упакованы в *.xr. Это файлы, имеющие расширение .s и лежащие в папках соответствующих рендеров. Вычислить правильное название шейдера в БД и шейдерного скрипта .s можно очень просто - для примера если у нас в БД шейдер находится в model/selflight, то имя шейдера должно быть model_selflight.s, если details/blend, то скрипт шейдера будет соответственно details_blend.s . Не так уж сложно.<br />
<br />
Вообще база данных с шейдерами была выдумана не потому что авторам сталкера очень нравилось плодить экземпляры труднораспарсиваемых форматов, а причина более банальна - чтобы увеличить скорость загрузки игры сэкономив за счет активности жесткого диска, при открытии файлов скриптовых шейдеров в папке соответствующего рендера. Плюс к тому, в этом случае уменьшается количество шейдерных файлов что как минимум вдвое уменьшает вероятность ошибки - при условии двух рендеров, эта экономия получается за счет тех шейдеров, которые являются общими для обоих рендеров. Плюс к тому вероятность ошибки еще более уменьшается тем, что базы данных редактируются в сдк, а сдк эти базы данных представляет в виде всевозможных галочек и полей ввода, поэтому ошибка может быть только во вводимых данных, но не в скриптовом коде шейдеров, который вероятнее всего генерируется во время загрузки игры.<br />
<br />
Скриптовые шейдеры используются же в основном только в тех случаях когда их код отличается для разных рендеров.<br />
<br />
По некоторым причинам я считаю что для модостроителей шейдерные скрипты являются более предпочтительными, чем распространение своих шейдерных модов в виде модифицированной .xr-БД. Причины в основном две - во первых скриптовые шейдеры предоставляют бОльшие возможности для полета фантазии :), а во вторых распространение шейдерных модов в виде скриптовых шейдеров все же делает меньше вероятность конфликта модов, так как разные шейдеры будут в разных файлах, а не все вместе в одном хитром и трудноредактируемом, и что самое плохое - трудно-объединяемом файле. Поэтому далее мы рассмотрим скриптовые шейдеры.<br />
<br />
Что собой представляют шейдерные скрипты? Это обычные скрипты на lua, и которые являются своеобразным языком для того чтобы объяснить движку, какие загружать текстуры и какие подключать шейдеры из наличествующих .ps и .vs файлов. <br />
<br />
: ''Для тех кто воспрял духом сразу скажу что несмотря на то, что шейдерные скрипты написаны на языке, который используется в игровых скриптах, это все-таки не одно и то же. Во первых шейдерные скрипты выполняются при загрузке уровня всего один раз (в фазу загрузки "загрузка шейдеров"), поэтому на отрисовку в реальном времени влиять неспособны, и кроме того к игровым скриптам скриптовые шейдеры доступа не имеют.''<br />
<br />
Вот для примера содержимое простейшего скриптового шейдера:<br />
<br />
function normal( shader, t_base, t_second, t_detail )<br />
<br />
shader:begin( "effects_gradient", "effects_gradient_p" )<br />
<br />
end<br />
<br />
Разберем его по косточкам:<br />
<br />
* '''function normal''' - объявление стандартной функции шейдерного скрипта. В некоторых шейдерах есть еще функция '''l_special''' аналогичного содержания, но явно просчитывающая поведение этого шейдера в условиях освещения (пока на данный момент неизвестно какого именно)<br />
<br />
* '''shader''' - вероятнее всего идентификатор шейдера в игре, содержимое этой переменной представляет собой вероятнее всего текстовую строку вроде "models_selflight" или "models/selflight".<br />
* '''t_base''' - путь к текстуре которую следует выводить с помощью этого шейдера<br />
* '''t_second''', '''t_detail''' - пути к другим текстурам, пока назначение их неизвестно.<br />
<br />
* '''shader:begin( "effects_gradient", "effects_gradient_p" )''' - святая святых шейдера. Если точнее - создание объекта шейдера как такового. <br />
:: '''effects_gradient''' - имя .vs файла используемого в этом шейдере<br />
:: '''effects_gradient_p''' - имя .ps файла соответственно.<br />
<br />
<br />
После этой строки могут быть такие строки (они необязательны)<br />
<br />
<br />
* ''': blend ( true, blend.srcalpha, blend.one )''' - обработка текстур, например полупрозрачные текстуры без применения этой строки будут выглядеть непрозрачными черными в прозрачных местах. Эти методы блендинга соответствуют переключателю в сдк, где варианты ALPHA-ADD, BLEND, SET и так далее. На примере выше блендинг соответствует положению ALPHA-ADD.<br />
<br />
:: '''true''' - может быть '''false''' - включение обработки текстур, тоесть true - обработка включена, false соответственно выключена.<br />
<br />
:: '''blend.srcalpha''', '''blend.one''' - соответственно методы блендинга, могут быть blend.one, blend.zero, blend.srcalpha, blend.invsrcalpha и null<br />
<br />
<br />
* ''': sorting ( 3, false )''' - порядок отрисовки поверхности по отношению к самому объекту, частью которого является поверхность.<br />
<br />
:: '''3''' - цифра порядка отрисовки, где 1 - за объектом, 2 - на уровне с объектом, 3 - спереди объекта (ближе к актору). Как правило при тройке шейдируемая поверхность будет отрисовываться поверх всего, в том числе и оружия.<br />
<br />
:: '''false''' - соответствует галочке "srict sorting" в сдк. Пока назначение неизвестно.<br />
<br />
<br />
* ''': aref ( false, 2 )''' - альфа-референс объекта, оператор, переключающий многобитную альфу текстуры в однобитную.<br />
<br />
:: '''false''' - включение/выключение данной функции.<br />
<br />
:: '''2''' - сам альфа-референс объекта<br />
<br />
<br />
* ''': zb ( false, false )''' - манипуляции с z-буфером, где первый аргумент соответствует галке z-test в сдк, второй - галке z-write.<br />
<br />
* ''': fog ( false )''' - действие представляет собой превращение текстуры в черно-белую и применение к ней функции calc_fogging в common.h шейдеров соответствующего рендера.<br />
<br />
* ''': emissive ( true )''' - применяется в источниках освещения.<br />
<br />
<br />
----<br />
<br />
<br />
* '''shader : sampler( "s_base" )''' - создание буфера для помещения туда текстуры. Аргумент представляет собой идентификатор, получаемый ps и vs шейдерами, где будет фигурировать как predefined-переменная s_base.<br />
<br />
<br />
''Перечисленные ниже параметры могут быть только ниже сэмплерной строки!''<br />
<br />
<br />
* ''': texture ( t_base ) ''' - помещение в вышеобъявленный буфер текстуры. аргумент этой ф-ции представляет собой путь к текстуре, так что вполне можно указать нечто вроде<br />
<br />
: texture ( "fx\\fx_sun" )<br />
<br />
чтобы в буфер воткнуть текстуру '''gamedata/textures/fx/fx_sun.dds'''<br />
<br />
<br />
* ''': clamp()''' - соответствует галке Texture Clamp в сдк. Что это такое - точно сказать не могу, Википедия [http://en.wikipedia.org/wiki/Clamping_%28graphics%29 отвечает] на этот вопрос весьма туманно.<br />
<br />
* ''': project()''' - используется в шейдере отрисовки неточечного источника света, и предположительно используется для проектирвоания текстуры сэмплера на те объекты которые находятся в пределах сектора сферы.<br />
<br />
<br />
Ниже представлены еще три оператора используемые с сэмплером, назначение которых неизвестно.<br />
<br />
<br />
* ''': f_linear ()'''<br />
<br />
* ''': wrap ()'''<br />
<br />
* ''': f_anisotropic ()'''<br />
<br />
<br />
----<br />
<br />
<br />
Также в папке с шейдерами лежат еще файлы .s (именно такого имени - точка и эс), которые являются для всех *.s-файлов своеобразными заголовочными файлами, функции из файла .s доступны из файлов *.s . На данный момент там имеются функции printf, и закомментированные во втором рендере ф-ции l_point и l_spot, которые отвечают за создание точечного и неточечного источников света соответственно.</div>80.93.126.66http://stalkerin.gameru.net/wiki/index.php?title=%D0%A1%D0%BA%D1%80%D0%B8%D0%BF%D1%82%D0%BE%D0%B2%D1%8B%D0%B5_%D1%88%D0%B5%D0%B9%D0%B4%D0%B5%D1%80%D1%8BСкриптовые шейдеры2010-12-14T22:09:48Z<p>80.93.126.66: </p>
<hr />
<div>Редактируя любую модель, многие в свойствах поверхностей замечали графу shader, в которой указывается нечто вроде models/model или подобные.<br />
Как правило эти шейдеры упакованы в shaders.xr и shaders_xrlc.xr, которые представляют собой своеобразную базу данных шейдеров, собранных по определенным шаблонам.<br />
<br />
Но кроме этих баз данных есть еще и скриптовые шейдеры, которые имеют приоритет перед теми шейдерами что упакованы в *.xr. Это файлы, имеющие расширение .s и лежащие в папках соответствующих рендеров. Вычислить правильное название шейдера в БД и шейдерного скрипта .s можно очень просто - для примера если у нас в БД шейдер находится в model/selflight, то имя шейдера должно быть model_selflight.s, если details/blend, то скрипт шейдера будет соответственно details_blend.s . Не так уж сложно.<br />
<br />
Вообще база данных с шейдерами была выдумана не потому что авторам сталкера очень нравилось плодить экземпляры труднораспарсиваемых форматов, а причина более банальна - чтобы увеличить скорость загрузки игры сэкономив за счет активности жесткого диска, при открытии файлов скриптовых шейдеров в папке соответствующего рендера. Плюс к тому, в этом случае уменьшается количество шейдерных файлов что как минимум вдвое уменьшает вероятность ошибки - при условии двух рендеров, эта экономия получается за счет тех шейдеров, которые являются общими для обоих рендеров. Плюс к тому вероятность ошибки еще более уменьшается тем, что базы данных редактируются в сдк, а сдк эти базы данных представляет в виде всевозможных галочек и полей ввода, поэтому ошибка может быть только во вводимых данных, но не в скриптовом коде шейдеров, который вероятнее всего генерируется во время загрузки игры.<br />
<br />
Скриптовые шейдеры используются же в основном только в тех случаях когда их код отличается для разных рендеров.<br />
<br />
По некоторым причинам я считаю что для модостроителей шейдерные скрипты являются более предпочтительными, чем распространение своих шейдерных модов в виде модифицированной .xr-БД. Причины в основном две - во первых скриптовые шейдеры предоставляют бОльшие возможности для полета фантазии :), а во вторых распространение шейдерных модов в виде скриптовых шейдеров все же делает меньше вероятность конфликта модов, так как разные шейдеры будут в разных файлах, а не все вместе в одном хитром и трудноредактируемом, и что самое плохое - трудно-объединяемом файле. Поэтому далее мы рассмотрим скриптовые шейдеры.<br />
<br />
Что собой представляют шейдерные скрипты? Это обычные скрипты на lua, и которые являются своеобразным языком для того чтобы объяснить движку, какие загружать текстуры и какие подключать шейдеры из наличествующих .ps и .vs файлов. <br />
<br />
: ''Для тех кто воспрял духом сразу скажу что несмотря на то, что шейдерные скрипты написаны на языке, который используется в игровых скриптах, это все-таки не одно и то же. Во первых шейдерные скрипты выполняются при загрузке уровня всего один раз (в фазу загрузки "загрузка шейдеров"), поэтому на отрисовку в реальном времени влиять неспособны, и кроме того к игровым скриптам скриптовые шейдеры доступа не имеют.''<br />
<br />
Вот для примера содержимое простейшего скриптового шейдера:<br />
<br />
function normal( shader, t_base, t_second, t_detail )<br />
<br />
shader:begin( "effects_gradient", "effects_gradient_p" )<br />
<br />
end<br />
<br />
Разберем его по косточкам:<br />
<br />
* '''function normal''' - объявление стандартной функции шейдерного скрипта. В некоторых шейдерах есть еще функция '''l_special''' аналогичного содержания, но явно просчитывающая поведение этого шейдера в условиях освещения (пока на данный момент неизвестно какого именно)<br />
<br />
* '''shader''' - вероятнее всего идентификатор шейдера в игре, содержимое этой переменной представляет собой вероятнее всего текстовую строку вроде "models_selflight" или "models/selflight".<br />
* '''t_base''' - путь к текстуре которую следует выводить с помощью этого шейдера<br />
* '''t_second''', '''t_detail''' - пути к другим текстурам, пока назначение их неизвестно.<br />
<br />
* '''shader:begin( "effects_gradient", "effects_gradient_p" )''' - святая святых шейдера. Если точнее - создание объекта шейдера как такового. <br />
:: '''effects_gradient''' - имя .vs файла используемого в этом шейдере<br />
:: '''effects_gradient_p''' - имя .ps файла соответственно.<br />
<br />
<br />
После этой строки могут быть такие строки (они необязательны)<br />
<br />
<br />
* ''': blend ( true, blend.srcalpha, blend.one )''' - обработка текстур, например полупрозрачные текстуры без применения этой строки будут выглядеть непрозрачными черными в прозрачных местах. Эти методы блендинга соответствуют переключателю в сдк, где варианты ALPHA-ADD, BLEND, SET и так далее. На примере выше блендинг соответствует положению ALPHA-ADD.<br />
<br />
:: '''true''' - может быть '''false''' - включение обработки текстур, тоесть true - обработка включена, false соответственно выключена.<br />
<br />
:: '''blend.srcalpha''', '''blend.one''' - соответственно методы блендинга, могут быть blend.one, blend.zero, blend.srcalpha, blend.invsrcalpha и null<br />
<br />
<br />
* ''': sorting ( 3, false )''' - порядок отрисовки поверхности по отношению к самому объекту, частью которого является поверхность.<br />
<br />
:: '''3''' - цифра порядка отрисовки, где 1 - за объектом, 2 - на уровне с объектом, 3 - спереди объекта (ближе к актору). Как правило при тройке шейдируемая поверхность будет отрисовываться поверх всего, в том числе и оружия.<br />
<br />
:: '''false''' - соответствует галочке "srict sorting" в сдк. Пока назначение неизвестно.<br />
<br />
<br />
* ''': aref ( false, 2 )''' - альфа-референс объекта, оператор, переключающий многобитную альфу текстуры в однобитную.<br />
<br />
:: '''false''' - включение/выключение данной функции.<br />
<br />
:: '''2''' - сам альфа-референс объекта<br />
<br />
<br />
* ''': zb ( false, false )''' - манипуляции с z-буфером, где первый аргумент соответствует галке z-test в сдк, второй - галке z-write.<br />
<br />
* ''': fog ( false )''' - действие представляет собой превращение текстуры в черно-белую и применение к ней функции calc_fogging в common.h шейдеров соответствующего рендера.<br />
<br />
* ''': emissive ( true )''' - применяется в источниках освещения.<br />
<br />
<br />
----<br />
<br />
<br />
* '''shader : sampler( "s_base" )''' - создание буфера для помещения туда текстуры. Аргумент представляет собой идентификатор, получаемый функцией main в шейдерах, где будет фигурировать как predefined-переменная s_base.<br />
<br />
<br />
''Перечисленные ниже параметры могут быть только ниже сэмплерной строки!''<br />
<br />
<br />
* ''': texture ( t_base ) ''' - помещение в вышеобъявленный буфер текстуры. аргумент этой ф-ции представляет собой путь к текстуре, так что вполне можно указать нечто вроде<br />
<br />
: texture ( "fx\\fx_sun" )<br />
<br />
чтобы в буфер воткнуть текстуру '''gamedata/textures/fx/fx_sun.dds'''<br />
<br />
<br />
* ''': clamp()''' - соответствует галке Texture Clamp в сдк. Что это такое - точно сказать не могу, Википедия [http://en.wikipedia.org/wiki/Clamping_%28graphics%29 отвечает] на этот вопрос весьма туманно.<br />
<br />
* ''': project()''' - используется в шейдере отрисовки неточечного источника света, и предположительно используется для проектирвоания текстуры сэмплера на те объекты которые находятся в пределах сектора сферы.<br />
<br />
<br />
Ниже представлены еще три оператора используемые с сэмплером, назначение которых неизвестно.<br />
<br />
<br />
* ''': f_linear ()'''<br />
<br />
* ''': wrap ()'''<br />
<br />
* ''': f_anisotropic ()'''<br />
<br />
<br />
----<br />
<br />
<br />
Также в папке с шейдерами лежат еще файлы .s (именно такого имени - точка и эс), которые являются для всех *.s-файлов своеобразными заголовочными файлами, функции из файла .s доступны из файлов *.s . На данный момент там имеются функции printf, и закомментированные во втором рендере ф-ции l_point и l_spot, которые отвечают за создание точечного и неточечного источников света соответственно.</div>80.93.126.66http://stalkerin.gameru.net/wiki/index.php?title=%D0%A1%D0%BA%D1%80%D0%B8%D0%BF%D1%82%D0%BE%D0%B2%D1%8B%D0%B5_%D1%88%D0%B5%D0%B9%D0%B4%D0%B5%D1%80%D1%8BСкриптовые шейдеры2010-12-14T22:06:38Z<p>80.93.126.66: </p>
<hr />
<div>Редактируя любую модель, многие в свойствах поверхностей замечали графу shader, в которой указывается нечто вроде models/model или подобные.<br />
Как правило эти шейдеры упакованы в shaders.xr и shaders_xrlc.xr, которые представляют собой своеобразную базу данных шейдеров, собранных по определенным шаблонам.<br />
<br />
Но кроме этих баз данных есть еще и скриптовые шейдеры, которые имеют приоритет перед теми шейдерами что упакованы в *.xr. Это файлы, имеющие расширение .s и лежащие в папках соответствующих рендеров. Вычислить правильное название шейдера в БД и шейдерного скрипта .s можно очень просто - для примера если у нас в БД шейдер находится в model/selflight, то имя шейдера должно быть model_selflight.s, если details/blend, то скрипт шейдера будет соответственно details_blend.s . Не так уж сложно.<br />
<br />
Вообще база данных с шейдерами была выдумана не потому что авторам сталкера очень нравилось плодить экземпляры труднораспарсиваемых форматов, а причина более банальна - чтобы увеличить скорость загрузки игры сэкономив за счет активности жесткого диска, при открытии файлов скриптовых шейдеров в папке соответствующего рендера. Плюс к тому, в этом случае уменьшается количество шейдерных файлов что как минимум вдвое уменьшает вероятность ошибки - при условии двух рендеров, эта экономия получается за счет тех шейдеров, которые являются общими для обоих рендеров. Плюс к тому вероятность ошибки еще более уменьшается тем, что базы данных редактируются в сдк, а сдк эти базы данных представляет в виде всевозможных галочек и полей ввода, поэтому ошибка может быть только во вводимых данных, но не в скриптовом коде шейдеров, который вероятнее всего генерируется во время загрузки игры.<br />
<br />
Скриптовые шейдеры используются же в основном только в тех случаях когда их код отличается для разных рендеров.<br />
<br />
По некоторым причинам я считаю что для модостроителей шейдерные скрипты являются более предпочтительными, чем распространение своих шейдерных модов в виде модифицированной .xr-БД. Причины в основном две - во первых скриптовые шейдеры предоставляют бОльшие возможности для полета фантазии :), а во вторых распространение шейдерных модов в виде скриптовых шейдеров все же делает меньше вероятность конфликта модов, так как разные шейдеры будут в разных файлах, а не все вместе в одном хитром и трудноредактируемом, и что самое плохое - трудно-объединяемом файле. Поэтому далее мы рассмотрим скриптовые шейдеры.<br />
<br />
Что собой представляют шейдерные скрипты? Это обычные скрипты на lua, и которые являются своеобразным языком для того чтобы объяснить движку, какие загружать текстуры и какие подключать шейдеры из наличествующих .ps и .vs файлов. <br />
<br />
: ''Для тех кто воспрял духом сразу скажу что несмотря на то, что шейдерные скрипты написаны на языке, который используется в игровых скриптах, это все-таки не одно и то же. Во первых шейдерные скрипты выполняются при загрузке уровня всего один раз (в фазу загрузки "загрузка шейдеров"), поэтому на отрисовку в реальном времени влиять неспособны, и кроме того к игровым скриптам скриптовые шейдеры доступа не имеют.''<br />
<br />
Вот для примера содержимое простейшего скриптового шейдера:<br />
<br />
function normal( shader, t_base, t_second, t_detail )<br />
<br />
shader:begin( "effects_gradient", "effects_gradient_p" )<br />
<br />
end<br />
<br />
Разберем его по косточкам:<br />
<br />
* '''function normal''' - объявление стандартной функции шейдерного скрипта. В некоторых шейдерах есть еще функция '''l_special''' аналогичного содержания, но явно просчитывающая поведение этого шейдера в условиях освещения (пока на данный момент неизвестно какого именно)<br />
<br />
* '''shader''' - вероятнее всего идентификатор шейдера в игре, содержимое этой переменной представляет собой вероятнее всего текстовую строку вроде "models_selflight" или "models/selflight".<br />
* '''t_base''' - путь к текстуре которую следует выводить с помощью этого шейдера<br />
* '''t_second''', '''t_detail''' - пути к другим текстурам, пока назначение их неизвестно.<br />
<br />
* '''shader:begin( "effects_gradient", "effects_gradient_p" )''' - святая святых шейдера. Если точнее - создание объекта шейдера как такового. <br />
:: '''effects_gradient''' - имя .vs файла используемого в этом шейдере<br />
:: '''effects_gradient_p''' - имя .ps файла соответственно.<br />
<br />
<br />
После этой строки могут быть такие строки (они необязательны)<br />
<br />
<br />
* ''': blend ( true, blend.srcalpha, blend.one )''' - обработка текстур, например полупрозрачные текстуры без применения этой строки будут выглядеть непрозрачными черными в прозрачных местах. Эти методы блендинга соответствуют переключателю в сдк, где варианты ALPHA-ADD, BLEND, SET и так далее. На примере выше блендинг соответствует положению ALPHA-ADD.<br />
<br />
:: '''true''' - может быть '''false''' - включение обработки текстур, тоесть true - обработка включена, false соответственно выключена.<br />
<br />
:: '''blend.srcalpha''', '''blend.one''' - соответственно методы блендинга, могут быть blend.one, blend.zero, blend.srcalpha, blend.invsrcalpha и null<br />
<br />
<br />
* ''': sorting ( 3, false )''' - порядок отрисовки поверхности по отношению к самому объекту, частью которого является поверхность.<br />
<br />
:: '''3''' - цифра порядка отрисовки, где 1 - за объектом, 2 - на уровне с объектом, 3 - спереди объекта (ближе к актору). Как правило при тройке шейдируемая поверхность будет отрисовываться поверх всего, в том числе и оружия).<br />
<br />
:: '''false''' - соответствует галочке "srict sorting" в сдк. Пока назначение неизвестно.<br />
<br />
<br />
* ''': aref ( false, 2 )''' - альфа-референс объекта, оператор, переключающий многобитную альфу текстуры в однобитную.<br />
<br />
:: '''false''' - включение/выключение данной функции.<br />
<br />
:: '''2''' - сам альфа-референс объекта<br />
<br />
<br />
* ''': zb ( false, false )''' - манипуляции с z-буфером, где первый аргумент соответствует галке z-test в сдк, второй - галке z-write.<br />
<br />
* ''': fog ( false )''' - действие представляет собой превращение текстуры в черно-белую и применение к ней функции calc_fogging в common.h шейдеров соответствующего рендера.<br />
<br />
* ''': emissive ( true )''' - применяется в источниках освещения.<br />
<br />
<br />
----<br />
<br />
<br />
* '''shader : sampler( "s_base" )''' - создание буфера для помещения туда текстуры. Аргумент представляет собой идентификатор, получаемый функцией main в шейдерах, где будет фигурировать как predefined-переменная s_base.<br />
<br />
<br />
''Перечисленные ниже параметры могут быть только ниже сэмплерной строки!''<br />
<br />
<br />
* ''': texture ( t_base ) ''' - помещение в вышеобъявленный буфер текстуры. аргумент этой ф-ции представляет собой путь к текстуре, так что вполне можно указать нечто вроде<br />
<br />
: texture ( "fx\\fx_sun" )<br />
<br />
чтобы в буфер воткнуть текстуру '''gamedata/textures/fx/fx_sun.dds'''<br />
<br />
<br />
* ''': clamp()''' - соответствует галке Texture Clamp в сдк. Что это такое - точно сказать не могу, Википедия [http://en.wikipedia.org/wiki/Clamping_%28graphics%29 отвечает] на этот вопрос весьма туманно.<br />
<br />
* ''': project()''' - используется в шейдере отрисовки неточечного источника света, и предположительно используется для проектирвоания текстуры сэмплера на те объекты которые находятся в пределах сектора сферы.<br />
<br />
<br />
Ниже представлены еще три оператора используемые с сэмплером, назначение которых неизвестно.<br />
<br />
<br />
* ''': f_linear ()'''<br />
<br />
* ''': wrap ()'''<br />
<br />
* ''': f_anisotropic ()'''<br />
<br />
<br />
----<br />
<br />
<br />
Также в папке с шейдерами лежат еще файлы .s (именно такого имени - точка и эс), которые являются для всех *.s-файлов своеобразными заголовочными файлами, функции из файла .s доступны из файлов *.s . На данный момент там имеются функции printf, и закомментированные во втором рендере ф-ции l_point и l_spot, которые отвечают за создание точечного и неточечного источников света соответственно.</div>80.93.126.66http://stalkerin.gameru.net/wiki/index.php?title=%D0%A1%D0%BA%D1%80%D0%B8%D0%BF%D1%82%D0%BE%D0%B2%D1%8B%D0%B5_%D1%88%D0%B5%D0%B9%D0%B4%D0%B5%D1%80%D1%8BСкриптовые шейдеры2010-12-14T20:42:59Z<p>80.93.126.66: </p>
<hr />
<div>Редактируя любую модель, многие в свойствах поверхностей замечали графу shader, в которой указывается нечто вроде models/model или подобные.<br />
Как правило эти шейдеры упакованы в shaders.xr и shaders_xrlc.xr, которые представляют собой своеобразную базу данных шейдеров, собранных по определенным шаблонам.<br />
<br />
Но кроме этих баз данных есть еще и скриптовые шейдеры, которые имеют приоритет перед теми шейдерами что упакованы в *.xr. Это файлы, имеющие расширение .s и лежащие в папках соответствующих рендеров. Вычислить правильное название шейдера в БД и шейдерного скрипта .s можно очень просто - для примера если у нас в БД шейдер находится в model/selflight, то имя шейдера должно быть model_selflight.s, если details/blend, то скрипт шейдера будет соответственно details_blend.s . Не так уж сложно.<br />
<br />
Вообще база данных с шейдерами была выдумана не потому что авторам сталкера очень нравилось плодить экземпляры труднораспарсиваемых форматов, а причина более банальна - чтобы увеличить скорость загрузки игры сэкономив за счет активности жесткого диска, при открытии файлов скриптовых шейдеров в папке соответствующего рендера. Плюс к тому, в этом случае уменьшается количество шейдерных файлов что как минимум вдвое уменьшает вероятность ошибки - при условии двух рендеров, эта экономия получается за счет тех шейдеров, которые являются общими для обоих рендеров. Плюс к тому вероятность ошибки еще более уменьшается тем, что базы данных редактируются в сдк, а сдк эти базы данных представляет в виде всевозможных галочек и полей ввода, поэтому ошибка может быть только во вводимых данных, но не в скриптовом коде шейдеров, который вероятнее всего генерируется во время загрузки игры.<br />
<br />
Скриптовые шейдеры используются же в основном только в тех случаях когда их код отличается для разных рендеров.<br />
<br />
По некоторым причинам я считаю что для модостроителей шейдерные скрипты являются более предпочтительными, чем распространение своих шейдерных модов в виде модифицированной .xr-БД. Причины в основном две - во первых скриптовые шейдеры предоставляют бОльшие возможности для полета фантазии :), а во вторых распространение шейдерных модов в виде скриптовых шейдеров все же делает меньше вероятность конфликта модов, так как разные шейдеры будут в разных файлах, а не все вместе в одном хитром и трудноредактируемом, и что самое плохое - трудно-объединяемом файле. Поэтому далее мы рассмотрим скриптовые шейдеры.<br />
<br />
Что собой представляют шейдерные скрипты? Это обычные скрипты на lua, и которые являются своеобразным языком для того чтобы объяснить движку, какие загружать текстуры и какие подключать шейдеры из наличествующих .ps и .vs файлов. <br />
<br />
: ''Для тех кто воспрял духом сразу скажу что несмотря на то, что шейдерные скрипты написаны на языке, который используется в игровых скриптах, это все-таки не одно и то же. Во первых шейдерные скрипты выполняются при загрузке уровня всего один раз (в фазу загрузки "загрузка шейдеров"), поэтому на отрисовку в реальном времени влиять неспособны, и кроме того к игровым скриптам скриптовые шейдеры доступа не имеют.''<br />
<br />
Вот для примера содержимое простейшего скриптового шейдера:<br />
<br />
function normal( shader, t_base, t_second, t_detail )<br />
<br />
shader:begin( "effects_gradient", "effects_gradient_p" )<br />
<br />
end<br />
<br />
Разберем его по косточкам:<br />
<br />
* '''function normal''' - объявление стандартной функции шейдерного скрипта. В некоторых шейдерах есть еще функция '''l_special''' аналогичного содержания, но явно просчитывающая поведение этого шейдера в условиях освещения (пока на данный момент неизвестно какого именно, предположительно - hemi )<br />
<br />
* '''shader''' - вероятнее всего идентификатор шейдера в игре, содержимое этой переменной представляет собой вероятнее всего текстовую строку вроде "models_selflight" или "models/selflight".<br />
* '''t_base''' - путь к текстуре которую следует выводить с помощью этого шейдера<br />
* '''t_second''', '''t_detail''' - пути к другим текстурам, пока назначение их неизвестно.<br />
<br />
* '''shader:begin( "effects_gradient", "effects_gradient_p" )''' - святая святых шейдера. Если точнее - создание объекта шейдера как такового. <br />
:: '''effects_gradient''' - имя .vs файла используемого в этом шейдере<br />
:: '''effects_gradient_p''' - имя .ps файла соответственно.<br />
<br />
<br />
После этой строки могут быть такие строки (они необязательны)<br />
<br />
<br />
* ''': blend ( true, blend.srcalpha, blend.one )''' - обработка текстур, например полупрозрачные текстуры без применения этой строки будут выглядеть непрозрачными черными в прозрачных местах. Эти методы блендинга соответствуют переключателю в сдк, где варианты ALPHA-ADD, BLEND, SET и так далее. На примере выше блендинг соответствует положению ALPHA-ADD.<br />
<br />
:: '''true''' - может быть '''false''' - включение обработки текстур, тоесть true - обработка включена, false соответственно выключена.<br />
<br />
:: '''blend.srcalpha''', '''blend.one''' - соответственно методы блендинга, могут быть blend.one, blend.zero, blend.srcalpha, blend.invsrcalpha и null<br />
<br />
<br />
* ''': sorting ( 3, false )''' - порядок отрисовки поверхности по отношению к самому объекту, частью которого является поверхность.<br />
<br />
:: '''3''' - цифра порядка отрисовки, где 1 - за объектом, 2 - на уровне с объектом, 3 - спереди объекта (ближе к актору). Как правило при тройке шейдируемая поверхность будет отрисовываться поверх всего, в том числе и оружия).<br />
<br />
:: '''false''' - соответствует галочке "srict sorting" в сдк. Пока назначение неизвестно.<br />
<br />
<br />
* ''': aref ( false, 2 )''' - альфа-референс объекта, оператор, переключающий многобитную альфу текстуры в однобитную.<br />
<br />
:: '''false''' - включение/выключение данной функции.<br />
<br />
:: '''2''' - сам альфа-референс объекта<br />
<br />
<br />
* ''': zb ( false, false )''' - манипуляции с z-буфером, где первый аргумент соответствует галке z-test в сдк, второй - галке z-write.<br />
<br />
* ''': fog ( false )''' - действие представляет собой превращение текстуры в черно-белую и применение к ней функции calc_fogging в common.h шейдеров соответствующего рендера.<br />
<br />
* ''': emissive ( true )''' - применяется в источниках освещения.<br />
<br />
<br />
----<br />
<br />
<br />
* '''shader : sampler( "s_base" )''' - создание буфера для помещения туда текстуры. Аргумент представляет собой идентификатор, получаемый функцией main в шейдерах, где будет фигурировать как predefined-переменная s_base.<br />
<br />
<br />
''Перечисленные ниже параметры могут быть только ниже сэмплерной строки!''<br />
<br />
<br />
* ''': texture ( t_base ) ''' - помещение в вышеобъявленный буфер текстуры. аргумент этой ф-ции представляет собой путь к текстуре, так что вполне можно указать нечто вроде<br />
<br />
: texture ( "fx\\fx_sun" )<br />
<br />
чтобы в буфер воткнуть текстуру '''gamedata/textures/fx/fx_sun.dds'''<br />
<br />
<br />
* ''': clamp()''' - соответствует галке Texture Clamp в сдк. Что это такое - точно сказать не могу, Википедия [http://en.wikipedia.org/wiki/Clamping_%28graphics%29 отвечает] на этот вопрос весьма туманно.<br />
<br />
* ''': project()''' - используется в шейдере отрисовки неточечного источника света, и предположительно используется для проектирвоания текстуры сэмплера на те объекты которые находятся в пределах сектора сферы.<br />
<br />
<br />
Ниже представлены еще три оператора используемые с сэмплером, назначение которых неизвестно.<br />
<br />
<br />
* ''': f_linear ()'''<br />
<br />
* ''': wrap ()'''<br />
<br />
* ''': f_anisotropic ()'''<br />
<br />
<br />
----<br />
<br />
<br />
Также в папке с шейдерами лежат еще файлы .s (именно такого имени - точка и эс), которые являются для всех *.s-файлов своеобразными заголовочными файлами, функции из файла .s доступны из файлов *.s . На данный момент там имеются функции printf, и закомментированные во втором рендере ф-ции l_point и l_spot, которые отвечают за создание точечного и неточечного источников света соответственно.</div>80.93.126.66