Шейдеры
(Видео из игр, поддерживающих различные версии шейдеров: 1,4, 2.0, 3.0)
Шейдер – это функция или микропрограмма, которая определенным образом модифицирует какой-то элементарный участок трехмерной сцены перед рендером. Еще несколько лет назад шейдерные функции были доступны только на мощных графических станциях и не в реальном времени. Шейдеры позволяют создавать совершенно потрясающие спецэффекты. Шейдеры рассчитываются не центральным процессором, а специальным блоком видеопроцессора. Впервые аппаратная поддержка шейдеров появилась в GeForce 3 в виде подсистемы NVIDIA nfiniteFX engine. На сегодняшний день существуют два типа шейдеров.
Вершинные шейдеры (Vertex Shaders) оперируют параметрами вершин объектов, такими как координаты самой вершины, координаты текстуры, цвет и параметры освещения. Акселератор применяет подпрограмму-шейдер к каждой вершине объекта перед рендерингом и изменяет один или несколько параметров, в зависимости от самой вершины или по какому-то хитрому алгоритму. К примеру, изменяя координаты вершин, мы запросто получим красивейшие волны, тонкие морщинки на лицах и разнообразные рельефные эффекты объектов. (ВИДЕО ВОДЫ ИЗ HL2)
Пиксельные шейдеры (Pixel Shader) – еще более интересная технология. Она позволяет разработчикам игр применять к виртуальному миру попиксельные эффекты и динамически изменять свойства материалов объектов. Например, в одной из демок от nVidia логотип красуется на анимированной шероховатой отражающей поверхности! (ВИДЕО ПОВЕРХНОСТЕЙ SPLINTER CELL 3)
Но самое интересное применение этой технологии – динамическое попиксельное освещение. Отныне никаких карт освещения и заковыристых ухищрений для псевдосвета и псевдотеней: все рассчитывает в реальном времени абсолютно честно. Пиксельные шейдеры позволяют разработчику контролировать закраску, освещение и цвет каждого пикселя сцены. Кафель должен быть бело-зеркальным и гладким, ведь так? А гранит – шероховатым, с вкраплениями, верно? Какого бы большого разрешения не была текстура, она не сможет передать все нюансы рельефной поверхности. В этом смысле пиксельные шейдеры – своего рода альтернатива текстурам в их теперешнем виде.
Несомненно, шейдеры – это шаг вперед, причем очень большой. Однако программирование шейдеров — не такое простое дело. Низкоуровневый язык пиксельных и вершинных шейдеров, на первый взгляд, сильно напоминает ассемблер. И на нем не слишком удобно программировать сложные эффекты. Поэтому компания nVidia создала специальный язык программирования высокого уровня – Cg, который очень похож на старый добрый Cи с новыми командами. Cg – это язык управления акселератором в целом, однако наиболее интересны именно его шейдерные возможности. Он нисколько не отрицает уже существующие 3D API, такие как Direct3D и OpenGL, а скорее является надстройкой для них.
7. 3D API
3D-акселератор — сложная штуковина. Несколько десятков миллионов вентилей в основном кристалле, еще несколько — в сервисных (DDR, RAMDAC и т.д.) плюс электронные цепи, размещающиеся на самой плате видеокарты. И со всем этим надо как-то управляться. У акселератора есть свой ассемблер (не совсем
|
Рис. 1. Так выглядел
легендарный 3dfx Voodoo,
понимавший исключительно
Glide. С него все и началось.
|
| так, но сравнение хорошее) и специальные команды, адреса и интерфейсы, через которые им можно управлять. Все вместе это сложнейшая система. У каждого конкретного акселератора (а их сотни) свои особенности, свои дополнительные команды, а иногда и целые блоки. Если написать программную последовательность для одного акселератора, на другом она работать уже не будет. А теперь поставьте себя на место разработчика компьютерных игр. С одной стороны, надо научиться управлять этой сложнейшей системой, понять ее язык, с другой — быть на гребне технологической волны, держать руку на пульсе прогресса, ну а с третьей — сделать игру совместимой с разными акселераторами. На практике это означает, что придется писать не один движок, а столько, сколько акселераторов поддерживается. Сразу грустно стало? На самом деле разработчикам живется не так уж плохо. И им не приходится писать сотни движков вместо одного. И им не приходится вникать в особенности акселераторов. Они могут вообще ничего не знать о железе игрока и успешно разрабатывать игры. А освободили их от этого тяжкого бремени программно-аппаратные интерфейсы — 3D API. (Application Program Interface)
|
Рис. 2. Еще десяток лет назад
каждый уважающий себя
геймер хотел получить под
елку такую коробочку...
|
| Это специальная библиотека, которая позволяет разработчикам не думать о таких мелочах, как адреса видеобуфера или заполнение системных регистров, и сосредоточиться на процессе разработки. На практике это выглядит так. Чтобы создать, например, точечный источник света, нужно задействовать многие команды акселератора, подумать о перераспределении памяти, количестве оставшихся источников (большинство акселераторов аппаратно обрабатывает лишь 8 источников света, остальные эмулируются) и еще много о чем. А вот через API это делается всего одной командой (максимум — двумя). Разработчик пишет эту команду, а все остальное делает 3D API. Примерно так же делаются и другие сложные вещи. Например, в OpenGL такая сложнейшая вещь, как NURBS (которая до сих пор считается признаком технологического шика), создается несколькими простыми командами.
|
Рис. 3. ...и возможности,
которые она давала, были по
тем временам невероятными.
Хотя сейчас, в эру HL2 и
Doom 3, такой скриншот
выглядит по меньшей мере
нелепо.
|
| В работе акселератора много рутины. Поэтому многие стандартные действия, вроде подготовки видеообласти (viewport), выполняет тот же 3D API. Не думайте, что он работает только с акселератором. И с процессором, и с памятью, и даже с другими API, например с Windows API, который отвечает за прорисовку окон. Получается, разработчику игр почти ничего делать не надо: задал несколько простых стандартных команд, и готово. Нет, не получается. Им тоже забот хватает. Зато с поддержкой 3D API остаются время и силы на проработку действительно интересных и сложных вещей, не рутинных, а творческих.
На самом деле взаимодействие 3D API и акселератора несколько сложнее, чем я сейчас описал. Ведь между ними стоит еще и драйвер. Зачем он нужен? Для разных версий акселераторов нет разных 3D API. Один 3D API, по-хорошему, должен понимать все железо, какое только есть на свете. Но если бы он на самом деле умел общаться со всем железом, то весил бы не несколько мегабайт. Поэтому 3D API один на всех, а вот драйверов много — под каждый акселератор свой. Говоря программистским языком, драйвер предоставляет небольшой, а 3D API — очень большой уровень абстракции.
На этом можно было бы и закончить наш разговор, если бы не было одной маленькой проблемки. На свете несколько 3D API от разных компаний. И разные игры также заточены под разные API. И даже те игры, которые формально работают с несколькими API, на самом деле по-настоящему хорошо понимают только один-два API, а остальные — через пень-колоду. Или нагло эмулируют. Впрочем, даже с родными API нередко возникают проблемы.
|
;)
;)
