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

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

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

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

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

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

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

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

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

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

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

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

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

К оглавлению

Опубликовано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, в которых последний выглядел явным аутсайдером.