Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / Выбор алгоритма порядок-независимой прозрачности (Directx 12)

Выбор алгоритма порядок-независимой прозрачности (Directx 12)

Страницы: 1 2 3 4 Следующая »
BernsПостоялецwww22 мая 201815:37#0
Доброго времени.
Разбираюсь с новым API, могу быть не в курсе других алгоритмов OIT и их возможностей оптимизации в этой версии. В Directx 11 уже как-то реализовывал depth peeling и однопроходный алгоритм с использованием UAV-буферов. К слову, первый вообще не был оптимизирован (4 слоя аж с отложенным освещением, на каждый - (4 байта глубины, 8 байт на нормали, по 4 на диффуз и материалы), после чего унылый просчет и сортировка. Но даже это работало куда быстрей второго, который всасывал с 200 до 30 кадров (против 80 кадров на 4 заграждениях у первого алгоритма) уже от двух прозрачных заграждений на весь экран. Из плюсов, он действительно отлично блендит множество мелких деталей, вроде волос или частиц. Из минусов - артефакты при переполнении, которые менее заметны в первом алгоритме ввиду того, что после 4-го слоя они блендятся как попало, что либо редко, либо незаметно.
Теоретически, depth peeling будет иметь меньшую производительность на высокополигональных сценах и ввиду частой нагрузки на Z-буфер.  Но дела обстоят так, что по большей части алгоритм затронет отрисовку волос и стекол.
Кто что верстает? Заметно ли улучшена работа с ресурсами неупорядоченного доступа в Directx12?
innuendoПостоялецwww22 мая 201816:16#1
Berns
> Заметно ли улучшена работа с ресурсами неупорядоченного доступа в Directx12?

там было что-то новое ?

prowkanПостоялецwww22 мая 201816:51#2
innuendo
> там было что-то новое ?
Raster Order View?
BernsПостоялецwww22 мая 201816:55#3
Ну, синхронизация теперь в самом коде. Не осмелюсь предположить, какой это даст выигрыш, но в DX11 ресурсы с подобным  доступом гораздо медленней (раз эдак в 10-30), чем любые другие ресурсы на фиксированное чтение/запись.
innuendoПостоялецwww22 мая 201817:27#4

prowkan
> Raster Order View?

https://msdn.microsoft.com/ru-ru/library/windows/desktop/dn914596(v=vs.85).aspx

MrShoorУчастникwww22 мая 201817:53#5
Berns
> Кто что верстает?
Хмм. У меня противоположная ситуация. Depth peeling чаще всасывал по производительности.
Да, наверное если во весь экран выводить забор, то dp может быть и затащит, но если у тебя прозрачная часть в результате занимает скажем 10% на экране, то dp сливает. Сильно динамическое количество слоев? dp опять сливает. Ботелнек cpu очень близок? Тогда у dp вообще нет шансов.
MrShoorУчастникwww22 мая 201817:56#6
Ну и есть еще ооочень быстрый и годный хак, это WOIT. Но в некоторых случаях хак становится заметен.
BernsПостоялецwww22 мая 201819:39#7
У меня одна очистка UAV'ов 1600x900 на два полных перекрытия занимала 3 миллисекунды. С двумя полными перекрытиями весь рендер и сортировка прозрачности занимает уже 40 миллисекунд. Реализация далеко не халтурная, тот же счетчик и структурированный буфер + сортировка пузырьком. Таки есть подозрения, что в ААА-проектах их никогда не используют для рендеринга крупных стекол и воды, а блендят с сортировкой по старинке. Как-то это, не круто.
MrShoorУчастникwww22 мая 201819:44#8
Berns
> У меня одна очистка UAV'ов 1600x900 на два полных перекрытия занимала 3
> миллисекунды.
Зачем чистить UAV на 2 перекрытия? Чистится только head буфер же

> Таки есть подозрения, что в ААА-проектах их никогда не используют для
> рендеринга крупных стекол и воды, а блендят с сортировкой по старинке.
В ААА проектах и depth peeling не используют. Так что оба алгоритма, что dp, что oit на линкед листах обычно редко применимы.

> Реализация далеко не халтурная, тот же счетчик и структурированный буфер +
> сортировка пузырьком.
При большом перекрытии пузырек надо делать с ранним выходом, а объекты по прежнему стараться сортировать со стороны CPU.

BernsПостоялецwww22 мая 201821:30#9
Сперва подумал, что в этом была проблема и уже побежал рыться в исходниках, но увы, там это было учтено.
А что вообще в ААА применяют? И я не имел ввиду depth peeling. Обычная отрисовка с блендингом и сортировкой на CPU, как минимум такой подход наблюдал в старых играх, типа fallout 3, для всяких окон и банок отлично подойдет, а вот кинешь банку в воду - и её уже не увидишь. Для волос и многослойных частиц такое не прокатит, но вот с OIT - в самый раз. Правда, тогда использовал двойной проход, чтобы непрозрачная часть текстуры не ела памяти и производительности.
MrShoorУчастникwww22 мая 201822:11#10
Berns
> А что вообще в ААА применяют?
Чаще всего обычная сортировка с обычным блендингом. Для всяких текстур типа листвы юзают ATOC, если получается. Вроде как WOIT годная техника, но из тех игр, которые я дебажил пока нигде её не встречал, вероятно потому что техника еще молодая. Но для всякого дыма её стопудов напихают. Надо новые тайтлы будет подебажить на досуге.

> а вот кинешь банку в воду - и её уже не увидишь.
Ну банку то увидишь, а вот воду через стекло банки вероятно нет.

Правка: 22 мая 2018 22:11

MAMOHT-92Постоялецwww23 мая 201817:46#11
MrShoor
> Вроде как WOIT годная техника
можно поподробнее, а то не гуглится.
Mr FПостоялецwww23 мая 201817:52#12
Из новенького: http://momentsingraphics.de/?page_id=210
MrShoorУчастникwww23 мая 201820:04#13
MAMOHT-92
> можно поподробнее, а то не гуглится.
Weighted Order Independent Transparency
СухарикПользовательwww24 мая 20183:41#14
Вот такое недавно нашёл. Говорят быстрый и точный. Сам не пробовал.

Moment-Based Order-Independent Transparency

Cedrick Münstermann, Stefan Krumpen, Reinhard Klein, and Christoph Peters
In: Proceedings of the ACM on Computer Graphics and Interactive Techniques (May 2018), 1:1(7:1-7:20)

http://cg.cs.uni-bonn.de/en/publications/paper-details/muenstermann2018-mboit/

Правка: 24 мая 2018 3:42

Страницы: 1 2 3 4 Следующая »

/ Форум / Программирование игр / Графика

2001—2018 © GameDev.ru — Разработка игр