Вступление
В данной статье анализируется традиционная технология отображения игровых миров, построенная на методе отрисовки треугольников с помощью z-буфера. Выявляются присущие ей ограничения и рассматривается альтернативная технология, основанная на методе обратной трассировки лучей.
Как пример нетрадиционной 3D технологии для компьютерных игр приводится оригинальный графический движок VirtualRay. Движок позволяет отображать потенциально бесконечные трёхмерные игровые вселенные, которые можно произвольно изменять в реальном времени.
Движок построен на методе обратной трассировки лучей, совершенно отличном от используемых в современных играх полигональных алгоритмов. Механизм рендеринга радикально отличается от реализованных в современных ускорителях игровой графики.
Данная статья является продолжением статьи "Пример реализации в реальном времени метода трассировки лучей: необычные возможности и принцип работы. Оптимизация под SSE", однако радикальное улучшение движка VirtualRay позволяет говорить более предметно. В предыдущей статье основное внимание уделялось различным аспектам оптимизации графических приложений под SSE, сейчас же речь пойдет о теории 3D.
Автор выражает надежду, что чтение данной статьи не вызовет затруднений у любого читателя iXBT.com, который прочитал первую часть.
Анализ традиционной технологии
Практически все современные трёхмерные игровые движки отображают сцену методом рисования текстурированных треугольников с применением z-буфера. Есть некоторый игровой мир, создаётся его представление с помощью треугольников. Сцена из треугольников заталкивается в акселератор, он её быстренько отрисовывает. Поскольку в сцене слишком много треугольников, если всю её рисовать, никакой акселератор не спасёт. Так что применяют различные методы оптимизации. Наиболее существенны следующие методы. Предварительное нахождение так называемых PVS (Potential Visibility Set) — предварительно просчитывают, из каких положений какие треугольники видны. Допустим, находится играющий в комнате. Все статические объекты, которые видны из окон и дверей, заранее определены, и только они и рисуются.
Далее, дополнительно производят предварительную сортировку треугольников, составляющих сцену. Строят так называемое BSP (Binary Space Partitioning) — дерево. С помощью информации, заложенной в нём, в процессе рисования уровня можно очень быстро осуществлять сортировку треугольников в зависимости от положения наблюдателя. Это позволяет существенно оптимизировать отрисовку полигонов. В то же время, построение же самого BSP-дерева — очень ресурсоёмкая задача.
И ещё один метод заключается в расстановке так называемых порталов. При создании уровня определяются двери, окна, проходы между помещениями, и это используется для отсечения невидимых объектов. Предметы, которые не находятся в том же помещении, что и играющий, проверяются перед отрисовкой на видимость через заранее найденные порталы.
Для оптимизации и повышения эффективности работы вышеописанных методов сцену разбивают на отдельные кластеры, выделяют отдельные модели и субмодели.
Высокополигональные компактные объекты заключаются в простые фигуры, вроде параллелепипедов или сфер. В первую очередь, это движущиеся модели, боты и т.п. Но не только. Стулья, которые можно разломать, ящики, которые можно подвигать, бочки, которые можно взорвать, — всё это отдельные модели.
Строится иерархическое дерево уровня. Выделяются отдельные кластеры, например, здание. В кластерах выделяются подкластеры, например, комнаты здания. В подкластерах так же выделяются подкластеры более низкого уровня, например, предметы, находящиеся в комнате. Видимость и другие свойства сначала определяют для всего кластера, если он полностью не виден, то не видны все объекты и подкластеры, содержащиеся в нём. Поскольку для кластера заранее просчитаны содержащие его простые фигуры, операции с которыми проводить существенно легче, чем с произвольной совокупностью треугольников, то достигается значительный выигрыш в скорости.
Построение иерархии сцены производится заранее, в основном, дизайнерами уровней, поскольку это алгоритмически очень сложная задача. Алгоритмы эффективной кластеризации большой сцены работают очень долго. И выполняться в реальном времени они будут весьма небыстро (разумеется, если речь идет не о суперкомпьютерах).
Но сцену нужно ещё правильно осветить, что бы она выглядела реалистично. Для этого опять-таки заранее для каждого объекта просчитывается его освещённость и записывается в специальную текстуру, которая называется lightmap. То есть, в основном освещение уровня современной компьютерной игры не более, чем заранее нарисованная картинка. Вообще, lightmap'ы мог и художник нарисовать. Взять в руки кисти, палитру и изобразить стены какой-нибудь комнаты. Сейчас просто есть автоматическое решение. Однако, применение таких методов имеет отдалённое отношение к настоящей трёхмерной компьютерной графике.
Всё это просто на корню уничтожает возможность существенно изменить уровень во время игры. Все эти предварительные просчёты сцены производятся очень долго, часто часами на самых мощных компьютерах. Иногда даже требуют участия дизайнера. Например, если слегка увеличить уровни для движка QuakeIII, то они будут обсчитываться десятки часов на мощных рабочих станциях.
Потом, нельзя не только изменить игровой уровень, но и построить в реальном времени новый. Далее, это не позволяет создавать действительно большие открытые уровни. Их неудобно просчитывать, хранить информацию и т.п.
Примеры традиционной технологии
Сколько уж лет назад выпустили первые ускорители, всё одно. Есть полностью статический игровой уровень, с практически полностью статическим освещением. Иногда можно лампочку разбить, тогда освещение изменится, потому что заранее известно, какие треугольники эта лампочка освещала. А новую включить нельзя. Тени иногда есть от небольшого количества динамических объектов, ботов всяких, в основном, полуправильные. Модели сами себя не затеняют.
Такие статические уровни объединяют в длинные цепочки. Получается как бы игровая вселенная. Только размерность её, по сути, 1. Такая перекрученная труба. Идти можно вперёд, назад, или немного вбок.
Рассмотрим свежие игры на движке третьего Quake. Я не буду останавливаться на моментах геймплея, в данном случае рассматривается трёхмерный движок. Идёшь тупо вперёд, глаза к центру. Всё заранее определено. Даже враги уже поставили посты и баррикады на пути. И это — не упущение геймдизайнеров, врагам просто негде развернуться.
А мультиплейер? Со времён не то, что QuakeII, QuakeI ничего принципиально нового не появилось. В смысле фич графического движка, влияющих на игру. Поэтому до сих пор некоторые играют в первый Quake.
Рассмотрим ещё один пример. На коробке написано, что эта игра: "… революционизирует следующее поколение гейминга новой технологией Geo-Mod, которая привносит возможность полностью менять или уничтожать окружение в реальном времени. … Единственный шутер с изменяемой в реальном времени геометрией. Несравнимый ни с чем multiplayer с особыми стратегиями, обусловленными Geo-Mod. " А в реальности, можно сказать, клон Half-Life. В графическом плане ничего нового.
Давно уже про новую трёхмерную игру можно сказать, что в ней будет больше треугольников. И всё.
Развитие традиционной технологии
Действительно, вычислительные мощности растут, может быть, со временем акселераторы станут достаточно мощными, чтобы вывести все треугольники, составляющие сцену, достаточно мощными, чтобы рассчитать в реальном времени освещение. Сейчас же есть тени от моделей ботов, потом, постепенно, будет и динамическое освещение сцены.
Сейчас в играх, за счёт предварительно анализа, рисуется относительно небольшой процент треугольников, составляющих уровень. Зачастую, несколько процентов.
Существует много алгоритмов расчёта теней, см. статью "Обзор алгоритмов построения теней в реальном времени". Они либо неявно требуют предварительную информацию об объекте, как метод теневых объёмов (иначе этот метод будет страшно долго работать на сложных объектах), либо требуют многократной отрисовки объекта (в текстуру) со стороны источника света и нещадно эксплуатируют видео-ускоритель, как методы наложения теней с помощью проективных текстур. Отмечу, что не просто в текстуру, а в текстуру очень большого разрешения. Иначе тень на удалённых объектах будет угловатой.
То есть, нужны мощности, в десятки раз превышающие мощности нынешних ускорителей.
Исходя из закона Мура об удвоении вычислительной мощности каждые два года, можно оценить, когда будет достигнута необходимая мощность. Видно, что это дело не ближайших лет.
Зададимся вопросом, что же планируется в ближайшем будущем производителями видео ускорителей? Какие новые фичи должны будут обогатить компьютерную графику?
Собственно, в основном, это не секретная информация. Планируется развитие пиксельных и вертексных шейдеров, тесселяция на треугольники кривых поверхностей. TruForm'ы и прочие RTPatch'и для начала. И различное полноэкранное сглаживание изображения.
Основное предназначение пиксельных шейдеров состоит в моделировании материала поверхности. В основном, поточечное освещение с наложением рельефа, всякие блики. Это добавляет реалистичности. С полноэкранным сглаживанием всё понятно, это улучшает визуальное качество. А аппаратная тесселяция позволит рисовать больше кривых поверхностей. То есть, акселератор будет разбивать заданную ему поверхность, какой-нибудь сплайн, на треугольники, и рисовать их обычным образом. Вертексные шейдеры призваны снизить нагрузку на центральный процессор.
В общем, уровни станут такими кривыми, текстуры рельефными, изображение гладким. Только всё останется по-прежнему в смысле практически полной статичности сцены. Опять можно будет ломать всякую мелочь и только. Светильники не будут качаться под потолками огромных залов, и солнечные лучи не будут проходить сквозь окна.
Истоки традиционной технологии
Современная игровая 3D графика начала развиваться примерно 10 лет назад. Ее истоком являются "Wolfentein3D'образные" и "Doom" образные игры. Можно сказать, что принципиально её развитие закончилось на игре QuakeI. Дальше пошло исключительно экстенсивное развитие, целиком основанное на эксплуатации мощностей 3D ускорителей. В алгоритмическом плане практически ничего нового. Программисты графических движков стали заниматься сизифовым, по сути, трудом — делом познания различных аспектов взаимодействия с новыми акселераторами. На первое место вышла оптимизация программ под железо. Однако появляются новые видео ускорители, и приходится адаптироваться заново. Например, сколько возились создатели Unreal: сначала написали под software, потом под glide, потом под Direct3D, нарушив, кстати, все заповеди программирования для акселераторов NVidia, потом сделали версию под расширения OpenGL.
Используемый ныне алгоритм отображения сцены, основанный на рисовании треугольников, хорош в первую очередь тем, что показывает более-менее приемлемые результаты даже на старых персональных компьютерах с процессорами типа 386. На которых и начиналась игровая 3D графика. Так получилось, что текстурирование треугольников с билинейной фильтрацией и прочие сопутствующие операции, кривые очень. То есть, плохо программируются. Нужно пользоваться специфическими неестественными приёмами. Собственно, этого и следовало ожидать в качестве расплаты за быстроту выполнения на маломощных процессорах. Потом эти кривые операции начали специально ускорять. По сути, акселераторы только и умеют, что рисовать текстурированные треугольники. В огромных количествах, гораздо быстрее, чем процессор. Потому что они специально спроектированы для этого. С другой стороны, например, так называемый Hardware T&L выполняется со сравнимой скоростью. Выигрыш производительности получается, в основном, за счёт лучшей работы с памятью.
Однако, пусть даже акселераторы на порядок увеличивают скорость отрисовки полигонов, всё равно принципиально это дело не меняет. Фундаментальный изъян в расчёте освещённости — затенённости, как плата за быстроту отображения статических сцен, всё равно остаётся.
3D Engine для игрового мира
Во многом современные жанры компьютерных игр ограничены в своём развитии возможностями графических движков. В идеале, графический движок с точки зрения геймплея должен удовлетворять следующим двум требованиям. Должна быть возможность произвольно изменять игровой мир, и не должно быть ограничений на размер игровой вселенной. Сейчас же всё развитие ушло в качество изображения. В итоге, современные 3D движки могут хорошо рисовать только арены для бесконечного deathmatch. Что интересно, мало стратегий в полном 3D, часто используется вид сверху или с полубоку, потому что вид от первого лица трудно реализовать.
RayTracing как альтернатива
Зададимся следующим вопросом: а каким методом предварительно рассчитывают освещённость для уровней современных компьютерных игр? Может, заставляют денно и нощно трудиться видеоускоритель? Да нет, используют методы по типу трассировки лучей. При рисовании всяких динамических сцен для видеопродукции также используют аналогичные методы. Это наводит на мысль, что для отображения динамических сцен с меняющимся освещением оптимально использование метода трассировки лучей. Действительно, при просмотре различных демо программ на тему рейтрейсинга, сразу бросаются в глаза динамические тени. Программы можно найти, например, на www.scene.org.
Однако скорость трассировки лучей оставляет желать много лучшего. Во многих рейтрейсерных демо программах для ускорения используются различные приёмы минимизации количества трассируемых лучей. Например, трассировать лучи не для каждой точки экрана, а через несколько, а для промежуточных точек получать цвет путём интерполяции. При этом, для повышения качества, чаще трассировать лучи около проекций на экран границ объектов, чтобы очертания не искажались. По сути, это просто снижение разрешения экрана.
Дело в том, что время работы алгоритма трассировки лучей содержит член, прямо пропорциональный количеству трассируемых лучей, то есть, прямо пропорциональный площади экрана. И этот член вносит самый значительный вклад. Даже определение пересечения луча с простейшими объектами вроде сфер, треугольников, цилиндров и конусов требует значительных вычислительных затрат. Эти затраты были очень велики для персональных компьютеров, что делало возможной трассировку лучей в реальном времени только в маленьких разрешениях, типа 320x240 и меньше. В разрешении 800x600 алгоритм бы работал в шесть раз дольше. Вместо 24 кадров стало бы 4.
Однако рано или поздно мощность процессоров станет достаточной, чтобы осуществлять трассировку достаточного количества лучей. Поскольку пока что мощность процессоров растёт быстрее разрешения мониторов.
Возникает соблазн построить графический движок на принципах рейтресинга, что бы проблема динамического изменения сцены, освещения и затенения была сразу решена. Действительно, такой движок сделает доступными новые возможности в трёхмерных компьютерных играх.
VirtualRay-3D движок, трассировщик лучей в реальном времени
Есть многочисленные демо программы, рисующие красивые сцены при помощи метода трассировки лучей. Я же решил создать полноценный графический движок, целиком работающий на принципах рейтрейсинга.
Главной целью является отображение полностью динамической сцены с полным её просчётом на каждом кадре. В том числе (и в первую очередь), с покадровым расчётом освещения всей сцены.
Ясное дело, выполнение такого жесткого требования должно потребовать уступок в чём-то другом.
Мне показалось правильным отказаться от стремления во что бы то ни стало нарисовать на компьютере копию реального мира. Тем более, что реальный мир и так вокруг нас, если отвернуть глаза от монитора.
Такой подход привёл к использованию в качестве базовых примитивов для представления объектов сферы. Они оптимальны с точки зрения метода трассировки лучей. Пусть всё будет состоять из сфер — сооружения, местность, монстры. Далее, по мере развития, можно включать сегменты сфер, те же треугольники.
В прошлой статье я уже рассказывал о движке VirtualRay. Теперь же появилась новая версия, радикально увеличивающая возможности его применения в играх. Итак, рассмотрим пример реализации в реальном времени метода трассировки лучей.
Для общего представления я приведу несколько скриншотов.
 Инопланетное сооружение и монстры  Пейзаж некоего мира  Инопланетные сооружения |
К сожалению, скриншоты не могут передать игру динамических теней. Минимальные системные требования — процессор с поддержкой MMX, примерно 64MB памяти, 32 битный цвет. Нет совместимости с Intel740. Рекомендуются новейшие процессоры с поддержкой SSE (Pentium4, AthlonXP).
Так как на больших мониторах низкие разрешения выглядят слишком зернисто, для повышения быстродействия вместо уменьшения разрешения рекомендуется несколько уменьшить площадь экрана.
В демо-версии есть возможность разрушать уровень в реальном времени и добавлять новые конструкции.
Итак, возможности движка.
Характеристики движка VirtualRay
- Отрисовка сцены, состоящей из нескольких тысяч сфер.
- Отсутствие предварительного просчёта сцены, возможность полного изменения сцены на каждом кадре.
- Отображение большой сферы, представляющей поверхность.
- Рендеринг в высоких разрешениях в 32 битном цвете.
- Поддержка нескольких глобальных цветных источников света типа "Солнце".
- Покадровый расчёт затенённости для всей сцены.
- Попиксельные тени.
- Ограниченное количество прозрачных сфер.
- Динамический коэффициент прозрачности.
- Билинейная фильтрация текстур.
Движок имеет высокоуровневый API, позволяющий клиентской стороне задать сцену — положение сфер, источников света, свойства объектов — и положение наблюдателя. Клиенту необходимо только определить сцену, сцена будет нарисована автоматически. Это совершенно не так, как в Direct3D и OpenGL, где нужно возиться с отрисовкой каждого треугольника. Запихнёшь треугольники в акселератор не в том порядке — производительность сразу упадёт.
Уникальные возможности. Отображение бесконечного изменяемого игрового мира
Построенный на основе рейтресинга движок VirtualRay предоставляет совершенно новые возможности для трёхмерных компьютерных игр с видом от первого лица. Как уже упоминалось, это, в первую очередь, возможность произвольно изменять всю сцену в реальном времени. Другая уникальная возможность стала доступной благодаря полному отсутствию предварительной обработки сцены. Она состоит в отображении потенциально бесконечных 3D вселенных. Задаётся поверхность планеты произвольного размера, с любым количеством шаров. Рисуются же только те шары, которые видны, которые не ушли за горизонт. В зависимости от мощности процессора можно устанавливать кривизну поверхности, то есть, дальность линии горизонта.
В текущей демо-версии показывается небольшой кусок 3D мира. Дело в том, что ещё не создан автоматический генератор рельефа местности и удобная база данных шаров, чтобы можно было быстро определять попадание в зону видимости сразу целых кусков поверхности. Однако, это совсем непринципиальная техническая проблема. Проблем с памятью тоже не должно быть, поскольку информация о сфере занимает совсем немного байт памяти, при необходимости можно загружать информацию о текущем секторе поверхности с диска.
Всё это делает движок VirtualRay идеальным графическим движком для широкого класса игр, вроде многопользовательских ролевых игр.
Производительность
Движок обеспечивает приемлемую для многих игр производительность на современных процессорах. На Pentium 4 и Athlon XP около 20 кадров секунду в разрешении 800x600x32. При этом, движок обладает очень ценным свойством стабильности FPS. То есть, минимальная частота кадров совсем ненамного ниже средней. Это связано с тем, что движок изначально оптимизировался с точки зрения увеличения именно минимального FPS. Средняя частота кадров может быть 25 при минимальной 20. Во многих играх при высоком среднем FPS минимальный FPS может быть в разы ниже среднего. Особенно, в самые важные моменты.
С другой стороны, алгоритмы трассировки лучей предоставляют огромное поле для оптимизации. За счёт улучшения алгоритма можно увеличить производительность на десятки процентов. Иногда применение более оптимального метода позволяет поднять скорость в разы. На самом деле, движок состоит из нескольких частей, как описано в предыдущей статье, и значительное улучшение реализации отдельной части оказывало небольшой эффект на общую производительность. Тем не менее, даже по сравнению с предыдущей версией, эффективность заметно возросла.
Развитие
Собственно, все эффекты придуманы. Весь вопрос в скорости работы. Высоко реалистичную компьютерную графику для мультфильмов и кино рассчитывают многими днями на мощных рабочих станциях, это совсем не реалтайм на персональных компьютерах. В каком же направлении может дальше развиваться движок VirtualRay, рассчитанный на трассировку лучей в реальном времени?
Алгоритмы трассировки лучей имеют свойство, которое заключается в том, что обработка материала поверхности не отнимает много времени, основной расход идёт на определение пересечения с объектами сцены. Можно легко делать такие эффекты, как bump-mapping, которые стали относительно доступными только на новых полигональных видеоускорителях. Сейчас запаса производительности практически нет, но он скоро появится в связи с ростом вычислительной мощности процессоров. И тогда можно будет существенно улучшить качество изображения. Планируется bump-mapping, трилинейная фильтрация текстур, блики, то есть, более сложная модель освещения. Собственно, bump-mapping уже почти реализован, только текстура рельефа не вращается.
 Планеты с рельефом. На самом деле серые луны абсолютно монотонного цвета |
Будет идти дальнейшая работа по улучшению качества отображения поверхности и увеличению количества шаров, что позволит рисовать сложный рельеф, холмы, овраги.
Сейчас есть только бесконечно удалённые источники света, типа солнца. Планируется реализация локальных источников света, что позволит радикально улучшить качество освещения. Можно будет моделировать светильники, вспышки, и т.п. И всё это с динамическими тенями. В демо-версии на космическую тему уже было нечто подобное, однако это требует оптимизации и повышения производительности.
Что бы радикально расширить возможности движка по моделированию объектов, необходимо добавить в качестве примитивов сферы с вырезами. То есть, части сферы, отсечённые другими сферами. Тогда можно будет моделировать практически любые объекты. Легко получить криволинейные трёх или четырёх угольники. Причём, часто несколько полусфер лучше представляют объект, чем сотни треугольников. Однако, для отрисовки в высоких разрешениях потребуются существенно более мощные процессоры.
Некоторые объекты и эффекты, спрайты, частицы и т.п. можно отображать при помощи обычных видео ускорителей.
Метод трассировки лучей вообще хорошо сочетается с мультипроцессорными системами, и движок VirtualRay не имеет оснований быть исключением. Сейчас многопроцессорные системы не очень распространены среди персональных компьютеров, но версия, рассчитанная для работы с несколькими процессорами, планируется к разработке. Тем более, что это несложно и не потребует значительных изменений в программе. Ожидается почти двухкратный выигрыш в скорости. Причём, такая система стоит меньше, чем навороченный акселератор, но обладает уникальными возможностями по производительности.
Заключение
В заключение можно сказать, что, так или иначе, прогресс игровой компьютерной графики не собирается останавливаться. Однако он не должен базироваться исключительно на росте вычислительных мощностей, должно идти совершенствование алгоритмов. Иначе можно оказаться в тупике, из которого не так просто будет выбраться.
Будем надеяться, что благодаря новым достижениям можно будет создавать невиданные ранее игры с необыкновенными возможностями. Графические движки не будут ограничивать геймплей, но только радовать глаз показом красивых сцен.
