Введение в обзоры графических технологий в играх
Современная терминология 3D графики
Обзор игры на iXBT.com
Разработчик: Human Head Studios (при участии 3D Realms Entertainment)
Издатель: 2K Games
Дата выхода: июль 2006 г.
Графический API: OpenGL
Техническая характеристика
Prey — это шутер с видом от первого лица, разработанный компанией Human Head Studios и основанный на модифицированной версии игрового движка DOOM 3. Играбельные демо-версии игры были выпущены 22 июня 2006 года в версии для ПК и 30 июня — для Xbox 360 (через Xbox Live Marketplace). Релиз игры состоялся 11 июля в Северной Америке и 14 июля в Европе. Хотя в Prey мы видим очень хорошую графику и качественно сделанные уровни, но ничего особенного и ранее не виденного в этой игре нет. Значительных изменений со времен DOOM 3 и Quake 4, использующих тот же движок, по сути, не видно. Игра похожа на перечисленные проекты визуально, так как технологических изменений было сделано не так много. За исключением поддержки parallax mapping, разве что.
Движок DOOM 3 использует унифицированную модель попиксельного освещения Блинна-Фонга, каждый рассчитываемый источник света дает диффузную и спекулярную составляющие на всех поверхностях. Как и DOOM 3 с Quake 4, игра выделяется тем, что на всех поверхностях используется несколько текстурных слоев, в том числе наложение карт нормалей, а для рендеринга некоторых из материалов применяется простая разновидность параллаксмаппинга. Также в Prey используется большее количество фильтров постобработки, по сравнению с их количеством в ранее перечисленных играх на том же движке, в этот список входят: bloom/glow, color correction (desaturation и saturation), blur, motion blur (radial blur), heat haze, distortion, refraction и др.
Уровни в Prey выполнены в виде закрытых пространств, в основном это комнаты и коридоры, есть и редкие открытые пространства, но небольшие и/или упрощенные, такие же, как и в DOOM 3 и Quake 4. В движке DOOM 3 для рендеринга теней используются теневые объемы (stencil shadow volumes), некоторые из теней (решетки и вентиляторы) — проективные текстуры. Метод был впервые предложен Frank Crow в 1977 году, а в дальнейшем Tim Heidmann использовал стенсильный буфер для рендеринга теней в реальном времени. У первоначального метода было ограничение, он работал только в случае нахождения камеры вне тени. Но в 2000 году сразу несколько исследователей нашли путь для доработки метода и обхода этого ограничения. Оригинальный метод получил название "z-pass", а новый — "z-fail" (или "depth-fail"). Похоже, что впервые новая техника была описана в презентации Sim Dietrich, а детальный анализ техники был проведен в отчете NVIDIA под авторством Cass Everitt и Mark Kilgard в 2002 году. Джон Кармак из id Software использовал технику в движке DOOM 3, поэтому иногда она называется "Carmack's Reverse". Есть несколько вариантов использования теневых объемов, использующих стенсильный буфер, варианты отличаются производительностью и точностью. Метод z-fail, использующийся в DOOM 3, отличается улучшенным использованием стенсильного буфера, и способен к обработке пересекающихся теневых объемов, а камера может быть расположена внутри них.
Игра содержит достаточно большое количество пиксельных и вершинных шейдеров низкой и средней сложности. Пиксельные шейдеры в игре используются для расчета освещения от нескольких источников света, наложения карт нормалей, параллаксмаппинга, используются в алгоритмах постфильтрации, включая фильтры bloom, blur, отражения и преломления и др. Графическим движком игры используются шейдерные программы, написанные на ассемблерном языке, они хранятся в подкаталоге glprogs архива pak000.pk4. В пиксельных шейдерах сделаны оптимизации в виде возможности выполнения расчетов с пониженной точностью (OPTION ARB_precision_hint_fastest), которые обычно полезны почти для всех видеокарт NVIDIA.
Объем геометрии, обрабатываемый движком игры в пределах одного кадра в типичных условиях и на максимальных настройках, оказался ниже среднего уровня для современных трехмерных игр. Количество полигонов в кадре изменяется от 7000 до 250000 полигонов на кадр, в редких случаях доходя до 300000 обрабатываемых треугольников. Сложность геометрии на разных уровнях отличается, есть примеры с 50000 средних треугольников на кадр, а есть — с 200000. Среднее количество обрабатываемых треугольников в кадре по всей игре на максимальных настройках составляет примерно 90000-110000.
Prey требователен к объему видеопамяти, особенно — при отключенном текстурном сжатии. В разрешении 1024x768 с включенным антиалиасингом 4x и максимально возможными настройками качества (но без отключения текстурного сжатия) игра использует до 270-280 мегабайт видеопамяти. Среднее использование видеопамяти в тестовом разрешении 1024x768 с включенным мультисэмплингом составляет 190-200 Мб. Даже на минимальных настройках и при разрешении 640x480, игрой используется более 100 Мб видеопамяти, так что объем локальной видеопамяти 128 мегабайт является предпочтительным значением для Prey даже для low-end видеокарт. На таких видеокартах достичь приемлемой играбельности может не получиться, в том числе из-за того, что часть системной памяти будет дополнительно использоваться как нелокальная видеопамять. А на 256-мегабайтных картах играть в Prey вполне комфортно во всех случаях, кроме отключенного насильно текстурного сжатия, когда требуемый объем видеопамяти возрастает в 1.7-2.0 раза, по сравнению с обычным режимом.
Так как игра использует OpenGL API, применить утилиту профилирования PIX из Microsoft DirectX 9 SDK для анализа не представляется возможным. Но NVIDIA PerfKit 2 предоставляет данные своих аппаратных счетчиков производительности, а также специальных OpenGL счетчиков, через интерфейс Performance Data Helper. Для сбора и анализа данных в таких случаях можно воспользоваться консолью управления Windows — встроенным приложением Performance Monitor (PerfMon). Но эта утилита неудобна для частого использования и для анализа больших массивов данных, также в ней нельзя задать частоту опроса счетчиков менее одной секунды, что бывает полезно в некоторых случаях. Поэтому автором была написана собственная утилита по сбору данных счетчиков NVIDIA по интерфейсу PDH, с необходимыми для анализа возможностями: выбором нужных счетчиков, запуском и остановкой считывания по "горячим клавишам", звуковым оповещением запуска и остановки подсчета, экспортом собранных данных в файлы *.csv формата, подсчетом средних, минимальных и максимальных значений и др.
Используя эту утилиту, написанную специально для технологических обзоров, были собраны привычные уже цифры статистики по нескольким уровням игры. Полученные нами цифры показывают, что при максимальных настройках и разрешении 1024x768 видеочип GeForce 7800 GTX простаивал (по счетчику gpu_idle) в среднем около 10% времени, причем, значение сильно зависит от уровня, есть случаи лишь с 2% простоя, когда производительность почти полностью ограничена видеочипом, а есть уровни с 20% времени простоя GPU. Сложность и количество пиксельных шейдеров достаточно велики, значение pixel_shader_busy составляет в среднем около 28-30%, есть уровни с 15, а есть — с 35-40%. А среднее использование блоков вершинных шейдеров (счетчик vertex_shader_busy) крайне невелико — всего лишь 2% (максимальная цифра — 5%)! Налицо очень низкая эффективность использования вершинных процессоров, причем это уже не списать на ограничения Direct3D, связанные с высокой затратностью вызовов отрисовки. Средняя доля времени ожидания блоками пиксельных шейдеров выборки данных из текстур (счетчик shader_waits_for_texture) — 15-17%, а доля ожидания окончания операций записи во фреймбуфер (shader_waits_for_rop) и того больше — целых 27-30%! Эти цифры говорят о явном смещении баланса в пиксельных шейдерах от математической сложности к текстурной обработке, а также об огромных потерях времени на операции с фреймбуфером, упоре в производительность этих частей графического конвейера.
Как обычно, мы исследовали и влияние некоторых настроек игры на средние показатели счетчиков производительности NVIDIA, сведя данные нескольких опытов в общую таблицу:
| Счетчик | Default | FSAA off | AF off | Post FX off | Shadows off | Bump+ Spec off | Shader off | Textures low |
| gpu_idle, % | 0.0 | 2.5 | 2.9 | 0.2 | 0.0 | 0.4 | 0.0 | 0.5 |
| vertex_shader_busy, % | 1.7 | 2.1 | 2.0 | 1.8 | 1.7 | 2.2 | 1.7 | 1.9 |
| pixel_shader_busy, % | 29.7 | 35.9 | 37.0 | 31.5 | 30.4 | 26.8 | 28.3 | 33.6 |
| triangle count, polys | 89855 | 87569 | 88359 | 70815 | 80361 | 85130 | 90358 | 88766 |
| shader_waits_for_texture, % | 23.8 | 25.6 | 9.0 | 26.8 | 26.1 | 19.0 | 24.2 | 15.5 |
| shader_waits_for_rop, % | 28.8 | 7.8 | 36.6 | 25.0 | 26.1 | 36.3 | 28.5 | 32.4 |
Средние значения счетчика gpu_idle сильно отличаются только для режимов с отключенным антиалиасингом и анизотропной фильтрацией, загрузка видеочипа в таких условиях неизменно снижается. Незначительно влияют на gpu_idle и некоторые из отключенных графических настроек. На значение vertex_shader_busy рассматриваемые нами настройки традиционно не оказывают почти никакого влияния, даже отключение стенсильных теней не дает изменения в цифре использования вершинных блоков. Значение pixel_shader_busy больше всего возрастает в режимах с выключенными анизотропной фильтрацией и мультисэмплингом, а снижается при отключении в меню игры карт нормалей и спекулярных карт.
Значения счетчика количества рассчитанных в кадре полигонов отличаются несильно, в небольших отличиях виновата погрешность тестирования и подсчета средних значений, полигонов используется ощутимо меньше только в режиме без теней и, особенно, в режиме отключенной постобработки. Значений счетчиков используемой локальной и системной видеопамяти в этот раз я не привожу, они показывают обычную картину: выключение антиалиасинга приводит к уменьшению цифры на несколько мегабайт, также влияет опция размера текстур, и в меньшей степени — отключение постобработки.
Значение shader_waits_for_texture сильнее всего изменяется при отключении анизотропной фильтрации. Это объясняется тем, что для анизотропии требуются дополнительные текстурные выборки. Также заметны ощутимые изменения значений счетчика в случаях с пониженным размером текстур (используется минимально возможное разрешение) и отключенным наложением карт нормалей и specular карт, что тоже понятно. Время ожидания записи данных во фреймбуфер (shader_waits_for_rop) сильно снижается в режиме с отключенным антиалиасингом, ведь мультисэмплинг увеличивает работу для блоков ROP, когда возрастает количество записываемых сэмплов. На значение этого счетчика влияет и отключение постобработки, анизотропной фильтрации и др. настройки. Интереснее всего сильное изменение в случае отключенных normal maps и specular maps. Это говорит о том, что во всех случаях операции с фреймбуфером являются наиболее важным ограничивающим производительность фактором.
Таким образом, подтверждаются выводы, написанные выше на основе усредненной статистики по всей игре — основными параметрами, ограничивающими производительность в Prey, являются работа блоков ROP и пропускная способность видеопамяти. Также сильно на скорость рендеринга влияет и скорость выборки текстур. Все остальные параметры видеокарты влияют на производительность игры в меньшей степени.
Краткая история появления
Prey с самого начала был очень амбициозным проектом, уже тогда нам обещали столько всего, что не сделать и поныне. С тех пор долгожданный (в самом прямом смысле слова) шутер минимум два раза менял используемый игровой движок, несколько раз менял команды и даже концепции. Соответственно, история создания игры весьма богата и запутанна, описать ее близко к действительности весьма непросто.
Мы попробуем остановиться на наиболее важных фактах в истории создания игры. В 1995 году состоялся первоначальный анонс Prey, игра должна была разрабатываться и быть выпущена компанией 3D Realms примерно в одно время с Duke Nukem Forever — еще одним долгостроем под тем же авторством. Самые первые скриншоты игры появились все в том же 1995 году, сейчас они смотрятся очень забавно, но на тот момент они даже могли поражать воображение (вероятно, использовался доработанный движок Duke Nukem 3D).
Начиналось все с дизайна Tom Hall, который затем ушел в Ion Storm, и с того времени игра претерпела множество изменений. 3D Realms отдали разработку игры Paul Schuytema. Новая команда придумала интересный дизайн для игры, основная тема которой осталась неизменной (инопланетное похищение), но теперь действие игры должно было происходить на огромном инопланетном космическом корабле, населенном несколькими типами инопланетян, игрок должен был играть роль индейца по имени Talon Brave.
В те времена концепция игры отличалась от других проектов порталами, которые, к слову, мы все-таки увидели и в финальной версии игры. Порталы должны были стать основной особенностью Prey, вместе с обещанным тогда разрушаемым окружением. Соответствующие демонстрации этих особенностей на выставке E3 в 1997 и 1998 годах были показаны за закрытыми дверьми.
Утечки с тех выставок были восприняты игровой общественностью очень хорошо, демонстрации выглядели отлично, а от 3D Realms после Duke Nukem 3D можно было ожидать еще одного шедевра… Но… Несмотря на все ожидания, разработка Prey погрязла в проблемах. Разработка была приостановлена, и очередной ее этап просто развалился. Приведем еще парочку интересных скриншотов, отражающих ранние этапы разработки Prey, для тех, кто забыл или не знал.
Вскоре после этого, в конце 1998, в 3D Realms в очередной раз попытались восстановить проект, но и эта попытка провалилась. Разработка игры была остановлена, но полностью проект отменять не стали. И вот, в 2001 году, компания 3D Realms решила возобновить разработку Prey, в этот раз было принято решение о лицензировании графического движка у id Software — DOOM 3. Сама разработка была отдана в компанию Human Head Studios, которая должна была использовать предыдущие наработки в основе своего проекта. Игра к тому времени изменилась неузнаваемо, но основными отличительными особенностями остались порталы, индеец и инопланетяне…
Немного о Human Head Studios… Это компания-разработчик компьютерных игр из США, которая была основана в 1998 году несколькими разработчиками, ранее бывшими в составе Raven Software: Chris Rhinehart, Paul MacArthur, Shane Gurno, Ben Gokey, James Sumwalt, Ted Halsted и Tim Gerritsen. Первым проектом Human Head в свое время стала игра Rune — экшн от третьего лица для PC и Mac, вышедший в 2000 году. Затем дело продолжилось другими проектами:
- 2000 — Blair Witch, Volume II: The Legend of Coffin Rock (PC)
- 2001 — Rune: Halls of Valhalla (PC и Mac)
- 2001 — Rune: Viking Warlord (Sony PlayStation 2)
- 2004 — Dead Man's Hand (PC и Microsoft Xbox)
Кое-какие слухи о возобновлении активной разработки Prey появлялись в 2002 году, но они были официально подтверждены только в 2005, когда на сайте 3D Realms появилась приманка для любопытных: «Keep your eyes open for the unveiling of our next game very soon. ;)». Затем был запущен официальный сайт проекта Prey, который подтвердил существование и скорый выход игры. Официальный анонс игры произошел в конце апреля 2005 года — издателем 2K Games был выпущен соответствующий пресс-релиз. В нем было указано, что игру покажут на выставке E3 на стенде ATI, а первая подробная информация об игре будет опубликована в июньском номере журнала PC Gamer.
В том самом июньском PC Gamer опубликовали статью, где было написано, что игра использует модифицированный движок DOOM 3, поддерживающий порталы, которые были показаны еще в ранних роликах игры. Также отмечалось, что отличительными особенностями игры будут изменение гравитации и разнообразные локации. Через год после анонса игры, в апреле 2006 года, была объявлена и дата ее выхода — 10 июля 2006 года.
Так как Prey использует известный игровой движок DOOM 3 Engine, необходимо вкратце рассказать и о нем. Движок DOOM 3 был разработан в id Software и впервые был использован в собственной одноименной игре. Как обычно для id, движок создавал Джон Кармак, также написавший предыдущие игровые движки компании: DOOM и Quake. Движок DOOM 3 изначально задумывался как улучшенный Quake 3 Engine, планировалось переписать только его часть, ответственную за рендеринг, а остальные части оставить с небольшими доработками. Однако в реальности получилось иначе — после окончания основных работ над рендером, было принято решение о переводе всего кода на язык программирования C++. В результате, движок полностью поменял структуру и был переписан, от кода Quake 3 там остались лишь маленькие фрагменты.
Движок DOOM 3 добавил несколько новых возможностей к Quake 3, применительно к 3D графике, вот, лишь основные из них: попиксельное освещение, расчет спекулярной компоненты освещения, наложение карт нормалей и рендеринг теней при помощи теневых объемов. Основным нововведением графического движка DOOM 3 стало унифицированное динамическое освещение и затенение для всех поверхностей и объектов, почти без исключений. Большинство предыдущих трехмерных игр использовали отдельные модели освещения для разных 3D объектов — динамических моделей и статической геометрии уровня. Информация об освещении и тенях размещалась в картах освещения (lightmaps), она была статической и предрассчитанной заранее, в то время как для движущихся моделей использовались иные методики расчета освещения и наложения теней — динамические, в реальном времени.
Так во многих играх делается до сих пор, а в движке DOOM 3 одними из первых (в свое время выходила бюджетная игра на относительно малоизвестном движке AMP II, предлагавшем схожие возможности) использовали общую модель, которая не делает различий между статикой и динамикой, в которой для каждого полигона используется один и тот же алгоритм освещения. В реальности, исключения есть — для некоторых моделей выставляется флаг отсутствия самозатенения, могут использоваться специфические шейдеры для отдельных материалов, а для некоторых полигонов освещение и вовсе не считается (например, для точечных спрайтов). Поэтому, если подходить к делу со всей строгостью, модель освещения в DOOM 3 нельзя назвать полностью унифицированной, но она очень близка к этому определению.
Список игр, использующих игровой движок DOOM 3:
DOOM 3 — id Software
DOOM 3: Resurrection of Evil — Nerve Software
Quake 4 — Raven Software
Prey — Human Head Studios
Enemy Territory: Quake Wars — Splash Damage (еще не вышла)
Используемая в Prey версия движка не была последней на момент выхода игры. Технологически движок игры близок к той версии, что использовалась в дополнении к DOOM 3, и чуть старше той, что используется в Quake 4. Изменений немного — добавлены давно обещанные порталы (которые были реализованы в других играх за прошедшие 11 лет), некоторые пиксельные и вершинные шейдеры переписаны и дописаны, например, появился уже упомянутый шейдер параллаксмаппинга.
В последующих играх, использующих DOOM 3 Engine, по мере доработки движка планируется внедрение других востребованных современных возможностей, таких как MegaTexture, parallax mapping и HDR. Алгоритм теней также может подвергнуться модификации. Тени в уже вышедших играх на движке имеют одну привычную проблему — их края резкие, в то время как в реальности такие тени очень редки, и почти все имеют мягкие края. Некоторые игры, также использующие теневые объемы для рендеринга теней, предлагают алгоритмы смягчения их краев (F.E.A.R., The Chronicles of Riddick: Escape from Butcher Bay), таким же образом могут поступить в будущих играх на DOOM 3 Engine. Хотя остается определенная вероятность, что сделают не простую эмуляцию мягкости границ теней методом их размывания, а "честные" мягкие тени, с расчетом полутеней в зависимости от физических величин: типа источников света, их размеров и расстояний от источников света до объектов, но это пока лишь догадки.
Первые версии движка DOOM 3 справедливо критиковались за сложность создания больших открытых пространств с современным уровнем графики (принципиальная возможность всегда есть). Для этого Кармак придумал технологию MegaTexture — технику наложения текстур, используемую в новых версиях движка DOOM 3, в частности, в игре Enemy Territory: Quake Wars от Splash Damage. DOOM 3 Engine, используемый в Quake Wars, отличается от использованного в Quake 4 и Prey. Хотя все эти игры основаны на одном движке, разрабатывались они отдельно, и в Quake Wars используется много специально разработанных нововведений, таких, как свои алгоритмы расчета физики, сетевой код, а также система рендеринга открытых пространств.
MegaTexture — это новая техника, призванная решить проблемы отображения больших пространств при помощи неких спецсредств. Суть технологии мне недостаточно понятна, везде, где я видел ее описание, это было настолько коряво сделано, что понять что-то определенное не представлялось возможным. Пишут, что эффект достигается при помощи одной огромной текстуры размером 32000 × 32000 пикселей (видимо, следует читать как «до 32000 × 32000» или «32768 × 32768»), покрывающей всю локацию, вместо создания многослойной поверхности, крупные детали которой задаются большой текстурой с разрешением в рамках возможностей видеочипов, растянутой на весь кусок ландшафта, а мелкие — накладываемыми дополнительно текстурами, вроде карт детализации. Заявляется, что «мегатекстура» может хранить и другую информацию о ландшафте, такую как привязка звуковых эффектов к определенным местам карты. id Software и Splash Damage утверждают, что применение технологии приведет к увеличению детализации по сравнению с привычными техниками, и что MegaTexture сделана, чтобы убрать повторяющиеся элементы текстур на поверхности ландшафта, возникающие из-за тайлинга.
Но вернемся к Prey… Первые скриншоты, показанные в 2005 году, явно делались с версии игры, близкой к финальной. На картинках были хорошо видны все основные особенности движка DOOM 3:
Скриншоты выставляли выгодные стороны хорошей игры на DOOM 3 Engine — на них было видно попиксельное освещение, использование качественных карт нормалей и specular карт, динамические тени для всей геометрии уровня, и набор эффектов постобработки: bloom, desaturation, heat haze, distortion и другие. К сожалению, одна из проблем D3E игр также осталась на месте — сравнительно слабая геометрическая сложность моделей и уровней в целом. Карты нормалей спасали, конечно, но лишь частично. С весны 2005 года технологический уровень графики в игре уже не изменялся, шло портирование на Xbox 360 и мелкая доработка ПК версии. Как оказалось, выложенные за год до релиза скриншоты показывали уровень картинки финальной версии.
Особенности графики в игре
Технологический уровень графики Prey явно был задан движком игры. Как и предыдущие игры на DOOM 3 Engine, в Prey мы видим массу закрытых (indoor) пространств. Игра проходит в помещениях, но есть и несколько открытых (outdoor) локаций, которые отличаются простой геометрией. В отличие от DOOM 3, в Prey гораздо меньше темных мест и тени не играют той роли, что в проекте id. Из нововведений именно рассматриваемой игры отмечаем параллаксмаппинг и новые эффекты постобработки, их список со времен DOOM 3 сильно расширился.
По скриншотам типичных замкнутых и открытых пространств игры видно, что хотя по сравнению с DOOM 3 прогресс в плане открытых местностей налицо, открытые пространства в Prey явно ограничены, и улучшение мы, скорее всего, увидим только в Enemy Territory: Quake Wars.
Демо- и финальная версии игры показали массовое применение карт нормалей, использование в описании материалов нескольких текстурных слоев: diffuse, normal, specular. Разрешение почти всех текстур достаточно велико, лишь в редких случаях поверхностям в игре не хватает детализации. Чаще всего все очень прилично, и если не смотреть на края полигонов, то все модели кажутся очень богатыми на мелкие детали.
Специальный режим рендеринга, который показывает геометрию в wireframe, был включен для того, чтобы сразу было видно, какие детали добавляются геометрией, а какие — картами высот и нормалей. Хотя параллаксмаппинга в игре много, к некоторым из подходящих поверхностей эффект не применяется, и я считаю это упущением — он вполне мог быть применен на большем количестве объектов.
Лично меня в игре больше всего раздражают относительно низкополигональные модели. К моделям людей и прочих инопланетян — самые большие претензии, так как они обращают на себя большее внимание, чем остальное окружение. Модели сделаны неплохо, а карты нормалей очень помогают им выглядеть отлично со среднего и дальнего расстояний (см. скриншоты), но местами полигонов очень сильно не хватает. Посмотрите на руки, например. Или на края моделей, которые выделяют явные недостатки их полигональной сложности. Уровни местами также страдают от недостатка полигонов, слишком много угловатых поверхностей. Но повторюсь, что нормалмаппинг помогает моделям выглядеть почти реалистично (если бы они еще нормальную кожу с подповерхностным рассеиванием сделали…):
Но все портит вид с близкого расстояния, когда становятся различимыми «слепленные» пальцы рук, слегка квадратные головы, плечи и т.п. Считаю, что для современной игры такое положение ненормально. Нормалмаппинг помогает, но зачем переносить на него всю работу? Посмотрите на долю занятости работой вершинных блоков видеочипа в первой части статьи — чего там экономить? Ресурсы CPU? Да, смысл есть. Но для владельцев high-end компьютеров можно было постараться и сделать чуть более сложные модели хотя бы для основных персонажей!
Зато на пиксельном уровне все хорошо, тут тебе и нормалмаппинг и алгоритм анизотропного освещения для рендеринга волос некоторых из персонажей. И ведь выглядят волосы действительно неплохо, им бы динамики еще побольше…
Тени в игре рассчитываются от большого количества источников освещения (кроме некоторых мелких источников и индейской зажигалки — заменителя фонарика в Prey) и почти для всей геометрии в сцене. Как уже было написано, используются теневые объемы, получившие довольно большую популярность в indoor шутерах от первого лица. Как раз одним из прародителей этой техники в ПК играх стал DOOM 3, а за ним и Quake 4 с Prey… Как ни удивительно, в Prey теням уделено меньше внимания, и даже чтобы привести заметные тени на скриншотах, пришлось поискать более-менее удачные сцены и ракурсы.
В Prey нашлось место даже таким эффектам, как водные поверхности. Казалось бы, откуда им там взяться? Однако пару луж (даже не будем интересоваться, что это за жидкость там изображена, но, судя по всему остальному, что-то очень-очень страшное :) мы нашли, вот, одна из них:
Волны сделаны на пиксельном уровне, вроде бы даже есть реалистичные преломления… В Prey также появились и спецэффекты на базе систем частиц. Они встречаются в игре пусть и не так часто, но приятно дополняют визуальную сторону игры, и в сочетании с постфильтром Glow выглядят весьма эффектно, простите за каламбур. Как и другие световые эффекты, примененные в игре.
Как обычно, подробный анализ мы учиняем эффектам постобработки, как одним из наиболее современных и эффектных моментов в технологических 3D играх. В Prey применяются как привычные фильтры: bloom (в данном случае носящий гордое имя glow) — фильтр, увеличивающий яркость светлых участков изображения; distortion — эффект искажения изображения прозрачными поверхностями, порталами и др; blur — полноэкранное размытие картинки; radial blur — эффект радиального размытия; а также некоторые другие постфильтры, такие как фильтры коррекции цвета — desaturation и saturation, подавляющие и усиливающие цвет получаемой картинки соответственно. Все основные постэффекты из Prey приведены на приложенных картинках:
Postprocessing (bloom)  | Postprocessing (bloom)  |
Postprocessing (color correction)  | Postprocessing (color correction)  |
Postprocessing (distortion)  | Postprocessing (distortion)  |
Postprocessing (blur)  | Postprocessing (blur)  |
Postprocessing (radial blur)  | Postprocessing (radial blur)  |
Нельзя было обойти вниманием мегафичу Prey с самых давних времен — рендеринг порталов. Ничего особенного, с технологической точки зрения, собой не представляющий, эффект применяется в играх не так часто и имеет право на отдельное выделение. Конкретная реализация в Prey выделяется разве что красивыми световыми эффектами и постфильтром distortion:
В целом, технологичность графики в игре находится на приличном, но не самом современном уровне. DOOM 3 и Quake 4 игра, пожалуй, превзошла, но другие современные игры ушли за это время еще дальше. В активе технологичности игры: динамические тени от всех основных источников света и всей геометрии, попиксельное унифицированное освещение, наложение карт нормалей, применение в отдельных случаях техники parallax mapping — простого алгоритма без трассировки лучей для определения пересечений деталей поверхностей, высокое разрешение большинства текстур, множество различных эффектов постобработки.
Отрицательные стороны, замеченные в Prey: отсутствие больших и сложных открытых пространств, отсутствие алгоритма смягчения границ теней, недостаточная геометрическая детализация многих моделей и уровней. Еще один очевидный недостаток — отсутствие рендеринга в HDR диапазоне. Большое количество современных игр уже умеют использовать HDR рендеринг с применением форматов фреймбуферов повышенной точности, а движок DOOM 3 пока нет. Остается надеяться, что включение этой возможности в D3E не за горами, и те же постфильтры, рассчитываемые в повышенном динамическом диапазоне, обретут новое качество в будущих играх.
Настройки качества графики
Prey не так требователен к мощности видеокарты, как DOOM 3 в свое время. Хотя игра использует многие возможности современных видеокарт, заставить ее работать плавно и быстро на максимальных настройках не так сложно. Видеокарты, начиная с ATI RADEON X1800 XL и NVIDIA GeForce 7600 GT, обеспечивают в Prey средний FPS 45-60 кадров в секунду и более в разрешении 1024x768 на максимальных настройках с включенными анизотропной фильтрацией и антиалиасингом. Начиная с этих моделей и на всех более мощных можно выставить настройки на максимум (в разрешении 1024x768), а для видеокарт более низкого уровня для достижения необходимого баланса между частотой смены кадров и качеством картинки придется обратить особое внимание на графические настройки и потратить некоторое время на поиск оптимальных значений.
Если нужная частота кадров, которую можно примерно оценить визуально, по плавности игры, не достигается, или кажется, что игра выставила слишком низкие настройки качества, нужно сначала проверить среднюю частоту кадров. Хотя движок DOOM 3 позволяет тестировать производительность, используя заранее записанные пользовательские демки, вместе с Prey официальных демок не поставляется. Для тестирования производительности придется записать свою собственную демку или скачать готовую в Сети. Для создания своей демки надо загрузить нужное место в игре, затем в консоли набрать "recorddemo" или "recorddemo (название демки)". Если не задавать название, то название демке присвоится автоматически. Затем, чтобы остановить запись, нужно выполнить в консоли команду "stoprecording". Игра записывает демки с расширением *.demo в каталог "\base\demos\" игры, и чтобы запустить одну из них, нужно набрать в консоли "timedemo (название демки)". После окончания проигрывания демо, игра предъявит результат в окне в виде достигнутого среднего значения FPS. Как обычно, для игр на движке DOOM 3 бенчмарк нужно запускать два раза минимум и не обращать внимания на первый результат. Средняя частота кадров должна быть не меньше 40-50 FPS, а еще лучше 60 FPS. Если средний FPS больше 50-60, можно попробовать улучшить качество картинки, изменив настройки в большую сторону, а если меньше 40, то лучше снизить их. Повторяя эксперименты, нужно постараться получить приемлемый лично для вас вариант, не забывая, что уровни в игре разные и неравноценные, с точки зрения нагрузки на видеокарту.
В обзоре мы рассмотрим влияние графических настроек игры с двух сторон, принимая за точку отсчета максимальные и минимальные настройки в разрешении 1024x768 и 640x480, соответственно. При минимальных настройках качества мы будем определять отрицательное влияние включенной на максимальное значение настройки, а при максимальных — наоборот, прибавление в кадрах в секунду от каждой установки, выкрученной на минимум. Это позволит более полно оценить влияние каждой настройки на общую производительность, и будет полезно как для пользователей с недостаточно мощными системами, желающими получить хорошее качество, так и для тех, кто хочет узнать, какие настройки имеет смысл снизить в первую очередь.
Prey, хотя и основан на модифицированном движке DOOM 3, предлагает заметно большее количество игровых настроек, которые нуждаются в подробном описании. Меню графических настроек «Video Settings» расположено в меню игры «Options-Video». Настройки, влияющие на производительность и качество рендеринга, разделены на три страницы: «Video Settings», «Advanced Video Settings 1», «Advanced Video Settings 2». Для достижения нужной играбельности, необходимо изменять эти настройки так, чтобы достичь средней частоты кадров хотя бы больше 30-40 FPS, и вот, основные параметры, на которые следует обратить внимание конкретно в игре Prey: «Video Resolution», «Image Anisotropy», «Antialiasing» (три самые важные настройки для любой игры), а также «Enable Bump Maps», «Enable Shadows» и «Use Glow». Рассмотрим все имеющиеся настройки подробнее…
Video Settings
Auto Detect Video Settings — как и во многих других играх, в Prey есть возможность автоматической настройки параметров конфигурации. При нажатии на кнопку "Detect", игра попытается определить и автоматически выставить приемлемые настройки для вашей системы. Делается это очень грубо и не оптимально, эта примитивная автонастройка близко не даст эффекта, схожего с тем, что дает грамотная ручная. Так, на тестовой системе игра установила разрешение 1024x768 и почти все настройки на максимум, кроме самых важных — антиалиасинга и анизотропной фильтрации. Мультисэмплинг игра вообще предложила отключить, а уровень анизотропной фильтрации выставила в 8х. Понятное дело, что ручной модификацией параметров в данном случае можно получить более качественную картинку при сохранении достаточно высокой производительности.
Texture Quality (Low Quality/Medium Quality/High Quality) — настройка, управляющая уровнем качества текстур, имеющая большое влияние на качество рендеринга и производительность, что особенно заметно в случаях нехватки видеопамяти. Это один из важнейших параметров, на который следует обратить особое внимание, так как от качества используемых текстур конечный результат зависит всегда. Настройке соответствуют три возможных уровня, для систем с малым объемом памяти, со средним объемом и последнее значение для high-end и верхних mid-end карт. Режим "Low Quality" больше всего подойдет для быстрых видеокарт с 64 Мб локальной видеопамяти, в этом режиме используются сжатые текстуры пониженного разрешения. Установка "Medium Quality" предназначена для видеокарт с набортным объемом памяти, равном 128 Мб. В нем используется компрессия для текстур, карт нормалей и спекулярных карт, но разрешение текстур не снижается. И последний режим — "High Quality", который отличается от "Medium Quality" только большим разрешением некоторых из текстур, данный режим предназначен для видеокарт с объемом видеопамяти 256 Мб и выше.
В максимальном режиме не используется runtime компрессия текстур, но заранее сжатые текстуры не распаковываются, а используются в их исходном виде. Владельцы видеоплат с 512 Мб памяти на борту могут попробовать чуть-чуть улучшить качество, отключив сжатие вообще, воспользовавшись настройками из командной строки, о которых речь пойдет ниже. Единственное замечание — заметное улучшение качества картинки вряд ли произойдет, так как большинство текстур, используемых игрой, заранее сжаты, и качество их уже не улучшить. Визуальная разница между минимальными и максимальными настройками "Texture Quality" показана на двух парах скриншотов (при нажатии на картинках открываются полноразмерные версии):
Как вы можете видеть, разница ощутима, хотя и не столь велика, как это порой бывает в других играх. Это объясняется тем, что даже минимальные настройки Prey не слишком-то ухудшают качество текстур, и на low-end картах, возможно, придется воспользоваться более тонкой настройкой из консоли, описанной в конце статьи. Разница в производительности между крайними настройками составила 12% при максимальных настройках и менее 1% — при минимальных.
Video Resolution (640x480/800x600/1024x768/1280x1024/1600x1200) — привычная настройка игрового разрешения. Список разрешений в версии 1.0 игры весьма небогат, наиболее высокое разрешение — всего лишь 1600x1200, но хотя бы востребованное 1280x1024 присутствует. Патч 1.1 к игре ввел широкоэкранные разрешения в меню игры, но даже если нужного вам разрешения нет в меню, всегда можно воспользоваться пользовательской установкой. Как это сделать при помощи консоли и команд r_mode, r_customheight и r_customwidth — написано в конце статьи.
Выбор разрешения в Prey очень сильно влияет на производительность игры, разница между разрешениями 640x480 и 1024x768 на тестовой системе с установленной видеокартой GeForce 7800 GTX 256MB, составила 33% для максимальных настроек и 0% — для минимальных, а между 1024x768 и 1600x1200 — 72% на максимуме и всего лишь 10% на минимальных настройках качества. То есть, средняя частота кадров в 1600x1200 получилась почти в два раза ниже, чем в 1024x768. Так что на этот параметр нужно обращать особое внимание при настройке, игра крайне требовательна к эффективной скорости заполнения (филлрейту), важнейшими параметрами видеокарт для этой игры являются филлрейт, зависящий от рабочей частоты видеочипа и количества блоков ROP, и пропускная способность памяти, зависящая от частоты работы и ширины шины памяти.
Fullscreen (Yes/No) — настройка управляет режимом полноэкранного рендеринга и дает возможность запуска в окне, если это нужно по каким-то причинам. Соответственно, чтобы играть в игру и видеть весь игровой экран, нужно задать разрешение меньше того, что установлено для рабочего стола :).
Тут же пользователю предлагается настроить яркость (Brightness) и гамму (Gamma), для этого нужно воспользоваться соответствующими ползунками. Обе настройки не влияют на производительность и нас в данном материале не интересуют.
Aspect Ratio (Normal[4:3]/Widescreen[16:9]/Widescreen[16:10]) — параметр задает соотношение сторон экрана (горизонтальное к вертикальному), используемое в игре. Возможны три значения, одно из которых стандартно для обычных мониторов (4:3), а два других полезны для широкоэкранных дисплеев с разным соотношением. Если и с этой настройкой правильная конфигурация вашего устройства вывода не получается, просто задайте нужное разрешение именно для вашего монитора, как описано в конце статьи. Или установите патч 1.1.
Хотя базовые возможности по настройке производительности есть на основной странице видеонастроек, для получения оптимального сочетания качества и производительности рекомендуется также настроить игру в двух страницах "Advanced Video Settings", которые мы сейчас рассмотрим.
Advanced Video Settings 1
Use Shader Programs (Yes/No) — судя по названию, эта настройка должна включать использование пиксельных и вершинных программ в игре. Но по какой-то странной причине, на тестовой системе эта настройка влияет разве что на некоторые эффекты постобработки, такие, как искажения во время взрывов и выстрелов из различных типов оружия. В то время как шейдеры в игре используются везде, для большого количества визуальных эффектов, и их отключение должно вызывать большой прирост в производительности и ухудшение качества картинки, которого не происходит. То ли разработчики чего-то напутали, то ли назвали параметр неправильно — теперь и не сказать. Главное, что и на производительности и на качестве на тестовой системе он почти не сказывается, а поэтому его рекомендуется держать постоянно включенным.
Shader Detail (Low/Medium/High/Highest) — еще одна непонятная настройка, тесно связанная с предыдущей. При выборе значения "No" в "Use Shader Program", возможность изменения "Shader Detail" блокируется. Видимо, настройка должна отвечать за изменение качества эффектов, выполняемых при помощи пиксельных программ. У нее три возможных значения, каждое из которых соответствует определенному уровню качества. Но никакой разницы в производительности и качестве лично я не нашел. Возможно, читателям повезло больше.
Enable Shadows (Yes/No) — настройка, определяющая, будут ли рендериться тени движком игры. Тени — одна из сильных сторон движка DOOM 3, они оказывают значительное влияние на атмосферу игры, отключать их следует только в крайнем случае, если не хватает производительности.
Как видите, тени хоть и влияют на реалистичность картинки, игра в целом не такая темная, как тот же DOOM 3, и в некоторых случаях, на слабых системах, если рендеринг теней ощутимо снижает производительность, то его можно отключить без особых визуальных потерь. Ведь выключение теней может принести большой эффект в скорости рендеринга, особенно на старых системах. На тестовой же системе отключение теней в режиме 1024x768 с антиалиасингом привело к повышению производительности на 6%, а при минимальных настройках разница составила лишь 4%. То есть, на более-менее мощных системах никакого смысла в отключении теней нет.
Enable Specular (Yes/No) — этот параметр отвечает за расчет спекулярной составляющей освещения. Если настройка выставлена в значение "Yes", то для полноценного расчета освещения используются спекулярные карты (specular maps). Они придают поверхностям реалистичный вид, и особенно сильно это влияет на металлические блестящие детали. Спекулярные блики можно отключить на маломощных системах, которым не хватает производительности, так как это не приведет к фатальному ухудшению картинки, хотя и снизит ее реалистичность. Кстати, на расчет спекулярной составляющей влияет также рассматриваемый далее параметр "High Quality Specular".
Как видите, разница есть и она значительна. Впрочем, вполне допускаю, что кому-то больше понравятся "матовые" поверхности при отключенных specular maps. Их влияние на производительность ощутимо только при максимальных настройках в разрешении 1024x768, с включенными антиалиасингом и анизотропной фильтрацией, разница достигает 6%. А на минимальных настройках и разница минимальная.
Enable Bump Maps (Yes/No) — настройка, включающая использование карт нормалей (только нормалмаппинг, по какой-то причине она не влияет на параллаксмаппинг). При ее включении, для всех поверхностей в игре используется наложение карт нормалей, они обретают мелкие детали и объем. Отключение нормалмаппинга лучше не делать, так как теряется очень большое количество деталей. Только в случае наиболее старых видеоплат или карт бюджетного уровня с очень низкой производительностью, не способных рендерить качественную картинку с нормальной скоростью, можно отключить карты нормалей. Конечно, при отключении нормалмаппинга вы можете получить большой прирост в FPS, но и в реалистичности картинки потеряете очень сильно. Потери можно оценить на сравнительных скриншотах:
По полноразмерным скриншотам хорошо видно, что все мелкие геометрические детали при отключении карт нормалей исчезают. Настройка сильно влияет не только на качество, но и на производительность — отключение карт нормалей приводит к росту FPS на максимальных настройках на величину до 13%, а включение нормалмаппинга на минимальных почти не приводит к снижению среднего FPS, так как производительность в этом режиме ограничивается другими частями графического конвейера.
Vertical Sync (Yes/No) — данная настройка отключает вертикальную синхронизацию. При включении VSync максимальная частота кадров ограничивается частотой обновления экрана. Например, если частота обновления составляет 60 Гц, а настройка VSync включена, то максимально возможное количество кадров в секунду будет равно 60 FPS. В некоторых случаях включение VSync помогает избавиться от артефактов разрывающейся на части картинки ("tearing"), и для максимального качества она полезна, но так как настройка ограничивает производительность, мы рекомендуем ее отключать, если это не приводит к заметным проблемам.
Конкретно в игре Prey настройка почти бессмысленна, так как движок DOOM 3 ограничивает производительность значением 60 FPS, поэтому получить более высокую частоту кадров просто невозможно, и неважно, как вы выставили VSync (эффект от него можно получить только на редких частотах обновления менее 60 Гц). Поэтому для снижения эффекта разрыва картинки, если такой проявляется на вашей системе, нужно изменить настройки графики до такого уровня, чтобы FPS был чуть меньше 60 FPS большую часть времени, но не снижался ниже 30 FPS.
Antialiasing (Off/2x/4x) — эта настройка включает полноэкранный антиалиасинг (мультисэмплинг). На нашей тестовой системе доступны три значения: отключенный антиалиасинг и мультисэмплинг с количеством сэмплов, равным 2 и 4. Как обычно, советуем задавать уровень антиалиасинга из настроек игры, а не форсировать его из панели драйверов, так как первый метод — более правильный.
Влияние мультисэмплинга уровня 4x на производительность игры достаточно велико, на нашей тестовой системе получилась разница в 20-25% между режимами с отключенным антиалиасингом и включенным. Так что, на старых и маломощных системах его нужно отключать в первую очередь (если он вдруг оказался включенным). Минимальные настройки не так требовательны, разница на нашей системе составила всего лишь пару процентов.
High Quality Specular (Yes/No) — настройка, отвечающая за качество расчета спекулярных бликов. При отключенной опции получается менее качественный эффект (возможно, используется не математический расчет, а специальная lookup текстура, или используются иные оптимизации), а при включенной качество бликов и картинки в целом немного улучшается.
Разница не такая большая, поэтому на слабых системах настройку следует отключить одной из первых, если не хватает производительности. Разница в производительности между значениями No и Yes на тестовой системе составила 6-7% на максимальных настройках и 1-2% — на минимальных.
Sharpen Bumpmaps (Yes/No) — этот параметр отвечает за изменения в алгоритме нормалмаппинга. Вероятно, в его более качественном варианте используется изменение значений в картах высот для достижения большего визуального эффекта от бампмаппинга. По крайней мере, так можно подумать, судя по названию настройки и по сравнительным скриншотам:
Влияние настройки на производительность на тестовой системе дало странный эффект. Если при минимальных настройках включение "Sharpen Bumpmaps" никак не отразилось на среднем FPS, то в 1024x768 с включенными анизотропной фильтрацией и антиалиасингом отключение параметра привело к снижению FPS на 3%. Пусть разница и невелика, но воздействие настройки на производительность получилось необычным.
Advanced Video Settings 2
Use Glow (Yes/No) — настройка включает и выключает эффект постобработки Glow, также известный как Bloom. При отключенном Glow все яркие фрагменты изображения становятся тусклыми, включение эффекта Glow увеличивает яркость светлых участков изображения, свет от них как бы переливается на соседние участки изображения, на которых появляются светлые ореолы.
Как видите, картинка в некоторых случаях получается совершенно другой! И отключать Glow следует только на очень слабых системах или тем, кому эффект не нравится в принципе. В отличие от других постэффектов в игре, Glow применяется всегда и его влияние на производительность Prey довольно велико, на нашей системе разница составила 11-13% при максимальных настройках и 7% при минимальных! То есть, ее влияние оказалось сравнимо с влиянием минимальных текстурных настроек или отключенным нормалмаппингом.
High Particle Detail (Yes/No) — опция изменяет качество эффектов, выполненных при помощи систем частиц: огонь, дым и т.д. При включенном "High Particle Detail" такие эффекты рендерятся с максимальным качеством, используется большее количество частиц, что может снизить производительность в отдельных случаях. Так это выглядит на деле:
Визуальная разница не так велика, поэтому владельцы слабых систем могут отключить настройку, так как она может вызывать падение производительности в сценах с большим количеством частиц. На тестовой системе в нашей демке влияние настройки в режиме максимального и минимального качества оказалось равным — 4%. Одинаковые значения в разных режимах говорят, скорее всего, о том, что производительность систем частиц в игре ограничена не видеокартой.
High Quality Skinning (Yes/No) — использование более качественного алгоритма скининга, использующегося в анимации персонажей. Скриншотами разницу между двумя разными режимами показать невозможно, я не нашел никакой видимой разницы, да и в производительности ее не оказалось.
Image Anisotropy (Off/2x/4x/8x/16x) — одна из самых важных настроек, отвечающая за включение уровня анизотропной фильтрации. Это обычная настройка для современных игр (но в Prey ее почему-то поместили в самый конец), предлагаются все возможные на современных видеокартах значения от отключенной анизотропной фильтрации до ее максимального уровня (16x).
Как все знают, этот тип текстурной фильтрации сильно влияет на качество картинки и на производительность, поэтому на слабых системах следует выключить анизотропную фильтрацию или использовать низкие уровни ее качества. Но на всех современных системах, начиная с mid-end видеокарт, мы советуем всегда включать максимально возможный уровень, так как это очень сильно влияет на реалистичность рендеринга. Конкретно в игре Prey разница между режимами с включенной и отключенной анизотропной фильтрацией составила 20-25% для максимальных настроек в разрешении 1024x768 и с включенным антиалиасингом, и лишь 2% в режиме минимальных настроек и разрешении 640x480.
В секции производительности остается отметить, что на тестовой системе в разрешении 1024x768 с включенным антиалиасингом уровня 4x и анизотропной фильтрацией 16x играбельны все максимальные настройки качества 3D рендеринга. Среднее количество кадров в секунду при этом по всей игре составляет около 50-55 FPS, а минимальное не опускается ниже 25. А для больших разрешений и уровней антиалиасинга нужны более производительные видеокарты…
Дополнительные возможности настройки
Prey основан на движке DOOM 3, поэтому многие из возможностей по настройке игр DOOM 3 и Quake 4 подходят и к нему. Некоторые команды этих игр не работают с Prey, а некоторые, наоборот, уникальны для последней. Движок D3E тонко настраивается при помощи настроек, доступных из консоли или конфигурационных файлов с расширением cfg. Консоль — наиболее простой метод, в ней можно ввести все перечисленные ниже команды прямо во время игры (для некоторых команд может потребоваться перезапуск). Чтобы вызвать консоль в Prey нужно нажать комбинацию клавиш Ctrl+Alt+~.
Чтобы не вводить команды каждый раз во время игры (ведь значения некоторых из переменных сбрасываются в значения по умолчанию при каждом новом запуске), можно воспользоваться изменением конфигурационных файлов preyconfig.cfg и autoexec.cfg. Оба должны находиться в подкаталоге «base» игры, но второй файл игрой не создается, для удобства вы можете его написать сами. В autoexec.cfg можно ввести все нужные команды, и они будут использоваться при каждом запуске Prey. Хотя можно воспользоваться и изменением файла preyconfig.cfg, но сначала лучше создать его резервную копию, чтобы в случае чего можно было восстановить настройки по умолчанию.
Команды для управления кэшем игры:
- com_precache (0 или 1) — основная настройка кэша, при ее включении использует динамическую подгрузку ресурсов. Рекомендуется использовать постоянно включенной.
- image_useCache (0 или 1) — настройка, отвечающая за использование фоновой подгрузки текстур в кэш, также полезная для повышения плавности и минимального FPS.
- image_cacheMegs (значение в мегабайтах) — значение определяет количество системной памяти, использующейся для загрузки текстур, имеет смысл при включенном кэше. Обычно используется сравнительно небольшая часть оперативной памяти для кэша, чтобы осталось место для всего остального, слишком большое значение будет неэффективно.
- image_cacheMinK (значение в килобайтах) — значение, определяющее минимальный размер текстуры в килобайтах, которая будет загружаться в кэш. Можно попробовать изменить это значение, чтобы добиться большей эффективности кэширования на конкретной системе.
Некоторые команды по оптимизации производительности:
- r_useTripleTextureARB (0 или 1) — полезная для современных видеокарт настройка, включающая двухпроходный рендеринг вместо трехпроходного для видеочипов с возможностью наложения трех и более текстур на пиксель. Обычно включена по умолчанию.
- cm_backFaceCull (0 или 1) — настройка для оптимизации рендеринга при помощи отбрасывания полигонов, расположенных к камере обратной стороной. При значении "1", все невидимые полигоны отбрасываются и не рисуются, что теоретически увеличивает производительность, но может вызвать артефакты. Практическое применение на тестовой системе не дало никаких результатов.
- r_useOptimizedShadows (0 или 1) — включение оптимизаций рендеринга статических теней. Включена по умолчанию, отключение настройки вызывает лишь небольшое падение производительности на 2-3%.
- r_useShadowCulling (0 или 1) — включение оптимизации удаления теней от частично видимых источников света.
- r_useLightCulling (0, 1, 2, 3) и r_useCulling (0, 1, 2) — значение определяет агрессивность оптимизаций по отбрасыванию бесполезной работы. Максимальные значения задают использование наиболее действенных методов, с точки зрения производительности, но могут вызвать некоторые визуальные артефакты.
- r_useTwoSidedStencil (0 или 1) — включение оптимизированного алгоритма стенсильных теней, использующего возможности современных видеокарт в виде двухстороннего стенсиля. Обычно включена по умолчанию.
- r_useTurboShadow (0 или 1) — еще одна оптимизация динамических теней, использующая W технику, ускоряющая рендеринг без изменений в качестве. Включена по умолчанию, но отключение на тестовой системе в тестовой демке привело к минимальному ускорению (!) на 2%.
Команды настройки качества текстур:
- image_useCompression (0 или 1) — настройка определяет использование сжатия основных текстур (сжатие карт нормалей оговаривается отдельно). При выставлении значения "1" компрессия используется для всех текстур, что снижает требования к объему видеопамяти, но потенциально ухудшает качество картинки. Значение "0" заставляет движок не использовать компрессию несжатых текстур, но предварительно сжатые текстуры игра использовать будет. Для видеокарт с 256 Мб и более рекомендуется значение "0", для плат с меньшим объемом локальной памяти — "1".
- image_usePrecompressedTextures (0 или 1) — значение управляет стратегией использования предварительно сжатых текстур. При значении «1» все прекомпрессированные текстуры используются в неизменном виде, что значительно повышает производительность. При выставлении значения «0» все зависит от image_useCompression, если оно также равно «0», то все текстуры загружаются в память не сжатыми (разжимаются при загрузке ресурсов уровня), что сильно влияет на производительность. Смысла в таком сочетании настроек нет никакого: качество не улучшится, так как текстуры были сжаты предварительно и уже потеряли в качестве. Наиболее правильной будет установка значения image_useCompression в «0», а image_usePrecompressedTextures — «1», тогда обеспечивается оптимальный баланс производительности с максимально возможным качеством.
- image_useNormalCompression (0, 1, 2) — настройка для выбора метода сжатия карт нормалей. Доступны три значения, при первом сжатие нормалей не используется, при втором используется оптимальный, с точки зрения производительности, режим, дающий некоторые артефакты, и максимальное значение обеспечивает наиболее качественное сжатие. Для 256 Мб карт и менее рекомендуется значение "2", для 512 Мб карт возможно использование и "0".
- image_preload (0 или 1) — при значении "1" игра предварительно загружает большинство текстур в память. Это должно выразиться в большем времени загрузки уровня, но меньшем количестве проблем с нестабильностью FPS во время игры.
- image_lodbias (значение mipmap LOD bias) — параметр определяет значение уровня детализации для мип-уровней. Чем выше значение, тем хуже качество картинки, но возможно чуть лучше производительность. Смысл есть лишь в значениях от -1 до 1, и значение подбирается под субъективный вкус игрока. Как ни странно, на тестовой системе значение "-1" привело к повышению производительности на 3-4%.
Следующий блок команд контролирует разрешение текстур, спекулярных карт и карт нормалей.
- image_downSize (0 или 1), image_downSizeBump (0 или 1) и image_downSizeSpecular (0 или 1) — настройки, отвечающие за снижение разрешения основных текстур, карт нормалей и спекулярных карт соответственно. Для систем с небольшим объемом видеопамяти, даже с учетом сжатия текстур, приходится использовать изменение размера текстур в нижнюю сторону (downsampling). Если эти настройки выставлены в "0", используются максимально возможные размеры текстур, а если в "1", то их размеры снижаются в зависимости от следующих настроек, также отдельных для основных текстур, карт нормалей и спекулярных карт.
- image_downSizeLimit (значение в пикселях), image_downSizeBumpLimit (значение в пикселях) и image_downSizeSpecularLimit (значение в пикселях) — настройки, определяющие размер, до которого будет снижаться разрешение основных текстур, карт нормалей и спекулярных карт. Эти настройки соответствуют настройкам качества текстур, доступным из меню игры, но упомянутыми командами можно более тонко конфигурировать разрешение текстур, подогнав его под оптимальное для конкретной системы. Задается максимальное разрешение в пикселях отдельно для трех упомянутых типов текстур. Так, при выставлении значения "256" для основных текстур, все имеющие большее разрешение текстуры будут приводиться к этому размеру. Для видеокарт с объемом видеопамяти 64 Мб нужно ограничить все значения разрешением 256 пикселей (или даже менее), а для карт нормалей и спекулярных, может быть, обойтись даже меньшим значением. Для видеокарт с 128 Мб нужно будет подобрать оптимальные размеры текстур, возможно, основные текстуры следует оставить как есть, а карты нормалей и спекулярные ограничить в размерах, так как предусмотренные игрой текстуры требуют слишком много видеопамяти, больше, чем 128 Мб.
- image_useHighRes (0 или 1) — похоже, что параметр отвечает за использование наиболее "крупных" версий текстур, ведь для режимов "Low Quality" и "Medium Quality" в настройках игры он равен "0", а для "High Quality" — "1". Но разницы в производительности между значениями на тестовой системе не обнаружено.
Другие команды, влияющие на качество и производительность:
- r_renderer (best, arb, arb2, cg, exp, nv10, nv20, r200) — настройка может использоваться разве что при проведении тестов, она определяет использование пути рендеринга, специфичного для разных типов видеокарт. По умолчанию выставляется в "best", и для абсолютного большинства систем это означает выбор лучшего рендерера. Лишь в некоторых случаях может быть полезно ручное определение. Естественно, все они поддерживаются не на любой видеокарте.
- r_displayRefresh (значение в Гц) — определяет частоту обновления, используемую игрой. Если значение, выставляемое системой по умолчанию, вас по какой-то причине не устраивает, этой командой вы можете задать его вручную.
- r_mode (-1, 3, 4, 5, 6, 7, 8) — настройка служит для установки игрового разрешения. Самой полезной для нас является возможность установки пользовательского разрешения при помощи значения "-1", так как всё остальное можно выставить из меню игры. Для задания пользовательского разрешения нужно использовать следующие две команды.
- r_customWidth (значение в пикселях) и r_customHeight (значение в пикселях) — устанавливают горизонтальный и вертикальный размер пользовательского разрешения в пикселях. Разрешение устанавливается при значении r_mode, равном -1.
- g_fov (значение угла в градусах) — задание угла видимости (FOV). Тут все на собственный вкус игрока, значение по умолчанию составляет 90 градусов, можно слегка уменьшить его для небольшого увеличения производительности.
- r_skipPostProcess (0 или 1) — значение этой настройки, равное единице, отключает такие эффекты постобработки, как distortion, heat haze и некоторые другие. Настройка не трогает Glow и может быть полезна для слабых систем, на которых включенная постобработка может сильно повлиять на производительность. На тестовой системе влияние отключения постфильтров было сравнительно невелико, тестовая демка показала лишь 3% прирост производительности.
Отдельно опишем возможность изменения игрового разрешения на нестандартное, если оно не поддерживается игрой (в версиях игры от 1.1 широкоэкранные режимы присутствуют в стандартных настройках меню). Для этого нужно выполнить несколько команд при помощи консоли или правки конфигурационных файлов. Например, таким образом можно выставить одно из распространенных широкоэкранных разрешений:
r_mode -1
r_customWidth 1920
r_customHeight 1200
r_aspectRatio "16:10"
vid_restart
