Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Графика, рендер, шейдеры
GAMEINATOR forums > S.T.A.L.K.E.R. > Мастерская: создание модов для S.T.A.L.K.E.R.
Страницы: 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
iOrange
Цитата(BD194 @ 03.12.2019, 18:05) *
А вы бараньей упрямостью прёте дальше, даже после того что я писал относительно недавно:

Все что вы писали я вам чуть ли не побуквенно ответил. Ничего внятного от вас не последовало, толко новые наборы рандомных слов.

> и именно для этого я запускал ртшник для блюра чтобы скрыть и отвести взгляд игрока от них
Простите, что вы запускали? При чем здесь блюр при обсуждении SSLR?
Zagolski
Цитата(iOrange @ 05.12.2019, 05:36) *
С какими флагами Map/Unmap делался? С Discard будет отдан новый буффер, никакой синхронизации не будет.

Да, флаг D3D11_MAP_WRITE_DISCARD.
Если взять к примеру структуризированный буфер с кол-вом элементов этак в 250 000, то в итоге с Map/Unmap получим 100% синк и заметное падение фпс. UpdateSubresource в этом случае четко отрабатывает, проблем нет, хоть и поболее грузит GPU. Но в целом для ординарных случаев я за Map/Unmap.

Цитата(-StalkMen- @ 04.12.2019, 17:18) *
Win 10, GTX 1050ti. А какой у тебя конфиг? Мб от видеокарты зависит.

GTX 660. А проц i7-2600K до 4.5 ГГц разогнанный.
Скорее всего у тебя просто в проц не упирается, поэтому и разницы нет. Нужна сцена, где в проц упирается. Такую можно обнаружить по неполной загрузке GPU. Хотя на чисто ванильном R4 куча QUERY_OCCLUSION на лайтах и вдобавок QUERY_EVENT на каждом кадре от инпут лага, поэтому такую сцену непросто будет найти.
В void CRender::Render() почти в самом начале есть такой кусок кода:
Код
    if (1)
    {
        CTimer    T;                            T.Start    ();
        BOOL    result                        = FALSE;
        HRESULT    hr                            = S_FALSE;
        //while    ((hr=q_sync_point[q_sync_count]->GetData    (&result,sizeof(result),D3DGETDATA_FLUSH))==S_FALSE) {
        while    ((hr=GetData (q_sync_point[q_sync_count], &result,sizeof(result)))==S_FALSE)
        {
            if (!SwitchToThread())            Sleep(ps_r2_wait_sleep);
            if (T.GetElapsed_ms() > 500)    {
                result    = FALSE;
                break;
            }
        }
    }

Вот его закомментируй, и желательно, чтоб при тестировании в игре в сцене источников света не было (солнце не учитываем). А в настройках максимум дальность и детализации включи, это сильно на загрузку CPU влияет.
eagleivg
Цитата(iOrange @ 05.12.2019, 05:39) *
Простите, что вы запускали? При чем здесь блюр при обсуждении SSLR?

Блин, я извиняюсь что влезаю, но ты исходник-то смотрел? Такое имя файла как gauss5.ps тебе что-нибудь говорит?
RayTwitty
Цитата(iOrange @ 05.12.2019, 05:39) *
При чем здесь блюр при обсуждении SSLR?

Я думаю он имел ввиду, что отражения блюрятся так, чтобы мелких косяков заметно не было biggrin.gif По крайней мере, то что показывали выше в видео по лужам меня совершенно не смутило - выглядит классно, может где-то что-то и косячит, но с вероятностью 99% игрок этого не заметит. Я вообще поражен, в ходе выпуска различных модов, насколько игроку похеру на некоторые вещи. Иной раз, нужно просто дизаблить управление и тыкать его туда, что хочешь чтобы он увидел biggrin.gif

За исключением конечно ваномасов - они будут в бинокль рассматривать каждый пиксель.
iOrange
Цитата(Zagolski @ 05.12.2019, 08:17) *
с Map/Unmap получим 100% синк

Он не так работает, с дискардом синк не будет, ибо драйвер видя Discard бросает текущий буфер и дает из пула тебе новый, и помечает себе сделать свап на следующем sync point.

Цитата(Zagolski @ 05.12.2019, 08:17) *
UpdateSubresource в этом случае четко отрабатывает, проблем нет, хоть и поболее грузит GPU

А метрики точны? UpdateSubresource должен больше грузить CPU, ибо он выполняет дополнительную работу.

Рекомендую почитать советы IHV - https://developer.nvidia.com/sites/default/...nt_McDonald.pdf
iOrange
Цитата(eagleivg @ 05.12.2019, 10:16) *
Блин, я извиняюсь что влезаю, но ты исходник-то смотрел? Такое имя файла как gauss5.ps тебе что-нибудь говорит?

Так себе влез, блюо здесь не обсуждается от слова совсем, его вкинул автор для отвода темы от основного вопроса.

Я же среагировал на фразу которую даже выделил жирным - запускал ртшник для блюра
Меня заинтересовало что такое ртшник, не более.
Zagolski
Цитата(iOrange @ 05.12.2019, 17:22) *
А метрики точны? UpdateSubresource должен больше грузить CPU, ибо он выполняет дополнительную работу.

В параллельном потоке, возможно. Он все же асинхронный. Главное то, что в сталке он малость снимает нагрузку на CPU на вызовах отрисовки. Я только это замерял. А на них как раз основной затык и часто в проц упирается, когда геометрии много. К тому же в сталке 4-х ядерный проц максимум на 2 ядра грузится, половина простаивает.

Цитата(iOrange @ 05.12.2019, 17:28) *
Меня заинтересовало что такое ртшник, не более.

Наверное, он имел в виду рендер-таргет, тут в движке они как rt помечаются.

Цитата(RayTwitty @ 05.12.2019, 16:13) *
По крайней мере, то что показывали выше в видео по лужам меня совершенно не смутило - выглядит классно, может где-то что-то и косячит, но с вероятностью 99% игрок этого не заметит.

Внимательный игрок, которому картинка небезразлична, всегда заметит подвох. smile.gif
iOrange
Цитата(Zagolski @ 05.12.2019, 18:31) *
Он все же асинхронный.

Ну так же как и Map/Unmap. Примерно так они работают:

С UpdateSubresource:
- Драйвер выделит в сторонке память, скопирует твою дату в эту память.
- Засунет команду на копирование памяти в command buffer
- Вставит барьер на доступ к ресурсу, чтоб дождаться если его юзают
- После барьера GPU скопирует дату в ресурс

C Map/Unmap (+ discard):
- Драйвер выделит в сторонке память, отдаст тебе указатель
- Ты скопируешь туда свою дату
- После Unmap драйвер поставет команду на копирование памяти в command buffer
- Вставит барьер на доступ к ресурсу, чтоб дождаться если его юзают
- После барьера GPU скопирует дату в ресурс

В твоем случае небольшое ускорение могло быть вызвано более грамотным копированием, реализованным в драйвере.
Я использую Streamed SIMD memory copying, и у меня разницы в целом в скорости не было между обоими, но я все же предпочитаю следовать советам IHV, ибо в будущих драйверах все может измениться.
BD194
Цитата(iOrange @ 05.12.2019, 19:28) *
его вкинул автор для отвода темы от основного вопроса

Я вкинул это к тому, что отражения блюрятся в итоге, это легче чем полностью их считать.
А у вас понимания нет "от слова совсем". Вы лишь пытаетесь казаться каким-то профи, но в моих глазах у вас это не получается.

И какой это основной вопрос такой? Я от вас слышу только непонятное бурчание про пересечение луча. Посему сочту вас за невменяемого и впредь не буду делать таких ошибок, как ответ вам. Всего хорошего)
iOrange
Цитата(BD194 @ 06.12.2019, 18:24) *
А у вас понимания нет "от слова совсем". Вы лишь пытаетесь казаться каким-то профи, но в моих глазах у вас это не получается.

Мне глубоко все равно что там у вас в глазах. Я вам по пунктам расписал почему "ваш" "алгоритм" не работает не будет работать и теоретически не может работать. Все эти пассажи про блур и прочее - непонятно зачем было вписано, об этом даже не спрашивалось.

Но да ладно, подозреваю что что такое SSLR вы слабо понимаете, нагуглили статью на Хабре, скопировали код, получилось плохо, но отстаиваете это копипасту как родную. Бывает.

И тут мы подходим к основному:

Цитата(BD194 @ 06.12.2019, 18:24) *
И какой это основной вопрос такой?

Если отмотать целиком назад, то это был не вопрос а утверждение - на видео не SSR. Я готов на это деньги поставить.

Основные места обведены красным, слева на право:

Вид этого отражения столба и его положения относительно задника говорит нам о том что использовался другой ракурс - а именно - перевернутая камера относительно воды.

Бетонная хрень по средине - тот "алгоритм" который вы тыкали мне - не сможет даже в ужасный SSR, не говоря уже о том что здесь черезчур много деталей для него, и - обратите внимание - опять таки из-за другой камеры получилось "заглянуть" снизу и увидеть забор между "ногами" постройки.

Столб справа - опять же - другая камера + отсутствующая тень на заборе (сверху она есть).

Попробуйте мне доказать что это SSR.

Xottab_DUTY
Тут isobolevskiy провёл тест Map/Unmap и UpdateSubresource:

UpdateSubresource:


Map/Unmap:

Zagolski
Тут вчера вернулся к отложенному рендеру, довел до ума упаковку сталкерского g-buffer на R4. Итого пакуем все в две DXGI_FORMAT_R8G8B8A8_UNORM и получаем хороший профит. Всего 64 бита, лучше вряд ли сделать. В ваниле была упаковка в 160 бит на R2 и в 96 бит на R4.
Глубину тащим из буфера глубины и восстанавливаем из нее позицию вида через обратную матрицу проекции. Можно другим способом, хотя ванильный вариант восстановления позиции из линейной глубины (через параметры экрана) оказался малость косячным, не совсем корректно восстанавливает...

Вот рецепт:

В первую DXGI_FORMAT_R8G8B8A8_UNORM пишем в три канала диффуз и в альфа-канал хеми. Во вторую пишем в два канала кодированную нормаль, в третий канал материал и в альфа-канал спекуляр. Важно делать именно так, тогда при освещении лайтами будет читаться только одна текстура со всеми необходимыми для освещения данными (в ваниле спекуляр писался вместе с диффузом).

Изюминка всего - упаковка нормали в сферические координаты. Пакует качественно, хоть и расходует чуть больше ALU (на современных GPU это почти бесплатно). В игре проверено, все четко и все летает.

Паковка нормали (при записи дополнительно переводим в диапазон 0..1, а при извлечении из g-buffer обратно в -1..1).
Код
float2 PackNormal(float3 N)
{
    float2 res;
    res.x = atan2(N.y, N.x) / 3.14159f;
    res.y = N.z;
    return res;
}
float3 UnpackNormal(float2 res)
{
    float2 theta;
    sincos(res.x * 3.14159f, theta.x, theta.y);
    float2 phi = float2(sqrt(1.0 - res.y * res.y), res.y);
    return float3(theta.y * phi.x, theta.x * phi.x, phi.y);
}


Ф-ция восстановления позиции:
Код
float3 GetPositionView(float2 tc, float zdepth)
{
    float4 P = 1.f;
    P.x = tc.x * 2.f - 1.f;
    P.y = -(tc.y * 2.f - 1.f);
    P.z = zdepth;
    P = mul(m_invP, P);
    return P.xyz / P.w;
}


Обратную матрицу проекции создаем в биндере так:
Код
class cl_inv_p    : public R_constant_setup {
    Fmatrix        result;
    virtual void setup    (R_constant* C)    {
        D3DXMatrixInverse((D3DXMATRIX*)&result, 0, (D3DXMATRIX*)&RCache.xforms.m_p);
        RCache.set_c    (C, result);
    }
};    static cl_inv_p        binder_inv_p;

r_Constant                ("m_invP",                &binder_inv_p);


И еще. Поскольку мы будем читать из буфера глубины, а он у нас часто установлен активным для трафарета, то нужно создать еще один DepthStencilView с флагом D3D11_DSV_READ_ONLY_DEPTH | D3D11_DSV_READ_ONLY_STENCIL с привязкой к базовому ZB ShaderResourceView, и на фазе combine_1 и при освещении лайтами устанавливать активным его (тогда мы сможем читать из него глубину, даже когда он активный, но при этом будет отключена запись).
macron
Недавно опять правил GTA-шную мапу, плюс адаптировал под ТЧ. Кому нравится графоний - качайте. laugh.gif

https://cloud.mail.ru/public/45Qj/4XZerf7AX

Картинки из ТЧ:












RayTwitty
Цитата(macron @ 13.12.2019, 23:11) *
Недавно опять правил GTA-шную мапу, плюс адаптировал под ТЧ. Кому нравится графоний - качайте. laugh.gif


totstalkir.gif
cjayho
iOrange, Zagolski, вот читаю вас и думаю где вы все были году эдак в 2010-м?

QUOTE (macron @ 13.12.2019, 22:11) *
Недавно опять правил GTA-шную мапу, плюс адаптировал под ТЧ. Кому нравится графоний - качайте. laugh.gif


Shadow of San Andreas kozak.gif
iOrange
Цитата(cjayho @ 15.12.2019, 23:50) *
iOrange, Zagolski, вот читаю вас и думаю где вы все были году эдак в 2010-м?

А что было в 2010-м ?
RayTwitty
Цитата(macron @ 13.12.2019, 23:11) *
GTA-шную мапу

Есть несколько пожеланий biggrin.gif :
1) Заменить везде шейдер def_trans_v на def_aref, у меня почему-то эти меши светятся. Заменил через распаковщик, стало намного лучше.
2) Наложить фейковую плоскость на прыжки: https://gta.ag.ru/lib/stunts
у меня не получается прыгать на машине! laugh.gif
3) Убрать нафиг траву (детейлы). Убрал сам, стало лучше.
4) Может какое-то дно простенькое замоделить, чтобы машина не улетала в бездну (ГГ кстати ходит нормально).
5) sound-env эхо в туннели и возможно усиление (гул) на мосты.
6) Дальнейшее улучшения: сделать столбы дестрой-объектами (как стекла, но с одним полигоном, чтобы можно было сбивать), стекла сделать разбиваемыми (там где можно реально проехать сквозь), освещение в индоре и т.д.

З.Ы. Дальность прорисовки/тумана у меня 2 км (на скринах выше). Больше/меньше имхо не надо, в целом похоже на вариант из ГТА4.
macron
Цитата(RayTwitty @ 16.12.2019, 01:01) *
1) Заменить везде шейдер def_trans_v на def_aref, у меня почему-то эти меши светятся.
У меня светились только люки на асфальте, очень чувствительны к параметрам hemi в погодных конфигах.

Цитата(RayTwitty @ 16.12.2019, 01:01) *
5) sound-env эхо в туннели и возможно усиление (гул) на мосты.
Вот этим творчеством со звуком точно сам занимайся. Снимай координаты, потом в sdk на любой/пустой мапе или в конвенторе ставь нужные зоны/источники.

Цитата(RayTwitty @ 16.12.2019, 01:01) *
3) Убрать нафиг траву (детейлы). Убрал сам, стало лучше.
Да, трава глючная и не в тему. В порядке бреда есть идея придумать скриптовой шейдер (или бамп). Чтоб из имеющейся текстуры зеленого газона каждый второй пиксель вытягивал вверх, чтобы получилось по типу щетки. Это так, просто идея, возможно не реализуемая в принципе.
macron
Цитата(RayTwitty @ 16.12.2019, 01:01) *
4) Может какое-то дно простенькое замоделить, чтобы машина не улетала в бездну (ГГ кстати ходит нормально).

Там обычный фейк. Может ты кривой gamemtl.xr или кривые тачки подсовывал? У меня машинки нормально по дну ездят, и нива, и камаз. Вот можешь проверить еще вариант с песком:

https://yadi.sk/d/JJNZ7KhNs5bGUA
RayTwitty
Цитата(macron @ 16.12.2019, 02:23) *
Может ты кривой gamemtl.xr или кривые тачки подсовывал? У меня машинки нормально по дну ездят, и нива, и камаз.

Не, материалы и машины точно нормальные. Ты попробуй из машины выйти - она провалится. Если актор внутри, то ездит.

З.Ы. еще к тем пунктам - надо бы no-sun меши вокруг тоннелей.
macron
Цитата(RayTwitty @ 16.12.2019, 02:49) *
Ты попробуй из машины выйти - она провалится. Если актор внутри, то ездит.

А, но с песком вроде нормально.

Цитата(RayTwitty @ 16.12.2019, 02:49) *
еще к тем пунктам - надо бы no-sun меши вокруг тоннелей.

Ну да...
atanda
Цитата(iOrange @ 16.12.2019, 00:52) *
А что было в 2010-м ?

Можешь листануть выше по теме и, о боже, окажется здесь шейдеры Сталкера копали, а должных спецов тогда, к сожалению, не было=)
cjayho
QUOTE (iOrange @ 15.12.2019, 23:52) *
QUOTE (cjayho @ 15.12.2019, 23:50) *
iOrange, Zagolski, вот читаю вас и думаю где вы все были году эдак в 2010-м?

А что было в 2010-м ?


редкие мододелы (и я в том числе) буквально наощупь разбирались в потрохах закрытого тогда еще двигла.
Когда это было еще актуально, а не так как сейчас, ковыряние давно устаревшего двигла давно забытой игры.

QUOTE (macron @ 16.12.2019, 00:57) *
В порядке бреда есть идея придумать скриптовой шейдер (или бамп). Чтоб из имеющейся текстуры зеленого газона каждый второй пиксель вытягивал вверх, чтобы получилось по типу щетки. Это так, просто идея, возможно не реализуемая в принципе.


там координаты во float (число с плавающей запятой), где ты инфу о пикселях возьмешь?
И каждый второй пиксель это слишком густо имхо.

четверть травинки на квадратный пиксель biggrin.gif
macron
Цитата(cjayho @ 16.12.2019, 10:39) *
там координаты во float (число с плавающей запятой), где ты инфу о пикселях возьмешь?
И каждый второй пиксель это слишком густо имхо.

Ok, тогда будем вытягивать через бамп. Кто бампы рисовать умеет, можете приступать. cool.gif
Fizzed
Hello.

I'm trying to make a new shader for weapon (env reflections like in old builds). R2 renderer.

I copied deffer_base_bump.vs, and deffer_model_bump.ps. + I've did a new .s shader.
Everything works just great, except bumpmaps.. I don't know what could be wrong, i didn't edited any "deffer_xxx" shader yet.






Здравствуйте.

Я пытаюсь сделать новый шейдер для оружия (отражения env как в старых билдах). R2 рендерер.
Я скопировал deffer_base_bump.vs и deffer_model_bump.ps. + Я сделал новый шейдер (.s).

Все работает просто замечательно, кроме bumpmaps ... Я не знаю, что может быть не так, я еще не редактировал шейдеры "deffer_xxx".
cjayho
QUOTE (Fizzed @ 16.12.2019, 19:22) *
Hello.

I'm trying to make a new shader for weapon (env reflections like in old builds). R2 renderer.

I copied deffer_base_bump.vs, and deffer_model_bump.ps. + I've did a new .s shader.
Everything works just great, except bumpmaps.. I don't know what could be wrong, i didn't edited any "deffer_xxx" shader yet.


Show me your shader code please.
I think bump texture is stretched because wrong coordinates
Zagolski
Цитата(Fizzed @ 16.12.2019, 20:22) *
Я скопировал deffer_base_bump.vs и deffer_model_bump.ps. + Я сделал новый шейдер (.s).

На .s файлах не будет работать бамп, он там не поддерживается. Только основная текстура и детальная. Нужно переделывать в ResourceManager_Scripting.cpp класс CResourceManager::_lua_Create, добавлять поддержку бампа.
Fizzed
Цитата(cjayho @ 18.12.2019, 11:41) *
Цитата(Fizzed @ 16.12.2019, 19:22) *
Hello.

I'm trying to make a new shader for weapon (env reflections like in old builds). R2 renderer.

I copied deffer_base_bump.vs, and deffer_model_bump.ps. + I've did a new .s shader.
Everything works just great, except bumpmaps.. I don't know what could be wrong, i didn't edited any "deffer_xxx" shader yet.


Show me your shader code please.
I think bump texture is stretched because wrong coordinates



Here's shaders
https://drive.google.com/open?id=1HT-VdbwtC...TGeAXfkqAN3yUWl
cjayho
QUOTE (Fizzed @ 19.12.2019, 04:38) *
QUOTE (cjayho @ 18.12.2019, 11:41) *
QUOTE (Fizzed @ 16.12.2019, 19:22) *
Hello.

I'm trying to make a new shader for weapon (env reflections like in old builds). R2 renderer.

I copied deffer_base_bump.vs, and deffer_model_bump.ps. + I've did a new .s shader.
Everything works just great, except bumpmaps.. I don't know what could be wrong, i didn't edited any "deffer_xxx" shader yet.


Show me your shader code please.
I think bump texture is stretched because wrong coordinates



Here's shaders
https://drive.google.com/open?id=1HT-VdbwtC...TGeAXfkqAN3yUWl


I think Zagolski is right, nothing wrong with your shaders

QUOTE (Zagolski)
S-files do not support bump, only main and detail textures. To add support into the .s files we need to rewrite class CResourceManager::_lua_Create in file ResourceManager_Scripting.cpp
Fizzed
So it's time to learn how to do this biggrin.gif

Thanks for help guys!
Yara
Для тех, кто правит двиг (улучшает тч / статику и т.п.):

связано с маской террейна, и на каком рендере она работает (60 строка)
тч - \xr_3da\xrRender\Blender_BmmD.cpp
зп - \Layers\xrRender\Blender_BmmD.cpp

а также возможность заставить компиль тч учитывать сглаживание, назначенное в 3д редакторе,
\xrLC\communicate.h, там параметр m_sm_angle установлен как 75 и используется в \xrLC\xrCalcNormals.cpp, CalcNormals() и кода там поболее чем в зп-варианте. Ещё встречается в \xrLC\xrMU_Model_Calc_normals.cpp, но там заремили, и уже используется значение 89.
xrModder
Цитата(Yara @ 30.12.2019, 08:33) *
Для тех, кто правит двиг (улучшает тч / статику и т.п.):

связано с маской террейна, и на каком рендере она работает (60 строка)
тч - \xr_3da\xrRender\Blender_BmmD.cpp
зп - \Layers\xrRender\Blender_BmmD.cpp

а также возможность заставить компиль тч учитывать сглаживание, назначенное в 3д редакторе,
\xrLC\communicate.h, там параметр m_sm_angle установлен как 75 и используется в \xrLC\xrCalcNormals.cpp, CalcNormals() и кода там поболее чем в зп-варианте. Ещё встречается в \xrLC\xrMU_Model_Calc_normals.cpp, но там заремили, и уже используется значение 89.

Что?
abramcumner
Цитата(Yara @ 30.12.2019, 05:33) *
а также возможность заставить компиль тч учитывать сглаживание, назначенное в 3д редакторе,
\xrLC\communicate.h, там параметр m_sm_angle установлен как 75 и используется в \xrLC\xrCalcNormals.cpp, CalcNormals() и кода там поболее чем в зп-варианте. Ещё встречается в \xrLC\xrMU_Model_Calc_normals.cpp, но там заремили, и уже используется значение 89.

Компилишь без -nosmg, вот тебе и используется сглаживание из 3д-редактора. На m_sm_angle хрлц при этом даже не посмотрит.

Правда между 3д-редактором и хрлц есть еще много слабых звеньев.
Diesel
Цитата(abramcumner @ 30.12.2019, 12:20) *
Цитата(Yara @ 30.12.2019, 05:33) *
а также возможность заставить компиль тч учитывать сглаживание, назначенное в 3д редакторе,
\xrLC\communicate.h, там параметр m_sm_angle установлен как 75 и используется в \xrLC\xrCalcNormals.cpp, CalcNormals() и кода там поболее чем в зп-варианте. Ещё встречается в \xrLC\xrMU_Model_Calc_normals.cpp, но там заремили, и уже используется значение 89.

Компилишь без -nosmg, вот тебе и используется сглаживание из 3д-редактора. На m_sm_angle хрлц при этом даже не посмотрит.
Правда между 3д-редактором и хрлц есть еще много слабых звеньев.


Во истину получается не так. Если на модели не запечен слой нормалей, то без носмг сглаживание вообще слетит до 0 у всех групп.

Если в 3d редакторе просто накинуть смутх и так оставить, то шансов на одекватную компиляцию нет. Перед сглаживание или до (что уже забыл), нужно закрепить нормали в модификаторе эдит нормалс.
Yara
Цитата(abramcumner @ 30.12.2019, 13:20) *
Компилишь без -nosmg, вот тебе и используется сглаживание из 3д-редактора.

Знаю, всё верно для зова припяти, но речь шла о тенях чернобыля.

Цитата(Дизель @ 30.12.2019, 18:28) *
Во истину получается не так. Если на модели не запечен слой нормалей, то без носмг сглаживание вообще слетит до 0 у всех групп.

Если в 3d редакторе просто накинуть смутх и так оставить, то шансов на одекватную компиляцию нет. Перед сглаживание или до (что уже забыл), нужно закрепить нормали в модификаторе эдит нормалс.

В 3д максе может и так, в майке по другому.

xrModder
Yara, как заставить ТЧ xrLC учитывать сглаживание от 3D редактора?
Yara
Цитата(xrModder @ 30.12.2019, 21:42) *
Yara, как заставить ТЧ xrLC учитывать сглаживание от 3D редактора?

Эхх, выше посты и были для людей знающих С+, может кто и сделает. Хотя, вроде тут проскакивало что можно как-то собирать двиг сталка на appveyor или я ошибся и всё не так, ну чтоб не ставить все эти студии и прочий хлам. Немного изучить сишку, да по экспериментировать с этим делом.

Вообщем, всех с Новым годом!
xrModder
Цитата(Yara @ 31.12.2019, 13:12) *
Цитата(xrModder @ 30.12.2019, 21:42) *
Yara, как заставить ТЧ xrLC учитывать сглаживание от 3D редактора?

Эхх, выше посты и были для людей знающих С+, может кто и сделает. Хотя, вроде тут проскакивало что можно как-то собирать двиг сталка на appveyor или я ошибся и всё не так, ну чтоб не ставить все эти студии и прочий хлам. Немного изучить сишку, да по экспериментировать с этим делом.

Вообщем, всех с Новым годом!

Значит то что ты писал это просто "пустышка".
xrModder
Учим движка X-Ray читать полноценные "таблицы" погодных конфигурации...
abramcumner
xrModder, прикольно.
А на sky_rotation забил?
xrModder
Цитата(abramcumner @ 02.01.2020, 02:04) *
xrModder, прикольно.
А на sky_rotation забил?

Нет, она находится в соседнем проекте.
cjayho
цвет солнца можно вполне себе неплохо вычислять из положения солнца относительно горизонта.

и его цвет лучше вообще мерить в кельвинах, а не rgb. https://habr.com/ru/post/193142/

берем константы, например у горизонта солнце 3200К, в зените 5000К, и lerp-им промежуточное положение, потом пересчитываем в rgb, только учитываем туман и облачность - чем сильнее то или другое то тем сильнее обесцвечиваем яркость солнца и соответственно затемняем его, (при полной облачности или тумане солнца вообще нет).

То же самое с луной, у горизонта 2200К, в зените 4000К.

На самом деле там спектр сложнее обычной цветовой температуры, но как довольно близкое (до единиц процентов) приближение - вполне себе сгодится.
Shoкer
xrModder, красиво смотрится laugh.gif. Но имхо тогда уже лучше научить движок полноценные табличные форматы переваривать. Иначе первая же длинная строка заставит форматирование всех остальных столбцов исправлять, как у тебя с thunderbolt на скриншоте.

https://github.com/troldal/OpenXLSX
Хотя конечно работы тут побольше потребуется.
cjayho
QUOTE (Shoкer @ 03.01.2020, 13:42) *
xrModder, красиво смотрится laugh.gif. Но имхо тогда уже лучше научить движок полноценные табличные форматы переваривать. Иначе первая же длинная строка заставит форматирование всех остальных столбцов исправлять, как у тебя с thunderbolt на скриншоте.

https://github.com/troldal/OpenXLSX
Хотя конечно работы тут побольше потребуется.


По-моему проще в формат sqlite паковать
xrModder
Shoкer, "присобачить" XLS к движку из-за одной длинной словы в конфиге? Шутишь? laugh.gif
Не вижу в этом никакого смысла. Можно просто укоротить слово, а не сделать простое сложным, тем более легко адаптировать код отношении для обработки "табличных" конфигов погоды.
xrModder
Цитата(cjayho @ 03.01.2020, 13:49) *
цвет солнца можно вполне себе неплохо вычислять из положения солнца относительно горизонта.

и его цвет лучше вообще мерить в кельвинах, а не rgb. https://habr.com/ru/post/193142/

берем константы, например у горизонта солнце 3200К, в зените 5000К, и lerp-им промежуточное положение, потом пересчитываем в rgb, только учитываем туман и облачность - чем сильнее то или другое то тем сильнее обесцвечиваем яркость солнца и соответственно затемняем его, (при полной облачности или тумане солнца вообще нет).

То же самое с луной, у горизонта 2200К, в зените 4000К.

На самом деле там спектр сложнее обычной цветовой температуры, но как довольно близкое (до единиц процентов) приближение - вполне себе сгодится.

Неплохой вариант. Но тогда нужна интенсивность света Солнца (к примеру от 0 до 1), не представляю как отделить его от sun_color как sun_color_temperature и sun_intensity.
cjayho
QUOTE (xrModder @ 03.01.2020, 20:36) *
Неплохой вариант. Но тогда нужна интенсивность света Солнца (к примеру от 0 до 1), не представляю как отделить его от sun_color как sun_color_temperature и sun_intensity.


паковать в трехмерный вектор(температура, насыщенность, яркость)?

-----

Зы, у меня были некоторые наработки в двигло, в environment.cpp, но недоделанные:

код

CODE
Fvector3 calc_temp( float temp ) // color temperature counter
{
    float r, g, b;

    temp /= 100.f;

    if( temp < 65.f ){
        r = 255.f;

        float green = temp - 2.f;
        g = (-155.25485562709179f - 0.44596950469579133f * green + 104.49216199393888f * log(green));

        if( temp > 20 )
        {
            float blue = temp - 10.f;
            b = (-254.76935184120902f + 0.8274096064007395f * blue + 115.67994401066147f * log(blue));
        }
        else
        {
            b = 0;
        }
    }
    else
    {
        b = 255.f;
        float red = temp - 55.f;
        r = (351.97690566805693f + 0.114206453784165f * red - 40.25366309332127f * log(red));
        float green = temp - 50.f;
        g = (325.4494125711974f + 0.07943456536662342f * green - 28.0852963507957f * log(green));
    }

    clamp( r, 0.f, 255.f ); // это можно перевести в фвектор и клампить одним махом
    clamp( g, 0.f, 255.f );
    clamp( b, 0.f, 255.f );

    Fvector3 out;

    out.x = r/255.f; // это можно делить одним махом как фвектор
    out.y = g/255.f;
    out.z = b/255.f;

    return out;
}

// цветовые температуры

float sun_maxtemp_nofog = 6000; // солнышко в зените без тумана
float sun_mintemp_nofog = 1400; // солнышко у горизонта без тумана
float sun_maxtemp_fog = 6500; // солнышко в зените в полный туман
float sun_mintemp_fog = 6000; // солнышко у горизонта в полный туман

float moon_maxtemp_nofog = 5500; // луна в зените без тумана
float moon_mintemp_nofog = 3000; // луна на горизонте без тумана
float moon_maxtemp_fog = 5500; // луна в зените в полный туман (а ее хоть будет видно?)
float moon_mintemp_fog = 5500; // луна у горизонта в полный туман

float hour_sunrise = 5.f; // когда всходит солнышко
float hour_sunset = 22.f; // когда заходит

float moon_multiplier = .3f; // насколько луна меньше светит чем солнце. Сейчас втрое меньше

void CEnvironment::calculate_dynamic_sun_dir()
{
    //if( CurrentCycleName != "auto" ) return;

    bool isMoon = fGameTime < 60.f*60.f*hour_sunrise || fGameTime > 60.f*60.f*hour_sunset;

    float fGameTime2 = isMoon ? fGameTime - (86400.f-60.f*60.f*12) : fGameTime;

        float g = (360.0f/365.25f)*(180.0f + fGameTime2/DAY_LENGTH);

        g = deg2rad(g);

        //    Declination
        float D = 0.396372f-22.91327f*_cos(g)+4.02543f*_sin(g)-0.387205f*_cos(2*g)+
            0.051967f*_sin(2*g)-0.154527f*_cos(3*g) + 0.084798f*_sin(3*g);

        //    Now calculate the time correction for solar angle:
        float TC = 0.004297f+0.107029f*_cos(g)-1.837877f*_sin(g)-0.837378f*_cos(2*g)-
            2.340475f*_sin(2*g);

        //    IN degrees
        float Longitude = -30.4f;

        float SHA = (fGameTime2/(DAY_LENGTH/24.f)-12.f)*15.f + Longitude + TC + 180.f;

        //    Need this to correctly determine SHA sign
        if (SHA>180) SHA -= 360;
        if (SHA<-180) SHA += 360;

        //    IN degrees
        float const Latitude = 50.27f;
        float const LatitudeR = deg2rad(Latitude);

        //    Now we can calculate the Sun Zenith Angle (SZA):
        float cosSZA = _sin(LatitudeR)
            * _sin(deg2rad(D)) + _cos(LatitudeR)*
            _cos(deg2rad(D)) * _cos(deg2rad(SHA));

        clamp( cosSZA, -1.0f, 1.0f);

        float SZA = acosf(cosSZA);
        float elevation = PI_DIV_2-SZA+PI_DIV_8;
        clamp( elevation, 0.f, 1.f );
        elevation = 1.f - elevation;
        //    To finish we will calculate the Azimuth Angle (AZ):
        float cosAZ = 0.f;
        float const sin_SZA = _sin(SZA);
        float const cos_Latitude = _cos(LatitudeR);
        float const sin_SZA_X_cos_Latitude = sin_SZA*cos_Latitude;
        if (!fis_zero(sin_SZA_X_cos_Latitude))
            cosAZ    = (_sin(deg2rad(D))-_sin(LatitudeR)*_cos(SZA))/sin_SZA_X_cos_Latitude;

        clamp( cosAZ, -1.0f, 1.0f);
        float azimuth = acosf(cosAZ);

        if (SHA<0)
            azimuth = 2*PI-azimuth;
    
    float mintemp_nofog = 0.f;
    float maxtemp_nofog = 0.f;
    float mintemp_fog = 0.f;
    float maxtemp_fog = 0.f;

    if( isMoon )
    {
        mintemp_nofog = moon_mintemp_nofog;
        maxtemp_nofog = moon_maxtemp_nofog;
        mintemp_fog      = moon_mintemp_fog;
        maxtemp_fog   = moon_maxtemp_fog;
    }
    else
    {
        mintemp_nofog = sun_mintemp_nofog;
        maxtemp_nofog = sun_maxtemp_nofog;
        mintemp_fog      = sun_mintemp_fog;
        maxtemp_fog   = sun_maxtemp_fog;
    }

    float sunbright = 1.f;

    if(    fGameTime >= hour_sunset*60.f*60.f) // когда всходит луна
    {
        float result = ((hour_sunset+1.f)*60.f*60.f) - fGameTime;
        result /= (60.f * 60.f);
        clamp( result, 1.f-moon_multiplier, 1.f );
        sunbright = 1.f - result;
    }

    if(    fGameTime <= (hour_sunrise-1.f)*60.f*60.f) // утром (нужно переделывать бо бажный участок кода)
    {
        float result = fGameTime - ((hour_sunset-1.f)*60.f*60.f);
        result /= (60.f * 60.f);
        clamp( result, moon_multiplier, 1.0f );
        sunbright = result;
    }

    if( elevation < 0.33f )
    {
        sunbright *= 3.f * elevation;
    }

    float fogginess = CurrentEnv.rain_density + .1f; // ugly hack to determine fog

    float temp_nofog = mintemp_nofog*(1.f-elevation)+maxtemp_nofog*elevation;
    float temp_fog = mintemp_fog*(1.f-elevation)+maxtemp_fog*elevation;
    float temp = temp_nofog*(1.f-fogginess)+temp_fog*fogginess;

    CurrentEnv.sun_dir.setHP    (azimuth,-elevation);
    CurrentEnv.sky_rotation += -azimuth - PI_DIV_4 - .2f; // little bigger than pi_div_4
    CurrentEnv.sun_color.set(calc_temp(temp));
    CurrentEnv.sun_color.mul(sunbright);

    CurrentEnv.hemi_color.mul(sunbright);
    CurrentEnv.ambient.mul(sunbright);
    CurrentEnv.sky_color.mul(sunbright);
    CurrentEnv.fog_color.mul(sunbright);

    CurrentEnv.sun_color.mul(1.f - fogginess);
}


Тут еще есть алгоритм более-менее правдоподобного движения светил по небу, стыренный из ЗП и подлатанный.
Zagolski
А в Сталкере в ванильных погодных конфигах цвет солнца из реальных хар-к брали или нет, кто-нибудь знает? С виду вроде как не очень похоже, хотя натуральное освещение все же прослеживается, если весь пост отключить. К примеру на статике.
cjayho
QUOTE (Zagolski @ 09.01.2020, 15:21) *
А в Сталкере в ванильных погодных конфигах цвет солнца из реальных хар-к брали ?


А как вы это себе представляете? с фотки пипеткой что ли?
Zagolski
Цитата(cjayho @ 09.01.2020, 16:46) *
с фотки пипеткой что ли?

Не, ну с фотки оно тебе чисто белый покажет. А как освещение от солнца человеку видно с учетом всех атмосферных явлений и в разное время суток. В справочниках наверняка данные об этом есть.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Форум IP.Board © 2001-2024 IPS, Inc.