Kilin

+6630
с 2022
51 подписчик
11 подписок

Ну базовый блум и яркость текстур всё равно можно попробовать настроить, это уже половина успеха. Я не знаю как там в ue делается, но думаю по такой же схеме как в юнити :)

У меня на ютубчике можно поглядеть какие-то референсы для понимания. Например вот последний пак эффектов.
Могу рассказать подробнее если чё-то интересно.
https://youtu.be/b-vqp0J2Aeo

3

Как VFX могу дать пару непрошеных советов.
Огромную роль в восприятии играет физически корректная апроксимация блума. Это буквально то как человеческий глаз и камера оценивает яркость. Когда мы хотим передать цвет эффекта, многие почему-то пытаются сделать это через текстуры и формы эффекта.
Скрин 8-и летней давности, но даже на нём должно быть понятно о чём я.
Поэтому вместо естественного свечения искр от меча, люди просто увеличивают искры в 5 раз больше и получаются летающие желтые фломастеры. Корректнее будет передавать яркость через bloom + emission.
В твоём случае на молнии слишком яркая эмиссия и слишком малая диффузия блума (это когда засветка должна быть на весь экран, а не кусок)
У остальных эффектов нет свечения вообще. Поэтому объект вообще яркий или нет?
Ещё один важный момент почему это сильно важно. Свечение размывает резкие границы и как бы смешивает отдельные объекты в общую картину. Поэтому всякие спрайты перестают выглядеть слишком плоскими и более однородными (будто это одно пламя, а не отдельные куски текстур).

Может вообще поделать уроки VFX?

7

Resident drawer использовали?
Если в вашей игре много разных объектов, то srp batcher / Resident drawer могут помочь, в ином случае (когда много одинаковых объектов, например травы), то от них лучше отказаться.
По какой-то причине разрабы юнити решили "мы не дадим вам свободы выбора", оставили инстансинг, но убрали возможность его активировать. Пока включен srp batcher или Resident drawer, инстансинг не работает.
Нужно открыть ассет настроек URP в режиме "debug" и выключить srp batcher, а взамен у всех материалов включить инстансинг.
В случае с растительностью это может дать огромный прирост ФПС.

Я не работал в ue, но для чего distance field? Он же не бесплатный в рантайме считать каждый кадр для всего мира, только ради "нагнуть травку"

У тебя есть персонаж и его позиция. Ты уже знаешь дистанцию между вершиной травы и персонажем. Если хочется прям точности, можно пересылать позиции примитивов для костей и определять с какой частью взаимодействует трава.
То есть одна проверка "насколько близко персонаж к траве", если близко, то пройтись по всем костям и точнее определить есть ли пересечение с костями (ну или примитивами). Точность наверное будет как у sdf или выше, и это самый быстрый способ.

1

Твоя проблема в том, что ты решил что он фанат. Фанаты как раз будут рады объедению сильных сторон 3 и 5 героев

16

В открытом океане от ветра, а на мелководье уже больше от глубины. Грубо говоря верхняя часть волны с одной скоростью, а нижняя типо запинается о поверхность и замедляется. Выходит так что волна падает. Это если на пальцах объяснять.
В реке таких перепадов высоты много и волны ведут себя по разному. Кароче сложно это все, даже я не все физические аспекты до конца понимаю :)

1

взять за основу референсное видео той же горной речушки и постараться приблизить поведение в симуляции

Да, это единственное верное решение которое мне видится.
Планировал взять референс какого-то видео и буквально создать сцену 1 к 1 (насколько возможно) с таким же масштабом.

где-то может течь быстрее, где-то медленнееКстати у алгоритма есть фича "скорость потока на мокрой и сухой поверхности". Типо там где уже есть слой воды, вода течет быстрее (из-за меньшего сопротивления).
Ну и плюс скорость потока тоже разная, там где есть препятствия или склоны и т.д.
То есть если всё это убрать, то реально будет выглядеть как текучий мед.

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

1

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

Алгоритм воды использует силу архимеда (вода течет в соседние пиксели с меньшей высотой) и скорость потока (типо инерции).
По сути симуляция рассчитывает "изменившийся уровень воды в каждом пикселе" 60 раз в секунду. То есть классических параметров вязкости/массы и прочего нет. Буквально всё что я могу - это замедлять/ускорять обновление пикселей и их плотность на метр.

Когда смотрю анимации в других играх, там вода выглядит "вязкой" как раз из-за неверной скорости волны.
Условно волна от персонажа где-то 5 см высотой и должна двигаться со скоростью 1 метр в секунду.
А волна от лодки где-то 50см высотой и скорость уже 4 метра. Цифры условны но смысл такой.

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

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

Поэтому в демке выше надо как-то подбирать скорость волны "на глаз", но как мы поняли, он у меня не очень xD

1

Чувак, как выяснилось, живёт в этой локации и буквально ходит с обвесом из самодельных камер и снимает мегасканы, а потом из них создаёт модели.
Плюс из гугл карт создаёт, ходит по объектам и домам, собирает всякие предметы (тазики, черепа и т.д.)
кароче делает какую-то невероятную работу.

вот публичная ветка, можно почитать и скрины всякие поглядеть
https://discord.com/channels/778960015716909057/932051522446032916/1389266222134067211