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

DirectX 11 Order Independent Transparency

Страницы: 1 2 3 4 5 6 Следующая »
#0
23:03, 28 окт. 2009

Кто-нибудь встречал в природе пейпер по OIT через DirectCompute11? Видео есть, демка есть (которую не могу запустить, т.к. требует карточку ати), а пейпер найти не могу :/
Может кто знает, чем отличается DirectCompute10 от 11? Можно ли на нем сделать аналогичный OIT?
Кто-нибудь может достать вычислительный шейдер из демки?


#1
10:57, 29 окт. 2009

evirus

Как точно сделано у ati в демке я не знаю. Но есть dxsdk11, там пример tonemap через cs.  Юзается там StructuredBuffer<float> , RWStructuredBuffer<float4>
в них пишется.  По идее, они пишут depth & transparency в эти буфера и затем финале выводят.

#2
12:18, 29 окт. 2009

evirus
Меня вот интересует насколько этот сэмпл быстрый. Судя по убогости геометрии - OIT штука неюзабельная. Вот был бы там дракон...

#3
12:54, 29 окт. 2009

Джо
> Меня вот интересует насколько этот сэмпл быстрый.

утверждается что поиск avgLum в несколько раз быстрее идёт по сравнению с обычным спрособом

#4
18:23, 29 окт. 2009

innuendo
Да не tonemap, а OIT.

#5
19:36, 29 окт. 2009

Джо
> Да не tonemap, а OIT.

Если avgLum ускоряется, то и OIT должен

#6
22:59, 29 окт. 2009

Джо
> Меня вот интересует насколько этот сэмпл быстрый. Судя по убогости геометрии -
> OIT штука неюзабельная. Вот был бы там дракон...
Мне кажется, или этому методу наплевать на геометрию? Он же работает с фрагментами, пускай там хоть куб, хоть хейтмапа с драконом.

#7
23:21, 29 окт. 2009

NULL_PTR
> Мне кажется, или этому методу наплевать на геометрию?
ну вроде как да, но сложная геометрия - больше overdraw. Я так понимаю, что они во фрагментном шейдере сваливают в буфер все, который потом сортируют в CS. Что-то вроде K-routed буфера через MSAA+stencil. Вот мне больше интересно фиксирован ли размер этого буфера или он расширяемый. Вероятнее всего фискирован числом каких-то регистров. Плюс в качестве недостатков там наверно фигурирует ограниченность одним материалом (либо может даже 1 DIPом - это тогда еще хуже) и фиксированным числом слоев (типо при M > N будет фейл). Пока это мне не понятно.

В DX SDK тоже оказывается есть демка, но поиграться нормально с нею не получается без железки. Да и не понятно многое и документации нету нормальной. Играясь с компилятором, я так понял, что оно не заживет на cs_4_0, пишет что не хватает регистров UAV. Попозже еще помедитирую над этим кодом.

#8
23:33, 29 окт. 2009

NULL_PTR
Чем больше геометрии, тем больше значений на пиксель, дольше сортировать, то-сё. В софтвере он работает дико медленно.

#9
23:38, 29 окт. 2009

evirus
Ну для DX 10 можно юзать K-buffer, но получается медленно - в больших разрешениях 8xMSAA буферы отъедают прилично памяти и скорости. Тестил зелёного дракона на GTX260 в 1280x1024 - 70 fps.

#10
0:09, 30 окт. 2009

Джо
Есть OIT демка АТИ с роботом. Overdraw и размеры треугольников побольше, чем у дракона из демок k-buffer.

#11
10:47, 30 окт. 2009

NULL_PTR
> Есть OIT демка АТИ с роботом.
сколько в это демке поли и сколько фпс она выдает?

#12
11:02, 30 окт. 2009

evirus
> сколько в это демке поли и сколько фпс она выдает?

важно число слоёв или  число полигонов ?

#13
12:16, 30 окт. 2009

В демке основной поинт, что нет глобальнъх буферов слоями на весь екран.

#14
12:38, 30 окт. 2009

Z
> В демке основной поинт, что нет глобальнъх буферов слоями на весь екран.
имхо, основной поинт в том, что проход 1

innuendo
> важно число слоёв или число полигонов ?
и то и другое

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

Тема в архиве.