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

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

Страницы: 1 2 3 4 Следующая »
BernsПостоялецwww4 июня 201814:44#30
допиливал алгоритм как ЧАЭС тушили, но по мне так производительность очень даже пригодная (непрозрачные части можно и вовсе вынести в отдельный рендер, а тут вся сцена через буферы). если объекта нет в поле зрения - выдает здоровые 1200 кадров даже без оптимизаций отсечения блендинга 
Изображение
BernsПостоялецwww4 июня 201819:14#31
Разогнал до 300 кадров на той же сцене, да появилась проблема - флаг [earlydepthstencil] не реагирует, проход прозрачной геометрии записывает глубину, а не отсекается по заготовленной.
MrShoorУчастникwww4 июня 201819:20#32
Berns
> флаг [earlydepthstencil] не реагирует
Рендертаргет с буфером глубины не забыл установить?
BernsПостоялецwww4 июня 201819:30#33
Поставил:
CommandList->OMSetRenderTargets(0, NULL, FALSE, &dsvDepth);

просматриваю буфер глубины - что с этим флагом, что без него - все равно в него пишется. Ставлю dsvDepth на нуль -вся прозрачная геометрия тип-топ, но по непрозрачной  разумеется не отсекается. шейдерная модель - 5.0
Вероятно, это настраивается через API в конвейере.

Правка: 4 июня 2018 19:36

MrShoorУчастникwww4 июня 201819:41#34
Berns
Не могу сказать насчет DX12, ибо с ним пока еще не работал, но в DX11 earlydepthstencil работает 100%. Значит должен и в DX12. Видимо ты что то делаешь не так.
BernsПостоялецwww4 июня 201819:51#35
А что на DX12 то не перешел? Мне мозгового штурма с управлением ресурсов 11-м хватило, перешел чисто ради фич, а в итоге увидел множество вариантов для улучшения производительности.
Кстати, профиксил. Там нужна была дополнительная структура D3D12_DEPTH_STENCIL_DESC для пейплайна, поставил D3D12_DEPTH_WRITE_MASK_ZERO и поехало.
MrShoorУчастникwww4 июня 201819:56#36
Berns
> А что на DX12 то не перешел?
Да как-то руки все не доходят. Работы с DX11 и OGL полно.

> а в итоге увидел множество вариантов для улучшения производительности.
Угу, я прекрасно знаю эти варианты, потому что буквально в них сейчас и упираюсь на DX11/OGL. Но производительности сейчас и на DX11 хватает.

BernsПостоялецwww4 июня 201820:01#37
Кстати, ты спрашивал, зачем очищать два буфера. Пересмотрел свои исходники и увидел, что счетчик был приклеен к структурированному. Отсюда и тормоза в простое.
innuendoПостоялецwww4 июня 201820:26#38
Berns
> допиливал алгоритм как ЧАЭС тушили

?

MrShoorУчастникwww4 июня 201820:28#39
Berns
> что счетчик был приклеен к структурированному.
Так вроде так и надо. Для того, чтобы счетчик сбросить - не надо весь буфер чистить.
BernsПостоялецwww4 июня 201820:59#40
Сбросить? Например?
MrShoorУчастникwww4 июня 201821:21#41
Berns
> Сбросить? Например?
https://msdn.microsoft.com/en-us/library/windows/desktop/ff476465(v=vs.85).aspx
смотри последний параметр
BernsПостоялецwww4 июня 201821:25#42
не, для DX12 это мимо.
MrShoorУчастникwww4 июня 201821:35#43
Berns
> не, для DX12 это мимо.
Пара минут гугления показала, что счетчики в DX12 - это отдельный ресурс (как в ОГЛ). И соответственно почистить можно только счетчик.
Счетчик привязывается к другому ресурсу во вьюшке:
https://msdn.microsoft.com/en-us/library/windows/desktop/dn788674(v=vs.85).aspx
BernsПостоялецwww4 июня 201822:32#44
Об этом я уже знал. А чтобы его чистить пришлось создать еще один UAV, а ресурс от этого указать в качестве счетчика. Пока что всё очень даже неплохо, 420 кадров, но можно и лучше. 1200 если миновать стадию блендинга, блестяще.

Правка: 4 июня 2018 22:35

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

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

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