[G] Мега оптимизация

[Sqwer]

Теперь , когда мы научились отсекать ненужные объекты, находящиеся вне пирамиды камеры( https://guest3d.wohlnet.ru/forum/index.php?topic=731.0 ), вновь появилось желание для дальнейшего усовершенствования и оптимизации.

Во многих игровых движках используются продвинутые методы отсечения ненужной геометрии. для индор сцен хорошо себя зарекомендовала BSP технология, а для аутдор - всё сложнее.

Возник ворос: как избавиться от рендеринга невидимого объекта, стоящего за препятствием? (Рисунок ниже)

Данный принцип используется в игре Call Of Duty 4 , те когда боундинг бокс одного предмета находится за другим боксом иного объекта и полностью закрывает его, первый объект не рендится. При том создаётся впечатление что всё это происходит динамически, без использования заранее подготовленных деревьев.

[cashis]

Мдаа интересненько ! Полезно очень будет, но к сожалению не знаю даже чем помочь. Потом надо бы сделать большую тему по оптимизации и описать все способы оптимизации.

[Sqwer]

Не ужели никто не делал больших сцен, содержащих более 200К поликов?!

Пока на ум приходит только следующее:

1) Порталы/сектора , которые делаются "ручками"
2) Первое приближение frustum culling через дерево из AABB
3) Окончательное frustum culling

[→|๖ۣۜDen|←]

Есть такой вариант - создать второй рендер с боксами (для меньшого просчёта геометрии) с различными RGB цветами. Запускать проверку на цвет, если есть в сцене такой цвет (r,g,b) то в первом рендере объект рендерится, если нету то ообъект соответсвенно не рендерится.

Существует технология Occlusion Query, где уже описан похожий алгоритм.

Всё бы просто - но как в КВЕСТЕ реализовать проверку вырисовывания данного цвета (r,g,b)?

[Viik]

Ну Ден правильно пишет, с помощью оклюжен квери это и делаеться. Но все не так просто как проверка цвета:
http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter06.html

Не ужели никто не делал больших сцен, содержащих более 200К поликов?!

Знакомый делал проект на 20 миллионов поликов, без всяких извратов с кулингом, просто минимум дроу колов и лоды, скорость полностью зависела от процессора.

Подобная оптимизация подходит только для специфических проектов, то что в сцене больше "200К поликов" толком ниочем не говорит.

Данный принцип используется в игре Call Of Duty 4

- источник?

[Sqwer]

Данный принцип используется в игре Call Of Duty 4
- источник?

наблюдения через программу 3Д Риппер

с помощью оклюжен квери это и делаеться.

Т.е. он уже зашит в Квест? Насколько я понял, при данной технологии мы всё равно посылаем геометрию на обработку, проводим тестирование, а дальше по результатам теста мы рисуем только необходимое(освобождая от черезмерной нагрузки пиксельный блок) - это так?

[Sqwer]

Любопытный факт, квест работает согласно логике, описанной выше в моём посте. Но тут важен порядок следования рендеринга объектов.

1
Т.е. если оъект "А" закрывается объектом "Б", и объект "Б" рендится первее "А", то от объекта "А" вызывается только геометрия, но он не растеризуется.

2
Т.е. если оъект "А" закрывается объектом "Б", и объект "Б" рендится познее "А", то от объекта "А" вызывается геометрия и он  растеризуется.

Логично предположить, что для увеличения скорости нам надо отсортировать объекты по удалению. Чем ближе предмет к камере, тем первее он появляется

[Viik]

Так это наверное просто Early Z в работе. Заполняеш деп буффер и не чистиш пока все не отрисуеться (там еще пачка вещей есть которые тоже не нужно делать чтобы все работало). Крайсиз эту штуку интенсивно использует, в моих тенях она поидее тоже работает, если я ее не отключил 
Она не помогает ренедрить сцену с миллионами поликов но позволяет снять нагрузку с пиксельного шейдера, а так как на последних видяхах шейдера унифицированные то и вертексным шейдерам будет легче дышать.

Для Оклюжен Кверис оригинальная геометрия не используеться, использует упрощенную или вообще боксы. Почитай статью там это все расказано, чтобы это заработало в квесте нужно делать кастомные ченелы. Это имеет смысл делать только при специфических особенностях проекта. 99% архитектурной визуализации к этому не относиться, так как камера в любой момент времени может видеть всю сцену целиком. Эффективность "кверис" при этом будет низкая и от нее будет больше тормозов чем толку.

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

[→|๖ۣۜDen|←]

Как писал Sqwer, по вызову геометрии, зависящей от порядка,

если оъект "А" закрывается объектом "Б", и объект "Б" рендится первее "А", то от объекта "А" вызывается только геометрия, но он не растеризуется.

удалось наконец вызывать рендер геометрии в зависимости от расстояния от камеры до самого объекта. Т.е. чем ближе объект к камере, тем выше приоритет рендеринга этого объекта. Пару слов как это работает:
в массив заносятся данные о расстоянии объектов к камере, затем эти данные сортируются, и в том порядке в каком выстроились расстояния (по возрастанию), происходит вызов объектов. всё динамически, и менятся порядок в зависимости от того как меняется дистанция.
Объекты должны быть в паблик статусе (-> Make Channel Public) и занесены в менеджере массивов.
Итак, единственно что следует сделать, при добавлении собственных "сотен" объектов (ибо оптимизацию можно проверить с большим кол-вом объектов ) это преобразовать объекты в паблик, узнать расстояния, и занести всё в массив.
Тестим. В квесте так никто не делал наверно ещё.

P.s. Интересное видео демонстрирующее оптимизацию объектов, скрывающихся за объектами на первом плане  http://www.umbrasoftware.com/index.php/player

[Sqwer]

Спасибо, ->Den<-, всё работает, объекты сортируются по расстоянию до активной камеры и рендятся соответственно этой сортировке.

и всё же очень хочется написать собственный канал ( используя SDK) чтоб он всё делал автоматически, а располагался между каналом Renderer и множеством каналов 3D object.

PS не доверяю квестовскому Lua и OO, из-за того что не знаю их скорость исполнения.

[Sqwer]

Для многих эффектов часто требуется глубина сцены.

Viik подсказал следующий алгоритм рендеринга:
1) Рендер глубины с записью в Z буфер при отключенном цвете
2) Рендер непрозрачных объектов сцены без записи в Z буфер.
3) Рендер прозрачных объектов по сортировке.

Собственно вопрос: как отключить цветовой рендер в первом стейте 1)?  (не нашёл я)

Суть метода в том, что мы рендим сцену сверхдещёвым шейдом глубины и заполняем З буфер, на основе которого будет выполнятся Early Z  для уже более тяжёлых шейдов, где очень важен овердрав.

[Viik]

Добавь вот этот рендер стейт при рендере глубины:
ColorWriteEnable = 0;

[DimiS]

Для многих эффектов часто требуется глубина сцены.

а можно узнать для каких? С шейдерами только знакомлюсь пока, хочу для себя систематизировать какой финт ушами когда может понадобится применить.

Насколько я понял, рендер глубины с записью в Z-буффер служит потом ещё и для оптимизации при нормальном рендере объектов. Чёто типа оклюжен кулинга получается, я правильно понял?

[Viik]

а можно узнать для каких?

Банальные DOF, SSAO, атмосферный скатеринг и скатеринг воды, деферред тени, для Motion Blur тоже можно использовать.

Насколько я понял, рендер глубины с записью в Z-буффер служит потом ещё и для оптимизации при нормальном рендере объектов. Чёто типа оклюжен кулинга получается, я правильно понял?

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

[DimiS]

SSAO, атмосферный скатеринг и скатеринг воды, деферред тени,

вот этих пока не знаю но думаю потом разберусь

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

Я не знаю насколько часто применяются вертекс шейдеры изменяющие геометрию. Могут ли они стать тормозом для такого метода, их ведь надо будет применять в обоих проходах?
Не возникает ли проблем при отрисовке второго прохода из-за того, что глубина уже как-бы занята первым проходом. Т.е. видяха считает, что не нужно отрисовывать пиксели даже ближайшего объекта, ведь у них точно такая же глубина как у уже отрисованых? Хотя я бы попробовал уменьшить немного фар плейн для второго прохода.
Насколько данный способ оптимизации сравним с сортировкой объектов по расстоянию до камеры, есть ли смысл использовать сортировку, если используется рендер глубины?