Цифровой журнал «Компьютерра» № 80

Цифровые актёры: что мешает «нечеловеческим» звёздам Юрий Ильин

Опубликовано 01 августа 2011 года

Сегодня, пожалуй, уже никого невозможно удивить цифровыми персонажами в кинематографе. Маховик, закрутившийся ещё в середине восьмидесятых, раскручивается всё быстрее, и если когда-то выпрыгивавший из витража стеклянный рыцарь (речь идёт о фильме «Молодой Шерлок Холмс» 1985 года) или CG-спецэффекты в «Газонокосильщике» чьё-либо воображение и могли зацепить, то сегодня на игровых консолях доступна в сто крат более качественная, реалистичная и эстетически привлекательная графика.

Цифровые персонажи сегодня в кино повсюду; они уже не просто фотореалистичны, но ещё и жизнеподобны, обладают чётко выраженными характерами живых существ и будто бы даже способны, как подобает настоящим актёрам, взаимодействовать на равных со своими партнёрами... Достаточно вспомнить Аслана из «Хроник Нарнии» (любого из трёх вышедших к настоящему моменту фильмов), который предстаёт зрителю не просто говорящим львом, но именно тем, кем и чем он является у Клайва Льюиса. Нелишним будет вспомнить также «Миссию Дарвин», само собой разумеется — «Аватар» и другие произведения кинопрома последних лет, где фигурируют CG-персонажи.

Однако лишь в единичных — и, как правило, очень громких — случаях создатели фильма имеют дерзость пытаться создать CG-человека. Можно ли говорить о том, что На'ви из «Аватара» — абсолютно жизнеподобны? Едва ли: их компьютерная природа на стоп-кадрах видна со всей очевидностью, насколько бы глубоко проработанными и технично исполненными они ни были.

"Удивительный случай с Бенджамином Баттоном", а позднее и «ТРОН: Наследие» показали, что в принципе «CG-актёры» вполне реализуемы. С помощью motion capture на цифровую голову старика «нацепили» всё богатство мимики Брэда Питта (так же, как «поддельных» На'Ви оснастили мимикой соответствующих актёров-людей), а персонажа Джеффа Бриджеса с помощью CG «омолодили» на 30 лет, сохранив, однако, характерные особенности его мимики.

И тем не менее даже специалисты временами признают: результаты далеко не идеальны, временами «компьютерность» чувствуется, а зритель нынче трепетный, всё повидавший, предвзятый и привередливый, его на мякине не проведёшь. Его и удивить-то уже чем-либо трудно. А вот спугнуть и вызвать у него отторжение — проще некуда.

Около двух месяцев назад Джордж Лукас заявил, что у него на будущее отложен сценарий телевизионного сериала по «Звёздным войнам» продолжительностью в полсотни серий; но он не может запустить его в производство, поскольку для этого нужен определённый технологический прорыв, ибо пока нужные ему технологии обходятся слишком дорого.

Возникает вопрос: что это за технология, которая оказывается настолько дорогущей, что и сам Лукас подвергается нападению жабы-душителя? Рискнём предположить, что речь идёт о полностью «цифровых» актёрах. Почему бы снова не притащить в кадр молодых Харрисона Форда, Марка Хэммилла и Кэрри Фишер, а то даже и омолодить их ещё больше? Почему бы не попытаться воссоздать ту атмосферу, которая была в «Эпизодах IV-VI», не заморачиваясь при этом выездами в пустыню или куда-нибудь за полярный круг, чтобы изобразить планеты Татуин и Хот, не вернуть на командный мостик «Звезды Смерти» зловещего Вилхуффа Таркина, даром что игравший его Питер Кушинг давно скончался, как скончался и первый исполнитель роли Оби Вана Кеноби — сэр Алек Гиннесс?

Осуществить это всё вполне реально. Вопрос в звонкой монете: у телевидения в принципе другая экономика. Если колоссальные бюджеты блокбастеров в кино в случае их успешного проката отбиваются за счёт кинозрителей, то телесериал так окупить не получится по определению. Вдобавок необходимо иметь в виду и хронометраж: скажем, бюджет того же самого «Бенджамина Баттона» составил 150 млн долларов, продолжительность — 166 минут, и «цифровой старик» в кадре пребывает даже не половину фильма.

Представить себе такие бюджеты для телесериала невозможно по определению. Сериал «Капитан Пауэр и солдаты будущего», снимавшийся в середине 1980-х, был закрыт после 22 серий по причине дороговизны (в среднем бюджет составлял по миллиону долларов на серию), а также в силу того, что его создатели не смогли сориентироваться с целевой аудиторией. В этом сериале цифровых тварей было всего две, зато они фигурировали почти в каждой серии. По нынешним временам Зоран и Бластаар выглядят совершенно примитивными, но тогда это были CG-шедевры.

Что же касается «Вавилона 5», то там полностью цифровые персонажи как раз таки довольно редкие гости. Во всяком случае в соотношении с общим метражом сцен с их участием не так много.

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

Что нужно, чтобы цифровой персонаж выглядел неотличимо от человека, если уж речь пошла об этом? Во-первых, его лицо не должно вызывать никаких подозрений в неестественности своей природы. Наш мозг к этому очень чуток — и до параноидального подозрителен. Понятие «зловещая долина» (uncanny valley) не просто так появилось: всякое «неполное человекоподобие» вызывает у нас совершенно инстинктивное отторжение и даже страх.

Речь совершенно необязательно идёт о человекоподобных фотореалистичных CG-образах: люди с сильными «косметическими изъянами» могут вызывать ровно такое же отторжение: представим себе жертву автокатастрофы, которой по сути пришлось пересаживать лицо заново. Повреждения были тяжёлыми, но врач был искусный, и операция прошла практически полностью успешно, но остаётся какой-то изъян, какая-то «ненатуральность» и... и не сразу поймёшь, что что-то с лицом не так, а организм уже «паникует».

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

Актёров специально обучают двигаться так, чтобы «мелкой моторики» оставался минимум: движения должны быть уверенными и чёткими, но при этом естественными, свободными.

Полное отсутствие мелкой моторики, однако, для человека невозможно, как невозможно и абсолютная бездвижность — в принципе. В живом человеке постоянно присутствует какое-то движение, пусть мы его и сами не замечаем. Зато его «ловят» инстинкты и подсознание. Так же, как ловят «нормальность» человеческих движений: если они оказываются слишком плавными или наоборот слишком резкими и угловатыми, мозг преисполняется подозрительности. Если они слишком регулярны, наш встроенный биологический индикатор «свой-чужой» тоже вспыхивает красной лампочкой.

Вот, например, японский робот Repliee Q2.

То, что это робот, видно моментально: слишком неизменная осанка (как аршин проглотила), «кукольные» движения головы, но самое главное — это руки.

В принципе, руки — это всегда главный вызов для художников любого рода. Иногда от самих художников можно услышать, что по тому, как нарисованы руки, судят об уровне мастерства. Это справедливо и для CG-области (и для робототехники). То, как вышепоказанный робот держит правую руку, моментально вызывает ассоциации с протезом, тем более что и расслабленная кисть выглядит совсем не так.

Потому, собственно, и применяется сегодня так активно motion capture, что с его помощью проще и дешевле добиться максимального «человекообразия» в движении тела — туловища, рук и ног.

Лица, впрочем, тоже: лицевой motion capture входит всё больше в джентльменский набор специалистов по визуальным эффектам. С его помощью снимались уже неоднократно упоминавшиеся «Аватар», «Бенджамин Баттон», «ТРОН», а сейчас он находит применение уже и в компьютерных играх — там мимика персонажей постепенно приобретает такое же значение, как и синхронизация губ, но это отдельная тема.

Что же касается лиц и uncanny valley, то для начала придётся констатировать весьма банальную истину: человеческое лицо имеет исключительно сложное устройство, и изобразить его в полнейшем жизнеподобии крайне сложно.

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

Кстати, сейчас, если требуется изобразить мертвеца на экране, то лица актёров, лежащих без движения, дополнительно «обездвиживают» с помощью компьютерной графики.

С конца 1970-х психологи и аниматоры пользуются системой кодирования лицевых движений — СКЛиД. Руководство по использованию системы занимает пятьсот страниц — неплохо, не правда ли?

Вероятнее всего, лет через пять и мощности для рендеринга, и разработки в области ПО сделают процесс создания полностью цифровых персонажей — или полных копий ныне живущих и покинувших нас актёров — достаточно «штатным» процессом, чтобы не сказать рутинным. В конечном счёте что нужно сделать, чтобы воскресить на экране ту же Мэрилин Монро, например? Безупречная 3D-модель и библиотеки пластики и мимики почившей кинолегенды. Создание их — вопрос времени и денег. А технология есть: средств видеоанализа на рынке достаточно, есть и такие, которые предназначены для того, чтобы точно воспроизводить в 3D-среде движения объекта, уже отснятого на видео (или на киноплёнку).

Ну а на крайний случай профессиональные мимы (или, лучше сказать, motion capture artists) могут с высочайшей точностью воспроизводить любые движения и копировать чью угодно пластику.

Но для того, чтобы создать цифрового актёра «с нуля», нужно создавать для него собственную библиотеку движений, собственную библиотеку мимики — это помимо, как уже сказано, безупречно проработанной модели. Для того чтобы действительно реализовать концепцию «цифрового актёра» и сделать её доступной не только для Голливуда с его мегабюджетами, но и для телевидения, весь процесс его создания — а точнее «оживления» его мимики и пластики — должен быть, во-первых, максимально автоматизирован; во-вторых, нужны нового уровня вычислительные мощности, чтобы перемалывать весь колоссальный массив необходимых вычислений. А их будет действительно много, поскольку в данном случае любая экономия на них приводит... прямиком в зловещую долину.

К оглавлению

Система PASS: софт для шаттла Евгений Лебеденко, Mobi.ru

Опубликовано 02 августа 2011 года

Если отладка — процесс удаления ошибок, то программирование должно быть процессом их внесения.

Э. Дейкстра

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

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

Именно так рассуждало руководство NASA, принимая решение о разработке компьютерной системы для проекта Space Transportation System, или, проще, Space Shuttle. И если с её аппаратной частью инженеры разобрались, создав дружную «пятёрку» компьютеров GPC, то с программами для них пришлось основательно повозиться. И не только затем, чтобы выловить все ошибки, но и для того, чтобы преодолеть стереотипы системных программистов, считающих, что они в точности знают, как правильно создавать софт для космического челнока.

Многочисленные успешные миссии Space Shuttle на практике доказали правильность выбранного в NASA подхода для создания одной из самых сложных программных систем авионики — PASS (Primary Avionic Software System).

Приступая к проектированию программной системы Space Shuttle, руководство NASA имело возможность постоять на распутье, выбирая между уже имеющимися наработками, доказавшими свою состоятельность в пилотируемых полётах проекта Apollo, или разработкой с чистого листа.

Программированием компьютеров AGC (Apollo Guidance Computer) для лунных путешествий занималась лаборатория Дрепера, расположенная в Кембридже и относящаяся к Массачусетскому Технологическому Институту. Программная система компьютеров AGC разрабатывалась с использованием языка ассемблера. И эффективность этого подхода у специалистов не вызывала сомнений. С помощью ассемблерного кода можно виртуозно управлять вычислительным процессом, наиболее эффективно используя каждый байт памяти. Но у такой оптимизации имеется и обратная сторона: процесс разработки лабораторией Дрепера ассемблерных программ для проекта Apollo ни разу не уложился в отведённые сроки. А в случае обнаружения в уже разработанной программе ошибок её переработка превращалась в длительный процесс совместной работы инженеров NASA и программистов Дрепера, полный взаимных упрёков и препирательств.

И это при том, что миссии Apollo были сугубо специализированными. Проект же Space Shuttle предполагал создание многоцелевого космического аппарата, гибко подстраивающегося под текущие потребности NASA. Перепрограммирование компьютерной системы шаттла для каждой новой миссии должно быть быстрым, и язык ассемблера для такого случая был совершенно не пригоден. Именно поэтому руководитель отдела программирования NASA Ричард Партен принял решение использовать язык высокого уровня. Этим он навлёк на себя «праведный» гнев ортодоксальных системных программистов, искренне считающих, что никакая программа на высокоуровневом языке по скорости исполнения не сравнится с ассемблерным кодом. В пример приводились многочисленные соревнования ассемблера и популярного тогда языка FORTRAN, в которых последний выглядел явным аутсайдером.

Но Партен и не предлагал использовать FORTRAN. Его выбор пал на разработку выходцев из лаборатории Дрепера, в 1969 году основавших компанию Intermetrics Inc. Созданный ими язык высокого уровня назывался HAL/S и, благодаря поддержке векторной арифметики и возможности планирования программистом уровней приоритета модулей программы, идеально подходил для создания кода компьютеров GPC космического челнока.

По просьбе NASA специалисты Intermetrics включили в синтаксис HAL/S специальные операторы, делающие возможной разработку программ реального времени. Оператор SCHEDULE позволял точно определить частоту смены процессов в многозадачном режиме работы системы, операторы TERMINATE/CANCEL — антагонисты SCHEDULE занимались приостановкой и принудительным завершением процессов, а оператор WAIT обеспечивал их приостановку в случаях, когда операции ввода/вывода неоправданно затягивались.

Чтобы доказать правильность своего выбора, Партен решил организовать соревнования. Тестовая задача, выданная NASA лаборатории Дрепера и компании Intermetrics, должна была быть выполнена в строго отведённый срок и показать высокую производительность. Вот тут-то HAL/S и показал себя во всей красе. Решение на нём было готово задолго до отведённого «времени Ч», и при этом его производительность была всего на десять процентов ниже ассемблерного решения (которое, как обычно, было разработано с опозданием). Чуть позже, рассказывая о выборе HAL/S, Партен сказал: «Если бы мы тогда начали использовать ассемблер, то до сих пор бы торчали на Земле». Красноречиво, ничего не скажешь.

Вот так компьютеры шаттлов заговорили на HAL/S. Кстати, его название ничего общего с известным компьютером-психопатом из кларковско-кубриковской «Космической одиссеи 2001 года» не имеет. Эта аббревиатура означает всего-навсего Higher Avionic Language. Ну а литера "S" говорит о том, где язык применялся (Shuttle).

К середине 1973 года, выбрав язык разработки, в NASA определились с контрактами на создание PASS. Поскольку основной контракт на производство челноков был у компании Rockwell Corporation, последняя, естественно, посчитала, что будет создавать шаттлы, включая и программное обеспечение для них, единолично. Тем более что опыт разработки систем авионики для реактивных самолётов у Rockwell был немалый.

Но не тут-то было. Контракт на создание челночного софта NASA разделила между Rockwell и... IBM. Определённый резон в этом был: несмотря на то что, по предварительным оценкам, объём программного обеспечения для шаттлов был значительно меньше, чем для проекта Apollo, разнообразие программ и высочайшие требования к отказоустойчивости системы были таковы, что одной, пусть и опытной компании, справиться с задачей было не под силу. IBM предоставляла для проекта свои компьютеры AP-101, и уровень квалификации её программистов был нисколько не хуже уровня сотрудников Rockwell. Ещё одним немаловажным фактором, определившим выбор в пользу Голубого гиганта, была территориальная близость штаб-квартиры IBM и космического центра имени Джонсона. NASA, намучившись с проектом Apollo, программисты которого располагались в далёком Кембридже, посчитала, что разработчиков лучше иметь под боком.

Итак, 10 марта 1973 года космическое агентство заключило контракт с компанией IBM, которая выступала в качестве головного подрядчика программной системы PASS. Поскольку программисты IBM не сильно смыслили в авионике, им в помощь придавались ударные силы разработчиков Rockwell. Ну и в качестве консультирующией стороны, имеющей опыт разработки космического софта, привлекалась лаборатория Дрепера.

Участие в проекте множества рабочих групп легко могло привести к хаосу и бесконечным, бессмысленным сражениям и «перетягиванию одеяла». Поэтому в NASA чётко разграничили полномочия участников проекта, определив, какие типы документов делает каждый из них. Было предложено использовать три уровня документов, обозначавшихся соответственно "А", "В" и "С". Документы уровня "А" разрабатывались программистами IBM и содержали описание общей структуры системы PASS и функции её базовых модулей. Уровень "В" тоже создавался айбиэмовцами, но при поддержке специалистов из Intermetrics. В этих документах структура и функции модулей детализировались вплоть до конкретных параметров и используемых структур языка HAL/S. За уровень "С" отвечали разработчики Rockwell. Используя свой опыт проектирования систем авионики, они предлагали конкретную реализацию той или иной подпрограммы. Зачастую излишне конкретную. Как сказал один из участников проекта, видимо, из-за срыва единоличного контракта ребята из Rockwell давали бумаги, описывающие не «что делать», а «как делать».

Такое разделение полномочий в реализации сложного проекта позволило поддерживать заданные сроки реализации и концептуальную целостность системы PASS. Чуть позже подобный подход станет широко применяться в CASE-системах. Впрочем, этот подход не спас проект от перерасхода бюджета. Вместо запланированных изначально двадцати миллионов долларов проектирование PASS «скушало» ровно в десять раз больше.

Что же собой представляет PASS? Как и в случае любой другой программной среды, PASS включает в себя системные и прикладные компоненты.

К системным относятся: операционная система FCOS (Flight Computer Operational System) и интерфейс пользователя, позволяющий астронавтам взаимодействовать с PASS. Пользовательские же программы весьма разнообразны и могут меняться от миссии к миссии. Среди них есть и «долгоиграющие» варианты, например софт для ориентации, навигации и управления кораблём в полёте (GN&C — Guidance, Navigation, Control) и для управления и проверки таких систем корабля, как шасси, двигатели, грузовой отсек и роботизированный манипулятор (SM — System Management и VCO — Vehicle CheckOut). К прикладным программам относился и софт, специфичный для каждого этапа миссии.

Сердцем всей системы, естественно, является FCOS. Приступая к её проектированию, в NASA вели длительные споры об архитектуре ядра этой системы. Компания Rockwell настаивала на архитектуре с разделением времени, где для каждого процесса выделяется квант времени длительностью сорок миллисекунд. IBM совместно с Intermetrics предлагала систему реального времени, в которой прерывание работы процессов выполнялось по приоритетам. Резон был и том и в другом предложении. В результате FCOS получилась гибридной. Основной цикл работы её диспетчера составляет 960 миллисекунд. В рамках этого «медленного» цикла выполняется множество высокочастотных циклов длительностью в 40 миллисекунд каждый. В том случае, если при выполнении программы появляется процесс с более высоким приоритетом, программа немедленно прерывается с сохранением своего слова состояния (PSW — Program Status Word). Программы, ожидающие завершения операций ввода-вывода, помещаются в очередь низкоприоритетных с постепенным повышением приоритета. Такой подход позволил реализовать в FCOS режим выполнения задач, близкий к реальному времени. Стоит напомнить, что за окном был 1975 год и многозадачность с разделением времени только набирала обороты.

FTOS была полностью разработана на ассемблере и занимала всего 35 килобайт ферритовой памяти AP-101, резидентно находясь в ней на протяжении всей миссии. Программы GN&C, SM и VCO создавались на HAL/S и составляли так называемую базу главных функций (MFB — Major Function Base).

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

Эти модули получили название «Последовательность операций» (OPS — Operational Sequence), и хранились они на ленточном устройстве внешней памяти (MMU — Mass Memory Unit). Каждый OPS отвечал за конкретный этап миссии, например за старт корабля, его работу на орбите или посадку. Структурно OPS состоял из базовых (Major Mode), специальных (Spec) функций и функции визуализации (Disp). Функции Spec содержали уникальные для каждой миссии параметры, отображаемые на дисплеях экипажа соответствующими функциями Disp.

Разработчикам пришлось серьёзно попотеть, чтобы умудриться делать каждую OPS меньше 106 килобайт имевшийся памяти. Например, в 1975 году первоначальный вариант программы старта корабля составлял 140 килобайт, к 1978 году модуль удалось уменьшить до 116 килобайт при требовании NASA в 80 килобайт. В результате дальнейшей оптимизации стартовый OPS стал занимать 98840 слов.

Благодаря модульному подходу система PASS получилась гибко настраиваемой средой, которая непрерывно развивалась и совершенствовалась в течение всех тридцати лет существования проекта STS. К моменту старта первой миссии STS-1 в 1981 году было разработано более тысячи разнообразных OPS. За первые двенадцать миссий около пятидесяти процентов кода этих OPS было переработано с учётом его реальной эксплуатации системы PASS.

Поставив шаттлы на крыло, руководство NASA осознало важность постоянного создания и совершенствования программ для многочисленных миссий STS. Именно поэтому имеющийся тогда отдел программирования был преобразован в лабораторию NASA Software Development Laboratory, которая в 1982 году превратилась в «фабрику» (SPF — Software Production Facility), на «конвейере» которой непрерывно создавались, отлаживались и модифицировались OPS и системные компоненты PASS.

Первоначально SPF состояла из: пяти ЭВМ IBM 360/75, совместимых по системе команд с AP-101, трёх AP-101, связанных между собой в избыточную структуру, подключённую к модулю управления оборудованием корабля (FEID — Flight Equipment Interface Device), и средства моделирования полёта — имитатора кабины шаттла с шестью степенями свободы.

В 1981 году состав оборудования SPF дополнился двумя мощными ЭВМ IBM 3033 с шестнадцатью миллионами байт памяти каждая, двадцатью ленточными накопителями, шестью принтерами и жёсткими дисками общим объёмом 23,4 миллиарда байтов (примерно 22 Гб).

К этой системе в самой SPF было подключено сто пять терминалов. Дополнительные терминалы располагались у коллег по разработке: в центрах космических полётов Годдарда, Маршалла и Кеннеди, а также в компании Rockwell и Массачусетском Технологическом Институте.

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

Существенные наработки в области космической авионики, сделанные SPF, позволяют успешно трудиться этой «фабрике» и после завершения проекта STS. В настоящее время специалисты SPF активно участвуют в разработке софта для разрастающейся Международной космической станции, а также для массы проектов, связанных с исследованием дальнего космоса.

А что же PASS? Уверен, что проверенный временем код этой программной системы авионики найдёт своё применение в будущих проектах пилотируемого освоения космического пространства.

К оглавлению