3D-конвейер
Большинство игр, а также множество более серьезных приложений следуют довольно стандартной схеме построения трехмерных изображений (далее мы будем называть этот процесс конвейером). Причем некоторые программы реализуют все стадии этого конвейера, некоторые же перекладывают часть работы на плечи аппаратных устройств, специальных библиотек программ (API), другие программы или даже на пользователя. Итак, конвейер состоит из следующих стадий:
Стадии конвейера
Определение состояния объектов(Situation modeling) – эта часть программы не имеет прямого отношения к компьютерной графике, она моделирует тот мир, который будет отображаться в дальнейшем. Например в случае Quake это - правила игры и физические законы перемещения игрока, искусственный интеллект монстров и т.д.Определение соответствующих текущему состоянию геометрических моделей(Geometry generation) – эта часть конвейера создает геометрическое представление текущего момента нашего маленького "виртуального мира".
Разбиение геометрических моделей на примитивы (Tesselation) – эта первая действительно зависимая от "железа" стадия. На ней создается внешний вид объектов в виде набора определенных примитивов, разумеется, на основе информации из предыдущего шага конвейера. Наиболее распространенным примитивом в наше время является треугольник, и большинство современных программ и ускорителей работают именно с треугольниками. Не вдаваясь в математические подробности можно сказать, что на треугольники всегда можно разбить любой плоский многоугольник, и именно тремя точками можно однозначно задать плоскость в пространстве.
Привязка текстур и освещения(Texture and light definition) – на этой стадии определяется, как будут освещены геометрические примитивы (треугольники), а также какие и как на них в дальнейшем будут наложены текстуры (Textures: изображения, передающие внешний вид материала объекта, т.е. негеометрическую визуальную информацию. Хороший пример текстуры – песок на абсолютно ровном пляже). Как правило, на этой стадии информация вычисляется только для вершин примитива.
Видовые геометрические преобразования(Projection) – здесь определяются новые координаты для всех вершин примитивов исходя из положения наблюдателя и направления его взгляда. Сцена как бы проецируется на поверхность монитора, превращаясь в двухмерную, хотя информация о расстоянии от наблюдателя до вершин сохраняется для последующей обработки.
Отбрасывание невидимых примитивов(Culling) – на этой стадии из списка примитивов исключаются полностью невидимые (оставшиеся позади или сбоку от зоны видимости).
Установка примитивов(Setup) – здесь информация о примитивах (координаты вершин, наложение текстур, освещение и т.д.) преобразуется в вид, пригодный для последующей стадии. (Например: координаты точек буфера экрана или текстур - в целые числа фиксированного размера, с которыми работает аппаратура).
Закраска примитивов(Fill) – на этой стадии, собственно, и происходит построение в буфере кадра (памяти, отведенной под результирующее изображение) картинки на основе информации о примитивах, сформированной предыдущей стадией конвейера, и прочих данных. Таких, как текстуры, таблицы тумана и прозрачности и пр. Как правило, на этой стадии для каждой точки закрашиваемого примитива определяется ее видимость, например, с помощью буфера глубин (Z-буфера) и, если она не заслонена более близкой к наблюдателю точкой (другого примитива), вычисляется ее цвет. Цвет определяется на основе информации об освещении и наложении текстур, определенной ранее для вершин этого примитива. Большинство характеристик ускорителя, которые можно почерпнуть из его описания, относятся именно к этой стадии, так как в основном именно эту стадию конвейера ускоряют аппаратно (в случае недорогих и доступных плат).
Финальная обработка(Post processing) – обработка всей результирующей картинки как единого целого какими-либо двумерными эффектами.
Теоретически мы подковались, теперь попробуем разобраться, как все обстоит на самом деле. Во-первых, некоторые стадии этого конвейера могут быть переставлены местами, разбиты на части или совмещены. Во-вторых, они могут отсутствовать вообще (редко) или могут появится новые (часто). И, в-третьих, результат работы каждой из них может быть послан (в обход других стадий) обратно. Например, картинку, полученную на последней стадии, можно использовать как новую текстуру для 8-ой, реализуя таким образом эффект отражающих поверхностей (зеркал). Таких, как мраморный пол в игре Unreal.
3D-API
Хорошо, теперь у нас есть последовательность действий. Но для получения результата надо определится с двумя вещами – кто какие стадии будет выполнять и как он это будет делать. У нас есть три основных кандидата на работу – сама программа (как правило, начальные стадии конвейера), библиотека прикладного программирования (интерфейс, API) и сам ускоритель. Впрочем, программы, не использующие ускоритель (Doom, Quake в программном режиме и т.д.), все стадии конвейера выполняют самостоятельно. В понятие библиотеки в данном контексте можно (без особого зазрения совести) поместить драйвера данного ускорителя, т.к., с точки зрения программы, они становятся частью библиотеки. Программ и ускорителей существует великое множество, а вот число общепризнанных библиотек весьма ограничено. Наиболее часто игры используют следующие библиотеки
OpenGL– созданная первоначально для профессиональных графических станций и программ трехмерного моделирования библиотека. Постепенно она пришла на платформу PC, в основном благодаря стремительному прогрессу в области "железа" и игре Quake, использовавшей урезанный вариант этой библиотеки. Наличие поддержки этой библиотеки у ускорителя крайне желательно из-за большого числа новых игр, ориентированных на нее. Библиотека является в некотором роде высокоуровневой, так как берет на себя все действия, начиная с середины 4-ой ступени нашего конвейера. С одной стороны, это здорово облегчает работу программистам, с другой - способно несколько осложнить ее же, особенно при реализации нестандартных эффектов или необходимости использовать новые возможности ускорителя, выходящие за рамки OpenGL. Хороший пример полезности подобного подхода – возможность выпустить версию OpenGL, значительно ускоряющую (конкретно – геометрические преобразования) работу игр на новых процессорах с SIMD наборами команд – AMD 3Dnow! и Intel Katmai New Instructions (MMX2). Очевидным достоинством также является переносимость программ на другие, не Wintel-платформы. Существенным, но быстро исправляемым недостатком – отсутствие ее полного варианта для некоторых распространенных ускорителей.
Direct3D– библиотека, являющаяся частью Microsoft DirectX и поддерживаемая сейчас практически всеми ускорителями. Фактически представляет собой две библиотеки – низкоуровневую (начиная с 7 стадии) и высокоуровневую (с 5-ой). Результат – большая гибкость для программиста в реализации его идей и, как следствие, головная боль для него же из-за множества связанных с конкретной реализацией ускорителя параметров. Сейчас идет бурное развитие этого продукта Microsoft, последняя на данный момент версия 10 обещает невиданные ранее эффекты и реалистичность изображения.
Glide– собственная низкоуровневая библиотека (стадия 7 конвейера и далее) фирмы 3Dfx, добившаяся популярности благодаря большому распространению первых, действительно успешных ускорителей (на базе набора чипов Voodoo). Библиотека уже не используется в связи с прекращением производства этих ускорителей. Она не поддерживается другими ускорителями и не будет ими поддерживаться (без разрешения 3Dfx это является незаконным), к тому же все новые игры, рассчитанные на нее, работают, как минимум, еще с одной из ранее описанных библиотек.
Еще существует около 10 библиотек низкого уровня, созданных разработчиками различных ускорителей; таких как: R-Redline фирмы Rendition, S3D Toolkit фирмы S3 и т.д. Как и следовало ожидать, программы, написанные специально для них, постепенно исчезают.
Хотя большинство современных ускорителей берут на себя лишь две-три последние стадии конвейера, существует важное и быстро прогрессирующие исключение из этого правила: появились первые доступные чипы с поддержкой геометрических преобразований, способные значительно увеличить скорость построения изображения на компьютерах с недостаточной вычислительной мощностью (а она, мощность, недостаточна по определению - иначе не было бы потребности в ускорителях вообще).