Полная версия этой страницы: Графика, рендер, шейдеры
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91
saas, спасиб, попробую агропром с подземкой на максах скомпилить, заодно может и светящиеся кусты тоже исчезнут. через сутки отпишусь
Цитата(saas @ 15.09.2016, 23:02) 
оригинальный компилятор из SDK 0.4 с такой правкой:
В него не входит фикс обхода инвалидов?
RayTwitty, конечно нет, оригинальный же 
saas, в общем затестил правку, глюки с разноцветными лайтмапами действительно пропали, и теперь темная комната действительно темная. светящиеся кусты правда так и светятся...
Можно ли движково сделать панораму для intro?
Короче фикс лайтмапов без сжатия визуально едва отличим, но всё-таки отличим, картинка мягче и без градиентов, правда у меня калькулятор и тестил на средних настройках компиляции. Однако и вес лайтмапов в четыре раза больше, если локаций много и они наворочены вес будет очень большим, могут возникнуть проблемы из-за нехватки памяти.
Must have для тех кто со статикой заморачивается.
Must have для тех кто со статикой заморачивается.
Цитата(Reznor @ 24.09.2016, 10:53)
картинка мягче и без градиентов
Ты наверное имел ввиду "без ступенек", а то противоречие получается.
Цитата(Reznor @ 24.09.2016, 10:53)
Однако и вес лайтмапов в четыре раза больше, если локаций много и они наворочены вес будет очень большим, могут возникнуть проблемы из-за нехватки памяти.
В игре для каждой локации свои лайтмапы грузятся заново, соответственно решающее значение имеет объём лайтмапов для конкретного уровня, а не суммарно со всех.
А конкретно по уровню, например, болото в OLR задействует 175 парных лайтмапов, это 350 файлов на 350 mb. На XP полёт нормальный.
Цитата(macron @ 24.09.2016, 21:01)
Цитата(Reznor @ 24.09.2016, 10:53)
Однако и вес лайтмапов в четыре раза больше, если локаций много и они наворочены вес будет очень большим, могут возникнуть проблемы из-за нехватки памяти.
В игре для каждой локации свои лайтмапы грузятся заново, соответственно решающее значение имеет объём лайтмапов для конкретного уровня, а не суммарно со всех.
А конкретно по уровню, например, болото в OLR задействует 175 парных лайтмапов, это 350 файлов на 350 mb. На XP полёт нормальный.
Жесть, откуда столько лайтмапов там? Качество pixel meter небось за 60 уже выкрутили?
Ну прикинь вес одного файла 4196, 1.5 гб на локу... + остальное, короче нагрузка, учитывая древность движка, очень большая на оперативку. Зато качество!
да качественные тени наше все, а убогие модельки авто из двух полигонов никого не смущают? Как и то что они заспавлены без физики даже там где бои гранатами
Цитата
оригинальный компилятор из SDK 0.4 с такой правкой:
А как называется оригинальный компиль с правкой по инвалидам? Есть Bench_xrLC_extra_v39, только среди всех этих макрон-харон-макарон.exe непонятно, какой компиль именно с фиксом.
Хотелось бы внести этот фикс в компиль с качественными лайтмэпами.
RayTwitty, насколько я знаю, все те что в bins\compiler-fixxed.
А вообще эта правка делается за пять минут, всего-то в паре мест JZ на JMP заменить.
А вообще эта правка делается за пять минут, всего-то в паре мест JZ на JMP заменить.
Цитата(saas @ 25.09.2016, 21:47)
А вообще эта правка делается за пять минут, всего-то в паре мест JZ на JMP заменить.
Это всё понятно, нужен файл с правкой чтобы сравнить, какие байты менялись.
Может кто нибудь замутит репозиторий только с исходниками компилятора KD?
Собрал вот из репо xrLC (x32) с этой правкой на качественные лайтмапы -
hi_flyer, из какого репо?
Ray,
hi_flyer, а почему не 64 бит?
Ray, потому что очень глючный x64
Недавно вышла новая версия nvidia texture tools
Нашел тут у себя архив sky4ce_r3_fixes.rar, в котором лежат шейдеры r3\lmodel.h и r3\rain_patch_normal.ps.
Вроде бы, они фиксят кривое намокание вертикальных поверхностей на DX10.
У меня ЧН нет, может ли кто потестить?
Вроде бы, они фиксят кривое намокание вертикальных поверхностей на DX10.
У меня ЧН нет, может ли кто потестить?
Хочешь сделать хорошо - сделай это сам ©
То, что когда-то выкладывалось для ЧН.
Фикс стекающих поверхностей действительно работает.
до/после
З.Ы. внезапно ожил объемный дым в ЧН
То, что когда-то выкладывалось для ЧН.
Фикс стекающих поверхностей действительно работает.
до/после
З.Ы. внезапно ожил объемный дым в ЧН
Shadows, а можешь перепаковать шейдеры? А то Protect и Защитник ругаются, говорят там вирус
QUOTE (macron @ 05.07.2016, 17:02)
#include "common.h"
struct v2p
{
float2 tc0 : TEXCOORD0; // base
float4 c0 : COLOR0;
};
half4 main_ps_2_0 ( v2p I ) : COLOR
{
float2 center = I.tc0;
float2 tc = I.tc0;
float4 col = tex2D(s_base,tc);
//начало COLOR_FRINGE
half amount = .003f;
half3 img = half3( 0.f, 0.f, 0.f );
half2 offset_fringe = distance( half2( .5f, .5f ), center ) * half2( amount, amount );
img.r = tex2D( s_image, center + offset_fringe ).r;
img.g = tex2D( s_image, center ).g;
img.b = tex2D( s_image, center - offset_fringe ).b;
//конец COLOR_FRINGE
//return col; //всё нормуль, но нет эффекта COLOR_FRINGE
//return I.c0; //всё белое
}
Оптимизировал шейдер. Как должна выглядеть строка return, чтобы задействовался эффект COLOR_FRINGE ?
struct v2p
{
float2 tc0 : TEXCOORD0; // base
float4 c0 : COLOR0;
};
half4 main_ps_2_0 ( v2p I ) : COLOR
{
float2 center = I.tc0;
float2 tc = I.tc0;
float4 col = tex2D(s_base,tc);
//начало COLOR_FRINGE
half amount = .003f;
half3 img = half3( 0.f, 0.f, 0.f );
half2 offset_fringe = distance( half2( .5f, .5f ), center ) * half2( amount, amount );
img.r = tex2D( s_image, center + offset_fringe ).r;
img.g = tex2D( s_image, center ).g;
img.b = tex2D( s_image, center - offset_fringe ).b;
//конец COLOR_FRINGE
//return col; //всё нормуль, но нет эффекта COLOR_FRINGE
//return I.c0; //всё белое
}
Оптимизировал шейдер. Как должна выглядеть строка return, чтобы задействовался эффект COLOR_FRINGE ?
Народ а не проще было к автору обратиться? я ж его писал!
return half4( img, 1 );
не морочьте себе голову.
Цитата(RayTwitty @ 29.09.2016, 23:29)
Нашел тут у себя архив sky4ce_r3_fixes.rar, в котором лежат шейдеры r3\lmodel.h и r3\rain_patch_normal.ps.
Вроде бы, они фиксят кривое намокание вертикальных поверхностей на DX10.
Вроде бы, они фиксят кривое намокание вертикальных поверхностей на DX10.
Баги с намоканием фиксятся в rain_patch_normal.ps правкой некоторых чисел. А зачем правлен lmodel.h?
Цитата(SkyLoader @ 02.10.2016, 15:33)
А зачем правлен lmodel.h?
Цвет блика принимает цвет источника.
Цитата(cjayho @ 01.10.2016, 23:18)
return half4( img, 1 );
Без полноценных тестов и допиливания нормальным шейдерщиком всё равно не заработает.
Цитата(cjayho @ 01.10.2016, 23:18)
Народ а не проще было к автору обратиться? я ж его писал!
Уже не помню, что тогда было. Захочешь сам нормально дописать, можешь использовать идею. Мне уже пофиг. Вот какие-то наработки для r2, чаще приводящие к белому экрану при прицеливании.
Протестировал я эти обновленные 32-х битные компиляторы (кстати, работают они заметно быстрее ускоренных версий НЫС), с пофикшенными лайтмапами - и нифига. Они все такие же синие. Криво собрали? На форуме АМК, по этой тематике чуть ли не целый срач развели. А выводы, на данный момент такие:
1. оригинальные ускоренные компиляторы ПЫС - синие лайтмапы. 2. 64-х бинтные за 2014 год - синий террейн и синие лайтмапы (но их генерируется мало, мне кажется это правильно) 3. 64-х битные компиляторы за 2015 год - норм. террейн, лучше тени, норм. лайтмапы, но плодится их дофига (думаю, что это баг). 4. Ну и эти, свежие 32-х битные из исходников, с отключенным сжатием лайтмапов и якобы исправленной синюшностью. Опять же, их генерируется много, даже на подземке.
1. оригинальные ускоренные компиляторы ПЫС - синие лайтмапы. 2. 64-х бинтные за 2014 год - синий террейн и синие лайтмапы (но их генерируется мало, мне кажется это правильно) 3. 64-х битные компиляторы за 2015 год - норм. террейн, лучше тени, норм. лайтмапы, но плодится их дофига (думаю, что это баг). 4. Ну и эти, свежие 32-х битные из исходников, с отключенным сжатием лайтмапов и якобы исправленной синюшностью. Опять же, их генерируется много, даже на подземке.
Подскажите, кто в курсе, на ЧН и ЗП солнечные лучи могут работать без объёмного света или должен быть объемный свет включен? Используются ли для лучей и объемного света технологии DX10?
Цитата(Rock`n_Roll @ 02.12.2016, 10:30)
Подскажите, кто в курсе, на ЧН и ЗП солнечные лучи могут работать без объёмного света или должен быть объемный свет включен? Используются ли для лучей и объемного света технологии DX10?
Независимые эффекты. Второго улучшенного рендера для них достаточно.
По поводу хром. абберации в прицеле.
Нужно пробовать, сам затестить не имею возможности.
Код
//////////////////////////////////////////////////////////////////////////////////////////
// Pixel
float4 main ( v2p I ) : COLOR
{
float2 tc = I.tc0;
float x = 1/(c_screen.y*TAR);
tc.x = tc.x*x + 0.5*(1-x);
// float4 col = tex2D (s_base,tc);
float amount = .003f;
float4 col = tex2D (s_base,tc);
float2 offset_fringe = distance( float2( .5f, .5f ), tc ) * float2( amount, amount );
col.r = tex2D( s_base, tc + offset_fringe ).r;
col.g = tex2D( s_base, tc ).g;
col.b = tex2D( s_base, tc - offset_fringe ).b;
return I.c0*col;
}
// Pixel
float4 main ( v2p I ) : COLOR
{
float2 tc = I.tc0;
float x = 1/(c_screen.y*TAR);
tc.x = tc.x*x + 0.5*(1-x);
// float4 col = tex2D (s_base,tc);
float amount = .003f;
float4 col = tex2D (s_base,tc);
float2 offset_fringe = distance( float2( .5f, .5f ), tc ) * float2( amount, amount );
col.r = tex2D( s_base, tc + offset_fringe ).r;
col.g = tex2D( s_base, tc ).g;
col.b = tex2D( s_base, tc - offset_fringe ).b;
return I.c0*col;
}
Нужно пробовать, сам затестить не имею возможности.
QUOTE (mrmnwar @ 27.12.2016, 11:19)
По поводу хром. абберации в прицеле.
Нужно пробовать, сам затестить не имею возможности.
CODE
//////////////////////////////////////////////////////////////////////////////////////////
// Pixel
float4 main ( v2p I ) : COLOR
{
float2 tc = I.tc0;
float x = 1/(c_screen.y*TAR);
tc.x = tc.x*x + 0.5*(1-x);
// float4 col = tex2D (s_base,tc);
float amount = .003f;
float4 col = tex2D (s_base,tc);
float2 offset_fringe = distance( float2( .5f, .5f ), tc ) * float2( amount, amount );
col.r = tex2D( s_base, tc + offset_fringe ).r;
col.g = tex2D( s_base, tc ).g;
col.b = tex2D( s_base, tc - offset_fringe ).b;
return I.c0*col;
}
// Pixel
float4 main ( v2p I ) : COLOR
{
float2 tc = I.tc0;
float x = 1/(c_screen.y*TAR);
tc.x = tc.x*x + 0.5*(1-x);
// float4 col = tex2D (s_base,tc);
float amount = .003f;
float4 col = tex2D (s_base,tc);
float2 offset_fringe = distance( float2( .5f, .5f ), tc ) * float2( amount, amount );
col.r = tex2D( s_base, tc + offset_fringe ).r;
col.g = tex2D( s_base, tc ).g;
col.b = tex2D( s_base, tc - offset_fringe ).b;
return I.c0*col;
}
Нужно пробовать, сам затестить не имею возможности.
В таком виде шейдер делает лишнюю работу. Проще так:
CODE
//////////////////////////////////////////////////////////////////////////////////////////
// Pixel
float4 main ( v2p I ) : COLOR
{
float2 tc = I.tc0;
float x = 1/(c_screen.y*TAR); // что за TAR и откуда он?
tc.x = tc.x*x + 0.5*(1-x); // Что это вообще за черная магия, вот эта строка и предыдущая? в оригинале я такого не писал.
// float4 col = tex2D (s_base,tc);
float amount = .003f; // вот это лучше вывести в конфиг, это сила расслоения на цвета.
// float4 col = tex2D (s_base,tc); // не нужно,
float4 col = float4(0,0,0,0); // один хрен мы ниже эти значения заменяем другими.
float2 offset_fringe = distance( float2( .5f, .5f ), tc ) * float2( amount, amount );
col.r = tex2D( s_base, tc + offset_fringe ).r;
col.g = tex2D( s_base, tc ).g;
col.b = tex2D( s_base, tc - offset_fringe ).b;
return I.c0 * col; // что мы за цвет получаем в шейдер, нужен ли он тут?
}
// Pixel
float4 main ( v2p I ) : COLOR
{
float2 tc = I.tc0;
float x = 1/(c_screen.y*TAR); // что за TAR и откуда он?
tc.x = tc.x*x + 0.5*(1-x); // Что это вообще за черная магия, вот эта строка и предыдущая? в оригинале я такого не писал.
// float4 col = tex2D (s_base,tc);
float amount = .003f; // вот это лучше вывести в конфиг, это сила расслоения на цвета.
// float4 col = tex2D (s_base,tc); // не нужно,
float4 col = float4(0,0,0,0); // один хрен мы ниже эти значения заменяем другими.
float2 offset_fringe = distance( float2( .5f, .5f ), tc ) * float2( amount, amount );
col.r = tex2D( s_base, tc + offset_fringe ).r;
col.g = tex2D( s_base, tc ).g;
col.b = tex2D( s_base, tc - offset_fringe ).b;
return I.c0 * col; // что мы за цвет получаем в шейдер, нужен ли он тут?
}
Раз уж ещё остались тут специалисты по шейдерам 
, хотел задать один вопрос. Я более менее понял как работать с пиксельными шейдерами, но вот с вертексными ещё толком не разбирался, пользуясь готовыми, поэтому вопрос скорее всего нубский.
Для примера: есть задача сделать аномалию, в радиусе которой вся геометрия будет обесцвечиваться, притом таких аномалий в сцене может быть произвольное кол-во. Для этого (как я полагаю) мне нужно в вертексном шейдере каким то образом просчитывать дистанцию каждого вертекса до каждой аномалии, а потом ещё каким то образом делать плавный переход (чтобы не весь полигон обесцвечивался, а только та часть, что непосредственно в радиус аномалии залезает.
Вопросов несколько:
1) Возможно ли такое вообще сделать. (в рамках сталкера)
2) Правильно-ли я понял принцип реализации подобного эффекта. Просто я в шейдерах даже динамических массивов не видел, а потому не ясно как туда вообще передавать данные о позиции каждой аномалии.
3) Нет ли похожих примеров в сталкере или где либо ещё, откуда их можно подсмотреть.
, хотел задать один вопрос. Я более менее понял как работать с пиксельными шейдерами, но вот с вертексными ещё толком не разбирался, пользуясь готовыми, поэтому вопрос скорее всего нубский.Для примера: есть задача сделать аномалию, в радиусе которой вся геометрия будет обесцвечиваться, притом таких аномалий в сцене может быть произвольное кол-во. Для этого (как я полагаю) мне нужно в вертексном шейдере каким то образом просчитывать дистанцию каждого вертекса до каждой аномалии, а потом ещё каким то образом делать плавный переход (чтобы не весь полигон обесцвечивался, а только та часть, что непосредственно в радиус аномалии залезает.
Вопросов несколько:
1) Возможно ли такое вообще сделать. (в рамках сталкера)
2) Правильно-ли я понял принцип реализации подобного эффекта. Просто я в шейдерах даже динамических массивов не видел, а потому не ясно как туда вообще передавать данные о позиции каждой аномалии.
3) Нет ли похожих примеров в сталкере или где либо ещё, откуда их можно подсмотреть.
Shoкer, а если смотреть сквозь аномалию, то то, что находится за аномалией, тоже должно обесцвечиваться? У меня как-то давно получалось такое для стекол.
Не обязательно, я аномалию привёл как пример, а вообще мне сам механизм интересен, например чтобы сделать обгоревшую листву\траву для огнемёта. 
+ для тех же аномалий можно ввести деформацию террейна, чтобы от огненных аномалий террейн становился потресканным, а от электрических высушенным и т.п
У тебя, я так полагаю, сделано через маску - рендеришь в неё стёкла и на стадии постпроцесса (в combine_1 \ _2) ты её используешь чтобы на часть экрана "не выводить" цвет? (я в рендере плохо разбираюсь на самом деле) Вообще прикольный эффект, через него можно коллиматорные ПНВ-прицелы как в Метро 2033 сделать.
UPD: Совсем вылетело из головы, что источники света в сталкере работают примерно так, как я и хочу. Нужно только вместо освещения обесцвечивать\заменять текстуру.
+ для тех же аномалий можно ввести деформацию террейна, чтобы от огненных аномалий террейн становился потресканным, а от электрических высушенным и т.п
У тебя, я так полагаю, сделано через маску - рендеришь в неё стёкла и на стадии постпроцесса (в combine_1 \ _2) ты её используешь чтобы на часть экрана "не выводить" цвет? (я в рендере плохо разбираюсь на самом деле) Вообще прикольный эффект, через него можно коллиматорные ПНВ-прицелы как в Метро 2033 сделать.
UPD: Совсем вылетело из головы, что источники света в сталкере работают примерно так, как я и хочу. Нужно только вместо освещения обесцвечивать\заменять текстуру.
А, ты такое имел ввиду обесцвечивание. У меня то вообще обесцвечивается полностью, я это не контролирую. Правил просто шейдер стекол, что-то криво начал передавать, в итоге такая байда.
По поводу аномалий, можешь создавать ингейм воллмарки с трещинами на горизонтальной поверхности, да и всё.
Может тебе попробовать аномалиям лайт черного цвета сделать? Вдруг будет казаться, что террейн и детейлы обгорели
По поводу аномалий, можешь создавать ингейм воллмарки с трещинами на горизонтальной поверхности, да и всё.
Может тебе попробовать аномалиям лайт черного цвета сделать? Вдруг будет казаться, что террейн и детейлы обгорели
QUOTE (Shoкer @ 02.01.2017, 14:11)
Раз уж ещё остались тут специалисты по шейдерам , хотел задать один вопрос. Я более менее понял как работать с пиксельными шейдерами, но вот с вертексными ещё толком не разбирался, пользуясь готовыми, поэтому вопрос скорее всего нубский.
Для примера: есть задача сделать аномалию, в радиусе которой вся геометрия будет обесцвечиваться, притом таких аномалий в сцене может быть произвольное кол-во. Для этого (как я полагаю) мне нужно в вертексном шейдере каким то образом просчитывать дистанцию каждого вертекса до каждой аномалии, а потом ещё каким то образом делать плавный переход (чтобы не весь полигон обесцвечивался, а только та часть, что непосредственно в радиус аномалии залезает.
Вопросов несколько:
1) Возможно ли такое вообще сделать. (в рамках сталкера)
2) Правильно-ли я понял принцип реализации подобного эффекта. Просто я в шейдерах даже динамических массивов не видел, а потому не ясно как туда вообще передавать данные о позиции каждой аномалии.
3) Нет ли похожих примеров в сталкере или где либо ещё, откуда их можно подсмотреть.
, хотел задать один вопрос. Я более менее понял как работать с пиксельными шейдерами, но вот с вертексными ещё толком не разбирался, пользуясь готовыми, поэтому вопрос скорее всего нубский.Для примера: есть задача сделать аномалию, в радиусе которой вся геометрия будет обесцвечиваться, притом таких аномалий в сцене может быть произвольное кол-во. Для этого (как я полагаю) мне нужно в вертексном шейдере каким то образом просчитывать дистанцию каждого вертекса до каждой аномалии, а потом ещё каким то образом делать плавный переход (чтобы не весь полигон обесцвечивался, а только та часть, что непосредственно в радиус аномалии залезает.
Вопросов несколько:
1) Возможно ли такое вообще сделать. (в рамках сталкера)
2) Правильно-ли я понял принцип реализации подобного эффекта. Просто я в шейдерах даже динамических массивов не видел, а потому не ясно как туда вообще передавать данные о позиции каждой аномалии.
3) Нет ли похожих примеров в сталкере или где либо ещё, откуда их можно подсмотреть.
Начинать нужно собственно с вопроса "чтоб не обесцвечивался весь полигон", что уже подразумевает работу с пиксельными шейдерами, и по возможности в постранстве вьюпорта, в экранном пространстве, если нужно действительно неограниченное количество аномалий в кадре, чтоб не делать отдельных проход или рендертаргет для каждой аномалии.
Учтите простую истину - шейдеры перемалывают данные только в пределах одного единственного кадра, причем даже не всего кадра а каждой вершины или пикселя текстуры в каком-либо пространстве, как в пространстве координат самой текстуры натянутой на фигуру, так и в пространстве координат экрана. И они вообще не знают такой штуки как аномалия: если вы хотите работать с аномалией, вам либо придется для каждой аномалии передавать в шейдер ее координаты и радиус (например) или делать отдельный материал, к которому привязан необходимый шейдер, и сфера из этого материала будет представлять собой аномалию.
Такое лучше всего замутить по примеру воды, только ставить шейдер не искажения а обесцвечивания.
QUOTE (Shoкer @ 02.01.2017, 16:47)
+ для тех же аномалий можно ввести деформацию террейна, чтобы от огненных аномалий террейн становился потресканным, а от электрических высушенным и т.п
Деформация терейна, ну то есть настоящая а не бампмаппинг - это работа геометрических шейдеров, то есть >= р3-онли, и то деформация будет чисто визуальная, если например шейдерами там сделать воронку, то физика об этом даже догадываться не будет, и болт например будет отскакивать от того места где ранее была поверхность, до обработки геометрическим шейдером, а не от нового положения поверхности, с учетом работы шейдера.
Добрый день, давно интересует вопрос, как исправить "белые сосны" на горизонте при использовании саншафтов ЧН из ОГСЕ?
Вроде как, связано с туманом - саншафты окрашиваются в его цвет, можно, конечно, его полностью убрать, но это не вариант
Вроде как, связано с туманом - саншафты окрашиваются в его цвет, можно, конечно, его полностью убрать, но это не вариант
Цитата(cjayho @ 02.01.2017, 09:44)
Цитата(mrmnwar @ 27.12.2016, 11:19)
По поводу хром. абберации в прицеле.
Нужно пробовать, сам затестить не имею возможности.
Код
//////////////////////////////////////////////////////////////////////////////////////////
// Pixel
float4 main ( v2p I ) : COLOR
{
float2 tc = I.tc0;
float x = 1/(c_screen.y*TAR);
tc.x = tc.x*x + 0.5*(1-x);
// float4 col = tex2D (s_base,tc);
float amount = .003f;
float4 col = tex2D (s_base,tc);
float2 offset_fringe = distance( float2( .5f, .5f ), tc ) * float2( amount, amount );
col.r = tex2D( s_base, tc + offset_fringe ).r;
col.g = tex2D( s_base, tc ).g;
col.b = tex2D( s_base, tc - offset_fringe ).b;
return I.c0*col;
}
// Pixel
float4 main ( v2p I ) : COLOR
{
float2 tc = I.tc0;
float x = 1/(c_screen.y*TAR);
tc.x = tc.x*x + 0.5*(1-x);
// float4 col = tex2D (s_base,tc);
float amount = .003f;
float4 col = tex2D (s_base,tc);
float2 offset_fringe = distance( float2( .5f, .5f ), tc ) * float2( amount, amount );
col.r = tex2D( s_base, tc + offset_fringe ).r;
col.g = tex2D( s_base, tc ).g;
col.b = tex2D( s_base, tc - offset_fringe ).b;
return I.c0*col;
}
Нужно пробовать, сам затестить не имею возможности.
В таком виде шейдер делает лишнюю работу. Проще так:
Код
//////////////////////////////////////////////////////////////////////////////////////////
// Pixel
float4 main ( v2p I ) : COLOR
{
float2 tc = I.tc0;
float x = 1/(c_screen.y*TAR); // что за TAR и откуда он?
tc.x = tc.x*x + 0.5*(1-x); // Что это вообще за черная магия, вот эта строка и предыдущая? в оригинале я такого не писал.
// float4 col = tex2D (s_base,tc);
float amount = .003f; // вот это лучше вывести в конфиг, это сила расслоения на цвета.
// float4 col = tex2D (s_base,tc); // не нужно,
float4 col = float4(0,0,0,0); // один хрен мы ниже эти значения заменяем другими.
float2 offset_fringe = distance( float2( .5f, .5f ), tc ) * float2( amount, amount );
col.r = tex2D( s_base, tc + offset_fringe ).r;
col.g = tex2D( s_base, tc ).g;
col.b = tex2D( s_base, tc - offset_fringe ).b;
return I.c0 * col; // что мы за цвет получаем в шейдер, нужен ли он тут?
}
// Pixel
float4 main ( v2p I ) : COLOR
{
float2 tc = I.tc0;
float x = 1/(c_screen.y*TAR); // что за TAR и откуда он?
tc.x = tc.x*x + 0.5*(1-x); // Что это вообще за черная магия, вот эта строка и предыдущая? в оригинале я такого не писал.
// float4 col = tex2D (s_base,tc);
float amount = .003f; // вот это лучше вывести в конфиг, это сила расслоения на цвета.
// float4 col = tex2D (s_base,tc); // не нужно,
float4 col = float4(0,0,0,0); // один хрен мы ниже эти значения заменяем другими.
float2 offset_fringe = distance( float2( .5f, .5f ), tc ) * float2( amount, amount );
col.r = tex2D( s_base, tc + offset_fringe ).r;
col.g = tex2D( s_base, tc ).g;
col.b = tex2D( s_base, tc - offset_fringe ).b;
return I.c0 * col; // что мы за цвет получаем в шейдер, нужен ли он тут?
}
Это шейдер универсальных прицельных сеток из 7 патча. 1) TAR - дефайн, 2) не писал, 3) нужен.
Цитата(D1mon @ 03.01.2017, 10:03)
Добрый день, давно интересует вопрос, как исправить "белые сосны" на горизонте при использовании саншафтов ЧН из ОГСЕ?
Вроде как, связано с туманом - саншафты окрашиваются в его цвет, можно, конечно, его полностью убрать, но это не вариант
Вроде как, связано с туманом - саншафты окрашиваются в его цвет, можно, конечно, его полностью убрать, но это не вариант
В ЧН такого нет, проблема в ОГСЕ. Те же лучи на ТЧ работают нормально:
Кто-нибудь знает как это исправить? Края воллмарков тянутся по поверхности и вылазит вот такая шляпа на динамических объектах.
Работаю на ТЧ, в рендере весьма плохо соображаю.
Цитата(mrmnwar @ 08.01.2017, 17:46)
В ЧН такого нет, проблема в ОГСЕ. Те же лучи на ТЧ работают нормально:
Дык понятно, что нет, а скрины откуда?
Тут недавно у себя заметил, что на 1.6 на дх11 отсутствует динамическое освещение от источников огня (костры, керосинки). Но что примечательно, при переключении на дх10 или 9 - все на своих местах. Не могу понять причину, копался в юзере, решения не нашел. Настройки все на максимуме. Подскажите, где копать.
Если бы не было его и там и там, оно понятно, но не понятно, почему на дх11 нет, а на дх10 есть.
Если бы не было его и там и там, оно понятно, но не понятно, почему на дх11 нет, а на дх10 есть.
Это костер, но динамика вроде есть и там и там, хотя картинка заметно отличается. Но на других источниках вроде лампад динамики на дх11 нет вообще, да и вообще свет не исходит. На дх10 все нормально.
Zagolski, в патчах поломали все фичи ДХ11, кроме тесселяции: https://www.gameru.net/forum/index.php?showtopic=56582
RedPython, а в непропатченой ЗП всё в порядке?
Цитата(Zagolski @ 11.02.2017, 11:04)
Но на других источниках вроде лампад динамики на дх11 нет вообще, да и вообще свет не исходит. На дх10 все нормально.
Да, многое забыли поправить для ДХ11. На данный момент следует сделать такие исправления:
1. В CustomZone.cpp исправить строку:
Код
bool br1 = (0==psDeviceFlags.test(rsR2|rsR3));
так:
Код
bool br1 = (0==psDeviceFlags.test(rsR2|rsR3|rsR4));
2. В Torch.cpp после строки:
Код
b_r2 |= !!psDeviceFlags.test(rsR3)
добавить:
Код
b_r2 |= !!psDeviceFlags.test(rsR4);
3. В ZoneCampfire.cpp изменить в функции CZoneCampfire::turn_on_script() строку:
Код
if( psDeviceFlags.test(rsR2|rsR3) )
на такую:
Код
if( psDeviceFlags.test(rsR2|rsR3|rsR4) )
4. В этом же файле в функции CZoneCampfire::turn_off_script() изменить строку:
Код
if( psDeviceFlags.test(rsR2|rsR3) )
на такую:
Код
if( psDeviceFlags.test(rsR2|rsR3|rsR4) )
По идее что-то, да должно заработать
глупый вопрос - а R4 рендер был с первой версии ЗП или его потом добавили?
mortan, насколько я помню - вроде был. По крайней мере я помню пиар-скриншоты с фичами dx11 (мягкие тени и тесселяция).
Цитата(mortan @ 12.02.2017, 18:14)
глупый вопрос - а R4 рендер был с первой версии ЗП или его потом добавили?
В 1.6.00 уже был r4
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.