英语原文共 8 页，剩余内容已隐藏，支付完成后下载完整资料

场景动画通用规范

基因李

不列颠哥伦比亚大学计算机科学系

加拿大温哥华V6T 1Z4 gslee@cs.ubc.ca gslee@alum.mit.edu

摘要。本文介绍了场景动画通用规范IBAL的基础。IBAL调节图形元素（如几何模型和行为算法）之间的交互，以描述动画场景。图形元素之间的交互由基本元素管理，基本元素被排列成三个图。这三个图形在逻辑上将动画分割成“谁”、“什么”和“什么时候”。IBAL独特的设计允许应用程序表示、保存和恢复各种复杂的场景。简要总结了现有的场景建模和场景动画格式，以区分和评估IBAL设计的实用性。

关键词：场景动画、通用规范、软件交互

1引言

计算机动画是计算机动画场景的开发和制作。动画场景由许多图形元素组成，随着时间的推移相互作用。图形元素是几何模型、算法和数据结构，它们定义动画的状态，并控制动画从一种状态到另一种状态的逐步演化。

有许多工具可以快速显示、存储和编辑各种图形元素。文件格式是一种非常重要和流行的工具。文件格式符合将信息存储到数据文件中的规范。它们为应用程序建立了存储和共享场景图形元素的方法。使用既定规范的应用程序必须按照特定的准则来读写信息，但它们可以自由地使用自己的方法和数据结构来表示和操作信息。

计算机图形学有多种规格。但是，只有存储和表示几何模型的规范（如3DMF[3]、IGES[13]和DXF[4]）才能获得广泛的成功。动画的规格很多，但很少流行或标准化。那些流行的，如QuickTime[12]和MPEG[9]，只存储动画的合成帧。它们既不描述也不控制动画的内容。仅从图像中，很难获取或识别定义动画的所有图形元素。

在许多描述动画场景的内容和行为的动画规范中，很少有流行的。对于大多数规范（如VRML[5]），快速开发、而不是重用或可移植性是主要目标。因此，规范通常很难划分为逻辑部分，并且随着场景复杂性的增加，使用起来很困难。要识别、提取或替换定义“谁”、“什么”和“何时”的动画部分并不总是容易的。【20】理想情况下，一个强大的规范可以管理复杂性，适应多种动画方法，并本地化控制结构。这些关键特性对于广泛接受和易于使用是必不可少的。

本文旨在为基于交互的动画语言IBAL奠定基础。IBAL是一种通用的、无需实现的场景动画规范。它依赖于一流的原语来组织和控制图形元素的交互。当图形元素交互时，它们交换信息并更新状态。规范由三个图组成。第一个图描述场景元素；第二个图描述动态行为；第三个图描述时间属性。这三个图形很容易将动画的本质部分分开，并将复杂的场景减少到交互的层次。通过IBAL，可以共享和重用各种场景和动画技术。

本文共分六个部分。第二部分概述了计算机动画的各种规范。本文简要讨论了确定建模常用规范成功的几个问题，并使用这些问题评估现有规范的激活质量。第三部分介绍了IBAL的概况，并介绍了IBAL三种图形的基本设计。第四节通过提供一个示例并将其与其他规范进行比较，来演示IBAL的实用性。第五部分和第六部分分析了IBAL的设计，并总结了本文的研究成果。

2背景

图形工业界对图形和动画提出了许多规范。应用程序通常支持许多场景建模规范，而场景动画仅支持一个或两个规范。应用程序比较容易共享模型的描述，而不是动画场景的描述。影响建模规范成功的许多问题并不能满足现有的动画规范。本节介绍这些问题，并将其用作分析和比较场景动画的各种类型规范的基础。

2.1场景建模规范

场景建模规范，如inventor[26]和obj[1]描述了静态场景的形状和物理特性。它们之所以流行和标准化，有五个原因：

需要在许多应用程序之间共享信息，并形成场景信息的档案。

共享和归档场景信息非常重要。并非所有应用程序都提供相同的特性和接口来构造静态场景并与之交互。共享的应用程序可以获得其他人提供的好处。档案馆强调场景整合，而不是场景开发。场景是通过浏览数据库生成的，例如由ViewPoint DataLabs公司[27]和New Worldgraphics公司[23]提供的库，以及通过调整可接受的元素。

有一套普遍接受的低层（和一些高层）数据结构用于场景构建。

不考虑效率，可以用基本结构（如点、线、多边形和样条线）或简单多面体（如立方体、球体和圆柱体）表示所有场景。通常，当场景转换为基本结构时，alternative结构的设计优势就会消失。但是，这个缺点被普遍接受，因为它允许所有应用程序生成原始场景的类似副本。

从逻辑部分（使用基本数据结构）形成方法静态场景的方法是可以接受的。

许多规范将场景分成许多逻辑部分，例如点集、法线、面和颜色。从部件构建的场景易于重建、集成和剖析。加载场景的应用程序可以快速选择和丢弃不需要的部分。

用基本结构表示高精度场景通常会降低质量。对于许多用户来说，近似表示是可以接受的，有时是首选的。

有一些方法可以有效地构建和管理复杂的场景。

许多规范使用逻辑运算符或层次结构方案从简单的模型组成复杂的场景。合成场景更容易更新，而且通常更容易存储。

可以制作各种各样的静态场景。

使用基本结构和逻辑运算符，可以描述场景中所有图形元素的形状和特征。并非所有的场景描述都能被有效地描述，但它们是可表示的。

2.2场景动画规范2.2.1分类

如其他地方所述[18]，场景动画的规范由外观格式和内容格式组成。外观格式存储场景的帧（图像），而内容格式存储场景的描述。每个主要类型进一步分解为几个子类型。所有这些类型共同构成一个类层次结构，如图1所示。

图1：场景动画规范的分类

外观格式分为两个相关的子类型，顺序电影和非顺序电影。前者存储图像的线性行进，后者存储图像的拼贴。这两种类型都不适合存储或获取有关动画场景内容的信息。内容格式还分为两个子类型：关键帧和脚本。keyframes规范[2]存储显式建立状态信息的键值序列，而脚本存储计算状态信息的表达式序列。

脚本进一步分为基于状态和基于交互的格式。基于状态的格式，由动画类型[16]和通用格式[22，6]组成，显式地操纵场景元素的状态。表达式将场景元素的参数与特殊的运算符混合，以管理状态值的演化。基于交互的格式[5]，包括消息传递和活动链接格式，识别场景元素之间的关系。相关的场景元素在交换信息时会改变状态。

2.2.2类型分析

表1中的图表比较了存储内容的三种主要格式。比较表明，这些类别都没有完全解决推广建模格式的问题。

关键帧格式非常有用并且易于使用，因为它们建立了信息的逻辑分区：关键帧更新状态变量。不幸的是，在指定非常复杂的场景时，关键帧的创建非常困难。很少有方法可以在关键帧上构建更高级别的抽象，也没有简单的方法可以创建适合运行时的动画。关键帧动画的状态总是在开始前设置。

基于状态的脚本文件对于描述各种各样的动画很有用。它们可以小心地引导动画，如关键帧文件，并且它们可以在图形元素之间形成关系，以建立约束和自适应行为。然而，它们不容易分离成部分。大多数使用简洁的表示来描述和控制状态信息。从修改（或计算）状态的脚本中快速提取和替换表达式并不总是容易的。通常，这些表达式与建立状态信息和指定时间属性的其他表达式紧密地交织在一起。

与关键帧文件一样，基于交互的脚本文件也分为两个基本部分：表示状态的部分和修改状态的部分。软件交互，如函数调用或方法调用，缓和了两部分之间的信息流。这两种文件类型都很容易识别，并在各部分中分开。但是，基于交互的脚本可以对各种各样的场景进行建模。它们提供了更多的抽象和更多的部分映射。不幸的是，它们缺少程序开发（和重用）的规则和模式。很少有组织许多软件交互和控制交互随时间的演变的结构。用户必须使用自己的方法或其他脚本语言来管理交互。因此，许多基于交互的脚本（如VRML[5]）都会遇到基于状态的脚本的问题。随着场景复杂性的增加，将动画分割成多个部分变得非常困难。

3动画通用规范

3.1概述

IBAL是一种基于交互的场景动画格式。建立了描述时变场景内容和行为的通用规范。该规范的设计基于RASP工具包的IMVCD（Informer Model-Viewer Controller Delegator）建模框架[20]。IMVCD将场景划分为用于场景建模的基本体和用于场景动画的基本体。后一个原语集通过在建模原语之间形成交互来动画场景。IMVCD标识IBAL指定和控制的动画的基本元素。

IBAL将动画分为三个动画图形：场景图、动作图和时间图。这三个图形分别标识动画的“谁”、“什么”和“何时”。场景图标识动画的图形元素。它描述了场景元素及其属性，如形状、表面特征和查看参数。动作图定义了图形元素之间的交互。它组织交互集合以形成行为、产生状态更改的操作。时间图定义了行为的时间顺序。它指出行为是如何与时间相关和执行的。

3.2框架

图2:IMVCD建模框架

IMVCD建模框架抽象地将计算机动画（和其他可视化模拟）分解为五个关键组件：告密者、模型、查看器、控制器和委托者。如图2所示，告密者定义了观察者可视化和控制器控制的模型的属性。授权程序决定控制器何时动作，以及控制器命令的模型和查看器。与流行的框架（如MVC[17]和访谈[21]）一样，IMVCD关注的是程序的体系结构，而不是实现的重用。它强调组件之间的通信路径，而不是组件之间的数据流。IMVCD不为其他组件定义抽象组件以派生函数和属性。IMVCD是一个实现自由框架，用于识别（而不是评估）软件组件之间的关系。

IBAL的组件与IMVCD描述的组件匹配。模型和告密者，由IBAL的场景图组织，识别图形元素。由ibalamp;apos;sactiongraph标识的控制器管理产生状态更改的交互。通过IBAL的时间图形成的去杠杆器，随着时间的推移改变了相互作用的行为。用

IMVCD，IBAL的规范易于理解和扩充。与IMVCD一致的新元素可以自由替换或补充任何IBAL脚本中的现有元素。

3.3场景图

IBAL的场景图类似于VRML的场景图。如图3所示，它由表示几何图形、转换、表面属性和查看参数的节点层次组成。节点的层次排列形成了一个（呈现）过程要解释的关系。

图3：两个冲突场景图

如果不禁用VRML，IBAL的scene图在解析后不会立即实现。IBAL的场景图是在运行期间形成的分层表示。在运行时，动作图和时间图确定哪些场景图处于活动状态。因此，与VRML不同，IBAL文件可能包含多个具有相同元素的场景图，这些元素似乎存在冲突。如图3所示，两个冲突图在不使用许多“开关”节点的情况下很难在VRML中维护。对于大量的排列，交换机节点比较麻烦，难以动态管理。

3.3.1端口

在IBAL中，所有场景图节点都有端口。端口是一类结构，用于调节节点及其环境之间的信息流。在IBAL的动作图中建立的第一类交互，在节点端口之间建立链接以促进通信。当交互接收到来自IBAL时间图的消息时，就会发生通信。在接收到交互通知后，端口要么接受数据以更新节点的状态，要么传播数据以标识节点的状态。

IBAL的端口和VRML的字段在功能上是等效的，但它们并不相同。虽然两者都是一流的，并且与引起

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[18595]，资料为PDF文档或Word文档，PDF文档可免费转换为Word