Период 2010-2011 гг. можно назвать очень насыщенным по части прогресса технологий 3D-визуализации. Сегодня мы уже можем наблюдать первые варианты вывода трехмерной графики в рамках браузеров по технологиям Abobe Molehill и WebGL, фактический апгрейд алгоритмов представления профессионального 3D-контента в OpenGL и DirectX 11. А осенью этого года произошел еще один мощный скачок - практически во всех пакетах 3D-моделирования/анимации, а также в программах видеомонтажа, работающего со стереоскопическим 3D-видео, благодаря недавнему появлению фреймворка OpenCL и его поддержки на уровне графических адаптеров появились возможности трехмерного просмотра (анаглиф и другие технологии).

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

OpenGL vs Direct3D

В принципе, совсем несложно проследить, что во всех трех названных выше эпохальных событиях участвуют представители семейства спецификации OpenGL. В последнее время оно практически "возродилось из пепла" после перехода в 2006-м под крыло промышленного консорциума Khronos Group, включающего 100 ведущих предприятий.

На самом деле, даже в начале-середине 90-х противостояние "OpenGL vs Direct3D" выглядело таковым чисто внешне. Ведь сама спецификация OpenGL появилась раньше и разрабатывалась под патронажем наблюдательного совета за этой архитектурой - ARB (OpenGL Architecture Review Board), одним из основоположников которого среди всех прочих являлась и компания Microsoft. Само направление является очень выгодным, в его развитии заинтересованы представители разных отраслей: военные, медицина, промышленность.

Во главе ARB выступала фирма Silicon Graphics Incorporated (SGI). В качестве прототипа для OpenGL была использована разработка этой фирмы - IRIS GL. Причем, основной упор новой архитектуры был сделан на перенесение большей части вычислений в программную часть, чем достигалось абстрагирование от "железа" - одна из самых ярких отличительных особенностей спецификации.

В 1995-м Microsoft предлагает свою собственную альтернативу - библиотеку Direct3D, причем сразу после ее появления была предпринята попытка объединения с OpenGL в единый универсальный программный 3D-интерфейс под общим названием Fahrenheit. Но сама идея сочленения двух API в один по объективным причинам так и осталась на уровне проекта.

Отличие подхода в решении Microsoft выражалось в том, что в Direct3D была снижена планка абстрагирования от аппаратной части с предоставлением реализации расчетов ключевых алгоритмов производителям видеоадаптеров. Программистам в данном случае предлагалось обращаться к нужным функциям через API (а если точнее, то через специальный "слой" HAL), и игры, сделанные под Direct3D, на каждом компьютере работали и выглядели по-разному - все зависело от видеоадаптера.

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

И только сейчас мы можем говорить о новом витке соперничества.

Противостояние последних лет выглядит не совсем равномерно, и чаша весов во многом уже склоняется в сторону OpenGL. По сравнению с Direct3D, мы говорим о практически равных технологических возможностях. Например, начиная со спецификации OpenGL 4.0, достигнута реализация прорисовки сгенерированных данных без участия центрального процессора, только за счет GPU. И при этом консорциум Khronos Group на данный момент предлагает более широкий спектр стандартов, таких как OpenGL ES (OpenGL for Embedded Systems - OpenGL для встраиваемых систем), WebGL (вывод 3D-контента в браузерах за счет использования графического ускорителя пользовательских компьютеров), COLLADA, объединяющим все пакеты 3D-моделирования/анимации, не говоря уже о большем охвате платформ.

Противостояние последних лет выглядит не совсем равномерно, и чаша весов во многом уже склоняется в сторону OpenGL.

Тесселяция. Игровые движки vs пакеты 3D-анимации

В данном случае стоит обратить внимание на противостояние технологий, использующихся в профессиональной 3D-анимации (кино) и компьютерных играх. Думается, что многие из наших читателей знают о том, что в фильме "Аватар" свет вычислялся по игровым технологиям, при стандартном способе расчеты заняли бы гораздо больше времени. И это только один из показательных случаев. Сейчас очень многое из телевизионного контента, визуализации дизайна и т.п. делается уже в профессиональных игровых движках AAA-класса вроде UDK и Cry Engine 3, которые предоставляют огромные возможности и быстрое время расчетов с высочайшим качеством рендеринга.

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

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

Сегодня хотелось бы поговорить о том, чего нет в пакетах 3D-моделирования/анимации, но уже активно используется в играх - тесселяции.

Под самим термином подразумевается сравнительно давняя технология, представляющая собой, если говорить простым обобщенным языком, динамическое разбиение полигонов на более мелкие части. Проблема состоит в том, что по мере приближения к зрителю объектам нужна различная степень детализации, за счет чего экономится нагрузка на вычислительные мощности. Раньше в игровых движках это решалось, в основном, таким нехитрым способом, как создание нескольких вариантов моделей с различными уровнями детализации (LOD), а игровой движок их переключал по мере удаления/приближения.

Стандартный вариант с созданием моделей с различными уровнями детализации (LOD)

Алгоритмы тесселяции позволяют разработчикам упростить процесс разработки: создать только одну Sub-D-модель, которая постоянно пересчитывается за счет графического ускорителя. Например, по мере приближения к зрителю, детализация увеличивается, модель сглаживается, после чего могут использоваться карты смещения (т.е. текстуры, хранящие информацию о высотах), bump-mapping и displacement. На выходе мы получаем качественное представление с кинематографическим уровнем реализма. Экономия происходит за счет того, что на GPU поступает только D-Sub модель, ее "улучшением" уже аппаратно занимается графический адаптер - для этого в графических процессорах предусмотрены специальные блоки, каждый из которых представлен специальным аппаратным обеспечением для выбора вершины, проведения тесселяции и трансформаций координат (например, в GeForce GTX 400 таких блоков 15). Они работают вместе с параллельными растровыми движками, превращающими вновь тесселированные треугольники в точный поток пикселов для закраски.

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

Пример из тестового пакета Unigine Heaven 2.0. Тесселяция отключена

Пример из тестового пакета Unigine Heaven 2.0. Тесселяция включена

На данный момент ключевые современные алгоритмы тесселяции поддерживаются со стороны OpenGL 4.0, DirectX 11 (актуально сравнивать именно эти версии) и, соответственно, большинством современных видеоускорителей. Причем сами результаты уже не сравнить с теми, что были на заре применения технологии в 2005 году на базе видеопроцессоров Xenos компании AMD для игровых консолей Xbox 360.

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

При работе в программах 3D-моделирования/анимации также иногда прибегают к "игровым" хитростям, уменьшая количество полигонов для удаленных объектов и наращивая - для близких. Такая модель поведения не нова и знакома многим, но ее трудно автоматизировать, особенно при расчетах анимации. Тесселяция бы не помешала.

Рэйтрейсинг/рейкастинг. Пакеты 3D-анимации vs игровые движки

А здесь мы посмотрим на ситуацию с обратной стороны, то есть от преимуществ профессиональных программ 3D-моделирования/анимации. Конечно, фильм "Аватар" выглядит технически безупречно, но на самом деле там присутствует мало моментов, которые активно используются в тех же 3D-мультфильмах от студии Pixar и подобной продукции, рассчитанной на профессиональных технологиях. Речь идет о сверхреалистичных отражениях либо прозрачных/полупрозрачных поверхностях, сглаженных мягких тенях и так далее.

Дело в том, что свет в играх должен рассчитываться в режиме реального времени, поэтому выбираются наименее затратные для мощностей ПК технологии. Для визуализации (наиболее часто применимой в игровых движках на сегодня) до сих пор остается растеризация, использующая Z-буфер. Смысл технологии состоит в том, что создается двумерный массив, каждый элемент которого соответствует пикселу на экране. При заполнении ячеек такого рода "таблицы" в каждый пиксел помещается фрагмент полигона того объекта, который расположен ближе к зрителю (выбор по Z-глубине). Сам метод имеет ряд недостатков, которые устраняются разработчиками по-разному. Например, для реализации отражений чаще всего используется карта окружения (environment map), которая на самом деле дает некую размытую эмуляцию отражения окружающего пространства, но при этом вы не можете, например, увидеть близкие объекты. Есть и более изощренные методы, такие как, например, dynamic cube maps. В его рамках производится специальный отдельный рендеринг, сохраняемый в динамических кубических картах - но это довольно громоздко по реализации, к тому же не очень эффективно по загрузке вычислительных мощностей.

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

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

И третий, довольно скользкий, момент растеризации - тени. Многие игроделы знакомы с понятием shadow mapping, а игроки - лишь с немногими примерами действительно хорошей реализации.

В пакетах 3D-моделирования/анимации, где нет потребности в режиме реального времени для визуализации, чаще всего используется более эффективная и реалистичная технология ray tracing. Она основана на том принципе, что все объекты сцены подразумевают реальные поверхности, но сами лучи рассчитываются по пути не от источника света к зрителю, а в обратном направлении (обратная трассировка луча). При первом проходе алгоритма производятся действия, схожие с Z-буфером. То есть создается "матрица" пикселов, которая заполняется информацией обо всех объектах в рамках видимого участка сцены. Затем "матрица пикселов" итерационно корректируется информацией, полученной в результате расчета вторичных лучей, к которым относятся освещение/тени, отражение и преломление.

Сам алгоритм можно назвать базовым, поскольку в профессиональных технологиях визуализации дополнительно используется множество ноу-хау для получения суперреалистичных результатов визуализации: трассировка путей (path tracing), распределённая трассировка лучей (distributed ray tracing), метод излучательности (radiosity) для диффузного отражения, фотонное отображение (photon mapping) для каустики и т.д.

На данный момент ведущие производители графических ускорителей говорят о том, что ближайшее будущее геймдева будет связано именно с внедрением визуализации ray tracing. Причем многие разработчики уже опробовали упрощенный вариант трассировки - ray casting (эти технологии подобны).

Подытожим

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

Кристофер,
itcs.3dn.ru