You are here: Home > Живопись в сети > Современная терминология 3D графики

Современная терминология 3D графики

Мир 3D графики, в том числе игровой, наполнен терминами. Терминами, которые не всегда имеют единственно правильное определение. Иногда одни и те же вещи называются по-разному, и наоборот, один и тот же эффект может называться в настройках игры то “HDR”, то “Bloom”, то “Glow”, то “Postprocessing”. Большинству людей из похвальбы разработчиков о том, что они встроили в свой графический движок, непонятно, что в реальности имелось в виду.

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

Если что-то в этой статье и в статьях Александра вам не понятно, то есть смысл начать с самого раннего, с “Терминологии 3D-графики” и других теоретических статей из раздела “Видеосистема” нашего сайта . Эти статьи уже несколько устарели, конечно, но основные, самые начальные и важные данные там есть. Мы же с вами поговорим о более “высокоуровневых” терминах. Основные понятия о 3D графике реального времени и устройстве графического конвейера у вас должны быть. С другой стороны, не ждите математических формул, академической точности и примеров кода – статья предназначена совсем не для этого.

Шейдером в широком смысле называется программа для визуального определения поверхности объекта. Это может быть описание освещения, текстурирования, постобработки и т.п. Шейдеры выросли из работ Кука (Cook’s shade trees) и Перлина (Perlin’s pixel stream language). Сейчас наиболее известны шейдеры RenderMan Shading Language. Программируемые шейдеры были впервые представлены в RenderMan компании Pixar, там определены несколько типов шейдеров: light source shaders, surface shaders, displacement shaders, volume shaders, imager shaders. Эти шейдеры чаще всего программно выполняются универсальными процессорами и не имеют полной аппаратной реализации. В дальнейшем, многие исследователи описывали похожие на RenderMan языки, но они уже были предназначены для аппаратного ускорения: система PixelFlow (Olano и Lastra), Quake Shader Language (применен id Software в графическом движке игры Quake III, который описывал многопроходный рендеринг), и другие. Peercy сотоварищи разработали технику для того, чтобы программы с циклами и условиями выполнять на традиционных аппаратных архитектурах при помощи нескольких проходов рендеринга. Шейдеры RenderMan разбивались на несколько проходов, которые комбинировались во фреймбуфере. Позднее появились языки, которые мы видим аппаратно ускоренными в DirectX и OpenGL. Так шейдеры были адаптированы для графических приложений реального времени.

Видеочипы раннего времени не были программируемы и исполняли только заранее запрограммированные действия (fixed-function), например, алгоритм освещения был жестко зафиксирован в железе, и нельзя было ничего изменить. Затем, компании-производители видеочипов постепенно ввели в свои чипы элементы программируемости, сначала это были очень слабые возможности (NV10, известный как NVIDIA GeForce 256, уже был способен на некоторые примитивные программы), которые не получили программной поддержки в Microsoft DirectX API, но со временем возможности постоянно расширялись. Следующий шаг был за и NV20 (GeForce 3) и NV2A (видеочип, примененный в игровой консоли Microsoft Xbox), которые стали первыми чипами с аппаратной поддержкой шейдеров DirectX API. Версия Shader Model 1.0/1.1, появившаяся в DirectX 8, была сильно ограничена, каждый шейдер (особенно это относится к пиксельным) мог быть сравнительно малой длины и сочетать весьма ограниченный набор команд. В дальнейшем, Shader Model 1 (SM1 для краткости) была улучшена с пиксельными шейдерами версии 1.4 (ATI R200), которые предлагали большую гибкость, но также имели слишком ограниченные возможности. Шейдеры того времени писались на так называемом assembly shader language, который близок к ассемблеру для универсальных процессоров. Его низкий уровень доставляет определенные сложности для понимания кода и программирования, особенно, когда код программы большой, ведь он далек от элегантности и структурированности современных языков программирования.

Версия Shader Model 2.0 (SM2), появившись в DirectX 9 (что было поддержано видеочипом ATI R300, ставшим первым GPU с поддержкой шейдерной модели версии 2.0), серьезно расширила возможности шейдеров реального времени, предложив более длинные и сложные шейдеры и заметно расширившийся набор команд. Была добавлена возможность расчетов с плавающей запятой в пиксельных шейдерах, что также стало важнейшим улучшением. DirectX 9, в лице возможностей SM2, также привнес и язык шейдеров высокого уровня – high-level shader language (HLSL), весьма похожий на язык Си. И эффективный компилятор, переводящий HLSL программы в низкоуровневый код, “понятный” для аппаратных средств. Причем, доступно несколько профилей, предназначенных для разных аппаратных архитектур. Теперь, разработчик может писать один код HLSL шейдера и компилировать его при помощи DirectX в оптимальную программу, для установленного у пользователя видеочипа. После этого выходили чипы от NVIDIA, NV30 и NV40, которые улучшили возможности аппаратных шейдеров еще на шаг, добавив еще более длинные шейдеры, возможности динамических переходов в вершинных и пиксельных шейдерах, возможность выборки текстур из вершинных шейдеров и др. С тех пор пока качественных изменений не было, они ожидаются ближе к концу 2006 года в DirectX 10…

В целом, шейдеры добавили к графическому конвейеру множество новых возможностей по трансформации и освещению вершин и индивидуальной обработке пикселей так, как этого хотят разработчики каждого конкретного приложения. И все-таки, возможности аппаратных шейдеров до сих пор не раскрыты в приложениях полностью, а ведь с увеличением их возможностей в каждом новом поколении “железа”, мы скоро увидим уровень тех самых шейдеров RenderMan, которые когда-то казались недостижимыми для игровых видеоускорителей. Пока в шейдерных моделях реального времени, поддерживаемых на сегодняшний день аппаратными видеоускорителями, определено лишь два типа шейдеров: Vertex Shader и Pixel Shader (в определении DirectX 9 API). В будущем DirectX 10 к ним обещает добавиться еще и Geometry Shader .

Вершинные шейдеры – это программы, выполняемые видеочипами, которые производят математические операции с вершинами (vertex, из них состоят 3D объекты в играх), иначе говоря, они предоставляют возможность выполнять программируемые алгоритмы по изменению параметров вершин и их освещению (T&L – Transform & Lighting). Каждая вершина определяется несколькими переменными, например, положение вершины в 3D пространстве определяется координатами: x, y и z. Вершины также могут быть описаны характеристиками цвета, текстурными координатами и т.п. Вершинные шейдеры, в зависимости от алгоритмов, изменяют эти данные в процессе своей работы, например, вычисляя и записывая новые координаты и/или цвет. То есть, входные данные вершинного шейдера – данные об одной вершине геометрической модели, которая в данный момент обрабатывается. Обычно это координаты в пространстве, нормаль, компоненты цвета и текстурные координаты. Результирующие данные выполняемой программы служат входными для дальнейшей части конвейера, растеризатор делает линейную интерполяцию входных данных для поверхности треугольника и для каждого пикселя исполняет соответствующий пиксельный шейдер. Очень простой и грубый (но наглядный, надеюсь) пример: вершинный шейдер позволяет взять 3D объект сферы и вершинным шейдером сделать из него зеленый куб :) .

До появления видеочипа NV20 у разработчиков было два пути, либо использовать собственные программы и алгоритмы, изменяющие параметры вершин, но тогда все расчеты делал бы CPU (software T&L), либо полагаться на фиксированные алгоритмы в видеочипах, с поддержкой аппаратной трансформации и освещения (hardware T&L). Первая же шейдерная модель DirectX означала большой шаг вперед от фиксированных функций по трансформации и освещению вершин к полностью программируемым алгоритмам. Стало возможным, например, выполнять алгоритм скининга полностью на видеочипах, а до этого единственной возможностью было их исполнение на универсальных центральных процессорах. Теперь, с сильно улучшенными со времен упомянутого чипа NVIDIA возможностями, с вершинами при помощи вершинных шейдеров можно делать уже очень многое (кроме их создания, разве что)…

Примеры того, как и где применяются вершинные шейдеры:

Пиксельные шейдеры – это программы, выполняемые видеочипом во время растеризации для каждого пикселя изображения, они производят выборку из текстур и/или математические операции над цветом и значением глубины (Z-buffer) пикселей. Все инструкции пиксельного шейдера выполняются попиксельно, после того, как операции с трансформированием и освещением геометрии завершены. Пиксельный шейдер в итоге своей работы выдает конечное значение цвета пикселя и Z-значение для последующего этапа графического конвейера, блендинга. Наиболее простой пример пиксельного шейдера, который можно привести: банальное мультитекстурирование, просто смешение двух текстур (diffuse и lightmap, например) и наложение результата вычисления на пиксель.

До появления видеочипов с аппаратной поддержкой пиксельных шейдеров, у разработчиков были лишь возможности по обычному мультитекстурированию и альфа-блендингу, что существенно ограничивало возможности по многим визуальным эффектам и не позволяло делать многое из того, что сейчас доступно. И если с геометрией еще что-то можно было делать программно, то с пикселями – нет. Ранние версии DirectX (до 7.0 включительно) всегда выполняли все расчеты повершинно и предлагали крайне ограниченную функциональность по попиксельному освещению (вспоминаем EMBM – environment bump mapping и DOT3) в последних версиях. Пиксельные шейдеры сделали возможным освещение любых поверхностей попиксельно, используя запрограммированные разработчиками материалы. Появившиеся в NV20 пиксельные шейдеры версии 1.1 (в понимании DirectX) уже могли не только делать мультитекстурирование, но и многое другое, хотя большинство игр, использующих SM1, просто использовали традиционное мультитекстурирование на большинстве поверхностей, выполняя более сложные пиксельные шейдеры лишь на части поверхностей, для создания разнообразных спецэффектов (все знают, что вода до сих пор является наиболее частым примером использования пиксельных шейдеров в играх). Сейчас, после появления SM3 и поддерживающих их видеочипов, возможности пиксельных шейдеров доросли уже до того, чтобы с их помощью делать даже трассировку лучей (raytracing), пусть пока с некоторыми ограничениями.

Примеры применения пиксельных шейдеров:

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

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

К сожалению, процедурные текстуры не получили пока должного применения в играх, в реальных приложениях до сих пор зачастую проще загрузить обычную текстуру, объемы видеопамяти растут не по дням, а по часам, в самых современных ускорителях ставят уже 512 мегабайт выделенной видеопамяти, которую надо чем-то занимать. Более того, до сих пор чаще делают наоборот – для ускорения математики в пиксельных шейдерах используют lookup tables (LUT) – специальные текстуры, содержащие заранее просчитанные значения, получаемые в результате вычислений. Чтобы не считать для каждого пикселя несколько математических команд, просто читают заранее вычисленные значения из текстуры. Но чем дальше, тем сильнее акцент должен смещаться именно в сторону математических вычислений, взять те же видеочипы ATI нового поколения: RV530 и R580, у которых на каждые 4 и 16 текстурных блоков приходится 12 и 48 пиксельных процессоров, соответственно. Тем более, если речь о 3D текстурах, ведь если двухмерные текстуры без проблем можно разместить в локальной памяти ускорителя, то 3D текстуры требуют ее намного больше.

Примеры процедурных текстур:

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

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

Источник: http://www.ixbt.com

Tags:

Leave a Reply