Современные достижения в области аппаратного обеспечения машинной графики предоставляют благоприятную возможность для расширения методов трехмерной визуализации на четвертое измерение - время. Но компьютерная анимация, управляемое движение и отображение действующих участников, камер и источников освещения в моделируемом мире, является сложным процессом, поэтому программное обеспечение, которое выполняет анимацию, должно скрывать эту сложность от пользователя. Более того, поскольку компьютерная анимация нв является полностью сформировавшейся областью, современные анимационные системы должны быть разработаны с учетом включения в них новейших методов, не отвергая при этом существующее программное обеспечение. Объектно-ориентированная технология, заслужившая на протяжении последнего десятилетия похвалы разработчиков программного обеспечения, предусматривает средства для работы как со сложностью, так и с изменчивостью, присущими компьютерной анимации. Объектно-ориентированная разработка позволяет провести естественное разбиение сложных систем на управляемые фрагменты, называемые объектами, что дает возможность архитекторам системы многократно использовспь существующие программы и расширять уже имеющиеся комплексы. В описано применение обьектно-ориентированной парадигмы для разработки и создания системы компьютерной трехмерной графической анимации в Центре исследований и разработки корпорации General Electric Мы предлагаем методологию разработки, системную архитектуру и стратегию внедрения систем анимации, которые могут быть использованы независимо от объектноориентированных возможностей среры применения. Эта технология применялась при разработке и внедрении проекта OSCAR, обьектно-ориентированного аниматора сцен (Object oriented SCene AnimatoR).
Введение
В современной компьютерной литературе значительное внимание уделяется двум аспектам информатики и машинной графики. Во-первых, ученые расхваливают достоинства объектноориентированных подходов, обещая, что выгоды при разработке систем превзойдут преимущества от применения структурного программирования. Во-вторых, исследователи в области МГ активно преследуют цель достижения реализма при создании высококачественных систем трехмерной анимации.
Ниже дается обзор последних работ в области объектно-ориентированных систем и компьютерной трехмерной анимации, а затем приводится методология разработки, в которой философия объектного ориентирования применена при разработке системы трехмерной анимации.
Объектно-ориентированная технология
Объектно-ориентированные системы базируются на следующих концепциях проектирования программ:
- Упрятывание(инкапсуляция) информации: детали системы, которые не оказывают влияния на другие части системы, не видимы снаружи.
- Абстракция: Объекты (сущности) системы группируются в соответствии с общими свойствами и операциями.
- Модульный подход: Части системы, поведение которых хорошо локализуется, группируются вместе, с хорошо определенным интерфейсом.
В объектно-ориентированных системах эти принципы дополняют друг друга.
Объектно-ориентированная разработка
Грэди Буч (Grady Booch) [1] в общих чертах обрисовал методологию объектно-ориентированной разработки для языка Ада. Его методология обходится без наследования, поскольку язык Ада его не поддерживает и подразумевает, что объектно-ориентированная разработка может быть выполнена путем извлечения существительных (объектов) и глаголов (методов) из описания требований.
Мы приняли альтернативный подход, в котором основной акцент приходится на процесс абстракции и наследование. Такая методология применяется на этапе выбора архитектуры программы. Главный упор при этом направлен на определение абстракции, что предусматривает наличие следующих шагов:
Идентификация абстракций данных для каждой подсистемы
Абстракции данных представляются классами системы. Начинающийся с описания требований, процесс абстракции продолжается сверху вниз пока это возможно, хотя во многих случаях абстракции явно упоминаются в требованиях. Часто классы соответствуют физическим объектам, в терминах которых моделируется система. В иных случаях полезным может оказаться использование аналогий из опыта разработчиков по созданию предшествующих систем. Это, несомненно, самый трудный шаг: выбор этих абстракций оказывает влияние на внутреннюю архитектуру системы.
Идентификация атрибутов для каждой абстракции
Во многих случаях, если классы соответствуют физическим объектам, очевидным оказывается и выбор необходимых экземплярных переменных. Другие переменные могут потребоваться,чтобы реагировать на требования от других объектов системы. Отложим пока спецификацию структур данных, составляющих атрибуты, до этапа детальной разработки.
Идентификация операций для каждой абстракции
Операции - это методы или процедуры для каждого класса. Некоторые методы получают доступ и обрабатывают экземплярные переменные, тогда как другие выполняют операции над классом в целом. Не будем определять сейчас детали применения методов, а ограничимся только этими функциями. Если новая абстракция получена путем наследования из другого класса, то необходимо изучение методов исходного класса, чтобы понять, надо ли заменить некоторые из них этим новым классом. Отложим внутреннюю разработку методов до этапа детального проектирования, где возможно использование более традиционной методики.
Идентификация связей между объектами
Определяются сообщения, которыми могут обмениваться объекты. Предполагается взаимосвязь между методами и порожденными ими сообщениями. Специфицированные сообщения помогают взаимодействию команды разработчиков и могут быть использованы на следующем этапе написания сценариев.
Тестирование разработки со сценариями
С помощью сценариев, состоящих из сообщений объектам, проверяется способность разработки соответствовать поставленным требованиям. Для каждой функции уровня пользователя в спецификации требований, пишется соответствующий сценарий.
Применение наследования везде, где зто возможно
Целью является максимальное повторное использование ранее разработанных данных и методов. На этом этапе часто всплывают на поверхность общие данные и операции и такие общие экземплярные переменные и методы, которые могут быть объединены в новый класс. Сами по себе экземпляры этого класса могут быть, а могут и не быть объектами. Если единственная цель такого класса - объединить общие экземплярные переменные и методы, то он называется абстрактным классом.
Разработчик повторяет эти шаги на каждом уровне абстракции. При помощи последовательной, все более точной разработки взгляд разработчика на систему изменяется в зависимости от требований момента. Каждый уровень абстракции выполняется на все более низком уровне, до тех пор, пока не будет достигнута точка, где абстракция соответствует простейшему элементу проектирования. Новые уровни абстракции должны предусматривать некоторый атрибут или операцию, которые не могли быть сформулированы на предыдущем, самом низшем уровне. Например, абстракции геометрических примитивов могли бы начинаться с многоугольника или с прямоугольника, определяемого на следующем уровне абстракции, который в свою очередь следует за квадратом.
Объектно-ориентированные системы
Пакет Sketchpad [2] Ивана Сазерленда был примером одной из первых объектно-ориентированных систем. Sketchpad являлся универсальной графической системой для интерактивного создания и редактирования изображений на графическом дисплее. Геометрические преобразования применялись к определениям мастера (класса) объектов, приводя в результате к экземпляру геометрического объекта. Хотя в 1963 году сама концепция объектно-ориентированной системы еще не была сформулирована, пользовательский интерфейс Сазерленда уже тогда имел много свойств, объединяющих его с такими системами.
Система Smalltalk [3] Исследовательского центра в Пало-Альто (PARC) корпорации Xerox наиболее часто ассоциируется с объектно-ориентированным подходом. Система основана на понятиях объектов, сообщений и классов; они используются для создания среды программирования и пользовательского интерфейса. Smalltalk отличается от других объектно-ориентированных систем тем, что не имеет какой-либо общепринятой типизации и процедурных конструкций, что могло бы нарушить строгость применения объектов и передачи сообщений. Единственной конструкцией в этой системе является объект, который даже управляет программным потоком. Каждый класс имеет методы, используемые для обработки сообщений, генерируемых внутри объектов. В системе допускается определение новых классов путем добавления данных и методов к другому классу, называемому суперклассом.
Система Flavor [4] компании Symbolic представляет собой пример внедрения объектов в диалект Лиспа. Эта система использует множественное наследование, допуская неиерархические комбинации классов, называемых объектами (flavors). Когда создается новый объект, он наследует атрибуты множества объектов. Методы управления сообщениями определяются как комбинация методов других объектов. Возможно возникновение конфликта, в случае если два комбинированных объекта обрабатывают одно и тоже сообщение разными способами, однако концепция объекта разрешает этот конфликт единым, заранее определенным способом.
Системы компьютерной анимации
Прогресс в создании компьютерных графических изображений продвинулся от каркасных образов трехмерных моделей к простым полутоновым изображениям, до современных реалистических картинок, являющихся образцами искусства. Это явилось результатом успеха в более точном определении среды моделирования. Прозрачность, отражение, тени, модели освещения и свойства поверхности - вот несколько областей, где напряженно работают группы исследователей, постоянно предлагающие новые алгоритмы создания все более приемлемых искусственных образов. Текущая тенденция компьютерной графики - применение этих передовых методов для создания качественной анимации.
Родственные работы
Хотя на протяжении последних лет появились дюжины фильмов, созданных с использованием трехмерной машинной графики, научные публикации сосредоточены главным образом на алгоритмах, используемых для создания образов, а не на анимационных системах, как таковых. Вероятно, это происходит потому, что существует очень немного общецелевых систем анимации. Большое количество компьютерной кинопродукции создано путем выполнения последовательности не связанных между собой программ, управляемых командными файлами. Наибольшие усилия в этих областях направлены на получение качественного образа и реализм, а не на анимационные интерфейсы как таковые.
Рейнольдс [5) на протяжение нескольких лет работал над анимационной системой Актер/Сценарист (ASAS, Actor/Scriptor Animation System). Начатая как докторская диссертация, ASAS использовалась в компании Information International, III, для создания эпизодов фильма Уолта Диснея TRON [6]. ASAS выполнена на Лиспе и полностью основывается на объектно-ориентированных концепциях. Актеры ASAS являются действующими лицами анимации, взаимодействуя путем передачи и получения сообщений. С того момента как некоторый актер вступает в действие, он остается частью анимации до тех пор, пока не остановится сам или не будет остановлен другим актером. Актеры могут также высказывать реплики при своем появлении или исчезновении. Обработка этих реплик содержится внутри самих актеров. Так же, как это свойственно другим системам на Лиспе, ASAS может использовать мощь Лисп-интерпретатора для расширения возможностей этого языка путем включения новых функций и форм.
Система MIRA [7] тоже является расширением алгоритмического языка, но на этот раз Паскаля. В ней определены абстрактные графические типы для описания участников анимации. Анимация описывается как серия сцен, где каждая сцена имеет имя и является последовательностью утверждений, управляющих актерами, камерами и декорациями. Декорации включают графические объекты, не изменяемые внутри данной сцены.
Пакет Clockworks [8], разработанный в R.P.I., является основанной на языке Си объектно-ориентированной системой анимации, которая объединяет моделирование, управление анимацией и воспроизведение. Как Clockworks, так и Oscar используют сценарий для управления процессом анимации. Эти системы разрабатывались параллельно, и в проекте Oscar реализованы многие полезные предложения от персонала R.P.I. Основные отличия заключаются в способности Oscar взаимодействовать с внешними программами, которые часто используются в промышленных приложениях.
OSCAR
Промышленные приложения машинной графики имеют некоторые общие черты с приложениями, используемыми в университетах и коммерческих киноассоциациях. Хотя программное обеспечение для моделирования и воспроизведения является общим для того и другого случая, университетские и коммерческие системы при передаче сообщения через анимацию больше полагаются на художественный талант. В промышленности, напротив, руководствуются анализом моделируемого явления. Например, художественное изображение робота в рабочей обстановке может концентрироваться на внешней реалистичности изображения, тогда как движение промышленного робота должно быть предопределено сложным кинетическим анализом. Целью промышленной анимации является не создание привлекательного фильма, а достижение понимания того, как взаимодействует робот с окружающей средой. Кроме того, если анимация используется для целей маркетинга, потенциальный покупатель не будет восхищен художественной интерпретацией поведения робота: ему нужно понять, как робот, которого он предполагает приобрести, работает в реальной среде.
В этом состоит ключевое различие между данной системой и другими системами: опора на анализ, а не на искусство. Это также иллюстрирует задачу, на которую должна быть направлена данная система анимации: программное обеспечение для выполнения анализа часто уже существует вместе со своим пользовательским интерфейсом и базами данных.
Объектно-ориентированный аниматор сцен OSCAR, обеспечивает возможность автоматизированной графической анимации для эффективного создания и управления трехмерными анимационными эпизодами, генерируемыми компьютером. OSCAR автоматизирует процесс создания высококачественных фильмов и видео, показывает результаты сложных исследований, экспериментов и другого выполняемого компьютером анализа.
Используя в качестве пользовательского интерфейса объектно-ориентированный язык сценариев, система анимации обеспечивает автоматическое управление процессами анализа, моделирования, воспроизведения, отображения и создания фильма. Разработаны интерфейсы для программ научного анализа в областях молекулярного моделирования, анализа механизмов и робототехники, в будущем планируются интерфейсы для анализа динамики твердых тел и жидкости. Объектноориентированная разработка позволила также создать систему, обеспечивающую взаимодействие с существующим, а также будущим встроенным и внешним программным обеспечением.
Процесс анимации
Необходимым предварительным условием для разработки системы программного обеспечения является понимание решаемой задачи. Также как и все отрасли науки, компьютерная анимация имеет свою собственную терминологию. Далее следует описание процесса анимации с использованием жаргона, достаточного для понимания читателем последующей разработки системы.
Пользователь системы компьютерной анимации действует как продюсер, автор сценария и режиссер фильма. Продюсер осуществляет общее управление производством фильма, составляет расписание, определяет задачи и предоставляет ресурсы. Автор сценария создает сценарий, основанный на требованиях заказчика. Режиссер управляет анимацией, размещает декорации, актеров, камеры и осветительные приборы. Создание анимации происходит в несколько шагов.
Фабула. Автор сценария, работая совместно с заказчиком, вырабатывает фабулу, которая описывает роль каждого участника, включая его наружность, диалоги и действия. Каждый фильм делается с некоторой осознаваемой целью. Она может заключаться в том, чтобы проверить или понять с помощью некоторого математического алгоритма, как нечто соотносится с физическим явлением, объяснить абстрактную идею аудитории, сбыть продукт или обеспечить развлечение. Создание фабулы является творческим процессом, в котором компьютер вряд ли может помочь.
Сценарий. Сценарий содержит детальное описание расположения и движения актеров, камер и источников освещения в анимации. Система OSCAR предоставляет язык написания сценария для документирования изменений и формирования окончательной анимации. Сценарий может быть написан с помощью текстового редактора или создан средствами Интерактивного генератора сценариев OSCAR. Сценарии состоят из предложений объектно-ориентированного языка, разработанного как часть этой системы.
Имитация. Для научных приложений эксперименты и имитация часто обеспечивают физику анимации. Эту имитацию направляют и выполняют технические аналитики, в качестве которых выступают ученые и инженеры, заказавшие анимацию. 0SCAR предполагает, что большинство анимаций зависит от некоторой компьютерной модели. Чтобы обеспечить имитацию результатов такой анимации, должен быть проведен анализ. OSCAR называет эти программы имитации "аналитиками".
Модели. Каждая декорация и актер, участвующие в анимации, должны иметь геометрическую модель. Во время анимации режиссер перемещает эти модели в окружающей среде. Некоторые аналитические модели имеют связанную с ними геометрическую модель, тогда как другие - не имеют. Например, инженер-конструктор, проводя анализ перегрузок турбины, перед выполнением анализа моделирует турбину методом конечных элементов. Таким образом, анализ и модель оказываются неразрывно связаны: как для анализа, так и для отображения требуется одна и та же модель. В вычислениях молекулярной механики используется простая точечная модель атома и модели связей для описания соединений. Здесь для процесса воспроизведения требуются более изощренные геометрические модели: состоящие из сфер и цилиндров. Модели создаются программами, называемыми "модельерами".
Воспроизведение. На этом шаге алгоритмы МГ применяются к геометрической модели, свойствам поверхности, освещению и т.д. для создания отображаемых теневых образов. Воспроизведение выполняется программами, называемыми "воспроизводителями".
Редактирование фильма. Объекты кадрового редактора создают титры, подписи и специальные эффекты, например, наплывы и изменения четкости изображения, добавляя профессиональный штрих законченному эпизоду.
Запись. Записывающие объекты выполняют последний шаг всего процесса и осуществляют отбор кинокадров и запись фильма или видео.
Главные подсистемы
Подсистемы, составляющие OSCAR, реализуют функции, выполняемые на каждом из шагов процесса анимации. Использование антропоморфного объекта во всех описаниях сохраняет соответствие с традиционной метафорой создания кинофильма.
Опишем теперь действующие объекты и программы, а также процесс их взаимодействия:
Режиссер - это набор объектов, который обеспечивает управление всеми компонентами OSCAR. Режиссер читает, интерпретирует сценарий и посылает команды другим модулям, выполняющим часть анимации.
Интерактивный генератор сценария - это объект, который обеспечивает графический пользовательский интерфейс для написания сценариев. Сценарии содержат инструкции, описывающие, что должно происходить в анимационном эпизоде. Интерактивный генератор сценария позволяет пользователю позиционировать камеры, источники освещения и описывать движение объектов, видимых пока только как каркасные образы, которые в окончательном фильме будут представлены уже реалистичными образами. Вводимые пользователем данные интерпретируются и сохраняются в файле сценария. Хотя Интерактивный генератор сценария предусматривает интерфейс как для новичка, так и для опытного пользователя, последний может писать и редактировать сценарии непосредственно с помощью текстового редактора.
Кадровый секретарь - это объект, который хранит путь каждого законченного кадра данного фильма, отмечает, был ли кадр записан или его следует положить в архив как уже не нужный. Кадры могут быть сохранены в разных местах: на активном диске, магнитной ленте или оптическом видеодиске.
Связисты - это объекты, которые обеспечивают интерфейс между OSCAR и внешними моделями. Связисты транслируют специфическую информацию OSCAR в форму, которую могут понять аналитики, модельеры или воспроизводители, и обратно от них в OSCAR.
Аналитики - это внешние программы, выполняющие анализ в различных научных областях. Интерфейсы с этими программными пакетами нельзя изменить, поэтому для взаимодействия каждого аналитика и OSCAR требуется специфический для данного аналитика связист.
Модельеры - это внешние программы, которые создают геометрию объекта для анимации. Обычно они используют геометрические примитивы для построения комплексного представления структуры. Список доступных модельеров включает GEOMOD, Movie.BYU, Phigs и Syntavision. Также как и аналитики, эти системы имеют определенные интерфейсы, и каждому нужен связист для перевода информации между режиссером и модельером.
Воспроизводители - это внешние программы и объекты, которые берут данные о геометрии и информацию о среде (такую как расположение источников освещения и камер) из сценария и создают кадры для дальнейшего отображения и использования в фильме. Такие воспроизводители включают Movie.BYU, Phigs+ и Syntavision. Для каждого внешнего воспроизводителя существует свой связист.
Объекты редактора кадров выполняют редактирование и обеспечивают создание специальных эффектов и титров. Эти объекты работают с кадрами.
Записывающие объекты выполняют сборку эпизодов. На данном этапе происходит получение окончательных кинокадров от кадрового секретаря, отображение образов в буфере кадра и запись этих образов на пленку или видеодиск.
Язык анимации
Язык анимации использует единую структуру предложений, которые определяют связь между объектами. В каждом предложении пользователь определяет объект и сообщения для этого объекта. В выдержке из приведенного далее описания синтаксиса этого языка, заглавные фрагменты и литеры, заключенные в двойные кавычки, являются терминальными символами.
Классы в OSCAR
В данный момент в системе существует более сотни классов. Приведем краткое описание нескольких классов:
Актеры - это геометрические объекты анимации. Для них заданы координаты, источник, ориентация, цвет и видимость. Их видимость управляется с помощью сообщений on! и off!. Они имеют связанную с ними модель, которая хранится в отдельном объекте модельера.
Сцены состоят из реплик и воспроизводителей. Кроме того, сцены имеют продолжительность (в секундах), разрешение (в кадрах в секунду) и список действий, которые выполняются в их начале, в период их существования и после завершения. Эти действия являются предложениями языка сценария. Действия выполняются путем посылки грамматического разбора: сообщения программе грамматического разбора с соответствующим предложением в качестве аргумента. Как только сцена запущена сообщением start!, выполняются некоторые стартовые действия, а затем сцена переходит к передаче сообщений tick! каждой из своих реплик. Когда реплики обработают свои кванты, сцена передает каждому из своих воспроизводителей сообщение render! (воспроизвести!). При завершении сцена выполняет свои финальные действия и передает каждому воспроизводителю сообщение complete! (завершить!).
Реплики содержат информацию по временам, управляющим внешним представлением и поведением участников сцены. Начальное и конечное время определяет интервал, в течении которого реплика является активной. Реплики имеют часы, которые идут с характерной для нее скоростью. Когда от другого объекта сцены получено сообщение tick! (квант!), реплика продвигает свои часы и проверяет, может ли она продолжать оставаться активной. Если это так, то выполняется каждое из стартовых и квантовых действий с продвижением часов. До тех пор, пока время реплики часов остается в заданном интервале, ее квантовые действия выполняются при каждом получении сообщения tick!. Как только истек интервал времени, реплика выполняет свои завершающие действия.
Камеры - это средства, с помощью которых ведется наблюдение за анимацией. В нашей реализации используется конвейер видовых преобразований, предложенный Дж. Фоли и А. ван Дэмом [9]. Камеры можно двигать, поворачивать, а также включать и выключать. Камера не имеет геометрического представления, поэтому если одна из них оказывается в поле зрения другой, она не будет видна. Хотя в сцене может быть использовано несколько камер, только одна из них может быть включена в заданный момент времени для заданного воспроизводителя.
Источники освещения - это объекты, которые освещают сцену. Для них указаны координаты, цвет и ориентация. Их можно двигать, а также включать и выключать. Одновременно могут присутствовать и быть включенными несколько источников освещения.
Воспроизводители - это объекты, которые конвертируют структуры геометрических данных актеров в формат, отображаемый с помощью специальных программ в растровые или векторные образы. Когда связист воспроизводителя принимает сообщение render!, он запрашивает информацию о координатах и ориентации определенных актеров, источников освещения и камер. Воспроизводители, которые существуют как объекты системы, создают образы в интерактивном режиме. Для внешних воспроизводителей соответствующий связист создает командный файл, который может быть выполнен позже. Существует абстрактный воспроизводитель, который строго задает протокол для всех воспроизводителей. Чтобы добавить новый воспроизводитель, пользователь должен следовать этому протоколу.
Редакторы - это объекты, состоящие из реплики записывающих устройств. Они подобны сценам в том, что передают сообщения tick! каждой из своих реплик и сообщения record! (запись!) каждому из своих записывающих устройств. Редакторы используются для работы с растровыми образами, созданными с помощью воспроизводителей.
Записывающие устройства - это объекты, которые составляют кадры из множества кинокадров. Каждое записывающее устройство имеет список последовательностей кинокадров, которые можно показать и записать. Другие классы, доступные внутри системы, включают преобразования матриц, сплайны, скаляры, векторы и наборы.
Резюме
Первый фильм на базе OSCAR был сделан десять лет назад, когда в системе было двадцать пять классов, включающих актеров, камеры, источники освещения, сцены, реплики и воспроизводителей. С момента исходной реализации система выросла до более чем девяноста классов, пятьдесят восемь из которых являются подклассами исходных классов - более половины классов делят программный код с другими классами.
В процессе работы над проектом нами сделаны следующие наблюдения:
- Применение процесса абстракции данных к циклу создания анимации позволяет создать естественный интерфейс, использующий близкую пользователю терминологию;
- Этап абстракции является критическим этапом разработки и требует большого количества времени и усилий. Путь, выбранный на этом этапе, определяет ход всей последующей разработки;
- Объектно-ориентированный подход позволяет разбить сложную систему на управляемые фрагменты. Ни один отдельно взятый объект не является сложным, но система, как целое, может отвечать сложности моделируемого процесса;
- Данная система представляется менее хрупкой, чем другие, написанные ранее. Модификация и добавление объектов может происходить без опасения разрушить систему.
Литература
[1] Воосн С. Software Engineering with Ada, Benjamin Cumming Publishing, 1983.
[2] Sutherland I. Sketchpad А Man-Machinegraphical Communication System, PhD Thesis, MIT, 1963.
[3] Goldberg А., О. Robson. Smalltalk-80, The Language and Its Implementation, Addison Wesley, 1983.
[4] Lisp Machine Manual. Symbolic Inc., 1983.
[5] Reynolds С. "Computer Animation with Scripts and Actors", Computer Graphics, vol 16, # 3, July 1982, рр. 289-296.
[6] "Disney Takes the Lead whith TRON", // Computer Graphics World, vol. 5, И 4, April 1982, рр. 41-45.
[7] Magnenat-Thalmann N., D. Thalmann. "The Use of High-Level Graphical Types in the Mira Animation System", // IEEE Computer Graphics and Applications, December 1983, рр. 9-16.
[8] Breen О., Apodaca А., Р. Ghetto. "The Clockworks. An lmplementation of an Objekt-Oriented Computer Animation System in а Conventional Programming Znvironment, TR-86016, Rensselaer Polytechnic Institute Center for Interactive Computer Graphics, 1986.
[9] Дж. Фоли, А. ван Дэм. Основы интерактивной машинной графики. В 2-х томах, - Пер. с англ. М. Мир, 1985.
СВОДКА СИНТАКСИСА OSCAR
предложение:= объект сообщения ";"
объект:= NAME
сообщения:= сообщение | сообщения сообщение
сообщение:= PREFIX "?"
| PREFIX "!"| PREFIX":" аргумент
| PREFIX "=" аргумент
| PREFIX "@" аргумент
| PREFIX "+" аргумент
| PREFIX "-" аргумент
| PREFIX "/" аргумент
| PREFIX "*" аргумент
| PREFIX "^" аргумент
аргумент:= VALUE
| МАМЕ
| STRING
| "(" список аргументов ")"
| "[" объект сообщения "]: список аргументов:= аргумент
| список аргументов "," аргумент
где VALUE - это десятичное число с плавающей точкой, NAME - строка литер, STRING - это строка, взятая в кавычки, PREFIX - необязательная строка. Специальные символы в начале строчки позволяют пользователю выполнить переназначение ввода и вывода, вызывать системные процедуры и печатать текст на терминале. Левая и правая квадратные скобки позволяют получать аргументы сообщения из другого объекта. Семантика сообщений поддерживается внутри самих объектов. Следующие правила, принятые для суффиксов сообщений, иллюстрируют их семантику: ? запрос значения экземплярной переменной. = установка экземплярной переменной : запрос аргументов, но без спецификации зкземплярной переменной. @ определяет индекс. +, -, /, * и ^ завершают сообщения арифметических операций. ! завершение сообщения без аргументов.
Сообщения одному и тому же объекту могут быть
конкатенированы в предложение. Типичным может быть следующее предложение:
ACTOR new: Abox
position (0, 5, 0) rotate_х: 30 color (1, 0, 1) on!;
Это предложение создает экземпляр класса ACTOR (актер) с некоторыми координатами
и цветом. Объект повернут относительно его локальной оси х. Эквивалентная
запись, приводящая к тому же результату, но лучше читающаяся, такова:
Abox:= ACTOR {
position=(0, 5, 0) rotate_х: 30
color=(1, 0, 1) on! };
Чтобы создать другой прямоугольник, с теми же значениями экземплярных переменных,
что и у первого, достаточно написать:
Abox new. Anotherbox;
Камера может быть определена следующим образом: CAMERA new: Acamera position (0, 20, 5) view_angle=30; а ее точка наблюдения может быть установлена в позицию прямоугольника, с помощью передачи прямоугольнику сообщения, запрашивающего его координаты: Acamera focal_point [Abox position?];
