Quest3D - Русскоязычное сообщество

Теперь , когда мы научились отсекать ненужные объекты, находящиеся вне пирамиды камеры( http://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)

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

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

- источник?

наблюдения через программу 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;

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

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

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

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

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

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

Даже если шейдер сложный, как скининг например, всеравно видяха его посчитает быстрее чем ЦПУ, поэтому тут особого выбора то и нет. Как бы могут, но на последних видяхах шейдера унифицированы на уровне железа, тобиш разгружая пиксельный шейдер легче будет дышать и вертексному.

На втором проходе делаеться только тест глубины, запись в буфер не делаеться. А видяха сама отсекает не прошедшие тест фрагменты еще до пиксельного шейдера. Есть ряд условий при которых автоматический кулинг работать не будет. Более подробно в GPU Programming guide 7xxx от Нвидии.

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

И вновь проблемы:

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

Viik подсказал рендить объекты прямиком через Chanel Caller, всё работает на ура. Но как быть с рендером в текстуру? И как в шедах указать параметры источников света, если они определяются в канале Render ?

По поводу первого:  у нас есть вызов из бэк буфера, таким образом можно глубину закодировать 3 цвета RGB , а потом при надобнасти восстановить. Но это лишний гемор.., и скорее всего есть другой метод решения проблемы.

Пример возможности использования бэкбуфера прилагается 422

По поводу второго: в шейдер можно передать параметры напрямую через CHANNELVECTOR и CHANNELVALUE. Это тоже - гемор...

Исправлено ли это в Квесте версии 4.3.х ?

Это из-за того что положение камеры считаеться несколько раз за один кадр, сколько раз вызываеться столько раз и пересчитываеться, сделай математику в ней принудидельно Ван Тайм.
Они "определяються" там где ты их вызываеш, Рендер ченел тут не нужен, просто в ченел коллере их вызывай и все.