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

Software Occlusion Culling (комментарии) (7 стр)

Страницы: 14 5 6 7 8 9 Следующая »
#90
16:17, 5 апр. 2011

TarasB
+1 
Тоже интересно почему DICE-ы юзают Z-буфер 256x114 float. Из чего исходили?


#91
16:18, 5 апр. 2011

TheGrayWolf
> Тоже интересно почему DICE-ы юзают Z-буфер 256x114 float. Из чего исходили?

чтобы работало быстрее :)

#92
16:23, 5 апр. 2011

Z
> Извини, а тъ делал HWOC, на реальнъх даннъх, где много-много DIP-ов и прочее? И
> как оно жило?
> Т.е. там или синхронизация или визуальнъе баги.
Outlaw
> ясно, теоретика видно сразу
Блин, парни. Я же не яйцами меряться пришел. Я вам говорю то, что знаю. А вы тупо все отрицаете.
Я уже давал вам ссылку на игру, где это работает, причем работает просто замечательно.
Splinter Cell:Conviction. AAA тайтл, в некоторых сценах до 6к DIP-ов. Весь Occlusion на DX9 и XBOX360 около 2-3 миллисекунд, на OpenGL хуже, около 15.
Да, я тоже считал, что чтение из видеопамяти - зло. Но как показала практика - при прямых руках, это не так и уж и страшно.

#93
16:24, 5 апр. 2011

TheGrayWolf
> Тоже интересно почему DICE-ы юзают Z-буфер 256x114 float. Из чего исходили?
чтобы в Local Store помещался на спу

#94
16:56, 5 апр. 2011

TarasB

>Ну вот закрасил этот объект этот пиксел. И значит, все другие уже не видны. Облом.
>Что делать? Как растеризовать окклузион так, чтобы он строго попал внутрь?

Имхо никак эта проблема не решается. Нужно чтобы буфер для OC был точно такого же размера как для рендера.
А если совсем придираться и рендер в мультисэмпловый буфер - еще и с точно такими же субсэмплами.

#95
16:57, 5 апр. 2011

shekh
> Имхо никак эта проблема не решается.

В общем, понятно, на этот вопрос пока забили.
Тогда я (когда-нибудь, когда буду это делать) буду применять ту технику с отрисовкой без границы.

#96
17:43, 5 апр. 2011

Necrys
> Он у них кстати и в первом так же фейлил.

Я думаю это просто косяк тех, кто делал уровень и расставлял оклюдеры.
Нежели алгоритма.

#97
17:50, 5 апр. 2011

VirT
> Я писал OGL реализацию и сравнивал производительность с DX.
Вот что интересно - как замерил что там 1ms? Т.е. с/без механизмом оклюжна на простой сцене, или просто сам ридбек столько стоил? Если второе, то ето неправильно, надо тестить вообще без ридбека как оно на простъх сценах, когда вся отрисовка пайплайнится и буферируется.

#98
18:36, 5 апр. 2011

Z
> надо тестить вообще без ридбека как оно на простъх сценах
Какой смысл тестить на простой сцене? Зачем тебе вообще какой-то окклющен тест на простой сцене, где проще все подрят рисовать. Не стоит оптимизировать, если нечего оптимизировать.
Для DX есть либы от НВИДИА и АТИ(про этого вендора не уверен), они позволяют мерять перфоменс видеокарточки. + можно написать встроенный перфоманс замеритель, который показывает на что у тебя уходит время кадра.
А мерять лучше всего так:
Берешь сцену, где у тебя без OcclusionQuery, скажем 15 000 DIP и 500 ms на кадр.
Включаешь OQ, получаешь 5 000 и 30 ms
Убираешь все объекты сцены, которые отсек OQ, выключаешь OQ, получаешь теже 5000 DIP и 35 ms/
Значит OQ стоит 5 ms.
Но это весь тест. Как правильно померять только ридбек, на самом деле сложно сказать. Тут ты прав, т.к. редбек, это только функция драйвера, он дальше сам определяет что и как делать, по сути от него требуется только переключить DMA контроллер, который уже позже сам разрулит доступ к памяти, когда ты уже будешь читать нужные тебе данные.
Все ведь еще зависит от задачи. Ведь если у вас так построенна сцена, что вашему OQ необходимо отсекать по 1 миллиону треугольников за кадр, то я не уверен, что софтовый растеризатор справится с этим.

#99
18:53, 5 апр. 2011

VirT
Так оно читает сдоунсемпленнъй буффер с прежнего или с текущего кадра?

> Ведь если у вас так построенна сцена, что вашему OQ необходимо отсекать по 1
> миллиону треугольников за кадр, то я не уверен, что софтовый растеризатор
> справится с этим.
Ну, он то работать будет с другим набором даннъх, как и HWOC конечно же, для такой сценъ.

#100
19:09, 5 апр. 2011

Z
> Так оно читает сдоунсемпленнъй буффер с прежнего или с текущего кадра?
С текущего. Можно сделать разные tricks, типа считаем с пред. кадра, или между рачетом и получением результата делаем какую-нибудь работу. Например, можно делать построцесс с пред. кадра и выводить результат на экран, т.е. игрок как бы получает картинку не в текужем кадре, а в следующем. Это позволит дать время видеокарточке отбработать наш OQ.
Более того, я знаю очень известные тайтлы, где вообще используется обычный DX OcclusionQuery, там просто архитектура рендера построена таким образом, что когда мы просим результат, то он уже готов. А если игра, не дай бог, на получание результата тратит какое-то время, т.е. собственно ждет синхронизации, то выводится сообщение об ошибке, и тестеры или геймдизы отсылают это обратно к программерам и те дальше полируют систему, чтобы синхронизации не было.
Z
> Ну, он то работать будет с другим набором даннъх, как и HWOC конечно же, для
> такой сценъ.
Да, точно ))) Какой еще миллион треугольников )) Тут я что-то протупил.

#101
19:13, 5 апр. 2011

VirT
> Ведь если у вас так построенна сцена, что вашему OQ необходимо отсекать по 1
> миллиону треугольников за кадр, то я не уверен, что софтовый растеризатор
> справится с этим.
Ну тут надо применять какие то ограничения, например рассматривать и растеризовать ближайшие/крупные треугольники до определенного количества (до определенного бюджета времени на ЦПУ). К тому же можно сделать упрощенную геометрию (по идее пару квадов может даже хватить), главное что бы она была консервативна по отношению к исходной геометрии модели.

#102
19:22, 5 апр. 2011

dmikos
Да, привильно. Буффер строиться по окклюдерам, где треугольников совсем мало, а объекты тестируются по боундинг боксам (ну, или по другой упрощенной геометрии), что тоже незатратно.

#103
5:07, 6 апр. 2011

VirtT
>Весь Occlusion на DX9 и XBOX360 около 2-3 миллисекунд, на OpenGL хуже, около 15.
а чего так на ГЛ много? разница в 5-7 раз.

#104
15:19, 6 апр. 2011

Outlaw
> а чего так на ГЛ много? разница в 5-7 раз.
Ну, про Винду сложно сказать почему так, там в драйвер особо не залезешь. На Маке можно еще посмотреть вызовы драйвера по OpenGL Profiler, так вот он показывал, что куча времени уходит на формирование следующего пакета для видеокарты (следуюшего после ридбека). Скорее всего сбрасываются какие-то внутренние состояния, или кеш, и драйвер по новому все собирает. В августе прошлого года Apple выпустили update для видео-драйверов и вообще для графической системы в целом. После него жить стало намного легче! Производительность увеличилась ощутима. Про это даже писали Valve, и ребята из Transgaming'a тоже говорили, что это спасло им жизнь и прервало мучения по оптимизации.
innuendo
> С этого места поподробнее, не все тут в это верят
Да, по мне так тоже изврат. Слишком это как-то нестабильно. Но все же вполне юзабельно.
В начале рендера ты все отправляешь на окклюжен тест, потом делаешь другие проходы, которые от этого теста не зависят. Например, ShadowPass или какой-нибудь EnvironmentSuperLightPass. За это время вполне вероятно, что данные уже будут готовы.
Опять же. Очень часто принятое мнение основывается на устаревших фактах. Когда-то OQ был совсем плох. Но за что я люблю Майкрософт, так за то, что они заботятся о своих продуктах, особенно, которые относятся к разработке чего либо. Так с того времени, когда считалось, что эта вещь совсем неюзабельна, прошло много времени. За это время DX тоже изменился и во многом стал работать быстрее и оптимальнее.

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

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