Цитата(DRKIP @ 09.11.2020, 22:36) 
Заблокировано.
Подправил.
Полная версия этой страницы: Графика, рендер, шейдеры
Страницы: 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
Подправил.
А кто-нибудь с PBR в жалкере знаком, работал?
Я немного заморочился и кое-каких результатов добился, но до конца дело довести не выходит.
Что сделал - вся требуемая обвязка, карты Roughness-Metalness-AO, освещение от динамических источников света, отражаемость скайбоксов.
Что не осилил - свет от солнца, хеми.
Для солнца по-идее можно использовать свет как от динамики, но блик получается слишком ярким. Можно колхозить с параметрами, но в идеале нужно придумать отдельный алгоритм с расчётом удалённости и размеров солнца.
Хеми - тупо не хватает навыков. Можно использовать подобие стандартных алгоритмов, но не смог оттуда вытащить направление для хеми-света. Без него цвет выглядит хуже а блики и вовсе не рассчитать.
В остальном - всё неплохо. Есть пара функций для обратной совместимости, чтобы не-пбр текстуры конвертились в подобие PBR (рафф из глосса, металличность из материала thm), в отражения можно добавить скринспейс, да и в целом выглядит интересно, но незавершённость не позволяет взять его за основу.
В общем, буду рад любой помощи. Если получится довести дело до конца - выложу подробное описание реализации и нужными исходниками в сеть, чтоб каждый (с доступом к исходникам движка) мог так же себе сделать. Не получится - чёрт с ним, гори оно синим пламенем, т.к. в текущей реализации оно уступает обычному глоссу и для финального качества всё равно не годится, только память выжирает.
Я немного заморочился и кое-каких результатов добился, но до конца дело довести не выходит.
Что сделал - вся требуемая обвязка, карты Roughness-Metalness-AO, освещение от динамических источников света, отражаемость скайбоксов.
Что не осилил - свет от солнца, хеми.
Для солнца по-идее можно использовать свет как от динамики, но блик получается слишком ярким. Можно колхозить с параметрами, но в идеале нужно придумать отдельный алгоритм с расчётом удалённости и размеров солнца.
Хеми - тупо не хватает навыков. Можно использовать подобие стандартных алгоритмов, но не смог оттуда вытащить направление для хеми-света. Без него цвет выглядит хуже а блики и вовсе не рассчитать.
В остальном - всё неплохо. Есть пара функций для обратной совместимости, чтобы не-пбр текстуры конвертились в подобие PBR (рафф из глосса, металличность из материала thm), в отражения можно добавить скринспейс, да и в целом выглядит интересно, но незавершённость не позволяет взять его за основу.
В общем, буду рад любой помощи. Если получится довести дело до конца - выложу подробное описание реализации и нужными исходниками в сеть, чтоб каждый (с доступом к исходникам движка) мог так же себе сделать. Не получится - чёрт с ним, гори оно синим пламенем, т.к. в текущей реализации оно уступает обычному глоссу и для финального качества всё равно не годится, только память выжирает.
Цитата(Lanforse @ 10.11.2020, 13:55)
А кто-нибудь с PBR в жалкере знаком, работал?
Спроси у Skyloader. Он что-то ковырял.
Цитата(Lanforse @ 10.11.2020, 15:55)
Для солнца по-идее можно использовать свет как от динамики, но блик получается слишком ярким.
Меня впринципе яркость блика устраивает (Желтый спекуляр сверху это солнце). Реализация по классике, дирекшин лайт, цвет из погоды. Скрин старый если что.
Да, я на своих скринах цвет не подмешивал. А с хеми что делать, не подскажешь?
Цитата(Lanforse @ 10.11.2020, 22:44)
А с хеми что делать, не подскажешь?
Если под хеми ты имеешь в виду амбиент лайтнинг, то я его делал как стандартный IBL, но умножал на хеми затенение (По факту латмапное AO). Кубмапы юзаю стандартные от текущего скайбокса, ну и юзаю репроецированый с прошлго кадра отраженный бекбуфер. А ну и юзаю АО карты для материалов. Пример (Видно небольшое просвечивание неба в помещении, но это изза достаточно неточного расчета Эмбиентного затенения у динамических объектов. Ну и на масштаб не смотри.
Цитата(Diesel @ 07.08.2020, 21:38)
Нафиг. Искать корни бага смысла нет.
Это не оно случаем? -
Мне помогло, правда у меня на статике не зелёным, а сереневым отдавало.
Нужна помощь в шейдерах, в оригинале используется сложная и устаревшая организация текстур.
_bump# хранящий в себе карту высот в альфа канале и коррекцию ошибок сжатия каты нормалей синего канала _bump.
_bump хранящий в себе спекуляр в R канале и карту нормалей в ABG.
Все это объединяется этим шейдером
чтобы использовать стандартную карту нормалей достаточно изменить одну строчку, вот так
Но это работает только для карты нормалей со всеми каналами
А теперь вопрос, как изменить шейдер чтобы корректно работали карты нормалей содержащие только два канала для осей x и y
Ось z нужно восстановить, только как?
Помогите пожалуйста, так как в шейдерах полный ноль.
Все это нужно для того чтобы перевести игру на использование карты нормалей с сжатием dxt_5nm либо bc5 и хранить в _bump, а в _bump# каналы RGB спекуляр, A канал карта высот. Это позволит добиться максимального качества каждой текстуры, а так же сохранять с меньшим разрешением _bump# если спекуляр простой, либо сохранять в dxt 1 если нет карты высот.
_bump# хранящий в себе карту высот в альфа канале и коррекцию ошибок сжатия каты нормалей синего канала _bump.
_bump хранящий в себе спекуляр в R канале и карту нормалей в ABG.
Все это объединяется этим шейдером
Код
float4 Nu = s_bump.Sample( smp_base, I.tcdh ); // IN: normal.gloss r(s) g(z) b(y) a(x) //r(x) g(y) b(z) a(w)
float4 NuE = s_bumpX.Sample( smp_base, I.tcdh); // IN: normal_error.height r(w) g(x) b(y) a(z)
S.base = tbase(I.tcdh); // IN: rgb.a
S.normal = Nu.wzy + (NuE.xyz - 1.0h); // (Nu.wzyx - .5h) + (E-.5)
S.gloss = Nu.x*Nu.x; // S.gloss = Nu.x*Nu.x;
S.height = NuE.z;
//S.height = 0;
float4 NuE = s_bumpX.Sample( smp_base, I.tcdh); // IN: normal_error.height r(w) g(x) b(y) a(z)
S.base = tbase(I.tcdh); // IN: rgb.a
S.normal = Nu.wzy + (NuE.xyz - 1.0h); // (Nu.wzyx - .5h) + (E-.5)
S.gloss = Nu.x*Nu.x; // S.gloss = Nu.x*Nu.x;
S.height = NuE.z;
//S.height = 0;
чтобы использовать стандартную карту нормалей достаточно изменить одну строчку, вот так
Код
S.normal = Nu.xyz;
Но это работает только для карты нормалей со всеми каналами
А теперь вопрос, как изменить шейдер чтобы корректно работали карты нормалей содержащие только два канала для осей x и y
Ось z нужно восстановить, только как?
Помогите пожалуйста, так как в шейдерах полный ноль.
Все это нужно для того чтобы перевести игру на использование карты нормалей с сжатием dxt_5nm либо bc5 и хранить в _bump, а в _bump# каналы RGB спекуляр, A канал карта высот. Это позволит добиться максимального качества каждой текстуры, а так же сохранять с меньшим разрешением _bump# если спекуляр простой, либо сохранять в dxt 1 если нет карты высот.
gridgt, нужно в фотошопе вычислить разницу каналов x и y и получившуюся разницу (инвертировать если требуется и осветлить на 80-90%) добавить в z.
Именно сейчас сижу и парюсь с такой текстурой и плагин паинт нет с коделабом под сурвариум не помогает - досадно.
Но вообще пока не тестировал результат, но вижу что двигаюсь в нужном направлении.
Имеем вот такую двухканальную текстуру:
Получаем трёхканальную под сталк
Именно сейчас сижу и парюсь с такой текстурой и плагин паинт нет с коделабом под сурвариум не помогает - досадно.
Но вообще пока не тестировал результат, но вижу что двигаюсь в нужном направлении.
Имеем вот такую двухканальную текстуру:
Получаем трёхканальную под сталк
Diesel, Как сделать это в фотошопе я знаю, а вот чтобы игра могла работать напрямую с такими текстурами, нужно изменить шейдеры.
Diesel, Для карт нормалей могу экшеном поделиться.
Diesel, Для карт нормалей могу экшеном поделиться.
Цитата(gridgt @ 15.11.2020, 16:01)
Diesel, Для карт нормалей могу экшеном поделиться.
Поделись. А что это?
Цитата(gridgt @ 15.11.2020, 14:50)
А теперь вопрос, как изменить шейдер чтобы корректно работали карты нормалей содержащие только два канала для осей x и y? Ось z нужно восстановить, только как?
Просто. Использовать алгоритм от iOrange:
xy2xyz.cs (плагин для CodeLab Paint.NET)
Код
// Name: xy2xyz
// Submenu:
// Author: iOrange
// Title:
// Version: 0.1
// Desc:
// Keywords:
// URL:
// Help:
float Clamp(float v, float a, float b)
{
return Math.Min(b, Math.Max(a, v));
}
void Render(Surface dst, Surface src, Rectangle rect)
{
ColorBgra srcPixel, dstPixel = new ColorBgra();
dstPixel.A = 255;
for (int y = rect.Top; y < rect.Bottom; ++y)
{
if (IsCancelRequested) return;
for (int x = rect.Left; x < rect.Right; ++x)
{
srcPixel = src[x, y];
float nx = (float)srcPixel.R / 127.5f - 1.0f;
float ny = (float)srcPixel.G / 127.5f - 1.0f;
float nz = (float)Math.Sqrt(Clamp(1.0f - (nx * nx + ny * ny), 0.0f, 1.0f));
dstPixel.R = srcPixel.R;
dstPixel.G = srcPixel.G;
dstPixel.B = (byte)Clamp(nz * 127.5f + 127.5f, 0.0f, 255.0f);
dst[x, y] = dstPixel;
}
}
}
// Submenu:
// Author: iOrange
// Title:
// Version: 0.1
// Desc:
// Keywords:
// URL:
// Help:
float Clamp(float v, float a, float b)
{
return Math.Min(b, Math.Max(a, v));
}
void Render(Surface dst, Surface src, Rectangle rect)
{
ColorBgra srcPixel, dstPixel = new ColorBgra();
dstPixel.A = 255;
for (int y = rect.Top; y < rect.Bottom; ++y)
{
if (IsCancelRequested) return;
for (int x = rect.Left; x < rect.Right; ++x)
{
srcPixel = src[x, y];
float nx = (float)srcPixel.R / 127.5f - 1.0f;
float ny = (float)srcPixel.G / 127.5f - 1.0f;
float nz = (float)Math.Sqrt(Clamp(1.0f - (nx * nx + ny * ny), 0.0f, 1.0f));
dstPixel.R = srcPixel.R;
dstPixel.G = srcPixel.G;
dstPixel.B = (byte)Clamp(nz * 127.5f + 127.5f, 0.0f, 255.0f);
dst[x, y] = dstPixel;
}
}
}
Сам алгоритм:
Код
float nx = (float)srcPixel.R / 127.5f - 1.0f; // Конвертировать R канал (0...255) в X (-1...+1)
float ny = (float)srcPixel.G / 127.5f - 1.0f; // Конвертировать G канал (0...255) в Y (-1...+1)
float nz = (float)Math.Sqrt(Clamp(1.0f - (nx * nx + ny * ny), 0.0f, 1.0f)); // Расчёт Z
dstPixel.R = srcPixel.R; // Без изменении
dstPixel.G = srcPixel.G; // Без изменении
dstPixel.B = (byte)Clamp(nz * 127.5f + 127.5f, 0.0f, 255.0f); // Конвертировать Z (0...1) в B канал (0...255)
float ny = (float)srcPixel.G / 127.5f - 1.0f; // Конвертировать G канал (0...255) в Y (-1...+1)
float nz = (float)Math.Sqrt(Clamp(1.0f - (nx * nx + ny * ny), 0.0f, 1.0f)); // Расчёт Z
dstPixel.R = srcPixel.R; // Без изменении
dstPixel.G = srcPixel.G; // Без изменении
dstPixel.B = (byte)Clamp(nz * 127.5f + 127.5f, 0.0f, 255.0f); // Конвертировать Z (0...1) в B канал (0...255)
Есть 2 варианта:
1. Можно хранить X в альфа канале, а Y на месте в зелёном канале, так как при сохранении DXT5 (BC3) в зелёном канале практический нет потерь, а альфа канал остается без изменении. Z и Height Map восстанавливать в шейдере из X и Y, а Specular Map на месте в красном канале. Тогда не будет нужды в bump#.
2. Лучше хранить текстуры в формате BC7, тогда не нужен расчёт в шейдерах и bump#. BC7 выигрывает по качеству DXT5 (BC3) при том же размере.
Diesel,
Операция для фотошопа которая конвертирует карту нормалей из сурвариум в обычную.
Операция для фотошопа которая конвертирует карту нормалей из сурвариум в обычную.
для работы необходим плагин Xnormal
xrModder, чтобы сделать нормальную текстуру в паинтнет, нужно сперва привести двухканальную текстуру вот к такому состоянию:
Цитата(Diesel @ 16.11.2020, 10:51)
xrModder, чтобы сделать нормальную текстуру в паинтнет, нужно сперва привести двухканальную текстуру вот к такому состоянию:
Если ты не заметил я специально поправил код iOrange для "стандартных" текстур Normal Map с X в R канале и Y в G канале. В Survarium X находится в альфа канале.
xrModder, зачётно. А я то всё башку ломаю, почему старый скрипт не работает.
Цитата(Diesel @ 16.11.2020, 11:04)
xrModder, зачётно. А я то всё башку ломаю, почему старый скрипт не работает.
Чёт не верится что ты не разбираешься в коде
xrModder, блин, если честно, то лень было напрягать мозги. Я когда анализирую код, то у меня кал сохнет от нагрева мозгов. 
Уже устал код ковырять, кстати вот все что наворотил про ЧН
Весь код альфа, бета, но ни как не релиз. Этот код можно лишь посмотреть и удалить и еще можно отправить в архив, если релизные сорцы потеряются.
Релизные сорцы уже были слиты ранее в других темах.
Надеюсь, что когда нибудь разрешать делать авторские проекты на x-ray, то тогда вернусь еще может быть.
Вчерась оценил оптимизацию Юнити на своём древнем железе, умерло оно от леса 100 на 100 метров. А всё хаим x-ray, да уж.
Но если отключить все навороты рендера в Юнити, то она еще и летает по сравнению с UE4, при примерных картинках.
Уже устал код ковырять, кстати вот все что наворотил про ЧН
Весь код альфа, бета, но ни как не релиз. Этот код можно лишь посмотреть и удалить и еще можно отправить в архив, если релизные сорцы потеряются.
Релизные сорцы уже были слиты ранее в других темах.
Надеюсь, что когда нибудь разрешать делать авторские проекты на x-ray, то тогда вернусь еще может быть.
Вчерась оценил оптимизацию Юнити на своём древнем железе, умерло оно от леса 100 на 100 метров. А всё хаим x-ray, да уж.
Но если отключить все навороты рендера в Юнити, то она еще и летает по сравнению с UE4, при примерных картинках.
Цитата(Lanforse @ 10.11.2020, 15:55)
А кто-нибудь с PBR в жалкере знаком, работал?
Цитата(Lanforse @ 10.11.2020, 15:55)
Не получится - чёрт с ним, гори оно синим пламенем, т.к. в текущей реализации оно уступает обычному глоссу и для финального качества всё равно не годится, только память выжирает.
Работал. Ну типо как он может быть хуже ориг модели освещения при хорошей реализации и правильном контенте. Тем более надо ж умудрится сделать так что и память выжирает, там по факту немного оригинальные строки изменить и пару функций приляпать, тем более что часть физ корректного(ну почти) IBL в сталкере и так есть.
А если ещё немного переделать нормал маппинг и исключить карты ошибок то и дополнительных текстур подгружать не придётся. В итоге одни плюсы, минус только в создании и поиска контента. Так то конечно оптимизаций можно много провести, для ТЧ и других Р2 допустим half оптимизации, BRDF не нужно в рилтайме калькулировать, достаточно просто один раз разработчику запустить локацию с контентом и сделать D3DXSaveTextureToFile, а дальше использовать эту текстуру как 2д семплер для выборки, либо юзать апроксимацию для мобилок, F0 и карты правильно упаковать в деферринг и так далее.
Некоторые пикчи
Ах да, ещё товарищ Хозар поделился довольно интересным способом обойти мип мапы в скайдоме.
Сам лайфак таков:
Ориг строки IBL
Лайфак
Смекаете? Это даже немного гениально. По сути получаем выигрыш в весе текстуры, ибо не нужно генерировать мип мапы.
Сам лайфак таков:
Ориг строки IBL
Код
refl = texCUBElod(s_cubemap,float4(refl_vec,roughness*MAX_REFL_LOD));
Лайфак
Код
refl_vec = lerp(refl_vec,N,roughness);
refl = texCUBE(s_cubemap,refl_vec);
refl = texCUBE(s_cubemap,refl_vec);
Смекаете? Это даже немного гениально. По сути получаем выигрыш в весе текстуры, ибо не нужно генерировать мип мапы.
QUOTE (BD194 @ 03.12.2020, 17:55)
Ах да, ещё товарищ Хозар поделился довольно интересным способом обойти мип мапы в скайдоме.
Сам лайфак таков:
Ориг строки IBL
Лайфак
Смекаете? Это даже немного гениально. По сути получаем выигрыш в весе текстуры, ибо не нужно генерировать мип мапы.
Сам лайфак таков:
Ориг строки IBL
CODE
refl_vec = float4( refl_vec, roughness * MAX_REFL_LOD );
refl = texCUBElod( s_cubemap, refl_vec );
refl = texCUBElod( s_cubemap, refl_vec );
Лайфак
CODE
refl_vec = lerp( refl_vec, N, roughness );
refl = texCUBE( s_cubemap, refl_vec );
refl = texCUBE( s_cubemap, refl_vec );
Смекаете? Это даже немного гениально. По сути получаем выигрыш в весе текстуры, ибо не нужно генерировать мип мапы.
а песку в картинку мы таким способом не натащим (артефактов при удалении от камеры не-мипмапленной текстуры)?
я думаю с нынешними видеоадаптерами, в которых пару гиг видеопамяти - норма жизни, это не так уж критично.
QUOTE (BD194 @ 03.12.2020, 17:33)
BRDF не нужно в рилтайме калькулировать, достаточно просто один раз разработчику запустить локацию с контентом и сделать D3DXSaveTextureToFile, а дальше использовать эту текстуру как 2д семплер для выборки, либо юзать апроксимацию для мобилок
Второй вариант точно мимо, если уж делать оптимизации с ухудшением картинки то проще тогда остаться на р1.
а вот с первым вариантом - можно поподробнее, в плане запекания брдф в текстуры? особенно интересно как это себя поведет при изменении погоды и времени суток. Насколько я знаю запекание освещения в текстуры было в р1, и да, р1 был быстрым, но ценой невозможности изменения положения солнца на небосводе.
Цитата(cjayho @ 07.12.2020, 11:03)
Насколько я знаю запекание освещения в текстуры было в р1
Странно, что ты забыл про это же в р2. Только там не запекается прямой свет от солнца и других динамических светильников. Остальное печётся, в полный рост.Цитата(cjayho @ 07.12.2020, 13:03)
особенно интересно как это себя поведет при изменении погоды и времени суток.
Останется как есть, на расчёт брдф используются другие параметры(шероховатость материала и произведение NdotV).
Цитата(cjayho @ 07.12.2020, 13:03)
Второй вариант точно мимо
Я бы так не спешил, тестировали все три варианта, все выдают хороший результат.
Цитата(cjayho @ 07.12.2020, 13:03)
я думаю с нынешними видеоадаптерами, в которых пару гиг видеопамяти
Для меня лайфхак подходит, ибо компуктер не огонь.
sergy172, На р2 из запечёного используется только индирект осещение и материал буфер для сан статика.
Цитата(cjayho @ 07.12.2020, 10:03)
а песку в картинку мы таким способом не натащим
Ой и натащим, способ не из новых. Дык еще и возможны мерцания на Сталкере.
Цитата(BD194 @ 07.12.2020, 11:17)
На р2 из запечёного используется только индирект осещение
А его мало что ли? Это и эмбиент оклюжен с рассеянной светотенью под козырьками крышь, подоконников и помещений, и имитация переотражения от солнца, как и на р1, добавлением источника, принимающего его цвет и яркость.
Цитата(BD194 @ 03.12.2020, 18:33)
Ну типо как он может быть хуже ориг модели освещения при хорошей реализации и правильном контенте. Тем более надо ж умудрится сделать так что и память выжирает, там по факту немного оригинальные строки изменить и пару функций приляпать, тем более что часть физ корректного(ну почти) IBL в сталкере и так есть.
Хорошо так говорить, когда уже всё знаешь и заведение PBR для тебя дело "в пару строк". А когда часами долбишься головой об стену, почему у скайбоксов мип-уровни не считываются, а дело оказывается в приписке _clf к сэмплеру - это совсем другое. Я не строю из себя эксперта, с графикой мне пару лет назад пришлось начать работать фактически с нуля, без каких-либо базовых знаний и представлений, как оно вообще функционирует. Не сказать, что я особо далеко продвинулся, но хотя б уже чуть дальше портирования готовых шейдеров от sweetfx. Потому да, приляпать PBR, чтоб выглядел не хуже стандартного рендера - лично для меня очень серьёзная задача. А по поводу "выжирания памяти" - я пошёл по пути подключения новой 4х-канальной текстуры, а не перетасовки старых в попытках впихнуть карты АО и Metalness.
В принципе, пока что-то, но всё же получается. Для базовых текстур, если не подключена pbr-карта, для раффа используется обратная глосса, а для металличности - значение xmaterial.
Есть проблема с разделением текстур на PBR и не-PBR. По-хорошему для этого нужен новый флаг в .thm, но для этого придётся править если не SDK, то сторонний thm-редактор. На данный момент использую флаг параллакса.
Есть проблема со скайбоксами, большая часть мне доступных использует рисованный горизонт, который даже на последнем, 10 мип-уровне отчётливо виден даже на 10% интенсивности отражения.
Ну и, наконец, остаются проблемы с хеми. IBL предполагает использование готовых карт окружения, да ещё и в HDR, а у меня в распоряжении только скайбоксы и смоллскаи. В итоге материалы в тени остаются совершенно матовыми, как правильно им считать спекуляр - не понимаю, использую костыли.
Я то прекрасно понимаю, что взялся за то, в чём практически не разбираюсь. Но ничего не делать и ждать, пока кто-то это сделает за тебя - тоже такой себе вариант.
А ещё большое спасибо Hozar_2002 за подсказку с бликом. Вроде такая банальщина - цвет солнца подмешивать, а упустил. В оригинальной ПЫСовской lmodel.h в plight_infinity() цвет солнца тоже не добавлялся, что интересно.
А никто не фиксил отрисовку воды в тумане? Чернеет.
Цитата(RayTwitty @ 25.12.2020, 01:25)
А никто не фиксил отрисовку воды в тумане? Чернеет.
SkyLoader фиксил. Поищи тут:
Xottab_DUTY, судя по всему это
RayTwitty, да, оно!
Xottab_DUTY, а освещение воллмарков (фонариком и дин.лампами) на р1 никто не фиксил случаем?)
Вот тут о проблеме более подробно: https://www.gameru.net/forum/index.php?s=&a...t&p=1577870
Вот тут о проблеме более подробно: https://www.gameru.net/forum/index.php?s=&a...t&p=1577870
RayTwitty, насчёт воллмарков не припомню, но вот такое было:
Xottab_DUTY, там насколько я понимаю р1 фиксы:
1) травы в тумане
2) рендер детейл текстур на дин. объектах
3) освещение детейл текстур фонариком и лампами
На последние два момента кстати внимания никогда не обращал, надо проверить действительно ли так в ТЧ.
А по воллмаркам ничего больше нет.
1) травы в тумане
2) рендер детейл текстур на дин. объектах
3) освещение детейл текстур фонариком и лампами
На последние два момента кстати внимания никогда не обращал, надо проверить действительно ли так в ТЧ.
А по воллмаркам ничего больше нет.
Цитата(RayTwitty @ 24.12.2020, 23:25)
А никто не фиксил отрисовку воды в тумане? Чернеет.
Я для ТЧ воду и т.д. давно фиксил, всё должно быть в Y0006. Стучите в личку, если что.
Цитата(macron @ 25.12.2020, 00:32)
Цитата(RayTwitty @ 24.12.2020, 23:25)
А никто не фиксил отрисовку воды в тумане? Чернеет.
Я для ТЧ воду и т.д. давно фиксил, всё должно быть в Y0006. Стучите в личку, если что.
Да у Скайлоадера вроде есть фикс, на прошлой странице я кидал коммит. Потом проверю. Вообще, у меня в шейдерах уже 100500 фиксов и большинство из них касаются именно тумана и воды, как-будто они самые кривые в графике столкира
А по воллмаркам, если что, могу видео записать о проблеме.
Цитата(RayTwitty @ 25.12.2020, 23:52)
100500 фиксов и большинство из них касаются именно тумана и воды, как-будто они самые кривые в графике столкира
Это проблема рендеринга полупрозрачных объектов (вода, стекла и т.д.), не только в сталкере. В современных движках с этим более-менее порядок.
А освещение партиклов и т.п сейчас исправили? Типа дыма/тумана который ночью видно с любого расстояния
dPlayer, такие же полупрозрачные элементы как стекла и вода. На отложенном рендере что-то сделать весьма трудоемко по ФПС. У КД получилось только фонарем сделать освещение стекол в ОГСЕ.
Высказывание из разряда риторических.
Зачем использовать отложенный рендер, чья главная фишка по заверениям ПЫС в ненапряжном размещении в кадре большого количества динамического света, если в игре концептуально его исчезающе мало.
Смысл врать, имеется, только если это выгодно, а когда враньё вызвано какими то не очевидными причинами, то оно всегда выглядит странно и нелепо.
У них же большая часть ответов на вопросы сообщества, состояло из подобного.
п.с. Я не про озвучиваемые планы или обещания, а именно про подобное странное враньё, которого у ПЫСов было уж как то с перебором. И не только у них кстати. Единственная логичная причина, приходящая в голову, это попытка увести внимание от какой либо неудобной темы.
Зачем использовать отложенный рендер, чья главная фишка по заверениям ПЫС в ненапряжном размещении в кадре большого количества динамического света, если в игре концептуально его исчезающе мало.
Смысл врать, имеется, только если это выгодно, а когда враньё вызвано какими то не очевидными причинами, то оно всегда выглядит странно и нелепо.
У них же большая часть ответов на вопросы сообщества, состояло из подобного.
п.с. Я не про озвучиваемые планы или обещания, а именно про подобное странное враньё, которого у ПЫСов было уж как то с перебором. И не только у них кстати. Единственная логичная причина, приходящая в голову, это попытка увести внимание от какой либо неудобной темы.
Шейдерная раскачка флагов.
QUOTE (sergy172 @ 27.12.2020, 00:26)
Высказывание из разряда риторических.
Зачем использовать отложенный рендер, чья главная фишка по заверениям ПЫС в ненапряжном размещении в кадре большого количества динамического света, если в игре концептуально его исчезающе мало.
Смысл врать, имеется, только если это выгодно, а когда враньё вызвано какими то не очевидными причинами, то оно всегда выглядит странно и нелепо.
У них же большая часть ответов на вопросы сообщества, состояло из подобного.
п.с. Я не про озвучиваемые планы или обещания, а именно про подобное странное враньё, которого у ПЫСов было уж как то с перебором. И не только у них кстати. Единственная логичная причина, приходящая в голову, это попытка увести внимание от какой либо неудобной темы.
Зачем использовать отложенный рендер, чья главная фишка по заверениям ПЫС в ненапряжном размещении в кадре большого количества динамического света, если в игре концептуально его исчезающе мало.
Смысл врать, имеется, только если это выгодно, а когда враньё вызвано какими то не очевидными причинами, то оно всегда выглядит странно и нелепо.
У них же большая часть ответов на вопросы сообщества, состояло из подобного.
п.с. Я не про озвучиваемые планы или обещания, а именно про подобное странное враньё, которого у ПЫСов было уж как то с перебором. И не только у них кстати. Единственная логичная причина, приходящая в голову, это попытка увести внимание от какой либо неудобной темы.
А чего там думать, Шишковцов еще давно в игроманиевских роликах говорил что они планируют первыми выпустить игру с отложенным шейдингом под компы. То есть основная задача была не технической а сбором медалек.
Цитата(sergy172 @ 27.12.2020, 03:26)
Высказывание из разряда риторических.
Зачем использовать отложенный рендер, чья главная фишка по заверениям ПЫС в ненапряжном размещении в кадре большого количества динамического света, если в игре концептуально его исчезающе мало.
Зачем использовать отложенный рендер, чья главная фишка по заверениям ПЫС в ненапряжном размещении в кадре большого количества динамического света, если в игре концептуально его исчезающе мало.
Источники освещения: артефакты, аномалии (в зависимости от конфигурации могут светить постоянно), лампочки/прожектора/фары, вспышки от выстрелов. К финалке стало меньше явных источников света, но технология была явно с потанцевалом. Так что в движок оно заложено, но потанцевал не раскрыт - как оно с A-Life, транспортом и прочим.
Думаю, за счёт отложенного рендера, у сталкера и есть такое честное освещение, за которое до сих пор хвалят. Battlefied 1 и Fallout 4 неврно курят в сторонке со своими прожекторами, которые просвечивают сквозь геометрию и оставляют пятно света без каких либо теней.
Цитата(RayTwitty @ 25.12.2020, 21:52)
Да у Скайлоадера вроде есть фикс, на прошлой странице я кидал коммит. Потом проверю.
Проверил - работает отлично. Я только не понял, зачем в water.vs (и кстати это единственное изменение в вертексном шейдере)
Код
o.c0 = float4 (L_final,o.fog);
заменено на
Код
o.c0 = float4 (L_final,1);
по идее, у ПЫС было правильно? По крайней мере, в игре это не влияет визуально ни на что (или я не заметил).
QUOTE (RayTwitty @ 03.01.2021, 01:23)
QUOTE (RayTwitty @ 25.12.2020, 21:52)
Да у Скайлоадера вроде есть фикс, на прошлой странице я кидал коммит. Потом проверю.
Проверил - работает отлично. Я только не понял, зачем в water.vs (и кстати это единственное изменение в вертексном шейдере)
CODE
o.c0 = float4 (L_final,o.fog);
заменено на
CODE
o.c0 = float4 (L_final,1);
по идее, у ПЫС было правильно? По крайней мере, в игре это не влияет визуально ни на что (или я не заметил).
Странный какойто фикс. Может все же не 1 а 1-o.fog?
cjayho, полный diff (с убранными изменениями пробельных символов):
QUOTE (RayTwitty @ 03.01.2021, 01:45)
cjayho, полный diff (с убранными изменениями пробельных символов):
Та я понял, просто странная логика у фикса. Если до правки непрозрачность увеличивалась с дальностью при тумане, то сейчас она всегда максимальная. Вот я и предположил что может всетаки непрозрачность должна убывать с дальностью при тумане?
Альфа от c0 не используется в данном случае, так как финальная альфа рассчитывается в пиксельном шейдере и юзает I.fog. Единицу поставил, чтобы никто не путался, думая, что оно используется.
Продолжение экспериментов с "Liberty City", безлайтмапными технологиями и шейдерами:
Update 04.01.2021
-упрощена установка, отключена поддержка ЧН
-больше псевдобампоблеска
-правки геометрии
-флаги раскачиваются
libertycity_soc_build_04_01_2021 для ТЧ:
Update 04.01.2021
-упрощена установка, отключена поддержка ЧН
-больше псевдобампоблеска
-правки геометрии
-флаги раскачиваются
libertycity_soc_build_04_01_2021 для ТЧ:
Кстати в ТЧ вроде бы такой проблемы нет. По крайней мере воллмарки в аутдоре нормально смешиваются с туманом, да и в wmark.vs o.fog не равен константе 1, как зачем-то в ЗП.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.