Идеологически чем-то похожи на CML и «боиды», при помощи которых уже двадцать лет моделируется поведение стай птиц, косяков рыб, облаков насекомых и т. д. [«КТ» уже писала об этой технике] Если вкратце, каждый член стаи подчиняется трем простым правилам: избегай столкновений; двигайся туда же, куда и все; придерживайся центра стаи. А поскольку область зрения считается весьма небольшой, то движение каждой птицы определяется движением лишь нескольких ближайших ее соседей. Группа итальянских ученых еще в 2004 году написала целиком работающую на GPU мощную систему для моделирования передвижений больших стай птиц (с облетом препятствий, включая динамические) и отрапортовала об отличных скоростных показателях детища. Если же вспомнить, что прямой потомок «боидов», система Massive, использовалась для расчета поведения многотысячных армад в кинотрилогии «Властелин Колец»… Ох, славные битвы грядут, камрады-ролевики!
О программировании систем частиц на современных графических процессорах я могу говорить часами. Хотя бы потому, что именно так называлась одна из моих курсовых работ. Более очевидного кандидата на вынос с CPU, наверное, не найти. Тысячи точек движутся по простым законам, минимально взаимодействуя друг с другом и окружающим миром — или не взаимодействуя вовсе. Выигрыш от того, что эти гигантские массивы данных не гоняются на каждом кадре из оперативной памяти на видеокарту, огромен. Если же приложение таково, что частицам требуется сортировка (такое бывает, например, при моделировании воды), то преимущество шейдерного подхода становится просто разгромным. Мой почти не оптимизированный код давал выигрыш в два-три раза, в Сети же встречаются отчеты о реализациях, дающих восьми— и даже десятикратный выигрыш.
Ну и конечно, на карточку уходит практически вся рутина: анимация (от колыхания травы до обратной кинематики моделей); выделение границ и силуэтных ребер; определение видимости (в том числе закрывание объектов друг другом); LOD-техника (выбор в реальном времени подходящей детализации модели для сокращения числа выводимых полигонов); вычисление пересечений геометрических примитивов (например, луча и объектов сцены, для определения точки попадания пули). GPU стали по-настоящему универсальны и, повторюсь, подходят практически для любых задач. Судя по всему, уже в ближайшие несколько лет можно ожидать серьезного повышения как качества картинки, так и реалистичности взаимодействия с игровым миром. И этому решительно невозможно не радоваться!
Автор: Алексей Калиниченко
Производители видеокарт и разработчики игр уже который год настойчиво обещают кинематографическое качество графики, но выполнить обещания никак не могут. Можно, конечно, «обвинить» киноиндустрию в том, что она не стоит на месте и, не снижая скорости, движется вперед. Но на руках киношников есть два козыря: они обладают куда большими вычислительными ресурсами и широко применяют материал, отснятый камерой. Игры же принципиально отличаются от кино интерактивностью: если один-единственный кадр для картины может просчитываться несколько минут и даже часов, то для игр это абсолютно недопустимо. В играх ситуация меняется в соответствии действиям пользователя, и просчитать все варианты заранее просто невозможно. А вот некоторый аналог композинга [Технология комбинированных съемок, основанная на совмещении и смешивании 2D-видеопоследовательностей; подробнее ] в свое время широко применялся для двухмерных игрушек, в которых большинство персонажей было сделано на основе спрайтов [Спрайтовая анимация основана на быстрой смене картинок, на которых тело персонажа находится в различных положениях. Больше всего это похоже на «мультик», нарисованный на уголках блокнота]. Но с широким распространением 3D-ускорителей эта технология стала неактуальной и почти не развивалась.
Однако сказать, что эти два «мира графики» не пересекаются, нельзя. В большинстве современных игр наличествуют предпросчитанные заставки, технология изготовления которых ничем не отличается от большого кино. А вот обратное проникновение до недавнего времени было только на стадии разработки 3D-моделей. Ведь 3D-редактор должен в реальном времени отображать постоянно изменяющуюся модель. Поэтому вполне логично, что тут используются технологии, подобные игровым. Правда, если мы вспомним, что OpenGL, одна из двух основных библиотек для разработки 3D-игр, была создана именно для применения в таких задачах, можно усомниться, кто у кого заимствовал технологии. Правда, в дальнейшем большинство нововведений в графике сначала появлялось в игровой индустрии и лишь потом перекочевывало в профессиональные программы, упрощая работу моделлеров и аниматоров и все больше приближая картинку, с которой работает человек, к тому, что увидит зритель.
Потом realtime-алгоритмы «проникли» в производство аниматиков — это небольшие видеоролики, которые обычно создаются до начала съемок и серьезной работой над cg[Computer graphics — компьютерная графика]. Они нужны для согласования того, как режиссер «видит» сцену, с тем, как оператор ее отснимет, и с тем, что и как в последствии предстоит сделать компьютерщикам. Согласитесь, намного проще работать, когда можно взглянуть на окончательный результат, хотя бы и в сильном приближении. Для подобных задач важнее не качество, а оперативность внесения изменений. Иногда их приходится вносить непосредственно на съемочной площадке, когда нет ни желания, ни возможности подождать полчасика, пока «машина думает». В аниматеках чаще всего нет ни теней, ни сложного света, и даже текстуры вполне могут отсутствовать. Современные видеокарты с легкостью справляются с такими задачами.
Теперь перейдем к самому интересному — к финальному рендерингу. И фильмы, и игры состоят из последовательности кадров, при этом в обоих случаях кадр — это проекция трехмерного пространства, каким-то образом заполненного треугольниками (полигонами), на плоскость экрана. Оба действа разбиты на некоторые отрезки, на которых действие происходит в одном и том же окружении. Только в игре этот отрезок называется уровнем, а в кино — планом. Принципиальная разница только в одном — куда будут помещены результаты: на экран или в файл для последующего перенесения на пленку. Получается, что для столь похожих задач используются принципиально разные аппаратные средства (GPU и CPU). Тут, конечно, можно увидеть игру букв GPU — Games, CPU — Cinematograph. Но причина отнюдь не в буквах — для решения этих задач применяются принципиально разные алгоритмы.
Описывать принцип действия GPU, думаю, смысла нет, а вот на технологиях «большого» рендеринга следует остановиться. В некотором роде они стремились как можно в большей степени подражать природе. При расчете освещения, например, часто используется технология, повторяющая естественный ход лучей, с многочисленными отражениями и преломлениями (метод фотонных карт). Для этого из источника света «испускается» большое количество фотонов, а на все объекты натягивается дополнительная текстура, в которой будет храниться информация об освещении. Если фотон попадает на поверхность какого-либо предмета, то он оставляет в его текстуре освещенности след и либо отражается, либо проходит сквозь предмет, преломляясь. После некоторого количества отражений или после того, как энергия фотона стала слишком мала, он умирает. Таким образом, при достаточном количестве фотонов мы получаем кроме основных текстур для объектов еще и текстуру освещенности, которую можно использовать при дальнейшем рендеринге.
Вычислительная сложность этого алгоритма очень высока, ведь надо проследить путь каждого фотона. Зато он прекрасно параллелится — движение всех частиц абсолютно независимо.
Решение подобной задачи для сложной сцены может занимать много времени, и вполне понятно желание как-то ускорить процесс. По аналогии с 3D-играми и для рейтрейсеров стали появляться акселераторы. Компания Advanced Rendering Technology производит PCI-карту аж с восемью узкоспециализированными процессорами на борту. Она предназначена для профессионального применения и на некоторых задачах позволяет получить ускорение более чем в десять раз.
Мощности современных GPU могут пригодиться не только «тридешникам». Как нельзя кстати они подойдут и для нелинейного монтажа в реальном времени. Рассмотрим самый простой пример — переход между двумя последовательными кадрами, осложненный анимацией. Представьте, допустим, эффект перелистывания страницы, при этом конец первой видеопоследовательности продолжает идти на одной странице, а на другой уже начинается вторая. Нет ничего проще: загружаем кадры на видеокарту, моделируем 3D-сцену с перелистывающимися страницами, устанавливаем камеру и, последовательно выводя на страницы соответствующие кадры, получаем желаемый эффект.
