| netlib.narod.ru | < Назад | Оглавление | Далее > |
Итак, мы увидели, как видеокарта выполняет визуализацию, но большой фрагмент головоломки все еще отсутствует. Нам необходима возможность сообщить аппаратуре, какую геометрию мы хотим визуализировать и как. Мы нуждаемся в программном интерфейсе, который позволяет взаимодействовать с оборудованием.
У первой потребительской видеокарты с аппаратным ускорением трехмерной графики, 3Dfx, был собственный API называвшийся Glide. Он позволял взаимодействовать непосредственно с аппаратурой и визуализировать вашу геометрию. Однако API, являющийся собственностью производителя оборудования имеет один большой недостаток. Когда другие компании также выпустили собственные видеокарты с аппаратным ускорением трехмерной графики, разработчикам стало практически невозможно писать приложения, которые бы одинаково работали на всех видеокартах. Требовался более стандартизованный и не привязанный к конкретной аппаратуре API для трехмерной визуализации. Ответом на эту потребность стали драйвера OpenGL и Microsoft Direct3D.
Разработку OpenGL начала Silicon Graphics, Inc (SGI) в конце 1980 годов. Целью разработки было создание многоцелевого, независимого от платформы API для трехмерной графики. Версия 1.0 OpenGL API вышла в 1990 году. С 1992 года развитием OpenGL управляет ARB (Наблюдательный совет архитектуры OpenGL). В наблюдательный совет входят представители ведущих производителей видеокарт и лидеров индустрии, таких как NVIDIA, ATI Technologies, IBM, Intel, SGI и многих других. Задачей ARB является усовершенствование стандарта и поддержка спецификаций OpenGL, чтобы они соответствовали текущим и будущим потребностям индустрии.
Текущая версия OpenGL имеет номер 1.5. Отсюда видно, что OpenGL меняется не часто. Однако ARB упорно трудится над новой версией спецификаций, которая будет использовать все преимущества новых технологий.
Изначально OpenGL разрабатывался для высокопроизводительных графических станций, и до недавнего времени это мешало его полноценному использованию на потребительских видеокартах. С появлением таких нововведений как мультитекстурирование, вершинные и пиксельные шейдеры, спецификации API отстали от жизни. Поэтому многие производители видеокарт создавали расширения стандарта, соответствующие их требованиям и последним инновациям. Однако за несколько прошедших лет среди производителей оборудования почти не было согласия по вопросу о расширениях что привело к появлению многих запатентованных расширений, которые могли работать только с определенным оборудованием. ARB упорно работает над новыми спецификациями, чтобы обеспечить более согласованный набор возможностей и лучшее взаимодействие между производителями, гарантирующее большую совместимость с будущими расширениями.
OpenGL предлагает набор из нескольких сотен функций, предоставляющих простой доступ к большинству возможностей, поддерживаемых видеокартой. Внутри OpenGL действует как простой конечный автомат. С помощью API вы можете устанавливать значения различных параметров, управляя таким образом состоянием автомата, в том числе такими вещами, как цвет, освещение, смешивание и т.д. Используя тот же самый API, вы можете передавать аппаратуре данные о геометрии и команды визуализации, которые будут учитывать состояния внутреннего автомата OpenGL.
В центре OpenGL лежит конвейер визуализации; независимо от того, программно он реализован или аппаратно, базируется он на тех принципах, которые обсуждались ранее в этой главе. В целом идея проста, а большинство усилий за рамками OpenGL направлены на гарантию поддержки текущего и будущего оборудования, а также на обеспечение кросс-платформенной среды разработки.
После выхода Windows 95 большая часть игр по-прежнему разрабатывалась для DOS. Microsoft решила, что разработчикам игр пришла пора переезжать с устаревшей DOS на более современную платформу Windows, чтобы увеличить ее популярность. Однако Windows не была хорошей игровой платформой, поскольку ее внутренний графический API имел слишком много уровней абстракции, предназначался для разработки пользовательских интерфейсов и, по этим причинам, работал очень медленно! Тогда Microsoft решила создать API для разработчиков игр, который позволял бы более прямой доступ к аппаратуре и обеспечивал приемлемую скорость работы игр под Windows.
Вместо того чтобы с нуля разрабатывать собственный API, Microsoft обратила внимание на перспективный API трехмерной графики, разработанный компанией RenderMorphics. Это был небольшой проект компании, который она демонстрировала на выставках. Microsoft решила использовать этот API и включила его в свою разработку, известную в то время под названием Game SDK. В конечном итоге Game SDK был переименован в DirectX 1.0. Но в то время этот API не получил широкого признания, поскольку был медленным, плохо структурированным и содержал много ошибок.
К чести Microsoft следует отметить, что она не забросила эту идею через несколько лет, когда выяснилось, что она работает не так, как планировалось. Работы продолжались с учетом предложений и отзывов разработчиков. В 1998 году появилась первая действительно жизнеспособная версия SDK под названием DirectX 3.0. С этого момента API обрел законченную форму и стал распространяться среди разработчиков. За прошедшие годы Microsoft выпустила версии 5, 6, 7, 8 и, наконец, последнюю на сегодняшний день, версию 9.0. Каждая новая версия работала лучше и предлагала новые возможности, требуемые сообществом разработчиков. Большим шагом в эволюции DirectX стала версия 8.0, где впервые была включена поддержка ныне широко известной архитектуры вершинных и пиксельных шейдеров.
Структура Direct3D, да и DirectX в целом, значительно отличалась от OpenGL. Однако с течением времени, DirectX постепенно становится все более похож на OpenGL. Не углубляясь в детали, я лишь упомяну, что DirectX основан на модели COM-объектов. Это означает, что вы создаете указатели на классы и используете их, вместо простого вызова функций, который не позволяет ясно видеть взаимосвязи. Таким образом, DirectX лучше структурирован, чем OpenGL.
Продолжительные дебаты и масштабные сражения разворачиваются по вопросу о том, какой API лучше: Direct3D или OpenGL. С одной стороны, Direct3D и DirectX работают только на платформе Windows, что не оставляет выбора разработчикам кросс-платформенных приложений. Но если вы разрабатываете приложения только для Windows, стоит рассмотреть сильные и слабые стороны каждого API.
Оба API достаточно просты в использовании. Однако DirectX в общем случае требует больше кода для инициализации. DirectX чаще обновляется и более приспособлен для использования преимуществ самых последних технологий чем OpenGL. DirectX предоставляет более объектно-ориентированную структуру, но, с другой стороны, OpenGL проще использовать. Большинство разработчиков имеют склонность к одному из API, но если вы начинающий разработчик ваши потребности удовлетворит любой из них.
Поскольку эта книга не пытается сконцентрироваться на каком-то конкретном API, вопрос, заданный в названии раздела останется без ответа. Поскольку RenderMonkey использует в работе DirectX, некоторые ограничения и концепции взяты из DirectX API. Но если вы решите использовать для разработки OpenGL, уроки из этой книги могут быть легко адаптированы.
Теперь, когда вы имеете представление о том, что происходит во время визуализации, и об основных используемых в индустрии API, я кратко рассмотрю базовую архитектуру, предлагаемую основными производителями видеокарт. На рис. 2.11 показана простая схема аппаратной архитектуры, используемая в ряде видеокарт. Хотя по сравнению с большинством современных архитектур эта схема значительно упрощена, она служит своей цели и помогает исследовать аппаратную реализацию.
Рис. 2.11. Схема архитектуры аппаратуры визуализации
Как видно на рис. 2.11, весь процесс визуализации может быть разделен на три отдельных категории операций: операции с источником, операции с вершинами и операции с пикселями.
Операции с источником берут поступающие данные вершин и готовят их к обработке. Некоторые аппаратные архитектуры могут выполнять высокоуровневое разбиение поверхностей; это значит, что в качестве источника геометрических данных могут быть указаны кривые поверхности, которые потом аппаратурой на лету разделяются на отдельные полигоны. Такие высокоуровневые поверхности предоставляют больше гибкости для детализации геометрии на основе таких критериев, как производительность и размер сетки на экране.
Следующая последовательность операций — вершинные. Это то место, где в игру вступают вершинные шейдеры. Как видно на рис. 2.11, поступающие от операций с источником данные вершин могут проходить либо через блок вершинных шейдеров, либо через блок фиксированного конвейера. Фиксированный конвейер является устаревшей, оставленной для обратной совместимости реализацией, выполняющей преобразования и освещение геометрии. Поскольку фиксированный конвейер оставлен для обратной совместимости, большинство разработчиков выбирают использование вершинных шейдеров. После того как данные вершины пройдут через вершинный шейдер или через блок фиксированного конвейера, они поступают в следующий блок, который выполняет заключительные операции, прежде чем из потока вершин будут сформированы реальные полигоны. Выполняемые на данном этапе операции включают отбрасывание обратных поверхностей, отсечение, разделение однородного пространства и преобразование порта просмотра.
Когда ваши вершины обработаны и готовы к рисованию, можно перейти к фазе операций с пикселями. Первый этап данной фазы — операции расстановки треугольников и растеризации. Здесь берется исходный поток вершин, на основе его устанавливаются полигоны, которые растеризуются в пиксели экрана. Как упоминалось ранее, при растеризации определяется область экрана, которую занимает полигон. После того, как область экрана определена, она разделяется на более мелкие части, обычно на горизонтальные линии пикселей, называемые фрагментами.
Теперь у нас есть пиксели, но перед рисованием надо завершить их обработку. Здесь вступает в действие следующий блок. Как и в случае с вершинными шейдерами, здесь пиксели могут пройти через пиксельный шейдер или через фиксированный конвейер. И тот и другой берут полученные в процессе растеризации интерполированные данные пикселя и определяют итоговый цвет пикселя путем просмотра данных текстур и выполнения других операций над пикселем. После определения цвета пикселя, он может пройти через последний набор блоков, выполняющих заключительные операции визуализации, такие как затуманивание, альфа-смешивание и проверка трафарета. В результате мы получаем пиксель, который можно смешивать с данными выходного буфера, которые будут выводиться на экран. Следует отметить, что в современных архитектурах несколько пикселей обрабатывается одновременно.
Вуаля! Ладно... в реальной жизни с последними технологиями все гораздо сложнее. Мы пропустили ряд этапов, таких как Z-буферизация, и новые этапы, такие как проверка заграждения и сжатие. Однако вы должны получить представление о том, как обсужденный ранее алгоритм визуализации находит отражение в архитектуре видеокарт. Что еще более важно, вы получили более точное представление о том, как вершинные и пиксельные шейдеры встраиваются в поток аппаратной визуализации. В этой книге мы в первую очередь сосредоточимся на операциях вершинных и пиксельных шейдеров, которые выделены на рис. 2.11.
Теперь вы представляете, что происходит во время визуализации. Но где вступают в игру шейдеры и какое место занимают они в формуле визуализации? Разработчики компьютерной графики быстро обнаружили, что фотореалистичное представление зависит от многих переменных, которые не могут быть выражены в виде простой системы уравнений или фиксированного набора состояний. Фактически, большинство фотореалистичных представлений одной частью зависят от полученных путем исследований формул, а другой частью — от наблюдений за явлениями реального мира и попыток воспроизвести их. Поэтому разработчикам необходим способ полностью контролировать поток информации, позволяющий реализовать сложные алгоритмы, необходимые для реалистичной визуализации. Одна из первых инкарнаций такой архитектуры — уже упомянутый RenderMan, разработанный анимационной студией Pixar.
RenderMan — это стандарт, разработанный почти 15 лет назад. Его цель — предоставить схему обмена информацией, обеспечивающую совместимость между программами трехмерного моделирования и аппаратурой визуализации. Помимо задания формата обмена данными, стандарт также описывает программный подход к материалам, позволяющий разработчикам указать, как должна быть визуализирована поверхность. Это было достигнуто путем использования простого языка, во многом похожего на язык С, который позволял разработчикам получать входные данные визуализатора и применять к ним перед началом визуализации собственные алгоритмы.
Сам по себе RenderMan это только стандарт, но Pixar на его основе разработала реальный программный визуализатор. С помощью RenderMan и собственного визуализатора Pixar доказала, что использование шейдеров позволяет создавать ошеломляющую компьютерную графику, и RenderMan используется в киноиндустрии до сих пор. Сам RenderMan никогда не разрабатывался как шейдерный язык реального времени, а позиционировался как решение для создания графики кинематографического качества, визуализация которой может занимать продолжительное время. Тем не менее, он послужил основой для создания современных шейдерных языков реального времени.
Из-за успеха RenderMan, обусловленного его гибкостью, производители аппаратуры захотели получить такую же гибкость для своих решений с аппаратным ускорением. Однако в то время производительность процессоров видеокарт не позволяла реализовать программируемые шейдеры, особенно пиксельные. Еще несколько лет назад производители оборудования и разработчики должны были жить с ограничениями, накладываемыми архитектурой фиксированного конвейера визуализации. Наконец, благодаря стремительному развитию индустрии производства микросхем, аппаратные средства усовершенствовались настолько, что позволили включить поддержку программируемых шейдеров.
С выпуском DirectX 8.0 SDK появился и первый видеопроцессор, обеспечивающий визуализацию с аппаратным ускорением для шейдеров. Это оборудование, разработанное NVIDIA, обладало ограниченными возможностями, но полностью реализовывало версию 1.1 стандарта вершинных и пиксельных шейдеров. Этот первый стандарт шейдеров обладал ограниченной функциональностью и не поддерживал такие возможности, как условные переходы и циклы. Поддержка пиксельных шейдеров также была очень ограниченной в плане количества инструкций и операций с текстурами. Однако это был первый шаг, позволивший разработчикам уйти от ограничений фиксированного конвейера и реализовать собственный творческий потенциал. Тогда же NVIDIA выпустила собственное расширение OpenGL делающее архитектуру вершинных и пиксельных шейдеров полностью доступной разработчикам.
Из-за жесткой конкуренции в индустрии производства видеокарт, ATI Technologies, главный конкурент NVIDIA, должна была ответить на этот первый выпуск аппаратно ускоренных шейдеров. Совместно с Microsoft ATI Technologies разработала вершинные и пиксельные шейдеры версии 1.4, поддержка которых была включена в DirectX 8.1 SDK. Эта новая версия добавила гибкости архитектуре пиксельных шейдеров путем увеличения количества арифметических и текстурных операций и добавления возможности чередовать арифметические операции с текстурными. У ATI появилось первое поколение технологии аппаратного ускорения шейдеров. Из-за скорого выхода DirectX 9.0 SDK эта инкарнация шейдеров оказалась недолговечной.
Microsoft решила, что ради разработчиков производители видеокарт должны теснее сотрудничать между собой. Как разработчик DirectX 9.0 она предложила два новых стандарта шейдеров — версии 2.0 и 3.0. Одновременно с выпуском последнего SDK от Microsoft ATI и NVIDIA запустили их первую итерацию вершинных и пиксельных шейдеров версии 2.0. В этот новый стандарт шейдеров было добавлено все, чего желали разработчики. Новые возможности включали увеличение количества инструкций в шейдере, условные выражения и циклы.
Таково положение дел сегодня. Разработчики получили те же возможности, которые были у создателей компьютерной графики для фильмов, и, как можно видеть в последних технологических демонстрациях, качество графики не прекращает улучшаться. Что ждет нас в будущем? Во-первых, версия 3.0 стандарта вершинных и пиксельных шейдеров предоставляет разработчикам еще большую мощь и гибкость. Во-вторых, лидеры отрасли предсказывают, что благодаря постоянно увеличивающейся скорости и производительности видеокарт в течение нескольких лет компьютерная графика в реальном времени сравнится по качеству, а возможно даже и превзойдет, качество графики в киноиндустрии. Это возлагает на разработчиков огромную ответственность, поскольку они должны не отставать от скачущей галопом эволюции. С другой стороны, мы наконец можем получить графику, о которой всегда мечтали.
| netlib.narod.ru | < Назад | Оглавление | Далее > |