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

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

С конца 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, программисты которого располагались в далёком Кембридже, посчитала, что разработчиков лучше иметь под боком.