суббота, 18 июня 2011 г.

Отложенное освещение и затенение в игре Tabula Rasa (Перевод) Часть 1

 

Rusty Koonce
NCsoft Corporation

Оригинал: http://http.developer.nvidia.com/GPUGems3/gpugems3_ch19.html

Эта глава является дополнением к статье Олеса Шишковстова "Deferred Shading in S.T.A.L.K.E.R." Она основана на работе , которая проводилась в течение 2 лет, над механизмом визуализации в многопользовательской онлайн игре Tabula Rasa разработанной Ричардом Гарриотом. Работа Шишовстова написана на тему фундаментального применения отложенного освещения и затенения (ООЗ),а эта глава рассматривает вопросы связанные с механизмом основанным на ООЗ на более высоком уровне.

19.1 Введение

В компьютерной графике понятие затенение связано с процессом визуализации освещенного обьекта. Этот процесс состоит из следующих шагов:
  1. Вычисление геометрических параметров обьекта
  2. Определение характеристик материала поверхности
  3. Вычисление падающего освещения на обьект
  4. Определение взаимодействия между поверхностью и светом, и получение окончательной визуализации
Типичный механизм визуализации выполняет все эти 4 гаша за один раз, когда визуализирует объект в какой-нибудь сцене. ООЗ является методом, который разделяет первые два шага от последних двух.
Мы предполагаем, что читатель знаком с базовыми понятиями ООЗ. Для ознакомления с этими базовыми понятиями рекомендуется прочитать следующие работы: Shishkovtsov 2005, Policarpo and Fonseca 2005, Hargreaves and Harris 2004.
В данной главе, термин форвард шейдинг относится к традиционному методу затенения в котором все 4 шага данного процесса выполняются вместе. Термин эффект относится к Direct3D D3DX эффекту. Термины техника, аннотация и переход использованы в контексте D3DX эффекта.
Термин шейдер материала ( material shader ) отсносится к эффекту отображения геометрических фигур, а термин световой шейдер (light shader ) относится к визуализации видимого света. Тело( body) – это обьект который отображается в данной сцене
Мы не использовали оптимизацию или применение GPU в этой главе. Все решения являются общими, нацеленными либо на Shader Model 2.0 or Shader Model 3.0 hardware. Таким образом, мы стараемся подчеркнуть технику, а не само применения данной техники.

19.10 Заключение

ООЗ перешло от теории к практическому применению. Часто бывает так, что некоторые методы очень дороги, слишком абстрактны или просто не практичны для использования вне ограниченной демо версии. Что касается ООЗ, то было подтверждено, что этот метод является достойным методом, который может быть применен в реальной игровой среде.
Но есть некоторые препятствия для использования ООЗ, вот главные из них :
  • Большое использование памяти
  • Нет устранения контурных неровностей
  • Недостаток правильной поддержки alpha-blending
Мы обнаружили, что современное hardware среднего класса может обрабатывать требования памяти для простейшего разрешения, в то время как более высококлассное hardware может обрабатывать более высокое разрешение со всеми включенными фичами. При использовании DirectX 10 hardware, MRT- performance был значительно улучшен при помощи АТI и NVIDIA. DirectX 10 и Shader Model 4.0 так же обеспечивают выполнение целочисленных операций затенения пикселей, что может быть использовано для уменьшения использования памяти. Исполнение будет улучшаться с использованием нового hardware и с появлением новых фич.
Надежный способ обнаружения граней в совокупности с правильной фильтрацией может значительно минимизировать неровности вокруг граней. Хотя этот метод не настолько точен как субсэмплтнг (subsampling) , этот метод все равно смягчает неровности для восприятия глаза.
Главной особенностью ООЗ является то, что не поддерживается alpha-blending. Мы сознательно пожертвовали качеством визуализации, но в целом мы получили результаты подтверждающие выгодность использования ООЗ.
Главные преимущества ООЗ :
· Затраты на освещение не зависят от сложности сцены.
· Затенители имеют доступ к глубине и другой информации о пикселях
· Каждый пиксель освещен только один раз.
· Полное разделение кода затенения : визуализация обьекта отделена от расчета освещения
Каждый день появляются новые методы обработки изображения, с использованием которых выгода использования ООЗ может как увеличиться, так и уменьшиться. Сложно предсказать,что будет в будущем, но мы уверены в правильности выбора использования ООЗ в нынешних условиях.

19.11 Ссылки

Hargreaves, Shawn, and Mark Harris. 2004. "6800 Leagues Under the Sea: Deferred Shading." Available online at http://developer.nvidia.com/object/6800_leagues_deferred_shading.html.
Kozlov, Simon. 2004. "Perspective Shadow Maps: Care and Feeding." In GPU Gems, edited by Randima Fernando, pp. 217–244.
Martin, Tobias, and Tiow-Seng Tan. 2004. "Anti-aliasing and Continuity with Trapezoidal Shadow Maps." In Eurographics Symposium on Rendering Proceedings 2004, pp. 153–160.
Policarpo, Fabio, and Francisco Fonseca. 2005. "Deferred Shading Tutorial." Available online at http://fabio.policarpo.nom.br/docs/Deferred_Shading_Tutorial_SBGAMES2005.pdf.
Shishkovtsov, Oles. 2005. "Deferred Shading in S.T.A.L.K.E.R." In GPU Gems 2, edited by Matt Pharr, pp.143–166. Addison-Wesley.
Sousa, Tiago. 2005. "Generic Refraction Simulation." In GPU Gems 2, edited by Matt Pharr, pp. 295–306. Addison-Wesley.
Stamminger, Marc, and George Drettakis. 2002. "Perspective Shadow Maps." In ACM Transactions on Graphics (Proceedings of SIGGRAPH 2002) 21(3), pp. 557–562.

19.2 Дополнительная Информация

В игре Tabula Rasa, мы использовали форвард шейдинг (forward shading) механизм в качестве механизма визуализации надстроенного над DirectX 9, используя ретушеры созданные на HLSL D3DX эффектах. В наших эффектах применялась pass annotations внутри методов, которые описывают освещение, поддержанное определенным переходом. Механизм со стороны CPU определяет какое освещение падает на каждое тело. Эта информация в совокупности с другой информацией об освещение была использована для задания параметров освещения и для способствовала совершению переходов нужное количества раз.
Несколько фактов о forward shading подходе :
  • Вычисление того какой именно свет воздействует на конкретный объект занимает время у CPU и в худшем случае это занимает O(n x m) операций
  • Ретушеры часто требуют более чем один render pass чтобы выполнить освещение, в сложных случаях требуется O(n) render passes для n освещений
  • Добавление новых осветительных моделей или типов освещения требует изменений всех эффектов исходного файла
  • Ретушеры довольно быстро сталкиваются с вычислительными ограничениями в Shader Model 2.0
При работе на ММО у нас нету полного контроля над игровой средой. Мы не можем контролировать сколько игроков одновременно видимы или сколько визуальных эффектов могут быть одновременно активны.Мы почувствовали, что это может дать нам визуализацию, которая может подойти к механизму любой топовой игры а так же освободит от зависимости сложности освещения от геометрической сложности сцены.
Метод ООЗ предоставляет следующие преимущества:
  • Затраты на освещение не зависят от сложности сцены.
  • Новые типы освещения или осветительные модели могут быть добавлены без изменений в затенителях объектов.
  • Затенители объектов не выполняют функции освещения.
ООЗ требует поддержки MRT (multiple render target ) и использует увеличенный обьем памяти, из чего следуют повышенные требования к железу, которые превышают минимальные требования, которые мы бы хотели иметь. Поэтому мы решили поддерживать ООЗ так же как и forward shading. Мы усилили существующий forward shading механизм , надстроив над ним новый канал ООЗ.

19.3 Поддержка метода затенения

Даже с механизмом, основанным на задержанном затенении, предварительное затенение все еще необходимо для просвечивающей геометрии (подробнее см. раздел 19.8). Мы сохранили поддержку для какала полного предварительного затенения в нашем рендерере. Наш рендерер предварительного затенения используется для просвечивающей геометрии, также как и альтернативный канал для all geometry on lower-end hardware
Эта часть описывает методы, которые использовались нами, чтобы сделать одновременную поддержку для каналов как предварительного, так и задержанного затенения более управляемой.

19.3.1 Ограниченный набор функциональных возможностей

Мы решили свести осветительные свойства нашего канала предварительного затенения к очень маленькому подмножеству свойств, поддерживаемых каналом задержанного затенения. Некоторые свойства не могли поддерживаться по техническим причинам, некоторые не были поддержаны в связи с сжатыми сроками, но многие не были поддержаны лишь с целью упростить разработку.
Наш рендер предварительного затенения поддерживает только полусферический, направленный и точечный свет (световые точки), причем световые точки являются дополнением. Другие типы света не поддерживаются ( такие как прожекторы узконаправленного света, модульный свет, оба поддерживаемые нашим рендером задержанного затенения). Затенения и другие свойства, найденные в канале задержанного затенения не были поддержаны в нашем канале предварительного затенения.
Наконец, шейдер (программа построения теней) в рендере предварительного затенения мог выполнять вершинное или пикселное освещение. В канале задержанного затенения любое освещение – пикселное.

19.3.2 Один эффект, множество технологий

В наших эффектах есть технологии предварительного затенения, задержанного затенения, рендеринга схем затенения и т.д. Мы используем аннотацию о технологии чтобы уточнить, для какого из видов рендеринга была написана технология. Это позволяет нам включить весь код шейдера (программы построения теней) в единственный файл эффекта, который обрабатывает все вариации шейдера, используемые механизмом рендеринга. См. перечень 19-1. Это включает в себя технологии статической и кинетической геометрии предварительного затенения, технологии для статической и кинетической геометрии «материального затенения» в нашем канале задержанного затенения, также как и технологии построения схем затенения.
Размещение всего кода шейдера в одном месте позволяет нам совместно использовать как можно большую часть этого кода во всех различных технологиях. Вместо того, чтобы использовать отдельный, единый файл эффекта, мы разбили его на множество библиотек шейдера, исходные файлы, которые содержат совместные вершинные и пикселные программы и обобщенные функции, которые используются многими эффектами. Такой подход минимизировал дублирование кода шейдера, что делает легче поддержку, снижает число ошибок и улучшает последовательность шейдеров.

19.3.3 Назначение световых приоритетов

Наш рендер предварительного затенения быстро генерирует дополнительные пути формирования изображения, когда больше световых зон становятся активными на геометрическом объекте. Это генерирует не только больше draw calls, но также и большее количество изменений состояний и больше overdraw излишнего рисования. Мы обнаружили, что наш рендер предварительного затенения с задействованной всего лишь долей света мог быть медленнее, чем наш рендер задержанного затенения с большим количеством задействованного света. Таким образом, чтобы максимизировать производительность, мы строго ограничили, какое количество света могло бы быть активным на отдельном геометрическом объекте в канале предварительного затенения.

  1.    // These are defined in a common header, or definitions  
  2.    // can be passed in to the effect compiler.  
  3.    #define RM_FORWARD 1  
  4. #define RM_DEFERRED 2  
  5. #define TM_STATIC 1  
  6. #define TM_SKINNED 2  
  7. // Various techniques are defined, each using annotations to describe  
  8.    // the render mode and the transform mode supported by the technique.  
  9.    technique ExampleForwardStatic  
  10. <  
  11.   int render_mode = RM_FORWARD;  
  12.   int transform_mode = TM_STATIC;  
  13. >  
  14. { . . . }  
  15. technique ExampleForwardSkinned  
  16. <  
  17.   int render_mode = RM_FORWARD;  
  18.   int transform_mode = TM_SKINNED;  
  19. >  
  20. { . . . }  
  21. technique ExampleDeferredStatic  
  22. <  
  23.   int render_mode = RM_DEFERRED;  
  24.   int transform_mode = TM_STATIC;  
  25. >  
  26. { . . . }  
  27. technique ExampleDeferredSkinned  
  28. <  
  29.   int render_mode = RM_DEFERRED;  
  30.   int transform_mode = TM_SKINNED;  
  31. >  
  32. { . . . } 

Наш канал задержанного затенения может справляться с 30, 40, 50 или более активными динамическими световыми точками в одном кадре, с затратами, не зависящими от обрабатываемой геометрии. Тем не менее, наш рендер предварительного затенения быстро сбивается когда всего лишь пара световых точек начинает действовать на большое количество геометрии. При наличии такого различия в работе двух каналов использование одинакового света в обоих каналах было бы невозможным.
Мы дали художникам и дизайнерам возможность назначать приоритеты точкам света и устанавливать, должен ли свет использоваться каналом предварительного затенения, задержанного затенения или обоими. Световой приоритет используется как в каналах предварительного, так и задержанного затенения когда механизму нужно снизить освещение в пользу производительности. С каналом предварительного затенения снижение освещения просто означает убрать его из сцены; тем не менее, в канале задержанного затенения, тени могли бы быть отключены или другие дорогие свойства света снижены на основании производительности, настроек качества или светового приоритета.
В общем, освещение карт было нацелено на канал задержанного затенения. Быстрый второй проход был осуществлен, чтобы убедиться, что освещение в канале предварительного затенения было приемлемым. В целом, единственной дополнительной работой стало увеличение рассеянного освещения в канале предварительного затенения с целью сделать так, чтобы иметь в нем меньше световых точек, чем к канале задержанного затенения.

Комментариев нет:

Отправить комментарий