Middleware

Umbra, Occlusion Booster (OB), dPVS, sPVS

31 мар 2010 14:58
+16
(Текст записи скрыт. Показать...)
Т.к. я, среди многих других вещей, также являюсь представителем компании Umbra Software на территории СНГ, то решил создать собственный топик посвященный middleware технологиям компании.

Umbra Software предлагает подпрограммное обеспечение (англ. middleware) для оптимизации графических движков для игр на ПК и игровых консолей (X360, PS3).

Если коротко, то это технология отсечения лишних объектов (occlusion culling). Если какой-то объект не виден (полностью заслоняется другим или находится вне камеры), то его можно не рендерить и таким образом увеличить скорость обработки. А так как таких лишних объектов на картах много, то получается значительный выигрыш в скорости. Технологии компании Умбра очень эффективно справляются с этой узкой задачей определения лишних объектов.

Общее впечатление что же вообще предлагается можно увидеть в этом маленьком двухминутном ролике. Ролик старый, но базовое понимание дает.


Из широко известных проектов, технологии компании используются в:
Guild Wars 2
Dragon Age: Origins
Mass Effect 2
Flatout 2
EVE Online
Age of Conan: Hyborian Adventures
EverQuest 2
Star Wars Galaxies
Lord of The Rings Online
Dungeons & Dragons
Alan Wake

Неполный список проектов и компаний (например отсутствует Северный клинок от ITT/Zakta) можно посмотреть здесь: http://www.umbrasoftware.com/index.php?page=clients2

Преинтеграция осуществлена в следующие движки: Big World, GameBryo, Unreal Engine (Epic), Hero Engine. Естественно технологию можно достаточно легко интегрировать и в другие движки. Работает на трех главных платформах: PC, PS3, X360.

Существует также более новый ролик, где сильно больше деталей (но я все равно рекомендую сначала посмотреть старый ролик).

Тоже хороший ролик: четырехминутная презентация на GDC 2009.

Разные брошюры, статьи, ссылки на интервью и демонстрации находятся по этому адресу.


По разнообразным вопросам Умбры, начиная от расценок и заканчивая получением доступа к evaluation version обращайтесь ко мне ( личка дтф; e-mail: mikko@umbrasoftware.com; Skype: mikkovedru ).


В этой же теме я предлагаю задавать вопросы, просить прокомментировать слухи (дадим им бой!), получать ответы, обсуждать технологию и делиться своим опытом использования технологий компании.
Отправлено 31.03.2010 в 15:51
Отвечает на сообщение 342413
+1
Мне вот интересно, сколько денег просят? =)

В целом первый приходящий в голову солюшин:
* WARP для софтверного рендеринга *хороших* окклюдеров в маленькую текстуру;
* Построение иерархического Z-буфера из нее (с мип-мапами);
* Простой чек каждого баундинг бокса через подходящий мип-уровень;
* Мип-уровни выбираем по размеру баундинг бокса так, чтобы чекать только пару пикселей;

Навскидку - неделя работы. Тут, видимо, что-то очень продвинутое. =)
Отправлено 31.03.2010 в 18:27
Отвечает на сообщение 342414
0
Максим Дяченко пишет:
>
> Мне вот интересно, сколько денег просят? =)


Существенно.


> Навскидку - неделя работы. Тут, видимо, что-то очень
> продвинутое. =)


Чтобы не гадать предлагаю лицензировать OB, купить дополнительную опцию "Предоставление исходников" и узнать правильный ответ! :))
Отправлено 31.03.2010 в 18:45
Отвечает на сообщение 342472
0
Микко Ведру пишет:
>
> > Навскидку - неделя работы. Тут, видимо, что-то очень
> > продвинутое. =)
>
> Чтобы не гадать предлагаю лицензировать OB, купить
> дополнительную опцию "Предоставление исходников" и
> узнать правильный ответ! :))


Ну вот чтобы не получилось как с книжками:
http://www.realtimerendering.com/blog/best-book-title-ever-period/

Потому и спрашиваю. =))
Микко Ведру  31.03.2010 19:21
Отправлено 01.04.2010 в 14:54
Отвечает на сообщение 342541
0
Сергей Милойков пишет:
>
> http://www.selfshadow.com/talks/rwc_gdc2010_v1.pdf


Спасибо, интересно.

Вот это позабавило:

<rant>You’ll see these issues or their side effects even in commercial middleware.
Either there’s popping (‘latent’ queries) or the tests must be interleaved with regular
rendering, which can complicate things or restrict you.</rant>
Микко Ведру  02.04.2010 17:51
Сергей Милойков  08.04.2010 16:02
Отправлено 01.04.2010 в 16:19
Отвечает на сообщение 342541
0
Сергей Милойков пишет:
>
> http://www.selfshadow.com/talks/rwc_gdc2010_v1.pdf


Не спорю - Монреальские парни жгут напалмом. =)
Но, к сожалению, на PC такая схема быстро работать не сможет из-за синхронизации с GPU. Хотя демку сварганить и посмотреть не помешало бы.
Максим Дяченко  16.04.2010 22:47
Антон Шеховцов  16.04.2010 23:56
Максим Дяченко  24.04.2010 18:35
В ветке ещё 2 сообщения
Максим Дяченко  17.04.2010 00:22
Максим Горбань  19.04.2010 14:56
В ветке ещё 5 сообщений
Отправлено 02.04.2010 в 16:41
Отвечает на сообщение 342414
+2
Ответ разработчика из Umbra Software
Максим Дяченко пишет:
>
> В целом первый приходящий в голову солюшин:
> * WARP для софтверного рендеринга *хороших* окклюдеров
> в маленькую текстуру;
> * Построение иерархического Z-буфера из нее (с
> мип-мапами);
> * Простой чек каждого баундинг бокса через подходящий
> мип-уровень;
> * Мип-уровни выбираем по размеру баундинг бокса так,
> чтобы чекать только пару пикселей;
>
> Навскидку - неделя работы. Тут, видимо, что-то очень
> продвинутое. =)


Попросил прокомментировать разработчика из Umbra Software. Вот что он сказал (за проблемы с переводом можете винить меня):
**************************
Инженеры считают все проблемы "легкими". :) Если бы дело было так легко, то игры бы никогда не фейлились.

Предложенное решение возможно работает, но также оно является неэффективным. Оптимизатор рендера, который замедляет игру - это плохое решение. Т.е. идея не в том, что эту систему нельзя имплементировать. А в том, что эту систему нельзя имплементировать эффективно и в короткое время.

Несколько проблем, которые первым делом приходят на ум:
1. потребление памяти увеличивается просто дохрена, потому что WARP является софтовым растеровщиком и в этом решении в памяти надо хранить z-buffer и все его уровни иерархии.
2. WARP работает только на PC
3. "рендеринг *хороших* окклюдеров в маленькую текстуру" :)
Как определить что такое "хорошо"? Если это делать ручками, то на стадии level design тратим лишнее время для их определения. Например в игре WoW-ого типа, проход всех уровней и определение "хороших" окклудеров - совсем немаленькая работа. Т.е. в этом "решении" инженеры банально перепихивают проблему на головы уровневых дизайнеров.
4. Тестируем каждый баундинг бокс... вот это действительно медленно! Первым делом мы говорим об операции O(n). Например в сцене 30 000 объектов. Если объекты распределены однообразно, то внутри VF может быть примерно 25% от объектов сцены. Видимых объектов например 5% (вполне типичные цифры). Это означает, что линеарная система будет тестировать 7 500 объектов из которых только 1 500 будут видны. Таким образом система делала бы 6 000 occlusion тестов совершенно напрасно. В обычной сцене OB делает в максимуме 300-500 тестов для каждого кадра.
5. Каким образом mip level выбираем по баундинг боксу? С помощью Screen space coverage? Это означает один лишний тест для каждого объекта.

В теории решение проблемы не является сложным. На практике является.

Обычно опытные девелоперы лучше всего видят пользу. Особенно если разработчики пытались воплотить подобную систему в реальную игру, а не просто в какой-то демо-уровень. Если какой-то инженер считает, что это легкая проблема, то я даже не знаю что и сказать... Разве что сослаться на референсы: если проблема такая легкая, то неужели Bioware, ArenaNet, Turbine, Remedy, CCP и пр. стали бы лицензировать Умбровскую технологию? Все эти студии обладают умением, временем и деньгами чтобы имплементировать собственную подобную систему. Однако проблема не является "легкой" и вышеназванные фирмы лицензируют Умбру/OB потому что лицензирование - значительно более быстрый и дешевый способ получить функциональность, чем делать это самим.
**************************
Отправлено 02.04.2010 в 16:59
Отвечает на сообщение 342790
0
Микко Ведру пишет:
>
> Предложенное решение возможно работает, но также оно
> является неэффективным. Оптимизатор рендера, который
> замедляет игру - это плохое решение. Т.е. идея не в
> том, что эту систему нельзя имплементировать. А в том,
> что эту систему нельзя имплементировать эффективно и в
> короткое время.


Ну "замедление" очевидно присказка здесь. Никто не мерял, насколько я вижу. В "Сталкере", если не ошибаюсь, используется аналогичное решение.

> Несколько проблем, которые первым делом приходят на
> ум:
> 1. потребление памяти увеличивается просто дохрена,
> потому что WARP является софтовым растеровщиком и в
> этом решении в памяти надо хранить z-buffer и все его
> уровни иерархии.
> 2. WARP работает только на PC


Для PC очевидно не проблема. И насколько я вижу по Таск Менеджеру - речь идет о паре мегабайт.

> 3. "рендеринг *хороших* окклюдеров в маленькую
> текстуру" :)
> Как определить что такое "хорошо"? Если это делать
> ручками, то на стадии level design тратим лишнее время
> для их определения. Например в игре WoW-ого типа,
> проход всех уровней и определение "хороших" окклудеров
> - совсем немаленькая работа. Т.е. в этом "решении"
> инженеры банально перепихивают проблему на головы
> уровневых дизайнеров.


Боже упаси руками расставлять такие свойства. =)
Какие проблемы определять это динамически по расстоянию и размеру?

> 4. Тестируем каждый баундинг бокс... вот это
> действительно медленно! Первым делом мы говорим об
> операции O(n). Например в сцене 30 000 объектов. Если
> объекты распределены однообразно, то внутри VF может
> быть примерно 25% от объектов сцены. Видимых объектов
> например 5% (вполне типичные цифры). Это означает, что
> линеарная система будет тестировать 7 500 объектов из
> которых только 1 500 будут видны. Таким образом система
> делала бы 6 000 occlusion тестов совершенно напрасно. В
> обычной сцене OB делает в максимуме 300-500 тестов для
> каждого кадра.


Э-э-э, я конечно извиняюсь - но ваш инженер совсем нас за нубасов держит. =)

Очевидно - тест должен проходить иерархически по дереву сцены.

> 5. Каким образом mip level выбираем по баундинг боксу?
> С помощью Screen space coverage? Это означает один
> лишний тест для каждого объекта.


Ну вот тут я не понял - почему проецирование для теста является "еще одним лишним тестом".

> В теории решение проблемы не является сложным. На
> практике является.
>
> Обычно опытные девелоперы лучше всего видят пользу.
> Особенно если разработчики пытались воплотить подобную
> систему в реальную игру, а не просто в какой-то
> демо-уровень. Если какой-то инженер считает, что это
> легкая проблема, то я даже не знаю что и сказать...
> Разве что сослаться на референсы: если проблема такая
> легкая, то неужели Bioware, ArenaNet, Turbine, Remedy,
> CCP и пр. стали бы лицензировать Умбровскую технологию?
> Все эти студии обладают умением, временем и деньгами
> чтобы имплементировать собственную подобную систему.
> Однако проблема не является "легкой" и вышеназванные
> фирмы лицензируют Умбру/OB потому что лицензирование -
> значительно более быстрый и дешевый способ получить
> функциональность, чем делать это самим.
> **************************


Ну такое. Поэтому про цену и спрашиваем. =)
Опытным девелоперам обычно влом, если что. Им нужно чтобы завтра работало. ;)

Как мне, например. Но я обязательно попробую на следующей неделе и расшарю результат.
Микко Ведру  02.04.2010 17:53
Максим Дяченко  02.04.2010 18:10
Отправлено 31.03.2010 в 15:56
Отвечает на сообщение 342413
0
Да, ждем эту радость в Unity и пускаем слюни :) оптимизация будет просто отличной судя по всему
Отправлено 31.03.2010 в 17:02
Отвечает на сообщение 342418
0
Уточнения
Сергей Королёв пишет:
>
> Да, ждем эту радость в Unity и пускаем слюни :)
> оптимизация будет просто отличной судя по всему


Соглашение с Unity - это круто. Но надо только понимать, что там используются разные технологии по сравнению с полновесными играми.

Т.е. до недавнего времени у Umbra Software было два продукта:
1. Umbra (да-да, я знаю что назвать продукт и компанию одинаково было плохой идеей). Umbra - это тот продукт, который всем знаком. Работает в рил-тайме и предварительных вычислений не требует.
2. OB (Occlusion Booster). Совсем новый, выпустили только в октябре прошлого года. Куча всего по сравнению с Umbra переделано, хотя внешне для игроделов изменения попытались минимизировать. Но общая идея осталась той же самой включая работу в real-time и отсутствие предварительных вычислений.

Если людям интересно, то могу подробнее описать в чем разница.

3. А в Unity - новый продукт, использующий ново-старую технологию под названием PVS. Это технология предварительного обсчета, которая все считает заранее, но расчетами в реальном времени не занимается. PVS это совсем-совсем новое, специально девелопили для Unity. Mы этот продукт даже пока официально не анонсировали и не продаем.

Т.е. "Umbra в Unity" - это круто, но это не та Умбра, которая Umbra/OB.

Это кстати отвечает на немой вопрос, каким образом Unity бесплатно предоставляет технологии компании Umbra для всех клиентов с лицензией Unity Pro, в то время как лицензии на Umbra/OB стоят значительно больше всего пакета Unity Pro. Разные продукты - поэтому и появилась такая возможность.

Но не надо думать что в Unity запихали какую-то дешевую фигню. :) Разные игры, разные масштабы, разные требования, разные возможности. PVS и Umbra/OB - это просто о разном... Поэтому PVS тоже должна очень неплохо улучшить скорость.

Когда будете тестировать, то я, а думаю и многие другие, с удовольствием и интересом бы посмотрели на результаты тестов производительности!
Отправлено 31.03.2010 в 17:10
Отвечает на сообщение 342447
0
Спасибо за развернутый ответ!
По идее можно было бы реал-тайм обработку сделать как опцию за деньги, и вам бы было хорошо и юзерам "с большими проектами" :)
Микко Ведру  31.03.2010 17:57
Сергей Королёв  31.03.2010 18:01
Микко Ведру  31.03.2010 18:06
Отправлено 31.03.2010 в 17:31
Отвечает на сообщение 342413
0
В UE3 Umbra уже используется или это пока только планируется? Если уже используется, то, соответственно, входит ли в комплект общей лицензии на движок или надо докупать отдельно?

Можно ли включить/выключить и посмотреть на разницу?
Отправлено 31.03.2010 в 18:05
Отвечает на сообщение 342458
0
Юрий Грачев пишет:
>
> В UE3 Umbra уже используется или это пока только
> планируется? Если уже используется, то, соответственно,
> входит ли в комплект общей лицензии на движок или надо
> докупать отдельно?


Используется давно. Надо докупать отдельно.


> Можно ли включить/выключить и посмотреть на разницу?


Можно. Для этого надо договориться со мной, чтобы я дал доступ к evaluation version OB. Это полноценная версия с одним лишь ограничением - работает только один месяц. За этот срок можно просто затеститься. :)

Интеграция OB в чистый UE3 длится примерно 30-60 минут. БОльшая часть времени уходит на перекомпилирование проекта. Интеграция очень легкая: пару файликов скопировать, парочку вещей залинковать. :)

Это если говорить о чистых исходниках UE3. Если там были произведены какие-то изменения в части рендера, то работы естественно будет больше.
Отправлено 31.03.2010 в 18:51
Отвечает на сообщение 342413
0
все на пальцах и без цифр\тестов.
хорошо бы в реальности погонять. а то действительно не понятно чем своя система иерархического оклужен теста хуже Убры.
Отправлено 31.03.2010 в 19:39
Отвечает на сообщение 342480
0
Денис Овод пишет:
>
> все на пальцах и без цифр\тестов.
> хорошо бы в реальности погонять. а то действительно не
> понятно чем своя система иерархического оклужен теста
> хуже Убры.


Я уже давно пытаюсь их назвать какие-нибудь точные цифры, но все же знают программистское: "Ну это зависит от ситуации, поэтому точных цифр мы дать не можем даже под пыткой". :-/

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

Чем свои варианты хуже? Ну кроме вполне очевидных типа скорости, работы на трех платформах и отлаженности, есть также качество фильтровки. В OB окклудером может служить каждый пиксель. Т.е. у нас нет никаких проблем например с листвой деревьев. Или например с анимацией и движущими объектами у людей тоже часто проблемы - у нас их нет.

Но в основном это конечно скорость, поддержка разных платформ и отлаженность.

А еще Умбру/OB можно использовать не только для Occlusion Culling, но и для многого другого. :) На фиче Intersection test весь Alan Wake (новая игра от Remedy) построен...
Отправлено 31.03.2010 в 19:43
Отвечает на сообщение 342489
0
Я, конкретно сейчас, не в геймдеве поэтому просить эвалуйшен видимо смысла нет. хотя и интересно.
HW Occlusion Culling как раз и работает на пиксельном уровне.
Я правильно понял, что утверждается что для PC-only проектов Umbra лишняя трата денег? :)
Микко Ведру  31.03.2010 19:50
Денис Овод  01.04.2010 16:23
Отправлено 31.03.2010 в 20:02
Отвечает на сообщение 342489
0
это пеар!!!)

> Я уже давно пытаюсь их назвать какие-нибудь точные
> цифры, но все же знают программистское: "Ну это зависит
> от ситуации, поэтому точных цифр мы дать не можем даже
> под пыткой". :-/

Я на GDC смотрел в том году - раза в 2 прирост был на такой сцене http://www.youtube.com/watch?v=ilTQAJcS-Kk (15->30 fps, PS3 hardware)

Ну на BigWorld еще демка была - в цифрах не помню, но шустрее бегало значительно с включенной убмрой.
Отправлено 01.04.2010 в 16:26
Отвечает на сообщение 342489
0
Микко Ведру пишет:
>
> Чем свои варианты хуже? Ну кроме вполне очевидных типа
> скорости, работы на трех платформах и отлаженности,
> есть также качество фильтровки. В OB окклудером может
> служить каждый пиксель. Т.е. у нас нет никаких проблем
> например с листвой деревьев. Или например с анимацией и
> движущими объектами у людей тоже часто проблемы - у нас
> их нет.


Ну у WARP'а проблем с листвой и анимацией не будет. Растеризация, ёпт. =)

По скорости - надо конечно проверить, но мне что-то подсказывает, что тоже будет меньше 1 мс на приличных сценах. А для X360 можно использовать Splinter Cell 5 схему (см. выше линк). С PS3 чуть тяжелее - придется писать софтверный растеризатор для SPU (хотя... наверняка есть уже?..).
Антон Юдинцев  01.04.2010 21:03
Отправлено 02.04.2010 в 16:47
Отвечает на сообщение 342480
0
Денис Овод пишет:
>
> все на пальцах и без цифр\тестов.
> хорошо бы в реальности погонять. а то действительно не
> понятно чем своя система иерархического оклужен теста
> хуже Убры.



Попросил прокомментировать разработчика из Umbra Software. Вот что он сказал (за проблемы с переводом можете винить меня):
**************************

Измерение скорости всегда является контекстнозависимым и проблемным.

Например сильно ли поможет знание, что в Age of Conan в некоторых местах выигрыш составляет 300%?

Проблема в том, с чем сравнивать. Например у Epic есть собственная система, но они не дают нам опубликовать цифры...

Ну а с другой стороны, OB работает настолько хорошо что бОльшая часть наших клиентов в конце концов даже и не пытается создать собственную систему.
**************************

Это к вопросу, почему не дают цифры, которыми можно было бы всем показывать.
Отправлено 08.04.2010 в 15:48
Отвечает на сообщение 342795
0
>Например сильно ли поможет знание, что в Age of Conan в некоторых местах выигрыш составляет 300%?
Ето если в сравнении с "без оклюжена"? Ето конечно интересно, но не познавательно, ибо если затачивать сценъ под оклюжн, а потом его отключить прибъль от него естественно будет огромная. Но ето только из-за построения уровней под оклюжн, не более.

А иначе ясно, что разработка middleware въигръвает разработке того же функционала inhouse, в том и поинт сей разработки.
Кроме одного момента - middleware оно старается бъть универсальнее, а inhouse наоборот и есть момент, когда написаннъй inhouse оклюжн под частнъй случай будет чисто теоретически много раз бъстрее универсального оклюжн буфера Umbra (примерно 2d оклюжн).

Разумеется будущее за генеральнъми решениями, в связи их более простой интеграции в продукт, бъла бъ цена в рамках разумного.
Микко Ведру  08.04.2010 19:28
Антон Юдинцев  09.04.2010 22:22
Микко Ведру  10.04.2010 01:01
В ветке ещё 2 сообщения
Отправлено 01.04.2010 в 09:25
Отвечает на сообщение 342413
0
Честно говоря, пускал слюни именно на реалтаймовый анализ в Unity 3.0, а оказалось вон оно как... предрасчитанный PVS... Это конечно тоже хорошо, но уже не cutting-edge. Да и в Unity iPhone расчёт grid-PVS уже есть давным-давно.

Кстати говоря, на днях доделали тулзу для расчёта PVS в Танках Онлайн. 30% прироста производительности, только карта считалось, зараза, 16 часов. Ну а динамический окклюдинг по силуэтам ещё в прошлом году внедрили.
Отправлено 02.04.2010 в 19:33
Отвечает на сообщение 342413
+2
Разработчик из Umbra Software. Подробнее о latent queries vs interleaved query, и об общих вопросах на тему, что же такое OB. Вот что он сказал (за проблемы с переводом можете винить меня):
**************************
При использовании latent queries может возникать popping. При использовании interleaved query такой проблемы нет, зато требуется синхронизировать GPU и CPU и в простых имплементациях (naive implementation) это приводит к значительным GPU stalls. В OB эта проблема решена путем тайминга вызовов на рендеринг и на occlusion query. Это полностью проблему не решает, но приводит к значительно меньшему (возможно 0ms) stall-а на GPU.

Latent queries:
+ GPU и рендеринговому треду не обязательно быть синхронизированными.
+ По этой причине легче интеграция в уже существующий рендер (например экзотические рендеры, в которых GPU задерживается на три кадра).
- Возможные артефакты при рендеринге (popping)
- Внутреннюю иерархию OB нельзя использовать эффективно -> в больших сценах вынуждены делать больше queries.

Interleaved queries:
+ Иерархию можем использовать эффективно -> вне зависимости от размера сцены, количество queries остается маленькой.
+ Нет артефактов
- GPU и рендеринг тред должны быть синхронизированы -> сложнее интегрировать в экзотические рендеры.

Экзотический рендер в данном случае означает плохо имплементированный рендер. Например Bioware, Epic, Remedy, ArenaNet, RockStar, Bungie и другие, написали свои рендеры таким образом, что OB туда интегрировался в два счета -> профессиональная работа.

В любом случае, мы говорим о tradeoff. Инженеры думаю, что получат идеальную победу (систему, в которой нет никакого дополнительного overhead), но на практике этого конечно же не получается.

С точки зрения конечного результата без разницы происходит ли stallin CPU или GPU, как влияет query latence и т.д. Все хорошо и без разницы почему, до тех пор пока в результате frame time в игре уменьшается. А если OB не может увеличить скорость, то тоже нет никакой разницы даже если любой возможный overhead сведен к нулю.

Иногда не очень опытным инженерам очень трудно понять, что решает конечный результат. :)

Одна из типичных вещей, за которые инженеры (особенно не очень опытные) хватаются, это то, что драйверы возможно рендерят с задержкой в три кадра. DX specification это разрешает, но на практике это означает что GPU постоянно опаздывает. Драйверы могут рендерить с задержкой (latent) в основном для того, чтобы не происходило т.н. GPU starvation, т.е. ситуации когда CPU не успевает запихивать в GPU дополнительного материала для рендеринга из-за чего происходит GPU stall. Этой фишкой выравнивают неровности происходящие в rendering pipe. Но никакой производитель GPU ни в коем случае не хочет, чтобы GPU рендерил с задержкой.

Если это происходит, то тут у нас на практике два варианта:
1. Игра является GPU bounded т.е. рендеринг кадра на GPU длится дольше чем рендеринг на CPU.
- Если CPU постоянно кормит GPU данными, то GPU постоянно же отстается - все больше и больше. По этой причине рано или поздно CPU будет вынужден ждать GPU, т.е. CPU будет idle. В этой ситуации совершенно без разници, происходит ли CPU idle на том же кадре или тремя кадрами позже. Рано или поздно синхронизацию в любом случае придется делать.

2. Игра является CPU bounded, т.е. обработка кадра на CPU длится дольше чем на GPU.
- В этом случае GPU stall происходят на каждом кадре и из-за queries, это stalling практически не влияет. OB естественно помогает, потому что она помогает работе треда рендеринга (меньше рендеринг-вызовов драйверы, меньше state change). Driver overhead обычно составляет большую часть работы CPU и его уменьшение обычно значительно помогает клиентам.

"Все пиксели являются окклудерами" - фича, которая работает в любой системе, которая использует occlusion query. Фишка в том, что эффективное использование occlusion query очень сложная задача. Да, occlusion query можно использовать неэффективно. То что все пиксели являются окклудерами означает, что все релевантные объекты нужно вывести на экран, после чего сделать occlusio queries всем объектам, которые возможно спрятаны.

Это сложный tradeoff: например если объект уже срендерен, то ему понятное дело нет смысла делать query (т.е. он уже на экране и это лишняя работа). Если же объект на экран не выведен, то он естественно не работает в качестве окклудера. Другими словами одна из серьезных проблем: придумать такие heurestics, которые решат что надо рендерить, чему стоит сделать query, когда все это сделать и т.д.

Другая проблема это query rendering. Это является чистым overhead-ом и идея состоит в том, чтобы делать query только если есть причина думать, что этот объект спрятан. Если query делать каждому объекту, то возникает значительный overhead и скорость прорисовки нисколько не увеличивается.

OB не является occlusion query wrapper, как думают многие инженеры. Occlusion queries - это просто способ узнать, виден какой-то объект или нет. Но то же самое можно сделать и с помощью растеринга и с помощью других решений. Сами Occlusion query OB оставляет интеграционному слою (OB говорит что occlusion query надо сделать, но использование API остается на совести интегрированного слоя --> другими словами OB не содержит platform dependent code). Идея OB состоит в том, что он доставляет пользователю компонент, который говорит какие объекты надо рендерить и когда это надо делать. Из-за объектной иерархии и из-за использования разных алгоритмов, OB делает проверки occlusion query только жалкому количеству из всех объектов на сцене.

Другими словами OB может выяснить множество видимых объектов делая только мизерное количество occlusion query -> очень эффективно!


OB можно представить как неким visibility preprocessor (где препроцессинг совсем минимальный) и задача которого в минимизации driver and GPU overhead.

Разговор принимает примерно такой же оборот как и разговоры о рендеринге вообще. Ведь создание хорошего рендеринга - это всего лишь: рисуем треугольники, добавляем текстуры + считаем освещение и тени в шейдерах. Все эти проблемы являются т.н. решенными, но несмотря на это некоторые игры выглядят хорошо, а некоторые очень плохо.

Пойнт не в том, что OB делает что-то, что никто и никогда не смог бы сделать. Пойнт в том, что OB выполняет эту работу очень эффективно и что его работа является доказанной (список игр, где используется технология).

Вполне вероятно, что инженер Х сможет сделать достаточно эффективную culling систему. Но я не верю, что найдется много людей, которые смогут сделать более эффективную и гибкую систему, при этом потратив на нее меньше времени (годы). Очень многие это пытались сделать, но безуспешно (здесь стояло название очень знаменитой компании).

Еще несколько пойнтов о пользе OB:
- out-of-the-box система, которая работает в очень многих (больше 20 миллионов проданных игр используют технологию) играх совершенно разных типов (Eve Online, Mass Effect 2)... Один из значительных плюсов OB является т.н. автоматическая работа. После того как OB интегрирован, он работает автоматически. OB не требует никакого вклада от художников, дизайнеров или любых других. Не надо организовывать порталы, делать occluder meshs, указывать (тэгировать) окклудеров, ждать препроцессинга (PVS), делать какие-то другие дополнительные шаги и т.д.
- Можно конечно попытаться имплементировать свою систему, но это займет много времени (имплементирование, баг фиксинг) и нет никаких гарантий нормальной работы. Не лучше ли приобрести проверенный продукт с точно известной ценой и результатом, а освобожденное время потратить на разработку игры и на то, чтобы она вышла вовремя? Фирмы могут конечно делать свои версии программ по обработке текстур, но почему-то предпочитают купить лицензии на Фотошоп у Adobe. :)
- OB является очень high end tech, который сделан именно для этого. Мы используем 100% нашего рабочего времени на доработку технологии и на общение и работу с игровыми студиями. Т.е. у нас достаточно хорошая картина того, какие проблемы есть у разработчиков и как их решать.
**************************
Отправлено 06.04.2010 в 09:35
Отвечает на сообщение 342836
0
то есть Umbra использует _только_ Interleaved query?

Не совсем понятен последний "-" Latent query - ведь
принципиально и то и другое прекрасно ложится на готовый иерархический scenegraph - да то же KDtree + немного кода внутри на occludee fusion - и можно держать систему на практически константном количестве query. В общем и interleaved и latent.

Вот Popping вправду проблемма ИМХО не выправляемая на latent схемах. Очень заматно в том же GeOW2 к примеру на резких перемещениях-вращениях
Отправлено 06.04.2010 в 21:33
Отвечает на сообщение 343358
0
Алексей Смирнов пишет:
>
> то есть Umbra использует _только_ Interleaved query?


В Умбре они тоже на самом деле есть, но т.к. в OB все работает значительно лучше (а в Umbra, соответственно, хуже), то факт наличия особо не рекламируем.


> Не совсем понятен последний "-" Latent query - ведь
> принципиально и то и другое прекрасно ложится на
> готовый иерархический scenegraph - да то же KDtree +
> немного кода внутри на occludee fusion - и можно
> держать систему на практически константном количестве
> query. В общем и interleaved и latent.


Ну вот такая архитектура и такие хитрые алгоритмы.

Пример хитрости: в Umbra есть поддержка порталов (
http://en.wikipedia.org/wiki/Portal_rendering ), а в OB такой поддержки нет. Как так? Umbra работает автоматически, но при желании у игроделов была возможность помочь Умбре, указав на места расположения порталов и таким образом сделать работу Umbra более эффективной. Вроде все хорошо - кто хочет, тот тратит дополнительное время на тонкую настройку, а кто не хочет - пользуется автоматикой.

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

Поэтому в OB нет поддержки порталов. :)
Антон Шеховцов  06.04.2010 21:57
Микко Ведру  07.04.2010 03:18
Антон Шеховцов  07.04.2010 13:04
В ветке ещё 1 сообщение
Алексей Смирнов  07.04.2010 18:57
Микко Ведру  08.04.2010 19:09
Отправлено 06.10.2010 в 19:13
Отвечает на сообщение 342413
0
Технологии Umbra в Unity 3
Недавно вышла третья версия графического движка Unity ( http://dtf.ru/news/read.php?id=61532 , http://unity3d.com/unity/ ). Там очень много разных улучшений. Одним из главных является включение в нее технологии окклудинга от компании Umbra Software.

На этом видео можно посмотреть что это за технология и чем она хороша: http://vimeo.com/15189993

P.S. В самых первых комментариях к моему заглавному посту можно прочитать подробности включенной в Unity3 технологии и то, чем она отличается от продаваемых отдельно решениях (Occlusion Booster).
Отправлено 02.11.2010 в 22:13
Отвечает на сообщение 342413
0
Выпустили новую версию: Occlusion Booster 2.4.0
Главные изменения следующие:
1. Добавили примеры интеграции OB на OpenGL и поддержки tiled rendering.
2. Новые фичи для дебаггинга. Например, теперь можно замораживать occlusion culling. Когда включаешь эту фичу, то occlusion queries больше не будут вызываться. Полезно для дебаггинга и измерения нагрузки (overhead) от OB. Также добавили возможности для визуализации.
3. Увеличение производительности во всех многопоточных программах. Касается всех платформ.
4. Добавили API для включения pre-computed PVS visibility. Это именно та фича, которую сделали для Unity 3 и о которой я говорил в первых комментариях к своему заглавному посту. Сейчас даем только API, чтобы при желании можно было бы ознакомиться с будущими изменениями. Сами тулзы для PVS последуют в будущем. Впрочем, если у вас есть желание попробовать/потестировать этот незаконченный функционал, то сконтактируйтесь со мной. Делайте это побыстрее - количество мест ограниченно (ищем буквально пару человек).


Новость на английском для простых людей:
http://www.umbrasoftware.com/index.php?mact=News,cntnt01,detail,0&cntnt01articleid=49&cntnt01origid=51&cntnt01returnid=54

Рас Новость для технарей:
http://www.umbrasoftware.com/uploads/umbra-ob-apidoc/html/release_notes.html
Списки доступа
  • Подписчики [580]
  • Белый список [3]
  • Черный список [1]
Права доступа
Вы можете читать группу, но не можете отвечать на сообщения и создавать новые темы.
Доступ для остальных:
анонимы : могут читать
новые : могут читать
постоянные : полный доступ

Copyright © 2020 ООО "ДТФ.РУ". Все права защищены.

Воспроизведение материалов или их частей в любом виде и форме без письменного согласия запрещено.

Замечания и предложения отправляйте через форму обратной связи.

Пользовательское соглашение