Kilin
Твоя проблема в том, что ты решил что он фанат. Фанаты как раз будут рады объедению сильных сторон 3 и 5 героев
В открытом океане от ветра, а на мелководье уже больше от глубины. Грубо говоря верхняя часть волны с одной скоростью, а нижняя типо запинается о поверхность и замедляется. Выходит так что волна падает. Это если на пальцах объяснять.
В реке таких перепадов высоты много и волны ведут себя по разному. Кароче сложно это все, даже я не все физические аспекты до конца понимаю :)
взять за основу референсное видео той же горной речушки и постараться приблизить поведение в симуляции
Да, это единственное верное решение которое мне видится.
Планировал взять референс какого-то видео и буквально создать сцену 1 к 1 (насколько возможно) с таким же масштабом.
где-то может течь быстрее, где-то медленнееКстати у алгоритма есть фича "скорость потока на мокрой и сухой поверхности". Типо там где уже есть слой воды, вода течет быстрее (из-за меньшего сопротивления).
Ну и плюс скорость потока тоже разная, там где есть препятствия или склоны и т.д.
То есть если всё это убрать, то реально будет выглядеть как текучий мед.
Ещё щас вспомнил, что у вязких жидкостей волны не могут принять подобную форму (слева, типо с сильным уклоном), и алгоритм точно так же не может (и выдаёт что справа по дизайну). Поэтому ещё этот момент даёт ощущение вязкости, наверное.
имеет ли смысл уменьшить массу воды по какой-нибудь зависимости, чтобы придать более натуральный вид
Алгоритм воды использует силу архимеда (вода течет в соседние пиксели с меньшей высотой) и скорость потока (типо инерции).
По сути симуляция рассчитывает "изменившийся уровень воды в каждом пикселе" 60 раз в секунду. То есть классических параметров вязкости/массы и прочего нет. Буквально всё что я могу - это замедлять/ускорять обновление пикселей и их плотность на метр.
Когда смотрю анимации в других играх, там вода выглядит "вязкой" как раз из-за неверной скорости волны.
Условно волна от персонажа где-то 5 см высотой и должна двигаться со скоростью 1 метр в секунду.
А волна от лодки где-то 50см высотой и скорость уже 4 метра. Цифры условны но смысл такой.
А текущий алгоритм не учитывает такие факторы, он распространяет волны с одной скоростью. Я думаю это и есть основная причина "вязкости" на каких-то масштабах.
Есть единственный алгоритм (опубликованный пару лет назад) который позволяет рассчитывать разные волны по отдельности, но это сильно медленнее, и сложный. Я долго с ним возился, но так и нихрена не понял его, математический язык понимают только математики, а не программисты.
Поэтому в демке выше надо как-то подбирать скорость волны "на глаз", но как мы поняли, он у меня не очень xD
Чувак, как выяснилось, живёт в этой локации и буквально ходит с обвесом из самодельных камер и снимает мегасканы, а потом из них создаёт модели.
Плюс из гугл карт создаёт, ходит по объектам и домам, собирает всякие предметы (тазики, черепа и т.д.)
кароче делает какую-то невероятную работу.
вот публичная ветка, можно почитать и скрины всякие поглядеть
https://discord.com/channels/778960015716909057/932051522446032916/1389266222134067211
Понял тебя, тебе нужен фидбек от специалистов для специалистаДа не, просто фидбек с подробностями уже хорошо.
однако на демке явных ориентиров, намекающих на такие размеры - нет, как минимум для меня, все воспринимается в пределах не 15 метров, а 2-5Тут не спорю, у меня нет нормальных локаций для демок, поэтому использую юнитековские. Но по какой-то причине у них демки тоже со странным масштабированием.
а вот чтобы они были легковесными для обсчета на консоляхЭто было кстати основной причиной почему я вообще решил делать вторую версию ассета. Из всех существующих алгоритмов симуляций, это самый быстрый, плюс мне всегда нравится выжимать максимум производительности (ну и красоты, насколько возможно).
Я наверное 80% времени трачу на тестирование разных вариантов оптимизаций и обдумывание "чё бы ещё придумать", ну и чтение всяких современных "хаков"
Поэтому у меня в гитхабе куча коммитов с припиской "потратил 2 дня, выяснилось что он медленее, инвестировал в говно" :)
В планах как-то релизнуть версию для мобилок, сам алгоритм позволяет, другой вопрос что смешивание всех зон и океана это самая мерзкая часть.
Мой работает на dx11, на всех пайплайнах, включая последние unity 6.3
Там алгоритм использует обычные dx9 фичи. Единственное, это частицы пены/брызг и проверка высоты уровня воды (для включения подводных эффектов) используют compute shaders.
Хотя зная как юнити всё вечно ломает в каждом обновлении...
Я буквально так и отвечал с первого сообщения, про ограничения алгоритма и масштабы. Когда на аргументы говорят что я говноспорю, то я не пойму чё от меня хотят?
Фидбек в стиле "это кисель и даже не говноспорь" буквально не даёт никакой конкретики и куда именно обращать внимание. Скорость пены/воды/частиц, турбулентность и хаос, микроволны и их отсутствие, скорость на глубине или скорость на поверхностях (например камней) и т.д.
Там вот ниже человек как-то попытался объяснить про плотность, как мог, и это уже даёт мне понимание куда двигаться.
Нормальный фидбек я слушаю, и например изменил некоторые параметры симуляции и обновил видео, для теста.
https://youtu.be/8RmSaYjJ4S4
Я не работал в ue, но для чего distance field? Он же не бесплатный в рантайме считать каждый кадр для всего мира, только ради "нагнуть травку"
У тебя есть персонаж и его позиция. Ты уже знаешь дистанцию между вершиной травы и персонажем. Если хочется прям точности, можно пересылать позиции примитивов для костей и определять с какой частью взаимодействует трава.
То есть одна проверка "насколько близко персонаж к траве", если близко, то пройтись по всем костям и точнее определить есть ли пересечение с костями (ну или примитивами). Точность наверное будет как у sdf или выше, и это самый быстрый способ.