С конца 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).
Язык HAL/S. Высоким штилем о реальном времени
Приступая к проектированию программной системы Space Shuttle, руководство NASA имело возможность постоять на распутье, выбирая между уже имеющимися наработками, доказавшими свою состоятельность в пилотируемых полётах проекта Apollo, или разработкой с чистого листа.
Программированием компьютеров AGC (Apollo Guidance Computer) для лунных путешествий занималась лаборатория Дрепера, расположенная в Кембридже и относящаяся к Массачусетскому Технологическому Институту. Программная система компьютеров AGC разрабатывалась с использованием языка ассемблера. И эффективность этого подхода у специалистов не вызывала сомнений. С помощью ассемблерного кода можно виртуозно управлять вычислительным процессом, наиболее эффективно используя каждый байт памяти. Но у такой оптимизации имеется и обратная сторона: процесс разработки лабораторией Дрепера ассемблерных программ для проекта Apollo ни разу не уложился в отведённые сроки. А в случае обнаружения в уже разработанной программе ошибок её переработка превращалась в длительный процесс совместной работы инженеров NASA и программистов Дрепера, полный взаимных упрёков и препирательств.
Читать дальше
