Щекочущее нервы наслаждение эффектом присутствия в компьютерных играх рождается, в том числе, и при исследовании искусно смоделированных виртуальных миров – чем реалистичнее, тем лучше. Игры переносят нас в бесконечное множество локаций, от фантастических миров магии и тайн до полной опасностей и азарта виртуальной реальности. Совершенствование графических ускорителей позволило программистам преодолеть ограничения двухмерных игр и создавать трехмерные пространства с потрясающей реалистичностью. В условиях постоянного роста быстродействия процессоров и совершенствования технологий оптимизации графики, как аппаратных, так и программных, у разработчиков появляются новые возможности для повышения реалистичности трехмерной графики и выхода на новые уровни интерактивности.

Невзирая на богатство и яркость оттенков, замысловатые текстуры и потрясающие визуальные эффекты современных игр, мозг все-таки ощущает нехватку чего-то существенного. Человек осознает, что изображение на экране – просто трюк, изощренный обман разума совместными усилиями электронов, математики и светящегося люминофора. Несмотря на сложные алгоритмы перспективного деления и коррекции перспективы в текстурах, изображению на экране все-таки недостает настоящего ощущения глубины. Чего же не хватает? Недостающим звеном могут оказаться тени. Без них любая иллюзия трехмерности окажется весьма несовершенной.

Свет и тень в компьютерной графике

В этой статье мы постарались снять покров тайны с процесса создания теней в трехмерных средах. Мы также предлагаем некоторые конкретные методы, с помощью которых программист может привнести в свой проект дополнительные элементы реализма, создаваемые рендерингом теней в реальном времени. Надеемся, что приведенные примеры и алгоритмы вдохновят программистов на новые эксперименты с предложенными методами и, может быть, на их адаптацию для конкретного приложения.

Совершенствование аппаратных средств ускорения и программных технологий обработки графики все больше расширяет спектр возможностей, доступных профессионалам. И сегодня, когда процессоры могут работать с ошеломляющей скоростью, а графические ускорители способны «строгать» треугольники быстрее, чем фабрика чипсов, мы можем воспользоваться преимуществами всех этих новых возможностей для создания весьма интересных приложений.

Когда спускаются тени

Сегодня существует множество методов расчета и отображения теней в реальном времени, включая проекции на плоскость (plane projections), наложение текстур (texture mapping), теневые объемы (shadow volumes) и трассировку лучей (ray tracing). Метод наложения текстур превосходно изложен в статье Хьюберта Нгуена «Построение теней на объемах» (Hubert Nguyen, "Casting Shadows on Volumes") в журнале «Game Developer» за март 1999 г. Наши первоначальные попытки реализовать тени в реальном времени были основаны на методе, весьма похожем на описанный в работе Нгуена. К сожалению, мы столкнулись с рядом негативных факторов, характерных для рассматриваемого метода, которые также были отмечены и описаны Нгуеном: низкая скорость рендеринга текстур, большие затраты вычислительных ресурсов при самозатенении, необходимость дополнительных итераций для сложных сцен и значительные размеры текстур, необходимые, чтобы избежать пикселизации. Наши поиски более эффективной технологии привели к методу отбрасывания теней (shadow casting).

Стремительное развитие технологий ускорения графики позволяет добиться на персональном компьютере такого же уровня быстродействия, как и на высокопроизводительной рабочей станции. Благодаря этому многие графические методы, первоначально разработанные для рабочих станций, были реализованы в трехмерных играх реального времени. Сегодня целый ряд видеокарт поддерживает 8-битные буферы шаблонов (stencil buffer), что позволяет использовать методы отбрасывания теней для создания теней в реальном времени при минимальном снижении производительности.

Алгоритм включает в себя три существенных компонента: построение внешнего ребра объекта, рисование полигонов с теневым объемом и рендеринг собственно тени. Мы рассмотрим каждый из этих компонентов в теории и затем, в последующих разделах, приведем подробные указания по их практической реализации.

Рис. 1 — увеличить

Построение теневого объема

Внешним ребрам объекта не всегда сопоставлена соответствующая выпуклая часть данного объекта. Необходимо определить все ребра объекта, описывающие силуэт этого объекта из точки текущего источника света. Когда ребра найдены, можно создать и спроецировать теневой объем. В местах, где ребра объекта пересекают конус света от источника в данной сцене, отбрасывается тень. Представьте себе луч света от карманного фонарика, но не заливающий сцену светом, а использующий объект для отбрасывания тени на сцену. Рис. 1 проливает немного света на эту концепцию (каламбур умышленный). После определения силуэтных ребер формируются новые полигоны путем продления граней в направлении, указанном текущим источником света. Совокупность этих полигонов обозначается термином «теневой объем» (shadow volume). Правильное сочетание полученного объема и операций с буфером шаблонов позволяет сформировать тени и разместить их на сцене.

Рис. 2 — увеличить

Увеличение и уменьшение буфера шаблонов

Сначала необходимо отрисовать всю сцену без учета затенения. Фокус в том, чтобы дважды отрисовать на сцене теневой объем (оба раза в буфер невидимых объектов). Первый раз объем рисуется на сцене путем увеличения значения буфера шаблонов для каждого пикселя, прошедшего проверку по Z-координате глубины. Затем необходимо сменить режим отбрасывания невидимых полигонов (cull mode) графической карты на отбрасывание передних ребер и повторно отрисовать объем. Буфер шаблонов уменьшается для каждого пикселя, который снова проходит нормальную проверку по Z-координате. Метод проиллюстрирован на Рис. 2. В результате этих операций буфер шаблонов содержит положительные значения для всех пикселей, лежащих внутри объема. Это логически ведет к следующему шагу алгоритма – собственно прорисовке тени.

После выполнения той же серии операций для всех объектов сцены необходимо нарисовать полупрозрачный четырехугольник (alpha-blended quad) во весь экран. Графическая карта настраивается на отрисовку только тех пикселей, для которых в буфере шаблонов содержится положительное значение. В результате на сцене появляются задуманные тени. Далее необходимо очистить буфер шаблонов и повторить весь процесс для следующего источника света в этой сцене. Правильная конфигурация буфера шаблонов при визуальной отрисовке теней позволяет минимизировать затраты ресурсов, связанные с очисткой буфера шаблонов. Графическая карта может устанавливать значение буфера шаблонов равным нулю каждый раз, когда пройден тест шаблона и нарисован пиксель тени. Эта операция обеспечивает заполнение буфера шаблонов нулевыми значениями, после чего он готов к обработке следующего источника света или кадра.

Практическая реализация: рождение теневого объема

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

В Примере 1 (ниже) приведен псевдокод, описывающий алгоритм расчета данных о соседних треугольниках. Этот расчет может проводиться при загрузке модели, либо данные могут быть обработаны заблаговременно и сохранены в файловом формате. После получения таких данных приложение может эффективно определить силуэтные ребра объекта. Ребра определяются путем отбрасывания (culling) граней, не видимых с текущей позиции источника света, и затем определения ребер, лежащих вдоль границы отброшенных и неотброшенных граней.

В Примере 2 (еще ниже) приведен псевдокод, описывающий эту процедуру. Демонстрацию процесса отбрасывания теней можно посмотреть, загрузив образец приложения (.zip, 739 KB).

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

Возможны следующие три варианта реализации:

1. Вытянуть ребра на достаточное расстояние, чтобы гарантировать их выход за пределы пирамиды видимости (это также называют методом brute force). В Примере 2 (ниже) приведен пример реализации этого метода.

Хотя этот метод работает достаточно хорошо, необходимо отметить две проблемы, сказывающиеся на производительности. Во-первых, необходимо предусмотреть отсечение (clipping) этих полигонов на аппаратном уровне или с помощью специального кода отсечения. Это может привести к потенциальному снижению производительности. Во-вторых, сгенерированные таким образом полигоны теневого объема проникают сквозь всю геометрию сцены. Это может быть хорошо или плохо, в зависимости от степени использования теней в конкретном случае. Более подробно эта проблема рассмотрена в разделе 2.

2. Отсекать вершины теневого объема при контакте с геометрией сцены.

Рис. 3 — увеличить

Несколько слов по поводу отсечения по геометрии (Clipping to Geometry)

Этот подход полезен в том случае, если тени генерируются не для каждого объекта сцены. Пример использования этого метода приведен на Рис. 3. Например, если объект находится с одной стороны стены, а при текущем положении камеры видна и другая сторона этой стены, тень объекта обычно проникает сквозь стену (если вы пользуетесь методом № 1). Это не создаст никаких проблем в том случае, если сама стена также отбрасывает тень.

При использовании этого метода зритель не увидит никаких артефактов - при условии, что тень отбрасывают все объекты сцены. В данном примере, если приложение не создает тени для стен, тени от каждого объекта должны быть отсечены по плоскости стены, чтобы избежать появления артефактов. Учтите, что при использовании метода отсечения по сцене (scene-clipping), если в стене есть отверстие, одного этого метода будет недостаточно, чтобы позволить тени проникнуть сквозь отверстие. Для этого потребуются дополнительные вычисления.

3. Отсечение теневого объема по пирамиде видимости

Этот подход представляет собой вариацию на тему описанного выше метода вытягивания ребер (edge-extension). Данный метод позволяет избежать падения производительности, возникающего из-за выполнения отсечения только с помощью аппаратных средств. Однако этот метод сопряжен с теми же проблемами, что и предшествующий.

Практическая реализация: движемся дальше

После того, как объем сгенерирован и сохранен в памяти, начинается самое интересное. Как мы упоминали при общем обзоре алгоритма, объем необходимо полностью отрисовать только в буфер шаблонов; никакая информация о цветах на экран не выводится.

В Примере 3 (ниже) показана реализация соответствующих настроек режима рендера (renderstate) в Direct3D. Полигоны отрисовываются в режиме плоского затенения (flat shading), чтобы не тратить циклы видеокарты на затенение по Гуро (Gouraud shading) с плавными цветовыми переходами для поверхностей, которые не будут отображаться на экране. Значения буфера шаблонов увеличиваются для каждого пикселя, отрисованного видеокартой за этот проход.

И вот, стоило вам поверить, что отрисовка объема уже позади, как приходится снова производить еще один проход рендеринга на тех же полигонах. На этот раз вам придется перевернуть все мироздание с ног на голову, и заодно поменять режим отбрасывания невидимых граней. В Примере 3 (Example 3 ниже) показана реализация в Direct3D настроек для правильного выполнения второго прохода рендеринга. Обратите внимание на изменения в функциях буфера шаблонов, а также на смену режима отбрасывания невидимых граней. Затем объем отрисовывается в буфер шаблонов так же, как и при первом проходе, но на этот раз значения буфера шаблонов уменьшаются, а не увеличиваются. Не забудьте вернуть правильные значения буфера глубины (z-buffer), буфера шаблонов и режима отбрасывания невидимых граней (cullmode) перед переходом к следующей сцене.

Приложение повторяет формирование и отрисовку объема для каждого отбрасывающего тень объекта, для текущего источника света, и только после этого отрисовывает собственно тень. Это не только увеличивает производительность (поскольку, как мы скоро увидим, отрисовка «настоящих» теней может потребовать очень больших затрат системных ресурсов), но и позволяет избежать артефактов – участков многократного падения освещенности в тенях.

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

Свет и тьма: за и против

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

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

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

При всех своих достоинствах, отбрасывание теней, как и многие новые технологии, имеет и свою теневую сторону (на этот раз каламбур родился случайно). Основная проблема – зависимость от поддержки аппаратными графическими средствами 8-битного буфера шаблонов. В то время, когда были написаны коды примеров, этот фактор был особенно актуален. Однако, глядя в будущее, можно предположить, что поддержка 8-битных буферов шаблонов станет стандартом среди графических ускорителей нового поколения. Существенное значение также имеет скорость заполнения сцены, так как при отбрасывании теней количество используемых в расчетах полигонов резко возрастает. Рендеринг теней легко может стать критическим параметром, ограничивающим производительность приложения. Единственный положительный момент заключается в том, что больше циклов процессора может быть потрачено на выполнение других частей приложения без снижения частоты кадров ниже уровня, достигнутого при рендеринге теней.

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

Последняя потенциальная проблема отбрасывания тени обусловливается сложностью продвинутого управления сценой (advanced scene management), особенно в случаях, когда освещение не ограничивается простым верхним светом (обратите внимание, что в большинстве демо-роликов, иллюстрирующих отбрасывание теней, показан только простой случай). Эта и другие проблемы более подробно рассматриваются в следующем разделе, где приводятся рекомендации по их устранению.

Путь к просветлению

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

Выше мы коснулись проблемы полигонов субпиксельного размера, появляющихся из-за создания теневых объемов для насыщенных сцен или мелких объектов. Избежать этой проблемы поможет расчет и отрисовка теневых объемов с модели невидимого уровня детализации (LOD, level of detail), что также приведет к сокращению времени вычислений и рендеринга. Хотя этот метод ведет к появлению определенных артефактов, особенно в случае моделей, затеняющих самих себя, но общий результат обычно вполне приемлем. Кроме того, этот метод значительно быстрее и позволяет избавиться от неприятных артефактов, часто возникающие при визуализации объектов субпиксельного размера. Большая часть системных затрат на отбрасыванием теней от упрощенных моделей может быть оптимизирована, если упрощенные модели используются приложением для других целей, например, для обнаружения столкновений.

Самая серьезная проблема, связанная с отбрасыванием теней, касается вопросов сцены и геометрии. Возможно, вы замечали, что в большинстве примеров отбрасывания теней метод демонстрируется с использованием одного верхнего источника света и неподвижной камеры. Это ловко задуманный способ вызвать восхищение зрителя (и будущего программиста), не учитывающего дополнительные проблемы при изменении точки зрения и источника света. Рано или поздно, во время или после просмотра демо, программист может задаться вопросом: «А что если камера находится внутри теневого объема?» Алгоритм отбрасывания тени основан на том, что луч, направленный от наблюдателя в любую затененную точку сцены, должен пройти и через переднюю, и заднюю сторону объема. Когда объем приближается к передней плоскости, этот эффект теряется. По сути, пользователь остается один на один с недостатками реализации теней.

Рис. 4 — увеличить

Покрывание теневого объема по передней плоскости (Near Plane)

Наше решение этой проблемы основано на «покрывании» (capping) теневого объема в каждом случае обнаружения данной ситуации. Чтобы реализовать данный эффект, геометрия объекта была преобразована в двухмерный вариант и затем трансформирована на переднюю плоскость, идеально покрывая открытый объем. Наглядный пример изображен на Рис. 4.

Активное отсечение невидимых объектов в пирамиде видимости и в сцене высокого уровня также может привести к проблемам генерирования теней. Даже если геометрия и источники света находятся вне текущей пирамиды видимости, тени от геометрии все же могут попадать в пределы видимой сцены. Например, когда теневой объем приближается к параллельной плоскости земли, он может вытягиваться на огромное расстояние до фактического контакта с землей. Этот фактор следует так или иначе учитывать в менеджере сцены (scene manager), в зависимости от конкретного приложения. К возможным решениям относится ограничение расстояния падения тени (чтобы упростить отбрасывание невидимых объектов в менеджере сцены), а также проведение простых проверок, чтобы определить, не может ли какой-либо элемент затенить видимую сцену. Ошибки в реализации этого аспекта могут привести к появлению внезапно появляющихся теней от объектов, которые слишком поздно были распознаны как имеющие тень.

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

Спецэффекты на основе теней

Алгоритм отбрасывания теней является источником не только потенциальных проблем, но и новых возможностей для спецэффектов. Так, одним из простых дополнений к алгоритму может стать окрашивание теней, что позволяет создавать чрезвычайно реалистичные или поразительные визуальные эффекты. Меняя цвет поверхности пересечения, показанный в наших примерах как базовый серый, можно получить участки теней с яркими цветами или замысловатыми текстурами. Этот эффект можно использовать для получения точных цветов тени в средах с многочисленными цветными источниками света, или даже для создания зловещих потусторонних эффектов, когда тени кажутся царством ужаса и тьмы.

Нигде не сказано, что для создания теней обязательно использовать именно метод теневых объемов. Выбирая режим альфа-смешивания видимых объектов (alpha blend mode) или даже подбирая текстуры, можно создавать интересные эффекты направленных лучей света, прожекторов или вспышек. Такой метод эффективен при выборе аддитивных режимов смешивания для перекрывающих полигонов, при этом в большей степени создаются реалистичные эффекты наложения освещения, а не теней.

Об авторах

Джейсон Бестимт (Jason Bestimt) окончил Технический Университет штата Виржиния (Virginia Tech) и начала работу в группе по связям с разработчиками трехмерных приложений. Недавно он присоединился к команде студии Firaxis Games, работающей над новыми продуктами компании.

Брайнт Фрайтаг (Bryant Freitag) является специалистом по прикладному программированию (Application Engineer) в Отделе по связям с разработчиками корпорации Intel. Если он не занят оптимизацией, анализом и вообще своей «настоящей» работой, то отдает все силы совершенствованию видеоигр на благо всего человечества. Похоже, для этого ему и самому приходится много играть.

Хотя разные источники приводят слегка отличающиеся статистические данные, можно утверждать, что в 2006-2007 годах Intel с долей в сегменте рынка, превышающей 50%, занимает первое место среди производителей интегрированных графических карт для настольных компьютеров, а также лидирует «в общем зачете» производителей интегрированной графики (с учетом мобильных компьютеров) – более 35% доли сегмента рынка по данным Mercury Research*.

При этом, в 2006-2007 годах общие поставки интегрированных графических карт по всему миру для всех производителей примерно в три раза превысили поставки неинтегрированных (дискретных) графических карт. И по прогнозам это соотношение со временем только увеличится, а именно – поставки интегрированных карт вырастут, а дискретных снизятся. Прежде всего, это произойдет за счет увеличения числа мобильных компьютеров, в которых по соображениям геометрических размеров, цены, тепловыделения и энергопотребления обычно нецелесообразно ставить отдельную графическую карту.

Что означают эти цифры? Что даже если на каждый PC со встроенным видеоадаптером была дополнительно поставлена дискретная графическая карта (что маловероятно), то 2/3 современных компьютеров остаются только со встроенной графикой. Если же дискретные карты ставятся исключительно на компьютеры без интегрированного видеоадаптера, то доля компьютеров только со встроенной графикой возрастает до ¾ общего числа всех PC.

Давайте посмотрим, какие чипсеты Intel представлены на рынке, и каковы их характеристики. Мы не будем упоминать уже давно выпускаемые и хорошо известные чипсеты 945G и 945GM – они основаны на графическом ядре предыдущего поколения –GMA950, в то время как абсолютное большинство современных чипсетов Intel базируется на графических ядрах нового поколения - семейства GMA 3x00.

В таблице ниже приведены сравнительные «высокоуровневые» характеристики работы с 3D-графикой ядер GMA 3x00 и модели базирующихся на них чипсетов.

^{1 – DirectX10 –реализован на аппаратном уровне, поддержка в драйвере ожидается в первом квартале 2008
2 – Шейдерная модельl 4.0 – реализована на аппаратном уровне поддержка в драйвере ожидается в первом квартале 2008}

В дополнение к этой информации нужно отметить, что не только все приведенные в таблице современные чипсеты, но и 945G, относящийся к предыдущему поколению, поддерживают Windows Vista Aero*

Intel® GMA 3x00 с индексом «X» также поддерживают 32-битные операции с плавающей точкой для Вершинных и Пиксельных шейдеров и текстурирования.

Но главное - аппаратная поддержка T&L (преобразования и освещения вершин), а также Вершинных и Пиксельных шейдеров Модели 3.0 реализована в драйверах Intel® GMA X3х00 начиная с августа 2007. Хотя, оставлена и возможность переключения на программный T&L – в некоторых случаях он работает быстрее.

Как видите, возможности Intel® GMA X3x00 сравнимы с возможностям дискретных видеокарт начального и даже среднего уровня. Но возможности – это только основа потенциала видеокарты, а сам потенциал – это ее производительность.

Что можно сказать о производительности GMA X3x00?

Прежде всего, то, что как у всякой встроенной карты, использующей для работы не только свои ресурсы, но и CPU, а также системную память, производительность сильно зависит от характеристик системы «в целом» - процессора, памяти, и конкретной материнской платы, частью которой является чипсет. Кроме того, сильное влияние на производительность карты оказывает графический драйвер. Поэтому давать оценку производительности интегрированной графики Intel «в общем», без учета специфики конкретного компьютера - некорректно. Но дать некоторые оценки – ориентиры можно.

Еще в 2004 году на ixbt.com была опубликована статья, посвященная исследованию производительности интегрированных графических карт для платформы Pentium® 4. Название данной статьи говорит само за себя: «Интегрированная графика для платформы Pentium® 4: все не так уж плохо…», а результаты тестирования интегрированной графики Intel для 3D-игр приятно удивили авторов. С момента выхода статьи сменилось уже два поколения Intel GMA, появились новые производительные многоядерные процессоры Intel® Core2™ и ускорился доступ к системной памяти, что положительно сказалось на быстродействии интегрированной графической карты Intel. Так что в 2007 можно смело утверждать, что «Интегрированная Графика Intel – все совсем неплохо».

GMA X3х00 с драйверами начиная с версии 14.31/15.6 (WindowsXP/Windows Vista) подходит для таких популярных игр, как Battlefield 2142*, Call of Duty 2*, Supreme Commander, Madden 2007*, Ghost Recon: Advanced Warfighter*, Unreal Tournament 2004*, World Of Warcraft*, Microsoft Flight Simulator X*, The Sims 2* (plus the expansion packs), Quake IV*, Half Life 2*, Far Cry*.
Полный список самых распространенных игр, работающих на GMA X3х00 , можно увидеть на сайте http://support.intel.com/support/graphics/intelg965/sb/cs-023018.htm

Приведем сравнение производительности некоторых игр для встроенных графических карт последнего поколения (выпущенных на рынок в 2007 году): Intel G965, NVIDIA7050 и AMD* 690G (конфигурация тестовых систем- в приложении 1 в конце статьи)

А сколько кадров в секунду выдает ваше графическое приложение на Интегрированной Графике Intel®?

Если ваш ответ - «ноль», то есть, оно вообще не запускается (но работает на дискретных видеокартах), то ваши действия:

• Установите последнюю версию графического драйвера Intel с http://downloadcenter.intel.com (в разделе «Products»(«Продукты») выбираете нужный чипсет, затем – ОС)
• Если ваше приложение использует Direct3D, то проверьте инициализацию D3D Device. Возможно, что, обнаружив отсутствие аппаратного преобразования и освещения вершин, приложение просто не создает D3D Device. Это не всегда правильно. Пример корректного кода инициализации DX9 Device с идентификацией Intel GMA приведен ниже - в приложении 2. Для инициализации DX9 Device сначала идет «стандартная» проверка возможностей устройства по аппаратному преобразованию и освещению:
  (caps.DevCaps & D3DDEVCAPS_HWTRANSFORMANDLIGHT),
  и если они присутствуют, то ставится соответствующий флаг обработки вершин:
  vertexprocessingmode = D3DCREATE_HARDWARE_VERTEXPROCESSING;
  иначе – определяется идентификатор графической карты
  g_pD3D->GetAdapterIdentifier(0,0,&adapterID )
  и сравнением VendorId и DeviceId проверяется на соответствие современной встроенной графике Intel:
  if ( ( adapterID.VendorId == 0x8086 ) && // Intel Architecture
  ( adapterID.DeviceId == 0x2A02 ) || // GM965 Device 0
  ( adapterID.DeviceId == 0x29A2 ) || // G965 Device 0
  ( adapterID.DeviceId == 0x27A2 ) // 945GM Device 0
  ........

Если такое соответствие обнаружено, то ставится (а потом используется при создании DX9 Device) флаг программной обработки вершин
vertexprocessingmode = D3DCREATE_SOFTWARE_VERTEXPROCESSING;
и только если оказывается, что графическая карта не только не поддерживает аппаратную обработку вершин, но и не принадлежит к производительным Intel GMA, то принимается фактическое решение не создавать DX9 Device.

• Возможно также, что ваше приложение некорректно определяет доступный объем видеопамяти – без учета того, что интегрированные карты Intel используют в качестве видеопамяти динамически выделяемую часть обычной системной памяти. Чтобы узнать действительный доступный объем видеопамяти на интегрированной графике Intel, проверяйте «локальную память» (“Local Memory”). Эта проверка вернет вам истинное значение, в то время как проверка «нелокальной памяти» (Non-Local Video Memory) покажет ноль.
  Для получения корректного значения доступной видеопамяти в DirectX 9 можно также использовать функцию получения доступной памяти для текстур:
  int AvailableMem = g_pd3dDevice->GetAvailableTextureMem()
  

Так сколько кадров в секунду выдает ваше приложение на Интегрированной Графике Intel?

Если меньше, чем хотелось бы, то обратите внимание на следующие советы по оптимизации или конфигурации вашего приложения.
Основной фактор, ограничивающий производительность современных Intel GMA, –это не скорость вычислений, а скорость заполнения (fill rate), поэтому большинство советов направлено именно на решение этой проблемы – на уменьшение числа отрисовываемых пикселей.

• Предоставьте пользователям возможность понизить экранное разрешение вашего приложения, уменьшить качество (разрешение) текстур, отключить эффекты, требующие двухпроходной отрисовки – например, тени.
• Сложные однопроходные шейдеры для GMA X3х00 предпочтительнее простых многопроходных шейдеров
• Используйте аппаратный тест буфера глубины (Z-test) для уменьшения числа пикселов, посылаемых на отрисовку. Z-test пикселя проводится перед пиксельными шейдерами (при их наличии) и работает достаточно эффективно. Поэтому, по возможности, пользуйтесь автоматическим Z-test, а не манипулируйте буфером глубины напрямую в пиксельных шейдерах.
  
  Чтобы еще больше ускорить работу Z-test, можно попробовать в списке отрисовки расположить объекты в сцене в порядке удаления от зрителя. Но если это переупорядочивание объектов приведет к промахам в кеше текстур или к дополнительным сменам состояния DirectX или OpenGL, а значит, и к падению общей производительности, то от полного переупорядочивания стоит отказаться. Выход – объединить объекты в группы по общим текстурам и\или состояниям и, по возможности, изменить порядок следования групп в сцене - «сначала ближние, потом дальние». Но если пространственная сложность сцены невелика и используются только простые шейдеры с одной текстурой, то повышения производительности от подобной сортировки ожидать не стоит.
• Также при использовании сложных пиксельных шейдеров для минимизации количества фактически отрисовываемых пикселей, попробуйте использовать двухпроходную обработку (rendering): сначала только с Z test (с отключенной записью в буфер цветов и выполнением пиксельных шейдеров), а потом уже с включенной отрисовкой. Однако, выигрыш производительности не гарантируется, так как может оказаться, что «стоимость» двух проходов окажется выше, чем у однопроходной обработки пиксельного шейдера.
• Используйте проверку на загораживание (Occlusion Query), поддерживаемую GMA X3х00 в D3D. Такая проверка используется для определения числа потенциально видимых пикселей объекта при помощи рисования не самого объекта, а его ограничивающего объема. Если Occlusion Query возвращает ноль, это значит, что ни один пиксель ограничивающего объема, а значит, и самого объекта, не был виден, следовательно, объект можно не рисовать. Такая проверка максимально эффективна для сложных объектов с большим количеством вершин. Для дополнительной информации обратитесь к справке по функции IDirect3DDevice9::CreateQuery()
• Для достижения максимального эффекта комбинируйте вышеописанные приемы.
  Например, при использовании двухпроходной обработки в первом проходе только с Z- test можно переупорядочить объекты сцены «от ближних к дальним». Так как этот проход не включает отрисовку на экран, изменение порядка объектов не внесет никаких дополнительных накладных расходов на смену состояния DirectX или OpenGL или загрузку-выгрузку текстур. Кроме того, к этому же проходу для сложных объектов можно добавить Occlusion Query, по результатам которого исключить невидимые объекты из финального прохода – отрисовки.

В заключение отметим, что, конечно же, эта статья не содержит всей информации о постоянно развивающейся Интегрированной Графике Intel. Поэтому рекомендуем обратиться за дополнительной информацией:

• Руководство Разработчика для Intel® GMA 3000 и X3000 (Intel® GMA 3000 and X3000 Developer's Guide) - /ru-ru/articles/intel-gma-3000-and-x3000-developers-guide
• Краткий Справочник по Интегрированной Графике Intel (Quick Reference Guide to Intel® Integrated Graphics) - /ru-ru/articles/quick-reference-guide-to-intel-integrated-graphics
• Форум Разработчиков Integrated Graphics Software Development (английский язык) /en-us/forums/user-community-for-intel-graphics-technology

Приложение 1. Конфигурация оборудования для тестов игр

• Intel System: Processor Intel ® core ™ 2 Duo E6700 Dual channel DS Micron* 2GB (2x1GB) @DDR2-667 5-5-5-15 with Integrated Intel GMAХ3000 graphics + Seagate* 320GB NCQ SATA2 (BIOS:0023, Graphics: 1268, Sound: 5274)
• AMD System: AMD * Athlon64 X2 6000+ 3.00G/1000/2x1MB on Asus M2A-VM Dual channel DS Micron 2GB (2x1GB) DDR2-800 5-5-5-18 with Integrated ATI X1250 graphics + Seagate 320GB NCQ SATA2 (BIOS:901, Graphics: ATI 7.7, Sound: 5386)
• NVIDIA System: AMD* Athlon64 X2 6000+ 3.00G/1000/2x1MB on BIOStar TF7050-M2 (nVidia C68) Dual channel DS Micron 2GB (2x1GB) DDR2-800 5-5-5-18 with Integrated nVidia 7050PV graphics + Seagate 320GB NCQ SATA2 (BIOS:07/16, Graphics: NV 7.15.11.6222, Sound: 6.01.5377)
• OperatingSystem: Windows* Vista* Ultimate RTM Build 6000 NTFS

Приложение 2. Пример корректной инициализации флага обработки вершин для создания D3D Device

DWORD SetVertexProcessingMode( LPDIRECT3D9 pD3D ) 
{ 
DWORD vertexprocessingmode; // vertex processing mode 
D3DCAPS9 caps; // Device CAPs structure 
D3DADAPTER_IDENTIFIER9 adapterID; // Used to store device info 

// Retrieve device capabilities 
if( g_pD3D->GetDeviceCaps( 0, D3DDEVTYPE_HAL, &caps ) != D3D_OK ) 
{ 
return E_FAIL; // exit if reading caps fails... 
} 

// Check if hardware T&L is supported... 
// - The D3DDEVCAPS_HWTRANSFORMANDLIGHT capability should 
// be enabled for GMA X3000 
if ( ( caps.DevCaps & D3DDEVCAPS_HWTRANSFORMANDLIGHT ) != 0 ) 
{ 
vertexprocessingmode = D3DCREATE_HARDWARE_VERTEXPROCESSING; 
} 
else 
{ 
// Check vendor and device ID and enable software vertex 
// processing for Intel(R) Graphics... 

// Gather the primary adapter's information... 
if( g_pD3D->GetAdapterIdentifier(0,0,&adapterID ) != D3D_OK ) 
{ 
return E_FAIL; 
} 

if ( ( adapterID.VendorId == 0x8086 ) && // Intel Architecture 
( adapterID.DeviceId == 0x2972 ) || // 946GZ Device 0 
( adapterID.DeviceId == 0x2973 ) || // 946GZ Device 1 
( adapterID.DeviceId == 0x27A2 ) || // 945GM Device 0 
( adapterID.DeviceId == 0x27A6 ) || // 945GM Device 1 
( adapterID.DeviceId == 0x2772 ) || // 945G Device 0 
( adapterID.DeviceId == 0x2776 ) || // 945G Device 1 
( adapterID.DeviceId == 0x2992 ) || // Q965/Q963 Device 0 
( adapterID.DeviceId == 0x2993 ) || //Q965/Q963 Device 1 
( adapterID.DeviceId == 0x29B2 ) || // Q35 Device 0 
( adapterID.DeviceId == 0x29B3 ) || //Q35 Device 1 
( adapterID.DeviceId == 0x29C2 ) || //G33/G31Device 0 
( adapterID.DeviceId == 0x29C3 ) || //G33/G31 Device 1 
( adapterID.DeviceId == 0x29D2 ) || //Q33 Device 0 
( adapterID.DeviceId == 0x29D3 ) //Q33 Device 1 

{ 
vertexprocessingmode = D3DCREATE_SOFTWARE_VERTEXPROCESSING; 
} 
else 
{ 
// Chipset does not meet minimum requirements... 
return E_MINSPEC; 
} 
} 
return vertexprocessingmode; 
}