Войти
ПрограммированиеФорумГрафика

Quadtree mesh и корректный frustum culling (3 стр)

Страницы: 1 2 3 4 5 6 7 Следующая »
#30
15:49, 16 сен 2022

Super_inoy
> мне казалось что в первом кризисе, который 2007 года еще без тесселяции сделали
> тупо плоскость для океана с переменной плотностью(ближе к игроку плотнее),
> в которой эта самая плотность никак не менялась(но двигалась с игроком) и у них
> прокатило. И был какой-то пейпер в котором они доказывали что так быстрее.
> Ну да ладно, это оффтоп.
Да, так и есть. О и ещё забыл про проблему (как раз на скринах говорят), это дрожание меша при смещении камеры.

+ Показать
#31
16:04, 16 сен 2022

Kripto289
а на мобилках будут заметны все эти косяки то? Если игра динамичная то точно нет, если же созерцать то всё равно попиксельные "косяки" нужно очень сильно стараться высматривать с той плотностью пикселей что на мобильных экранах. Как вариант отрендерить в отдельный рендер тагет, и наложить поверх чуть размазанный вариант с подобранной формулой смешивания, помогает замылить подобные косяки.

#32
16:12, 16 сен 2022

Aroch
> а на мобилках будут заметны все эти косяки то? Если игра динамичная то точно
> нет, если же созерцать то всё равно попиксельные "косяки" нужно очень сильно
> стараться высматривать с той плотностью пикселей что на мобильных экранах. Как
> вариант отрендерить в отдельный рендер тагет, и наложить поверх чуть
> размазанный вариант с подобранной формулой смешивания, помогает замылить
> подобные косяки.
Я люблю универсальные методы. А то поддержка 3-х рендерингов под разные версии юнити и так непроста, так ещё и отдельный форк для мобилок.

А вот рендеринг в отдельный рендер таргет я выпилил (хотя была такая фича изначально). По моим тестам, рендеринг даже в половинное разрешение и растягивание на весь экран (то есть как делает dlss/fsr на perfomance режиме), я получал 0 выигрыш производительности.
Грубо говоря 2 мс рендеринг воды в 4k
или 1,4 мс рендеринг воды в fulldhs + 0.6 мс растягивание кадра до 4k.
Я там ещё и msaa добавлял, но он жрёт чудовищно много, поэтому хз, не производительно на мобилках выйдет наверное

#33
17:15, 16 сен 2022

Kripto289
> поэтому хз, не производительно на мобилках выйдет наверное
ну на мобилках и нет 4к, но дополнительный проход для них скорее и не понадобится, нужно смотреть как это выглядит на устройстве чтобы делать выводы. Делать полностью универсально всё равно не получится, под мобилы так или иначе придется резать графику если ты хочешь покрыть основной парк устройств и при этом не даунгрейдить графику для ПК.

Но по теме даже честная проверка на попадание не должна быть проблемой, её делали десятки лет назад на совсем древних железках и никогда это не было узким местом. Но можешь сперва отсекать грубо сферой, потом уже уточняешь аппроксимацию из 3-4 сфер и если нужна еще большая точность переходить к проверке бокса. При этом если все 3 проверки пройдены можно сохранить текущую позицию камеры и точки взгляда для данного патча ландшафта, и в след раз сперва сравнив отклонение сохраненных значений от текущего положения камеры выбрать нужный тип проверки и пропустить остальные.

#34
(Правка: 17:50) 17:50, 16 сен 2022

Aroch
> Делать полностью универсально всё равно не получится, под мобилы так или иначе
> придется резать графику если ты хочешь покрыть основной парк устройств и при
> этом не даунгрейдить графику для ПК.
Не, у меня код разделен на общий/платформо-специфичный, поэтому у меня уже изначально заложена база для подобных отличий. Скорее причина в том, что quadtree весьма полезен и на ПК платформах. В частности на ios с тесселяцией есть некоторые ограничения. Поэтому иметь дополнительный вариант рендеринга с quadtree это плюс. Считай запасной вариант, на случай если тесселяция не пашет по каким-то причинам.
Это кстати одна из причин, почему не хочется усложнять расчеты всякими разделяющими плоскостями, потому что мобилки и так медленные.

Aroch
> Но по теме даже честная проверка на попадание не должна быть проблемой, её
> делали десятки лет назад на совсем древних железках и никогда это не было узким
> местом. Но можешь сперва отсекать грубо сферой, потом уже уточняешь
> аппроксимацию из 3-4 сфер и если нужна еще большая точность переходить к
> проверке бокса. При этом если все 3 проверки пройдены можно сохранить текущую
> позицию камеры и точки взгляда для данного патча ландшафта, и в след раз сперва
> сравнив отклонение сохраненных значений от текущего положения камеры выбрать
> нужный тип проверки и пропустить остальные.
Кто бы подсказал формулу для пересечения конуса и куба. А так да, попробую апроксимировать фрустум сферами. Хуже, чем ложные срабатывания на все квадраты quadtree я не сделаю.

#35
19:16, 16 сен 2022

Kripto289
Океан - же вообще считай плоский, что там отсекать?
Для поверхности планеты нужно еще отсечение по горизонту, отбрасывай все на дальше чем  дальность горизонта юзера плюс далность горизонта самой высокой горы.

#36
(Правка: 19:18) 19:18, 16 сен 2022

Aslan
> Океан - же вообще считай плоский, что там отсекать?
Я отсечение использую для правильного выбора минимального уровня из quadtree. При неправильной отбраковке я практически ничего не отсекаю и рендерю в 2-3 раза больше полигонов.

#37
4:33, 17 сен 2022

Aslan
> Для поверхности планеты нужно еще отсечение по горизонту, отбрасывай все на
> дальше чем  дальность горизонта юзера плюс далность горизонта самой высокой
> горы.
Ты забыл приплюсовать глубину самой большой впадины.

Aslan
> Океан - же вообще считай плоский, что там отсекать?
Океан-множество треугольников. И если не отсекать, то в 4 раза больше рендерить.

#38
4:35, 17 сен 2022

samrrr
> И если не отсекать, то в 4 раза больше рендерить.
в 4 раза больше аппаратно отсекать сильно неоптимальным методом. Это не рендер.

#39
4:36, 17 сен 2022

Kripto289
> Кто бы подсказал формулу для пересечения конуса и куба. А так да, попробую
> апроксимировать фрустум сферами. Хуже, чем ложные срабатывания на все квадраты
> quadtree я не сделаю.
То-есть до идеи определения частичного полного и никакого попадания квада и итеративного прохода вниз ты так и не додумался? Да и вообще, я тупо тестил все меши по фрустуму и норм работало.

#40
7:33, 17 сен 2022

samrrr
> Да и вообще, я тупо тестил все меши по фрустуму и норм работало.
+1, мне даже лень было заводить иерархию потому как даже простой перебор не спотыкался от слова совсем. Узлов там было около 4к что-ли.

#41
(Правка: 9:33) 9:28, 17 сен 2022

samrrr
> То-есть до идеи определения частичного полного и никакого попадания квада
А какая разница между "частично попадает квад" или "полностью", если в любом случае нужно будет рекурсивно (или другим способом) пройтись дальше?

samrrr
> и итеративного прохода вниз ты так и не додумался?
ммм, у меня сейчас рекурсивно так и работает, не?
Проверяю квадрант верхнего уровня, если он виден, то проверяю его потомков рекурсивно.
Так же проверяю дистанцию до камеры, если она слишком высокая для текущего уровня, то так же пропускаю квадрант и его потомков.
Не знаю, вроде именно так quadtree и должен работать? (первый раз с таким работаю)
Для примера из 10 подуровней на 20 километров я проверяю порядка 100-150 видимых квадрантов, а не миллион.

samrrr
> Да и вообще, я тупо тестил все меши по фрустуму и норм работало.
В смысле меш в виде пирамиды по фрустуму? Но камера может взлететь и посмотреть вниз и меш должен уже быть квадратным.
Или меш деленный на квадраты, отсекающиеся по фрустуму? Но для 20 километров мне сколько таких квадратов надо? (кстати этот способ у меня уже реализован, но он дико не оптимален в плане отсечения дальних планов).
Или про что речь? Может скрины есть как это выглядит?

В любом случае, для океана важно иметь количество треугольников примерно равное разрешению текстуры симуляции FFT волн. Даже для 128*128 текстуры на 10 метров домена, мне надо иметь разрешение 128*128 точек на 10 метров, иначе будут артефакты видимости задней части волны и видимое дрожание вершин при перемещении.
Такая плотность даже с учётом lod-ов приведёт к тому, что мне надо использовать сотни тысяч треугольников для всей поверхности океана. С quadtree я могу уменьшить количество полигонов в 2-3 раза, а это существенный буст.

#42
(Правка: 10:20) 10:17, 17 сен 2022

Kripto289
Я в своих планетах вообще не делал frustum culling и все летало на GF5200
Тебе нужно пересечение не бокса, а только квада (верхней стороны), взятого по макс высоте волны, но не выше камеры и фрустум бери не  бесконечный - меньше на 1 грань и 4 ребра, уже задача намного упрощается. Считать можно хоть через SAT и тут еще можно оптимизировать, используя информацию с верхних уровней QuadTree и др трюки геометрии
> В любом случае, для океана важно иметь количество треугольников примерно равное разрешению текстуры симуляции FFT волн
А можно просто поднимать пикселы и нормали в frag shader

+ Показать
#43
10:36, 17 сен 2022

Aslan
> Я в своих планетах вообще не делал frustum culling и все летало на GF5200
У тебя наверняка было на порядок меньше треугольников, а так же сложность твоего вертексного шейдера на порядок меньше.
В моём же случае мне нужно рендерить меш дважды (для маски/глубины/нормалей/scattering) и для основного рендеринга воды. Ну и вертексный шейдер на порядок сложнее (потому что мне надо считать каскады волн и плюс активные доп фичи, такие как пляжные волны, бикубическая фильтрация, flowmap, fluids map и рябь)
Для статистики вертексный шейдер
  d3d11: 117 avg math (27..204), 7 avg branch (2..13)
Поэтому экономия каждого полигона довольно существенна в моём случае.


Aslan
> Тебе нужно пересечение не бокса, а только квада (верхней стороны), взятого по
> макс высоте волны, но не выше камеры и фрустум бери не бесконечный - меньше на
> 1 грань и 4 ребра, уже задача намного упрощается.
Идея отличая, да.

ps Решил я потестить сложный и точный вариант отсечения, на удивление разницы почти нет. В очередной раз убеждаюсь что предварительная оптимизация бесполезна.

#44
(Правка: 12:04) 12:00, 17 сен 2022

Kripto289
> У тебя наверняка было на порядок меньше треугольников, а так же сложность твоего вертексного шейдера на порядок меньше
У меня вообще примитив и блоки считались на CPU (и передевались в VBO) но всеже
> В моём же случае мне нужно рендерить меш дважды (для маски/глубины/нормалей/scattering) и для основного рендеринга воды. Ну и вертексный шейдер на порядок сложнее (потому что мне надо считать каскады волн и плюс активные доп фичи, такие как пляжные волны, бикубическая фильтрация, flowmap, fluids map и рябь)
Ну незнаю, мне кажется сложные эффекты считаются только вблизи
> Кто бы подсказал формулу для пересечения конуса и куба
Это плохая идея. Для стандартного монитора 16x9 площадь основания фрустума - 16*9=144, а площадь основания описанного вокруг фрустума конуса PI*(16^2+9^2)/2=529, убивает весь смысл frustum culling
> попробую апроксимировать фрустум сферами
Лучше уж кубы описанными сферами - намного проще считать
Достаточно проверить, что сфера снаружи от хотя бы одной плоскости, притом даже dot-ы считать только для верхнего уровня QuadTree, а дальше они сокращаются

Страницы: 1 2 3 4 5 6 7 Следующая »
ПрограммированиеФорумГрафика