Компьютерная графика и ее аппаратная реализация (обзор видеокарт)

Есть и еще одна проблема: если игрок видит текстуру намного дальше или намного ближе, чем предполагал разработчик, текстура очень сильно корежится фильтрацией. До поры до времени это не заметно, но со временем в рисунок текстуры закрадываются сильные искажения, своеобразные “помехи”. Обе проблемы надо было решать, и решение быстро нашлось в симбиозе двух технологий: трилинейной фильтрации (Tri-Linear filtering) и мип-мэппинга (MIP Mapping).

Для избежания ошибок "depth aliasing" и имитации того факта, что объекты на расстоянии выглядят менее детализированными, чем те, что находятся ближе к точке наблюдения, используется техника, известная как mip-mapping. Если говорить кратко, то mip-mapping - наложение текстур, имеющих разную степень или уровень детализации, когда в зависимости от расстояния до точки наблюдения выбирается текстура с необходимой детализацией.

Mip-текстура (mip-map) состоит из набора заранее отфильтрованных и масштабированных изображений. В изображении, связанном с уровнем mip-map, пиксель представляется в виде среднего четырех пикселей из предыдущего уровня с более высоким разрешением. Отсюда, изображение связанное с каждым уровнем mip-текстуры в четыре раза меньше по размеру предыдущего. Данная версия текстуры называется мип-уровнем, а все мип-уровни вместе -- мип-каскадом. Когда игрок удаляется от текстуры, она сменяется на мип-уровень с меньшим разрешением, а когда приближается -- с большим. Плюсов у этой технологии много. Во-первых,текстура отображается без геометрических искажений. Во-вторых, далеко расположенные текстуры не используют лишние акселераторные ресурсы. Но есть и существенные недостатки. В памяти приходится хранить несколько копий одной и той же текстуры. Переходы между мип-уровнями выполняются резко. Еще год назад вы могли наблюдать в не очень качественных играх характерный артефакт -- полосы мип-мэппинга, выражающиеся в резких переходах между разными версиями одной текстуры.

По-настоящему востребованной оказалась технология, совмещающая MIP Mapping и билинейную фильтрацию и добавляющая в этот процесс несколько новых этапов. Речь идет о трилинейной фильтрации. Цвет конкретного пиксела на экране определяется в результате интерполяции цветов текселов двух соседних мип-уровней. При этом над каждым мип-уровнем предварительно проводится билинейная фильтрация, а для интерполяции берутся не 4, а 8 соседних текселов. За счет этого переход между мип-уровнями становится плавным и незаметным. Трилинейная фильтрация (trilinear filtering) представляет собой технику, которая удаляет артефакты "mip-banding", возникающие при использовании mip-текстурирования. При трилинейной фильтрации для определения цвета пикселя берется среднее значение цвета восьми текселей, по четыре из двух соседних текстур и в результате семи операций смешивания определяется цвет пикселя. При использовании трилинейной фильтрации возможен вывод на экран текстурированного объекта с плавно выполненными переходами от одного mip уровня к следующему, что достигается за счет определения LOD путем интерполяции двух соседних mip-map уровней. Таким образом решая большинство проблем, связанных с mip-текстурированием и ошибками из-за неправильного расчета глубины сцены ("depth aliasing").

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

Венцом эволюции стала анизотропная фильтрация (Anisotropic filtering) -- самая сложная и ресурсоемкая из всех. После всех предыдущих фильтраций и мип-мэппингов все еще остается одна проблема. Более или менее красиво эти алгоритмы работают для текстур, которые располагаются параллельно экрану. Если текстура сильно наклонена, фильтрация в одном направлении выполняется больше, чем надо, а в другом -- меньше. Поэтому и появилась анизотропная фильтрация. Анизотропная фильтрация представляет собой продвинутую технику, следствием применения которой, при корректной реализации, является появление лишь нескольких ошибок визуализации, по сравнению с использованием трилинейной фильтрации. Анизотропная фильтрация может быть реализована с помощью использования выборки по шаблонам (over-sampling или оверсемплинг), в качестве которых могут выступать тексели. Идея в том, что для наложении текстуры на пиксель используется больше текселей, причем количество используемых текселей зависит от применяемого алгоритма. Тем не менее, применение over-sampling серьезно влияет на производительность графического чипсета. Для примера, восьмикратный over-sampling (т.е. когда для наложения текстуры используется восемь текселей) может снизить частоту смены кадров в приложении в восемь раз или больше, по сравнению с тем, что было бы без использования over-sampling..

Во-первых, можно решить проблему “в лоб”. Если восьми текселов на пиксел не хватает, почему бы не интерполировать 16, а то и 32? В результате текстура отображается красиво даже на сильно наклоненных поверхностях. Но даже сейчас очень мало акселераторов, которые могут справиться с такими объемами информации, ведь требуется гигантская ширина пропускания памяти. Во-вторых, некоторые разработчики пытаются решить проблему умом. Сцена рендерится не целиком, а “плитками”, например, 32х32 пиксела. Для каждой плитки (тайла) применяются очень сложные алгоритмы, которые “делают нам красиво”.В настоящее время поддержка трилинейной фильтрации стала стандартной функцией графических чипсетов, так как она обеспечивает вывод трехмерного изображения с высоким качеством при наличии известного количества артефактов визуализации. Более того, все больше и больше появляется графических чипсетов, реализующих трилинейную фильтрацию без ущерба общей производительност. В общем, очевидно, что графические чипсеты, которые поддерживают трилинейную фильтрацию наряду с высокой скоростью заполнения пикселями текстур, будут обеспечивать наивысшее качество визуализации трехмерной графики в ближайшем будущем

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

Разработчики долгое время пытались найти компромисс между качеством и производительностью -- и придумали bumpmapping. Он позволяет создавать объекты с реалистичной рельефной поверхностью с помощью рельефных карт. Кроме самой текстуры, разработчик готовит карту высот (height map), которая описывает рельеф в виде высот, или же карту смещений нормалей (normal dispmap), описывающую рельеф с помощью нормалей.

Рельефные карты бывают двух видов: карты освещенности и карты смещений. Карта освещенности содержит светлые и темные пятнышки, которые символизируют неоднородность освещения из-за неоднородности рельефа. Карта смещений задает искажения для environment map Рельефные карты обоих типов накладываются на основную текстуру альфа-смещением. Игроку кажется, что поверхность действительно рельефна.

7.7. Некоторые хитрости

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

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

Туман бывает двух видов -- полигонный (per-polygon) и пиксельный (per-pixel). При полигонном тумане значение затенения для каждого тексела интерполируется из значений затененности вершин полигона, а при пиксельном -- рассчитывается независимо для каждого тексела. Конечно, пиксельный туман выглядит красивее и естественнее. Есть еще один вид тумана -- объемный туман (Volumetric fog). Он не имеет никакого отношения ни к обычному туману, ни к текстурам вообще, потому что формируется из процедурных частиц.

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

7.8. Процедурные текстуры

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

У процедурных текстур есть несколько преимуществ перед “классическими”. Во-первых, они могут неограниченно масштабироваться в реальном времени. Для них не нужны мип-уровни. Во-вторых, они не занимают в оперативной памяти драгоценного места и “разворачиваются” только непосредственно перед рендером. В-третьих, они легко могут быть трехмерными. Немудрено, что и разработчики компьютерных игр обратили на процедурные текстуры свое внимание. Ведь такие текстуры практически не занимают места на диске. Процедурными текстурами можно имитировать дерево, мрамор, камень, кирпичную кладку, мокрый асфальт, стекло -- словом, любой однородный материал. Процедурные текстуры такого типа создаются по “шумовым” алгоритмам Перлина. До последнего времени рендер процедурных текстур был довольно ресурсоемкой задачей. Но не так давно появились специальные алгоритмы, заточенные под MMX и 3D Now!, которые позволяют накладывать процедурные текстуры с такой же скоростью, что и обычные.

7. 9. Антиалиасинг

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

Чтобы игроки думали, что они видят гладкую линию или кривую, компьютер добавляет вокруг линии пиксели с различными оттенками цвета линии. Эти "серые" пиксели создают иллюзию отсутствия "ступенек". Такой процесс добавления пикселей для обмана зрения называется сглаживанием, и он является одной из технологий, отличающих компьютерную 3D графику от "ручной" графики. Задачи сохранения линий и добавления нужного количества "сглаживающих" цветов являются еще одним сложным делом для компьютера при создании 3D анимации на вашем дисплее. Как следует из приставки "анти", эта технология призвана бороться с алиасингом. Что же это такое? Не так давно, слова "алиасинг" и "анти-алиасинг" были совершенно неизвестны широкой общественности. А между тем, проблема алиасинга стояла очень давно. Чтобы понять, что такое алиасинг, необходимо понять самый общий принцип вывода изображения на экран монитора.

Экран состоит из сотен тысяч очень мелких квадратов (обычно, называемых точками или пикселями) - примерно как бумага в клетку, только гораздо мельче. Каждый квадрат (точка, пиксель, клетка) может быть закрашена только одним цветом. Так, например, когда говорят, что установлено разрешение 1024х768 True Color, это значит, что по горизонтали на экране помещаются 1024 точки, а по вертикали - 768 точек, т.е. всего на экране 1024*768=768 432 точек, каждая из которых может быть закрашена любым из доступных цветов (в True Color их 16 777 216, в High Color - 65 536).

Обратите внимание, что рисунок, состоящий из таких больших точек, выглядит странно. Собственно, это и есть алиасинг - на краях букв видны "ступеньки". Самое очевидное решение проблемы - уменьшить точки. К сожалению, экран монитора имеет очень существенный недостаток: он не позволяет сделать точки настолько малыми, чтобы взгляд не мог их различить. Для сравнения: хороший принтер может печатать изображения с разрешением 2048х2048 точек на дюйм и больше, в то время, как лучшие мониторы ограничены разрешением около 100х100 точек на дюйм.

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

На первый взгляд, задача кажется невыполнимой: из цельных кирпичей круглое колесо не сделать никак! Но оказалось, что решение все-таки есть. При помощи плавных переходов цветов на изображении, можно очень существенно сгладить "ступеньки", т.е. как бы компенсировать недостаток пространственного разрешения цветовым. Это стало всем очевидно еще с появлением видеоадаптера VGA, поддерживающим 2 новых разрешения - 640х480 16 цветов и 320х200 256 цветов. Самое интересное в том, что многие игры работали в разрешении 320х200 и имели на порядок более качественную графику, чем игры, использующие режим 640х480! Все дело в том, что большее количество цветов (256 против 16) позволило сделать плавные переходы между цветами и не только компенсировать потери в разрешении, но и получить существенно более качественную графику и даже показывать настоящие фотографии, вместо простенькой "мультяшной" графики в режиме 640х480. Основано это на особенности зрения человека, которое стремится сгладить плавные переходы между близкими цветами, усиливая эффект.

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

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

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

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

Мультисэмплинг - гораздо более хитрый и интеллектуальный метод сглаживания. Правильнее это называть даже не метод, а скорее инструмент. Идея, по сути, очень проста: зачем просто так тупо вычислять N субпикселей для каждого пикселя? Ведь, уже рассчитанные субпиксели, во многих случаях, можно использовать несколько раз, для формирования не одного, а нескольких результирующих пикселей. С другой стороны, в некоторых участках изображения, сглаживание не требуется вовсе, так зачем рассчитывать их по нескольким субпикселям? Достаточно и одного. И, наоборот, в других участках нужно очень хорошее качество сглаживания и там можно рассчитать очень много субпикселей. Этот инструмент позволяет не только значительно сэкономить ресурсы ускорителя, но и получить лучшее качество сглаживания! Этот инструмент может использоваться как угодно и, качество сглаживания и скорость зависят от конкретной реализации, которую выбрал разработчик ускорителя или игры.

Необходимо также отметить, что анти-алиасинг не только борется с таким артефактом, как алиасинг. Ведь работает он, как правило, не только с краями объектов, но и со всем изображением. Это значит, что его включение не только оказывает влияние на алиасинг на краях объектов, но и на текстуры, наложенные на объект. Какое же влияние это оказывает на них? Это зависит от конкретной реализации. Но стоит отметить, что если каждый пиксель из области с текстурами, рассчитывается на основании нескольких "честных" субпикселей (т.е., не взятых у другого пикселя), то это весьма положительно сказывается на качестве. Если он (пиксель) накладывается на большой (или близкий) объект, занимающий область примерно 256х256, то все в порядке. А вот что делать, если объект занимает область, намного меньшую, чем разрешение текстуры, например 128х128? В этом случае, на один реальный пиксель приходится 4 текселя (так называется один пиксель текстуры) и физического разрешения не хватает для вывода текстуры. В обычном режиме, ускоритель снижает качество (разрешение) текстуры. Эта техника называется LOD (Level Of Detail) Biasing. К сожалению, она далеко не идеальна: текстуры упрощаются гораздо больше, чем необходимо потому, что метод применяется для всех текстур сразу, на определенном расстоянии от экрана, без учета размера объектов, на который они наложены и без учёта их разрешения. К счастью, уровень LOD Biasing можно изменять, т.е. текстуры с увеличением расстояния от наблюдателя будут упрощаться сильнее или слабее. Если LOD Biasing уменьшить, то текстуры будут упрощаться слабее, т.е. их четкость на удалении будет намного выше. Но, если слишком занизить Biasing, то на удаленных объектах появляется артефакт, называемый "дрожание текстур", "шум текстур", "песок" и пр. Выглядит это так: пиксели как будто разбросаны и явно находятся не на своем месте, причем, во время движения сцены, пиксели хаотично прыгают на новые места, в результате чего, на удаленных текстурах заметен шум, немного напоминающий то, что мы видим на экране телевизора после того, как канал прекратил свое вещание. Как я уже упомянул выше, этот артефакт вызван тем, что текстура имеет большее разрешение, чем область экрана, отведенная для ее изображения.

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

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

Несмотря на то, что метод давно реализован, по причине огромного падения скорости (в рассмотренном нами случае - примерно в четыре раза!), практически никакого распространения он не получал, до сравнительно начала 2000 года. Именно тогда появились достаточно мощные ускорители, такие как NVIDIA GeForce2 GTS и ATI Radeon256, в которых стало возможна релизация этого принципа.

8. 3D API или язык акселераторов

8.1. Что это такое

3D-акселератор -- сложная штуковина. Несколько десятков миллионов вентилей в основном кристалле, еще несколько -- в сервисных (DDR, RAMDAC и т.д.) плюс электронные цепи, размещающиеся на самой плате видеокарты. И со всем этим надо как-то управляться. У акселератора есть свой ассемблер (не совсем так, но сравнение хорошее) и специальные команды, адреса и интерфейсы, через которые им можно управлять. У каждого конкретного акселератора (а их сотни) свои особенности, свои дополнительные команды, а иногда и целые блоки. Если написать программную последовательность для одного акселератора, на другом она работать уже не будет. Или будет, но не адекватно. А игры надо выпускать совместимой с разными акселераторами. На практике это означает, что придется писать не один движок, а столько, сколько акселераторов поддерживается. Чтобы этого не делать придумали программно-аппаратные интерфейсы -- 3D API.

Это специальная библиотека, которая позволяет разработчикам не думать о таких мелочах, как адреса видеобуфера или заполнение системных регистров, и сосредоточиться на процессе разработки. Например, чтобы создать точечный источник света, нужно задействовать многие команды акселератора, подумать о перераспределении памяти и еще много о чем. А вот через API это делается всего одной командой (максимум -- двумя). Разработчик пишет эту команду, а все остальное делает 3D API. Примерно так же делаются и другие сложные вещи. Например, в OpenGL такая сложнейшая вещь, как NURBS (которая до сих пор считается признаком технологического шика), создается несколькими простыми командами.

В работе акселератора много рутины. Поэтому многие стандартные действия, вроде подготовки видеообласти (viewport), выполняет тот же 3D API. Не думайте, что он работает только с акселератором. И с процессором, и с памятью, и даже с другими API, например с Windows API, который отвечает за прорисовку окон. Получается, разработчику игр почти ничего делать не надо: задал несколько простых стандартных команд, и готово. Нет, не получается. Зато с поддержкой 3D API остаются время и силы на проработку действительно интересных и сложных вещей, не рутинных, а творческих.

На самом деле взаимодействие 3D API и акселератора несколько сложнее.Ведь между ними стоит еще и драйвер. Но драйвер -- существо подневольное, что ему API скажет, то он и будет делать. Зачем он нужен? Для разных версий акселераторов нет разных 3D API. Один 3D API, по-хорошему, должен понимать все железо, какое только есть на свете. Но если бы он на самом деле умел общаться со всем железом, то весил бы не несколько мегабайт. Поэтому 3D API один на всех, а вот драйверов много -- под каждый акселератор свой. Говоря программистским языком, драйвер предоставляет небольшой, а 3D API -- очень большой уровень абстракции. Некоторые тут возмутятся и воскликнут, что тот же Detonator подходит к нескольким десяткам разных акселераторов. Путаете, господа. Detonator -- это не драйвер, а целый пакет драйверов. А для каждого типа акселераторов “дрова” нужны и вправду уникальные.

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

8.2. Glide

В 1995 году на свет появился легендарный 3D-акселератор 3dfx Voodoo. Это был первый массовый акселератор. Но на старых играх, не созданных для Voodoo, почти не было прироста красоты и производительности. Почему? Да потому, что управлять акселератором можно было только с помощью специального API -- Glide. И именно Glide -- первый массовый 3D API. Но народным он так и не стал. Тому было две причины. Во-первых, это специальный API. Он работает (точнее, с ним работают) только Voodoo-совместимые акселераторы, в отличие от OpenGL и Direct3D, которые универсальны. Во-вторых, Glide -- закрытая коммерческая библиотека. Его коды и функции доступны разработчикам только после того, как они хорошенько заплатят.

С раcпадом 3dfx Glide давным-давно забыли. С точки зрения производительности и возможностей Glide был довольно хорошей библиотекой, но теперь безнадежно отстал.

8.3. Direct3D

Очень многие путают DirectX и Direct3D. DirectX -- это комплексная библиотека, которая включает в себя целый выводок API: и Direct3D, и DirectDraw, а также DirectPlay, DirectInput, DirectSound и DirectMusic. С трехмерной графикой работает только Direct3D. DirectDraw отвечает за двумерную акселерированную графику, DirectPlay -- за сетевые и интернет-сессии (помогает при создании сетевых игр), DirectInput обслуживает устройства ввода (включая даже авиационные рули), а DirectSound и DirectMusic распоряжаются ресурсами вашей звуковой карты.

Но речь не о них, а о Direct3D. Этот API может работать в двух режимах: Retained Mode и Immediate Mode. В режиме Immediate Mode API общается с железом напрямую и дает наибольшую производительность. Retained Mode -- режим абстракции, программировать в котором значительно легче, но цена простоте -- производительность. Иногда в настройках игр можно найти две аббревиатуры: HAL и HEL. HAL (Hardware Abstraction Layer) -- уровень аппаратной абстракции. Если вы выберете этот режим, игра будет акселерироваться железом. HEL (Hardware Emulation Layer) -- это программный растеризатор. В этом режиме акселерация не работает, и 3D обсчитывает центральный процессор. Иногда этот режим называют Software Emulation. Его наиболее заметный признак -- всякое отсутствие фильтрации, как следствие -- страшно пикселизованные текстуры. Как правило, даже при очень серьезных проблемах с 3D HEL-режим остается работоспособным. И в самых крайних случаях приходится выбирать именно этот режим, как бы дико он ни выглядел.

Direct3D стал стандартом де-факто для разработчиков игр. Microsoft поставил на простоту и функциональность и не прогадал. Но чем-то пришлось поступиться. И это “что-то” -- скорость работы. Зато разрабатывать игры с его помощью просто. К тому же все новые навороты, которые напридумывают разработчики акселераторов, традиционно первыми начинают поддерживаться именно в Direct3D, а уж потом -- во всех остальных библиотеках. В отличие от Glide, Direct3D универсален и подходит к любой видеокарте. Поддержка Direct3D на уровне драйверов, как правило, сама лучшая.

8.4. OpenGL

OpenGL -- это универсальная, аппаратно- независимая библиотека, которая поддерживает разнообразные 3D-объекты и конструкции, начиная с примитивов и заканчивая NURBS и даже шейдерами.

Библиотека OpenGL существует в двух вариантах: ICD и MCD. ICD (Installable Client Driver) включает в себя все стадии конвейера и все доступные возможности. С одной стороны, это дает весомый прирост производительности, а с другой -- ICD очень сложно программировать. MCD (Mini Client Driver) -- это немного урезанная версия ICD, в которую добавлен элемент абстракции. OpenGL считается самой быстрой из массовых графических библиотек.

Однако его не часто используют. На одну игру, заточенную под OpenGL, приходится десяток под Direct3D. Программисты -- люди по большей части ленивые. Без дополнительного стимула лишнюю работу делать не будут. Оказалось, что программировать под Direct3D проще, чем под OpenGL. Есть и еще одно препятствие на пути массового внедрения OpenGL. OpenGL-драйвера почти у всех акселераторов раньше были “сырыми”. OpenGL-игры глючили и вываливались через каждую минуту. За последние годы ситуация изменилась в лучшую сторону. Теперь все мейнстрим-акселераторы достойно поддерживают OpenGL. Поэтому в ближайшее время количество игр под этот API возрастет. И еще одна деталь: в OpenGL есть интересный механизм расширений, когда любой желающий может добавить в библиотеку какие-то функции, не реализованные в базовой версии API. В Direct3D есть нечто подобное, но первопроходцем был все-таки OpenGL

9. Форсаж 3D

3D API -- это своеобразным язык, на котором программист общается с акселератором. А как же акселератор этот язык понимает? И что такое вообще этот акселератор? Конечно, все более или менее знают, для чего он нужен, но с его анатомией уже возникают проблемы. Сейчас, когда мы говорим “видеокарта”, то подразумеваем “акселератор”, и наоборот. Когда-то знак равенства между этими словами поставить было нельзя, потому что это были совсем отдельные устройства! А еще раньше акселераторов вообще не было, а были только видеокарты.

Лет пятнадцать назад видеокарта только и делала, что преобразовывала цифровой сигнал от процессора в аналоговый сигнал, понятный монитору. Картинку на экране рассчитывал процессор, а сама картинка хранилась в оперативной памяти. Потом видеокарта обзавелась некоторым количеством своей оперативной памяти (ее называют видеопамять), и образ картинки перенесся из оперативной памяти компьютера “на борт” видеокарты.

С появлением графических интерфейсов стало ясно, что процессор один уже не может справляться с расчетом изображения. Тогда на видеокарте разместили небольшой дополнительный процессор, который должен был взять на свои плечи часть забот по прорисовке изображения. Само изображение по-прежнему создавалось процессором, только он посылал видеокарте не готовую картинку, а общие команды для ее создания: там нарисовать линию такой-то толщины, здесь создать прямоугольник и закрасить его таким-то цветом, а вон там -- круг пунктиром. Этот дополнительный процессор назвали “2D-акселератором” или ускорителем двумерной графики (ведь, помогая центральному процессору, он как бы ускорял расчет изображения). Вначале он устанавливался только на дорогих моделях видеокарт. Потом новая технология “пошла в массы”, а с появлением Windows 2D-акселератор прочно обосновался во всех видеокартах.

Когда появились первые трехмерные игры, все тяготы по прорисовке трехмерных миров снова легли на центральный процессор, так как 2D-акселератор был для этого практически бесполезен. Вот тогда-то и возникла идея устройства, которое должно само рассчитывать трехмерную картинку и передавать ее видеокарте. Так появился первый 3D-акселератор -- 3dfx Voodoo от 3dfx Interactive. Вскоре инженеры поняли, что видеокарта и акселератор -- вещи, в общем-то, неотделимые. И стало одним занятым слотом в компьютере меньше -- 3D-акселератор переехал на видеокарту, где на тот момент уже были 2D-акселератор и преобразователь видеосигнала (RAMDAC).

Немного о стандартах выводимой графики. С самого начала стандартов было довольно много. Потом всех затмил VGA, а за ним -- SVGA. И на этом стандарты закончились. Ведь SVGA -- это не какой-то один стандарт, а обобщенное наименование “всего, что после VGA”. Организация VESA (Video Electronics Standards Association) решила внести в этот хаос толику упорядоченности и разродилась своим стандартом -- SVGA.VESA. Он помог программистам, которые пишут драйвера. Теперь им можно было не задумываться над детальным устройством конкретной видеокарты, а программировать под среднестатистическую типовую модель.

10. Практическое воплощение видеокарт

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

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

Одна из важнейших характеристик любого акселератора -- скорость закраски или fillrate. Она показывает, сколько пикселей или текселей может акселератор обработать за одну секунду. Соответственно, fillrate измеряется в мегапикселях в секунду или мегатекселях в секунду. Цифры, показывающие количество бит информации, нужных для создания одного изображения, отображают лишь часть требуемой вычислительной мощности. Для того чтобы намекнуть вам о величине суммарной загрузки процессора, мы поговорим о математическом процессе, называемом трансформацией (transform). Трансформация используется всякий раз, когда мы изменяем угол зрения на какой либо объект. Например, картинка машины, движущейся на нас, становится больше с помощью трансформации. Другим примером трансформации является преобразование созданного 3D мира в 2D форму на экране компьютера.

Давайте посмотрим, какое же количество вычислений задействовано в такой трансформации, при этом учитывайте, что она используется во всех трехмерных играх. Сейчас мы разберемся, чем же занимается компьютер. Даже в простой анимации требуется выполнить множество расчетов. Стены и мебель имеют текстуры, которыми покрыты каркасы. С помощью световых лучей предметы отбрасывают тени. Также следует заметить, что по мере продвижения камеры по офису, некоторые объекты появляются из-за угла или стены и становятся видимыми. Таким образом вы наблюдаете эффект использования Z-буфера. А так как все это происходит еще до вывода изображения на экран монитора, то становится очевидным: даже самым крутым современным процессорам (CPU) требуется помощь для реализации трехмерных игр или графики. Для этого и были разработаны графические ускорители.

Все современные акселераторы обладают важнейшим блоком с кодовой аббревиатурой T&L -- Transforming and Lighting (трансформация и освещение), который можно условно разделить на три части.

Модуль трансформации (Transformation) преобразует трехмерные координаты в двумерные, привязанные к конкретной точке пространства, из которой наблюдатель смотрит на мир, и к направлению его взгляда. Именно здесь рассчитывается проекция перспективы.

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

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

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

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

11. Альтернативные технологии

11.1. Где не ступала нога Безье...

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

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

Один из видов таких кривых -- хорошо известные любому дизайнеру кривые Безье. Однако нам больше всего интересны не сами кривые, а их совокупности, которые вместе задают криволинейную поверхность. Такие поверхности сокращенно называются NURBS (от Non-Uniform Rational B-Spline -- неравномерный рациональный B-сплайн). Каждая такая поверхность задается сложным математическим уравнением. Графическая библиотека решает это уравнение относительно заданной области и получает набор точек в трехмерном пространстве, которые затем проецируются на экран.

Разработчикам достаточно задать опорные точки, их первоначальное положение и границы будущей поверхности, а 3D API сам рассчитает все остальное.

Об опорных точках стоит рассказать поподробнее, так как это самая важная часть технологии. Программист может поставить на поверхность столько опорных точек, сколько захочет. Если он потом изменит положение одной из этих точек, все остальные точки поверхности будут рассчитаны так, чтобы в поверхности не образовалось разрывов. Именно поэтому простая поверхность с всего парой десятков опорных точек может стать красивым платьем принцессы с множеством живописных складок, которое меняет свою форму в такт ходьбе. К сожалению, NURBS пока никак не обрабатываются графическими акселераторами, и все тяготы по их обсчету ложатся на плечи центрального процессора.

Представьте, что вам нужно вывести на экран красивую трехмерную сцену с множеством источников освещения, полупрозрачными объектами, зеркалами и затемненными местами. Получается та еще задачка, решить которую конвейер обычной графической библиотеки сможет только за очень большое число ходов. Как представишь себе: сцену тесселировать, невидимые плоскости отсечь, треугольники трансформировать, текстурировать, осветить, затенить, потом все это сгладить да на экран вывести -- руки опускаются. А нельзя ли это все сделать одним махом, как-нибудь по-быстрому? Да еще и качество картинки, и реалистичность освещения повысить на два порядка? И чтобы все это замечательно смотрелось в динамике? Лет пять назад вам категорично сказали бы: нельзя. Тогда методы рендера, основанные на Z-буфере, правили бал, так как они были, по сути, единственными, с которыми могли справиться компьютеры того времени. Сейчас компьютеры поднабрались силенок, и ответ специалиста будет другим: “Вообще-то можно, но...”. Давайте посмотрим, как это можно сделать и в чем заключается пресловутое “но”.

Технология, о которой пойдет речь, называется Ray Tracing -- обратная трассировка луча. Она с самого начала предназначалась для создания фотореалистичного изображения со сложной моделью освещения. Ray Tracing используется в мощных пакетах создания трехмерной графики -- 3D Studio MAX, Maya и LightWave при окончательной визуализации. Она засветилась и в “Властелинах колец”, и в “Звездных войнах”, и в “Шреке”, и во многих других анимационных фильмах и эпизодах со спецэффектами. Однако до недавнего времени никому не пришло бы в голову применять Ray Tracing в реальном времени -- уж больно он ресурсоемок.

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

Увы, у Ray Tracing есть один огромный недостаток -- он безумно ресурсоемок. Как и NURBS, трассировка обратного луча не рассчитывается акселератором. Даже самые современные процессоры могут рассчитывать в реальном времени картинку только в очень маленьком разрешении -- не больше 640х480. Как альтернатива -- мир должен состоять из простых и однозначно рассчитываемых примитивов, например из сфер. Несмотря на это, за обратной трассировкой лучей -- будущее. Современные методы визуализации трехмерной картинки рано или поздно упрутся в потолок реалистичности. Но к тому времени процессоры станут достаточно мощными, чтобы применять Ray Tracing даже в больших разрешениях. У этой технологии есть еще один плюс: алгоритм построения обратного луча легко распараллелить на много процессоров. А это значит, что его легко реализовать на многопроцессорных домашних компьютерах недалекого будущего.

11.2. Пиксели в 3D

Как известно, любая двумерная картинка, которая выводится на экран монитора, состоит из пикселей. Само слово pixel происходит от picture element -- элемент изображения. Такое представление довольно естественно, ведь экран монитора также состоит из дискретных элементов, каждый из которых может принимать тот или иной цвет. А почему бы этот принцип не перенести без изменений в 3D? Ведь если взять структурные единицы побольше да составить из них трехмерные картинки, то вывести их на экран монитора будет не так сложно. Этот принцип лежит в основе так называемой воксельной графики.

Воксель -- это, по сути, трехмерный пиксель (слово voxel образовано из VOlumized piXEL, то есть “объемный пиксель”). Как и пиксель, он имеет свой цвет. Из полигональной графики воксель позаимствовал свойства материала -- он может быть полупрозрачным и даже зеркальным. Любой объект в 3D, как из кубиков, составляется из вокселей. При этом воксели, как правило, образуют только внешнюю поверхность объектов, внутренности не заполняются.Так как каждый воксель передает свой цвет, необходимость в текстурах отпадает. Объекты из вокселей очень просто сделать разрушаемыми -- ведь перемещение каждого элемента объекта при, скажем, взрыве рассчитывается по простым и очевидным законам. Воксельные объекты очень просто анимировать -- достаточно задать последовательность трехмерных кадров.

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

В целом, воксельное представление трехмерного мира куда более естественно, чем полигональное. Картинка, полученная с использованием этой технологии, будет четкой и красивой. Но у вокселей есть два существенных недостатка. Первый заключается в том, что для хранения даже небольшой сцены высокого качества уходит огромное количество памяти и дискового пространства. Допустим, наш мир -- это всего лишь кубик 1024х768х1000. Это не очень большая сцена, но достаточно детальная, чтобы выглядеть фотореалистично. Она будет занимать “всего-то” чуть больше 750 мегабайт. Конечно, есть хитрости, которые позволяют уменьшить эту цифру в десятки раз. Например, можно хранить не матрицу вокселей, а их список. Это проще, так как в объектах очень много пустот. Данные о вокселях можно хранить в сжатом виде. Вторая ложка -- все те же акселераторы. Ну никак они не предназначены для новаторских технологий! Хотя если воксели представлять геометрическими примитивами (да теми же кубиками), акселератор возьмется-таки их ускорять. Но вот толку от этого будет существенно меньше, чем, если бы акселератор был специально предназначен для обработки вокселей.

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

11.3. Братья Шейдеры

Шейдеры ворвались в нашу жизнь неожиданно, нежданно-негаданно, сначала в виде изменений в очередной версии DirectX, а потом и от ведущих производителей видеокарт. Что же это за зверь такой, шейдер?

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

Вершинные шейдеры (Vertex Shaders) оперируют параметрами вершин объектов, такими как координаты самой вершины, координаты текстуры, цвет и параметры освещения. Акселератор применяет подпрограмму-шейдер к каждой вершине объекта перед рендером и изменяет один или несколько параметров, в зависимости от самой вершины или по какому-то хитрому алгоритму. К примеру, изменяя координаты вершин, мы запросто получим красивейшие волны, тонкие морщинки на лицах и разнообразные рельефные эффекты объектов. И все это в динамике! И все это без заметного падения производительности! Изменяя координаты текстур и параметры освещения, мы можем создать фантастические эффекты освещения и затенения, вплотную подходящие к тому, что может дать “честный” Ray Tracing. Хотите комнату, залитую динамическим светом тысяч свечей? Как скажете. Хотите объемный туман, медленно сползающий в лощину? Нет проблем.

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

Несомненно, шейдеры -- это шаг вперед, это настоящая революция в трехмерной графике (кстати, шейдеры версии 2.0 - это нововведение DirectX 9.0). Однако программирование шейдеров -- не такое простое дело. Низкоуровневый язык пиксельных и вершинных шейдеров, на первый взгляд, сильно напоминает ассемблер. И на нем не слишком удобно программировать сложные эффекты. Поэтому компания nVidia разжилась специальным языком программирования высокого уровня -- Cg, который очень похож на старый добрый Cи с новыми командами. В спецификации Cg сказано, что это язык управления акселератором в целом, однако наиболее интересны именно его шейдерные возможности. Он нисколько не отрицает уже существующие 3D API, такие как Direct3D и OpenGL, а скорее является продолжением их. Стандарт этот совершенно открытый, и любой желающий может скачать с сайта nVidia все необходимое, чтобы попробовать себя в режиссуре великолепных шейдерных эффектов новой эпохи.