Теперь , когда мы научились отсекать ненужные объекты, находящиеся вне пирамиды камеры( https://guest3d.wohlnet.ru/forum/index.php?topic=731.0 ), вновь появилось желание для дальнейшего усовершенствования и оптимизации.
Во многих игровых движках используются продвинутые методы отсечения ненужной геометрии. для индор сцен хорошо себя зарекомендовала BSP технология, а для аутдор - всё сложнее.
Возник ворос: как избавиться от рендеринга невидимого объекта, стоящего за препятствием? (Рисунок ниже)
Данный принцип используется в игре Call Of Duty 4 , те когда боундинг бокс одного предмета находится за другим боксом иного объекта и полностью закрывает его, первый объект не рендится. При том создаётся впечатление что всё это происходит динамически, без использования заранее подготовленных деревьев.
Мдаа интересненько ! Полезно очень будет, но к сожалению не знаю даже чем помочь. Потом надо бы сделать большую тему по оптимизации и описать все способы оптимизации.
Не ужели никто не делал больших сцен, содержащих более 200К поликов?!
Пока на ум приходит только следующее:
1) Порталы/сектора , которые делаются "ручками"
2) Первое приближение frustum culling через дерево из AABB
3) Окончательное frustum culling
Есть такой вариант - создать второй рендер с боксами (для меньшого просчёта геометрии) с различными RGB цветами. Запускать проверку на цвет, если есть в сцене такой цвет (r,g,b) то в первом рендере объект рендерится, если нету то ообъект соответсвенно не рендерится.
Существует технология Occlusion Query (http://www.gamedev.ru/code/terms/OcclusionQuery), где уже описан похожий алгоритм.
Всё бы просто - но как в КВЕСТЕ реализовать проверку вырисовывания данного цвета (r,g,b)?
Ну Ден правильно пишет, с помощью оклюжен квери это и делаеться. Но все не так просто как проверка цвета:
http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter06.html (http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter06.html)
ЦитироватьНе ужели никто не делал больших сцен, содержащих более 200К поликов?!
Знакомый делал проект на 20 миллионов поликов, без всяких извратов с кулингом, просто минимум дроу колов и лоды, скорость полностью зависела от процессора.
Подобная оптимизация подходит только для специфических проектов, то что в сцене больше "200К поликов" толком ниочем не говорит.
ЦитироватьДанный принцип используется в игре Call Of Duty 4
- источник?
ЦитироватьДанный принцип используется в игре Call Of Duty 4
- источник?
наблюдения через программу 3Д Риппер
Цитироватьс помощью оклюжен квери это и делаеться.
Т.е. он уже зашит в Квест? Насколько я понял, при данной технологии мы всё равно посылаем геометрию на обработку, проводим тестирование, а дальше по результатам теста мы рисуем только необходимое(освобождая от черезмерной нагрузки пиксельный блок) - это так?
Любопытный факт, квест работает согласно логике, описанной выше в моём посте. Но тут важен порядок следования рендеринга объектов.
1
Т.е. если оъект "А" закрывается объектом "Б", и объект "Б" рендится первее "А", то от объекта "А" вызывается только геометрия, но он не растеризуется.
2
Т.е. если оъект "А" закрывается объектом "Б", и объект "Б" рендится познее "А", то от объекта "А" вызывается геометрия и он растеризуется.
Логично предположить, что для увеличения скорости нам надо отсортировать объекты по удалению. Чем ближе предмет к камере, тем первее он появляется
Так это наверное просто Early Z в работе. Заполняеш деп буффер и не чистиш пока все не отрисуеться (там еще пачка вещей есть которые тоже не нужно делать чтобы все работало). Крайсиз эту штуку интенсивно использует, в моих тенях она поидее тоже работает, если я ее не отключил ;D
Она не помогает ренедрить сцену с миллионами поликов но позволяет снять нагрузку с пиксельного шейдера, а так как на последних видяхах шейдера унифицированные то и вертексным шейдерам будет легче дышать.
Для Оклюжен Кверис оригинальная геометрия не используеться, использует упрощенную или вообще боксы. Почитай статью там это все расказано, чтобы это заработало в квесте нужно делать кастомные ченелы. Это имеет смысл делать только при специфических особенностях проекта. 99% архитектурной визуализации к этому не относиться, так как камера в любой момент времени может видеть всю сцену целиком. Эффективность "кверис" при этом будет низкая и от нее будет больше тормозов чем толку.
На мой взгляд, при всех остальных "ньюансах" квеста, такая оптимизация даст незначительный результат.
Как писал
Sqwer, по вызову геометрии, зависящей от порядка,
Цитироватьесли оъект "А" закрывается объектом "Б", и объект "Б" рендится первее "А", то от объекта "А" вызывается только геометрия, но он не растеризуется.
удалось наконец вызывать рендер геометрии в зависимости от расстояния от камеры до самого объекта. Т.е. чем ближе объект к камере, тем выше приоритет рендеринга этого объекта. Пару слов как это работает:
в массив заносятся данные о расстоянии объектов к камере, затем эти данные сортируются, и в том порядке в каком выстроились расстояния (по возрастанию), происходит вызов объектов. всё динамически, и менятся порядок в зависимости от того как меняется дистанция.
Объекты должны быть в паблик статусе (-> Make Channel Public) и занесены в менеджере массивов.
Итак, единственно что следует сделать, при добавлении собственных "сотен" объектов (ибо оптимизацию можно проверить с большим кол-вом объектов :)) это преобразовать объекты в паблик, узнать расстояния, и занести всё в массив.
Тестим. В квесте так никто не делал наверно ещё. :)
P.s. Интересное видео демонстрирующее оптимизацию объектов, скрывающихся за объектами на первом плане http://www.umbrasoftware.com/index.php/player
Спасибо, ->Den<-, всё работает, объекты сортируются по расстоянию до активной камеры и рендятся соответственно этой сортировке.
и всё же очень хочется написать собственный канал ( используя SDK) чтоб он всё делал автоматически, а располагался между каналом Renderer и множеством каналов 3D object.
PS не доверяю квестовскому Lua и OO, из-за того что не знаю их скорость исполнения.
Для многих эффектов часто требуется глубина сцены.
Viik подсказал следующий алгоритм рендеринга:
1) Рендер глубины с записью в Z буфер при отключенном цвете
2) Рендер непрозрачных объектов сцены без записи в Z буфер.
3) Рендер прозрачных объектов по сортировке.
Собственно вопрос: как отключить цветовой рендер в первом стейте 1)? (не нашёл я)
Суть метода в том, что мы рендим сцену сверхдещёвым шейдом глубины и заполняем З буфер, на основе которого будет выполнятся Early Z для уже более тяжёлых шейдов, где очень важен овердрав.
Добавь вот этот рендер стейт при рендере глубины:
ColorWriteEnable = 0;
Цитата: Sqwer от 25 июля 2009, 09:47:23
Для многих эффектов часто требуется глубина сцены.
а можно узнать для каких? С шейдерами только знакомлюсь пока, хочу для себя систематизировать какой финт ушами когда может понадобится применить.
Насколько я понял, рендер глубины с записью в Z-буффер служит потом ещё и для оптимизации при нормальном рендере объектов. Чёто типа оклюжен кулинга получается, я правильно понял?
Цитироватьа можно узнать для каких?
Банальные DOF, SSAO, атмосферный скатеринг и скатеринг воды, деферред тени, для Motion Blur тоже можно использовать.
ЦитироватьНасколько я понял, рендер глубины с записью в Z-буффер служит потом ещё и для оптимизации при нормальном рендере объектов. Чёто типа оклюжен кулинга получается, я правильно понял?
Да, причем это может критически сказаться на производительности. Незаменимая вещь при высоком филрейте.
Цитата: Viik от 28 июля 2009, 15:24:16
SSAO, атмосферный скатеринг и скатеринг воды, деферред тени,
вот этих пока не знаю но думаю потом разберусь :)
Цитата: Viik от 28 июля 2009, 15:24:16
Да, причем это может критически сказаться на производительности. Незаменимая вещь при высоком филрейте.
Я не знаю насколько часто применяются вертекс шейдеры изменяющие геометрию. Могут ли они стать тормозом для такого метода, их ведь надо будет применять в обоих проходах?
Не возникает ли проблем при отрисовке второго прохода из-за того, что глубина уже как-бы занята первым проходом. Т.е. видяха считает, что не нужно отрисовывать пиксели даже ближайшего объекта, ведь у них точно такая же глубина как у уже отрисованых? Хотя я бы попробовал уменьшить немного фар плейн для второго прохода.
Насколько данный способ оптимизации сравним с сортировкой объектов по расстоянию до камеры, есть ли смысл использовать сортировку, если используется рендер глубины?
ЦитироватьЯ не знаю насколько часто применяются вертекс шейдеры изменяющие геометрию. Могут ли они стать тормозом для такого метода, их ведь надо будет применять в обоих проходах?
Даже если шейдер сложный, как скининг например, всеравно видяха его посчитает быстрее чем ЦПУ, поэтому тут особого выбора то и нет. Как бы могут, но на последних видяхах шейдера унифицированы на уровне железа, тобиш разгружая пиксельный шейдер легче будет дышать и вертексному.
ЦитироватьНе возникает ли проблем при отрисовке второго прохода из-за того, что глубина уже как-бы занята первым проходом. Т.е. видяха считает, что не нужно отрисовывать пиксели даже ближайшего объекта, ведь у них точно такая же глубина как у уже отрисованых? Хотя я бы попробовал уменьшить немного фар плейн для второго прохода.
На втором проходе делаеться только тест глубины, запись в буфер не делаеться. А видяха сама отсекает не прошедшие тест фрагменты еще до пиксельного шейдера. Есть ряд условий при которых автоматический кулинг работать не будет. Более подробно в GPU Programming guide 7xxx от Нвидии.
ЦитироватьНасколько данный способ оптимизации сравним с сортировкой объектов по расстоянию до камеры, есть ли смысл использовать сортировку, если используется рендер глубины?
Это разные вещи, сортировка в первую очередь нужна для блендинга полупрозрачной геометрии и кулинга на уровне боундинг боксов. Ничто не мешает использовать оба варианта сразу.
И вновь проблемы:
При раздельном рендере полигонов , находящихся на одной плоскости, возникает впечатление "запаздывания " результатов одного от другого. В итоге при изменении положения камеры появляется эффект наложения обного объекта на другой...
Viik подсказал рендить объекты прямиком через Chanel Caller, всё работает на ура. Но как быть с рендером в текстуру? И как в шедах указать параметры источников света, если они определяются в канале Render ?
По поводу первого: у нас есть вызов из бэк буфера, таким образом можно глубину закодировать 3 цвета RGB , а потом при надобнасти восстановить. Но это лишний гемор.., и скорее всего есть другой метод решения проблемы.
Пример возможности использования бэкбуфера прилагается 422
По поводу второго: в шейдер можно передать параметры напрямую через CHANNELVECTOR и CHANNELVALUE. Это тоже - гемор...
Исправлено ли это в Квесте версии 4.3.х ?
При раздельном рендере полигонов , находящихся на одной плоскости, возникает впечатление "запаздывания " результатов одного от другого. В итоге при изменении положения камеры появляется эффект наложения обного объекта на другой...
Это из-за того что положение камеры считаеться несколько раз за один кадр, сколько раз вызываеться столько раз и пересчитываеться, сделай математику в ней принудидельно Ван Тайм.
Viik подсказал рендить объекты прямиком через Chanel Caller, всё работает на ура. Но как быть с рендером в текстуру? И как в шедах указать параметры источников света, если они определяются в канале Render ? Они "определяються" там где ты их вызываеш, Рендер ченел тут не нужен, просто в ченел коллере их вызывай и все.