Компьютерра - Журнал «Компьютерра» № 13 от 04 апреля 2006 года

Идеологически чем-то похожи на CML и «боиды», при помощи которых уже двадцать лет моделируется поведение стай птиц, косяков рыб, облаков насекомых и т. д. [ «КТ» уже писала об этой технике] Если вкратце, каждый член стаи подчиняется трем простым правилам: избегай столкновений; двигайся туда же, куда и все; придерживайся центра стаи. А поскольку область зрения считается весьма небольшой, то движение каждой птицы определяется движением лишь нескольких ближайших ее соседей. Группа итальянских ученых еще в 2004 году написала целиком работающую на GPU мощную систему для моделирования передвижений больших стай птиц (с облетом препятствий, включая динамические) и отрапортовала об отличных скоростных показателях детища. Если же вспомнить, что прямой потомок «боидов», система Massive, использовалась для расчета поведения многотысячных армад в кинотрилогии «Властелин Колец»… Ох, славные битвы грядут, камрады-ролевики!

О программировании систем частиц на современных графических процессорах я могу говорить часами. Хотя бы потому, что именно так называлась одна из моих курсовых работ. Более очевидного кандидата на вынос с CPU, наверное, не найти. Тысячи точек движутся по простым законам, минимально взаимодействуя друг с другом и окружающим миром — или не взаимодействуя вовсе. Выигрыш от того, что эти гигантские массивы данных не гоняются на каждом кадре из оперативной памяти на видеокарту, огромен. Если же приложение таково, что частицам требуется сортировка (такое бывает, например, при моделировании воды), то преимущество шейдерного подхода становится просто разгромным. Мой почти не оптимизированный код давал выигрыш в два-три раза, в Сети же встречаются отчеты о реализациях, дающих восьми— и даже десятикратный выигрыш.

Ну и конечно, на карточку уходит практически вся рутина: анимация (от колыхания травы до обратной кинематики моделей); выделение границ и силуэтных ребер; определение видимости (в том числе закрывание объектов друг другом); LOD-техника (выбор в реальном времени подходящей детализации модели для сокращения числа выводимых полигонов); вычисление пересечений геометрических примитивов (например, луча и объектов сцены, для определения точки попадания пули). GPU стали по-настоящему универсальны и, повторюсь, подходят практически для любых задач. Судя по всему, уже в ближайшие несколько лет можно ожидать серьезного повышения как качества картинки, так и реалистичности взаимодействия с игровым миром. И этому решительно невозможно не радоваться!

Автор: Алексей Калиниченко

Производители видеокарт и разработчики игр уже который год настойчиво обещают кинематографическое качество графики, но выполнить обещания никак не могут. Можно, конечно, «обвинить» киноиндустрию в том, что она не стоит на месте и, не снижая скорости, движется вперед. Но на руках киношников есть два козыря: они обладают куда большими вычислительными ресурсами и широко применяют материал, отснятый камерой. Игры же принципиально отличаются от кино интерактивностью: если один-единственный кадр для картины может просчитываться несколько минут и даже часов, то для игр это абсолютно недопустимо. В играх ситуация меняется в соответствии действиям пользователя, и просчитать все варианты заранее просто невозможно. А вот некоторый аналог композинга [Технология комбинированных съемок, основанная на совмещении и смешивании 2D-видеопоследовательностей; подробнее ] в свое время широко применялся для двухмерных игрушек, в которых большинство персонажей было сделано на основе спрайтов [Спрайтовая анимация основана на быстрой смене картинок, на которых тело персонажа находится в различных положениях. Больше всего это похоже на «мультик», нарисованный на уголках блокнота]. Но с широким распространением 3D-ускорителей эта технология стала неактуальной и почти не развивалась.

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

Потом realtime-алгоритмы «проникли» в производство аниматиков — это небольшие видеоролики, которые обычно создаются до начала съемок и серьезной работой над cg[Computer graphics — компьютерная графика]. Они нужны для согласования того, как режиссер «видит» сцену, с тем, как оператор ее отснимет, и с тем, что и как в последствии предстоит сделать компьютерщикам. Согласитесь, намного проще работать, когда можно взглянуть на окончательный результат, хотя бы и в сильном приближении. Для подобных задач важнее не качество, а оперативность внесения изменений. Иногда их приходится вносить непосредственно на съемочной площадке, когда нет ни желания, ни возможности подождать полчасика, пока «машина думает». В аниматеках чаще всего нет ни теней, ни сложного света, и даже текстуры вполне могут отсутствовать. Современные видеокарты с легкостью справляются с такими задачами.

Теперь перейдем к самому интересному — к финальному рендерингу. И фильмы, и игры состоят из последовательности кадров, при этом в обоих случаях кадр — это проекция трехмерного пространства, каким-то образом заполненного треугольниками (полигонами), на плоскость экрана. Оба действа разбиты на некоторые отрезки, на которых действие происходит в одном и том же окружении. Только в игре этот отрезок называется уровнем, а в кино — планом. Принципиальная разница только в одном — куда будут помещены результаты: на экран или в файл для последующего перенесения на пленку. Получается, что для столь похожих задач используются принципиально разные аппаратные средства (GPU и CPU). Тут, конечно, можно увидеть игру букв GPU — Games, CPU — Cinematograph. Но причина отнюдь не в буквах — для решения этих задач применяются принципиально разные алгоритмы.