Шейдеры

[KD87 715]

игра вылетит

Я ж говорю - его физически нет. В файле mblur.h на р3 закомментирован старый dx9-код, он не будет работать с dx10. Потому и закомментирован.

Ну а раз sunmask не дает эффекта, может быть, в движке уже нужного кода нет.

Изменено 18 Августа 2013 пользователем KD87

[*Shoker* 322]

В процессе работы с шейдерами возник ряд вопросов:

 

1) Я кажется не совсем понял разницу между VS и PS шейдерами, то есть по идее это Вертексные и Пиксельные соответственно, и вот по последним: они работают уже с финальной картинкой или с промежуточными? То есть можно допустим через те же пиксельные шейдеры отрезать ненужный кусок из объекта так чтобы отрисовалось то, что за ним? Или же это нужно делать через вертексные?

 

2) Собственно вот экспериментировал с e_weight

Сперва добавил его в шейдер  deffer_base_flat.ps, он в частности отвечает за яркость терреина.

 

Модифицировав строчку

D.rgb = 2*D.rgb*tex2D (s_detail, I.tcdbump).rgb; 

в

D.rgb = e_weights.x*D.rgb*tex2D (s_detail, I.tcdbump).rgb;

Получилось управлять яркостью земли из консоли. (правда для работы параметров пришлось r2_aa включать в консоли)

 

Дальше я открыл base_lplanes.ps, это от шейдера model\lightplanes - светящаяся прозрачная поверхность, который в частности на лампах используется, ручное изменение параметров работает на ура, а вот когда я попытался по аналогии с прошлым шейдером сделать, у меня ничего не вышло. Судя по всему в этот шейдер параметры просто не передаются, или передаются стандартные значения... Потому что в игре в не зависимости от моих настроек всегда одна и та же картинка (перезапуск игры не помогает)

 

#include "common.h"

struct v2p
{
half2 tc0: TEXCOORD0; // base
half2 tc1: TEXCOORD1; // lmap
half4 c0: COLOR0; // sun
};

uniform half4 e_weights;
uniform half4 e_kernel;
uniform half4 e_barrier;

//////////////////////////////////////////////////////////////////////////////////////////
// Pixel
half4 main ( v2p I ) : COLOR
{
half4 t_base = tex2D (s_base,I.tc0);

// out
return half4 (e_weights.x*255, e_weights.y*255, e_weights.z*255, e_barrier.x*255);
//return half4 (t_base.r*e_weights.x,t_base.g*e_weights.y,t_base.b*e_weights.z,t_base.a * I.c0.a);
//return half4 (t_base.r, t_base.g, t_base.b, t_base.a * I.c0.a);
}

 

 

 

Тестировал на ЧН, на ЗП так и не разобрался при каких именно условиях происходит перекомпиляция шейдеров. 

 

*2.1 - Будет ли работать e_weight с вертексными шейдерами?

*2.2 - Каким образом вообще происходит передача e_weight и других консольных переменных в код шейдера, везде где я видел их использование они просто объявляются в начале шейдера без каких либо начальных значений.

 

3) Есть ли способ выводить значения из шейдерного кода в консоль\текстовый файл или куда либо ещё, чтобы проследить какие переменные чему равны?

 

4) Синтаксис vs и ps файлов очень похож на Си-шный, это он и есть или это спец. шейдерный язык? 

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

 

5) r2_aa команда второго рендера, соответственно будут ли доступны в шейдерах значения e_weight если игрок играет на первом или четвёртом рендере? Если нет, то есть ли другие подходящие консольные команды, которые представлены в шейдерах для всех рендеров. (мне хватит даже обычного float или int (только если диапазон int не ограничен 0-1)

 

6) Есть ли какой то механизм наследования между рендерами? Допустим я создам новый шейдер, который будет одинаков на всех рендерах. Тогда мне нужно просто положить его в папку r1, или же нужно его подключать\класть копию во всех рендерах?  

 

 

 

Изменено 19 Августа 2013 пользователем *Shoker*

[macron 1 777]

@*Shoker*, по 6. Наследование есть между shaders.xr и r1/r2. Например, шейдер из папки r1(или r2) может перекрыть настройки из shaders.xr. Но между собой r1 и r2 не связаны. То есть новый шейдер надо будет создавать и класть для обеих папок.

[KD87 715]

1) Я кажется не совсем понял разницу между VS и PS шейдерами

 

Вершинному на вход подается буферы с геометрией, он обрабатывает вершины. Его дело - рассчитать "текстурные" координаты вершин ну и параметры для пиксельного шейдера, если нужно. Потом все это дело дальше растеризуется (устанавливается соответствие между вершинами и экранными пикселями) и запускается пиксельный шейдер, который работает уже попиксельно. Его задача - выдать цвет пикселя. Таким образом, шейдера начинают работать после вызова отрисовки (DrawIndexedPrimitive). Какие шейдеры будут работать при вызове, какие текстуры передаются в шейдер, в какую текстуру записывается результат рендеринга - все это задается в движке. В общем случае из шейдеров ничего не понять. Если что-то нужно выяснить предметно - спрашивай, буду пояснять подобные вещи. Например, важнейший шейдер combine_2 пишет в $user$generic0, которая является "бэкбуфером", то есть текстурой, выводимой на экран. А шейдера типа deffer_ пишут сразу в три текстуры - $user$position, $user$normal, $user$albedo (или $user$accum, зависит от видеокарты).

 

 

2) Собственно вот экспериментировал с e_weight

 

Тут есть нюанс. Константы (как и текстуры для шейдера) в общем случае задаются перед вызовом отрисовки из движка. Поэтому в шейдере они только объявляются, но не определяются. Соответственно, доступны такие константы только во время отрисовки, когда они были выставлены. Хотя и есть список "глобальных" констант, конкретно e_weight в этот список не входит, и доступна эта константа только в шейдерах, наследующих от combine_2. С deffer_base_flat у тебя обман зрения, там тоже не должно работать

 

 

3) Есть ли способ выводить значения из шейдерного кода в консоль\текстовый файл или куда либо ещё, чтобы проследить какие переменные чему равны?

 

Увы, нет. Даже в студии отладка шейдеров появилась только в 2012  версии. Можно поковырять PIX, говорят, неплохой профайлер, может, он сможет чего показать.

 

 

4) Синтаксис vs и ps файлов очень похож на Си-шный, это он и есть или это спец. шейдерный язык?  Есть ли у него возможность расширения, допустим путём подключения тех же Си-шных библиотек, или даже просто вызовом X-Ray-евских Си-шных движковых функций. 

 

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

 

 

5) r2_aa команда второго рендера

 

Больше нигде не будет доступно. Но это как раз логично, на dx10 и dx11 антиалиасинг хардварный, msaa, там нафиг не нужно это шейдерное извращение. Потому и нет.

Изменено 19 Августа 2013 пользователем KD87

[*Shoker* 322]

 

С deffer_base_flat у тебя обман зрения, там тоже не должно работать 

 

 

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

Только я ошибся в названии - deffer_impl_flat.ps

 

Хотя и есть список "глобальных" констант, конкретно e_weight в этот список не входит

То eсть кроме координат солнца\тумана\камеры игрока больше нет ничего что как нибудь можно было бы регулировать из игры и что было бы доступно везде и на всех рендерах?

А возможностями HLSL тоже нельзя каким нибудь костылём сделать проверку, например на наличие\отсутствие какого нибудь файла, чтобы таким образом регулировать его работу прямо из игры в реальном времени?

 

[KD87 715]

Оно там действительно работало.

 

Ничего подобного на чистом ЧН не наблюдаю.

 

 

наличие\отсутствие какого нибудь файла

 

Снова - не стоит заблуждаться. HLSL - язык программирования отдельных этапов графического конвейера, GPU. Какой тут может быть доступ к файлам? Dynamic branching приличный и то только в SM 3.0 прикрутили.

Изменено 20 Августа 2013 пользователем KD87

[krovosnork 257]

@KD87, возможно сделать снег, не заменяя дождь? Как второй тип дождя. 

[Malandrinus 611]

@krovosnork, нет, снег ведёт себя совершенно иначе. Капли дождя рисуются движком, как цветные линии. Рисуются всплески в месте удара. К снегу это просто неприменимо. Если его и делать, то дождь отключать вовсе, а снег реализовывать самостоятельно, партиклами к примеру. И если намокание худо-бедно реализовано, то динамический снег на земле ты в сталкере точно не сделаешь.

[krovosnork 257]

@Malandrinus, мне нужен осенний снег, который сразу тает. Даже не знаю, как сделать его партиклом.

[*Shoker* 322]

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

 

@KD87, а ты r2_aa 1 не забыл включить?

 

http://images.gameru.net/image/42025b9e51.jpg

 

http://images.gameru.net/image/86c69494a8.jpg

 

http://images.gameru.net/image/8fb5acec0b.jpg

 

У меня он как раз заработал, вот я и полез в lightplanes эксперементировать. 
Ну а так фиг его знает, в любом случае если нету больше способа как то влиять на шейдер извне то тема закрыта. 

FOV ведь случаем в шейдера не передаётся в виде float? 

Изменено 20 Августа 2013 пользователем *Shoker*

[Malandrinus 611]

Shoker,

 

партиклом снег сделать очень легко, ... партикл также можно двигать вокруг ГГ

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

А если не решить эту проблему, то будет смотреться уродливо.

 

 

[KD87 715]

@*Shoker*, включал. Но это неважно. Давай свои шейдера, я проверю на чистом ЧН. 

[*Shoker* 322]

@KD87, 

http://rghost.ru/48258967

Тестировал на полном динамическом (не DX10)

Игру запускал через xrEngine.exe

Бинарники от какого то репака, что оригинал что нет хз, но никаких движковых модификаций боле там быть не должно.

 

@Malandrinus, 
ну если источник снега сделать высоко над ГГ метров на 20-30 то снег будет просто уничтожатся при контакте со статикой, если у него включить физику. Другое дело что снег же падает медленно, поэтому если ГГ резко телепортируется куда-то, то и снег у него над головой из воздуха появится и будет некоторое время падать до земли, но это уже другой вопрос, возможно решаемый увеличением радиуса партикла снега. 

[Akcok 164]

1 - Есть ли какой-нибудь компилятор, прога или что-то вроде для переноса шейдеров формата hlsl 3.0 в 4.0? Например чтобы восстановить тот-же Motion Blur на DX10. 

2 - Какие примерно эффекты можно создать в сталкере, а какие нет (например требующих изменений в рендере)? Например можно ли создать эффект Боке и так далее.

3 - Какое-то SSAO в ЧН ужасное. Какой-то горошек получается. HBAO ваще дает грубые толстые контуры, HDAO лучше смотрится чем обычный SSAO, гороха в принципе нету. Вроде бы в ЗП более-менее норм, можно ли портануть? Так-же в самом ЧН нету в опциях HDAO, HBAO хотя есть консольные команды. Мож разрабы вырезали опции по их включению так-как есть выше перечисленные недочеты?

P.S. Возможно ли создать в сталкере регулируемый через шейдеры эффект оттенка? Например чтобы картинка была допустим с синими тонами, или например другого цвета, чтобы регулировать. Например в ТЧ все отдает синевой, в ЧН желтизной. Только это настройки погоды и текстуры, а это чтобы регулировать через шейдер.

Изменено 24 Августа 2013 пользователем power-cat

[*Shoker* 322]

@power-cat, по контрасту смотри этот мод. 
Там где то даже были сравнительные скрины ЗП с синей гаммой, но видимо они в другой теме потерялись. 

 

______________________
Такой вопрос ещё по шейдерам, возможно ли в Сталкере без правок движка сделать такой шейдер, чтобы объекты с ним было видно лишь через другие шейдера. Допустим шейдер, который будет видим лишь через сталкерское стеклко?

[k01jan 815]

Подскажите, пожалуйта, полупрозрачный шейдер для худовой модели под ЗП. Нужен эффект стекла. Для мировой подходит models\xdistortinv. А в худовой выглядит прозрачным. то есть совсем невидимый материал становится.

[KD87 715]

@power-cat,

1 - нет, конечно, ручками надо.

2 - надо немножко конкретней спрашивать. Вот про Боке могу сказать - сам эффект dx11-only, но имитацию можно сделать, что у нас в ОГСЕ и реализовано.

3 - HDAO dx10-only, HBAO перенести можно, что у нас в ОГСЕ и реализовано

P.S. да легко. Вот примерный шейдерный код, вставлять в конец combine_2_xxx, но до combine_bloom:

 

#define COLOR_GRADING_LUMINANCE half3(0.213, 0.715, 0.072)
#define c_color_grading half3(1.0, 0.0, 0.0)

half fLum = dot(img.xyz, COLOR_GRADING_LUMINANCE); 
half3 cMin = 0.0; 
half3 cMed = c_color_grading; 
half3 cMax = 1.0; 
half3 cColor = lerp(cMin, cMed , saturate( fLum * 2.0 ) ); 
cColor = lerp( cColor, cMax, saturate( fLum - 0.5 ) * 2.0 ); 
img.xyz = lerp( img.xyz, cColor.xyz , saturate( fLum ) );

В c_color_grading хранится нужный оттенок. В данном примере - красный цвет.

 

 

Такой вопрос

Я сомневаюсь, что хоть где-то такое можно. Лучше опиши ситуацию, 90%, что есть приличное решение 

 

@k01jan, а models/glass не подходит? 

Изменено 25 Августа 2013 пользователем KD87

[k01jan 815]

В models/ нет glass, а просто glass, вне свитка  models тоже прозрачный/невидимый.

 

 

 

 

Изменено 25 Августа 2013 пользователем k01jan

[topdog 45]

@k01jan, а если текстурку бутылки (альфа-канал на стекле) сделать сереньким?

Покажи свою текстуру.

Изменено 25 Августа 2013 пользователем topdog

[KD87 715]

@k01jan, тогда models/window.