Журнал «Компьютерра» № 13 от 04 апреля 2006 года
Шрифт:
Другим довольно редким на экранах наших мониторов гостем является имитация одежды. Обратите внимание: плащи к персонажам игр насмерть прибиты гвоздями, в шляпы вделан титановый каркас, а все складки накрахмалены и для надежности пропитаны клеем-"момент". Но надежда есть: в последнее время стали появляться алгоритмы, позволяющие сравнительно недорогими средствами моделировать поведение ткани в интерактивном режиме. В простейшем случае поступают так: участок ткани представляют как решетку узлов, каждый из которых образует упругие связи с четырьмя соседями. Затем на каждом кадре последовательно: а) применяют действие гравитации, то есть сдвигают все узлы вниз в соответствии со временем, прошедшим с предыдущего кадра; б) проверяют, что расстояние между соседними узлами не стало слишком большим, в противном случае корректируют координаты узлов; в) следят за тем, чтобы узлы не проходили сквозь препятствия и, опять-таки, подправляют их положение в случае необходимости.
Еще одна весьма многообещающая техника – так называемые Coupled Map Lattices (CML). Многие из вас, наверное, слышали про математическую игру «Жизнь». Напомню правила. Место действия – двухмерный массив клеток, противоположные края которого во избежание граничных эффектов отождествлены: получается этакий дискретный тор. Каждая клетка может находиться в двух состояниях: она либо жива, либо мертва. У клетки, очевидно, восемь соседей. Задается распределение живых клеток в начале игры. Это «первое поколение». Каждое следующее поколение рассчитывается по таким правилам: 1) если у мертвой клетки ровно три живых соседа, она оживает; 2) если у живой клетки два или три живых соседа, она продолжает жить; 3) если же живых соседей меньше двух или больше трех, то клетка умирает (от одиночества и от перенаселенности соответственно). Задавая различные первые поколения, можно получать разнообразнейшие картины развития популяции. Так вот, если в игре «Жизнь» разрешить клеткам принимать не два состояния, а больше, и соответственно усложнить свод правил, по которым клетки переходят из одного состояния в другое, то как раз и получится CML. Оказывается, при помощи этих систем очень удобно моделировать целый ряд природных явлений, в частности кипение жидкостей, рост барханов и формирование облаков. Более того, эта техника как будто специально придумана, чтобы ее реализовали на графическом процессоре: N+1-е поколение (текстура) получается из N-го поколения (текстуры) применением одного и того же свода правил (пиксельного шейдера) к каждой клетке поля (пиксела текстуры). Замечу, что я писал такую программу для центрального процессора, и нормального быстродействия удавалось добиться лишь для сеток весьма скромных размеров. Здесь же все просто летает.
Идеологически чем-то похожи на CML и «боиды», при помощи которых уже двадцать лет моделируется поведение стай птиц, косяков рыб, облаков насекомых и т. д. [«КТ» уже писала об этой технике] Если вкратце, каждый член стаи подчиняется трем простым правилам: избегай столкновений; двигайся туда же, куда и все; придерживайся центра стаи. А поскольку область зрения считается весьма небольшой, то движение каждой птицы определяется движением лишь нескольких ближайших ее соседей. Группа итальянских ученых еще в 2004 году написала целиком работающую на GPU мощную систему для моделирования передвижений больших стай птиц (с облетом препятствий, включая динамические) и отрапортовала об отличных скоростных показателях детища. Если же вспомнить, что прямой потомок «боидов», система Massive, использовалась для расчета поведения многотысячных армад в кинотрилогии «Властелин Колец»… Ох, славные битвы грядут, камрады-ролевики!
О программировании систем частиц на современных графических процессорах я могу говорить часами. Хотя бы потому, что именно так называлась одна из моих курсовых работ. Более очевидного кандидата на вынос с CPU, наверное, не найти. Тысячи точек движутся по простым законам, минимально взаимодействуя друг с другом и окружающим миром – или не взаимодействуя вовсе. Выигрыш от того, что эти гигантские массивы данных не гоняются на каждом кадре из оперативной памяти на видеокарту, огромен. Если же приложение таково, что частицам требуется сортировка (такое бывает, например, при моделировании воды), то преимущество шейдерного подхода становится просто разгромным. Мой почти не оптимизированный код давал выигрыш в два-три раза, в Сети же встречаются отчеты о реализациях, дающих восьми– и даже десятикратный выигрыш.
Ну и конечно, на карточку уходит практически вся рутина: анимация (от колыхания травы до обратной кинематики моделей); выделение границ и силуэтных ребер; определение видимости (в том числе закрывание объектов друг другом); LOD-техника (выбор в реальном времени подходящей детализации модели для сокращения числа выводимых полигонов); вычисление пересечений геометрических примитивов (например, луча и объектов сцены, для определения точки попадания пули). GPU стали по-настоящему универсальны и, повторюсь, подходят практически для любых задач. Судя по всему, уже в ближайшие несколько лет можно ожидать серьезного повышения как качества картинки, так и реалистичности взаимодействия с игровым миром. И этому решительно невозможно не радоваться!
ТЕМА
Автор: Алексей Калиниченко
Производители видеокарт и разработчики игр уже который год настойчиво обещают кинематографическое качество графики, но выполнить обещания никак не могут. Можно, конечно, «обвинить» киноиндустрию в том, что она не стоит на месте и, не снижая скорости, движется вперед. Но на руках киношников есть два козыря: они обладают куда большими вычислительными ресурсами и широко применяют материал, отснятый камерой. Игры же принципиально отличаются от кино интерактивностью: если один-единственный кадр для картины может просчитываться несколько минут и даже часов, то для игр это абсолютно недопустимо. В играх ситуация меняется в соответствии действиям пользователя, и просчитать все варианты заранее просто невозможно. А вот некоторый аналог композинга [Технология комбинированных съемок, основанная на совмещении и смешивании 2D-видеопоследовательностей; подробнее ] в свое время широко применялся для двухмерных игрушек, в которых большинство персонажей было сделано на основе спрайтов [Спрайтовая анимация основана на быстрой смене картинок, на которых тело персонажа находится в различных положениях. Больше всего это похоже на «мультик», нарисованный на уголках блокнота]. Но с широким распространением 3D-ускорителей эта технология стала неактуальной и почти не развивалась.
Однако сказать, что эти два «мира графики» не пересекаются, нельзя. В большинстве современных игр наличествуют предпросчитанные заставки, технология изготовления которых ничем не отличается от большого кино. А вот обратное проникновение до недавнего времени было только на стадии разработки 3D-моделей. Ведь 3D-редактор должен в реальном времени отображать постоянно изменяющуюся модель. Поэтому вполне логично, что тут используются технологии, подобные игровым. Правда, если мы вспомним, что OpenGL, одна из двух основных библиотек для разработки 3D-игр, была создана именно для применения в таких задачах, можно усомниться, кто у кого заимствовал технологии. Правда, в дальнейшем большинство нововведений в графике сначала появлялось в игровой индустрии и лишь потом перекочевывало в профессиональные программы, упрощая работу моделлеров и аниматоров и все больше приближая картинку, с которой работает человек, к тому, что увидит зритель.
Потом realtime-алгоритмы «проникли» в производство аниматиков – это небольшие видеоролики, которые обычно создаются до начала съемок и серьезной работой над cg[Computer graphics – компьютерная графика]. Они нужны для согласования того, как режиссер «видит» сцену, с тем, как оператор ее отснимет, и с тем, что и как в последствии предстоит сделать компьютерщикам. Согласитесь, намного проще работать, когда можно взглянуть на окончательный результат, хотя бы и в сильном приближении. Для подобных задач важнее не качество, а оперативность внесения изменений. Иногда их приходится вносить непосредственно на съемочной площадке, когда нет ни желания, ни возможности подождать полчасика, пока «машина думает». В аниматеках чаще всего нет ни теней, ни сложного света, и даже текстуры вполне могут отсутствовать. Современные видеокарты с легкостью справляются с такими задачами.
Теперь перейдем к самому интересному – к финальному рендерингу. И фильмы, и игры состоят из последовательности кадров, при этом в обоих случаях кадр – это проекция трехмерного пространства, каким-то образом заполненного треугольниками (полигонами), на плоскость экрана. Оба действа разбиты на некоторые отрезки, на которых действие происходит в одном и том же окружении. Только в игре этот отрезок называется уровнем, а в кино – планом. Принципиальная разница только в одном – куда будут помещены результаты: на экран или в файл для последующего перенесения на пленку. Получается, что для столь похожих задач используются принципиально разные аппаратные средства (GPU и CPU). Тут, конечно, можно увидеть игру букв GPU – Games, CPU – Cinematograph. Но причина отнюдь не в буквах – для решения этих задач применяются принципиально разные алгоритмы.
Описывать принцип действия GPU, думаю, смысла нет, а вот на технологиях «большого» рендеринга следует остановиться. В некотором роде они стремились как можно в большей степени подражать природе. При расчете освещения, например, часто используется технология, повторяющая естественный ход лучей, с многочисленными отражениями и преломлениями (метод фотонных карт). Для этого из источника света «испускается» большое количество фотонов, а на все объекты натягивается дополнительная текстура, в которой будет храниться информация об освещении. Если фотон попадает на поверхность какого-либо предмета, то он оставляет в его текстуре освещенности след и либо отражается, либо проходит сквозь предмет, преломляясь. После некоторого количества отражений или после того, как энергия фотона стала слишком мала, он умирает. Таким образом, при достаточном количестве фотонов мы получаем кроме основных текстур для объектов еще и текстуру освещенности, которую можно использовать при дальнейшем рендеринге.