JPH03168877A - 動画生成方式 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 く産業上の利用分野〉 この発明はコンピュータによる動画の生成方式に関する
ものである。

く従来の技術〉 現在コンピュータにより扱われている動画は自然動画と
コンピュータアニメーションに大別できる。

自然動画は，実世界の動きをビデオカメラなどで録画し
たものである。コンピュータ処理可能なデジタル情報は
，例えば、画面の縦方向の大きさが７５０ド・Ｊト、横
方向の大きさが１１２０ドット、色情報の表現に１バイ
ド用いるとすると一画面あたり＝８４０，０００バイト
必要となる。このデータ量は膨大であり，自然動画のデ
ータベース化，あるいは通信を行うためには、データの
圧縮技術が必要となる。

渣た、このアプローチは現実の出来事の撮影，あるいは
作者の意図に沿，て現実の物を動かしその撮影を行うも
のであり，一度録画されたものは切り貼りによる編集は
可能であるが，登場物の動き方１で編集することは現状
の技術では困難である。

一方コンピュータアニメーションでは，任意の動きを表
現・編集する事が可能である。実際、コンピュータグラ
フィックス技術の進展により、コンピュータにより作底
された動画が，社会生活のさまざ１な局面で利用されて
いる。ビデオカメラでは撮影不可能な過去や未来の建築
物を実在感豊かに描き出したり、人体の内部のような仮
想的な状況を美しく描いている。しかし，現在利用され
ているＣＧ技術は，動きを表現するためのたくさんの静
止画を作或する技術であり、美しい画像を生成すること
に重点が置かれている。

こういった動きの表現方法には関数法やキーフレーム法
、制約による表現等がある（沓沢：コンピュータアニメ
ーション技法＋　大特集：コンピュ−タグラフィノクス
．　情報処理−　Ｖｏ　Ｉ．　２　９　．Ａ１０．（１
９８８））。これらの方法は個々の登場物の動きの表現
技法にすぎず、これらを組み合わせて一つのス｝　−　
ＩＪを構成する手法は確立されていない。これは、コン
ピュータの処理能力が実時間アニメーション〔画像の生
底と動画の表示を同時に行う）を行うには不十分であっ
たため、コンピュータアニメーションといえトモコンピ
ュータは画像の生成のみを行い，それをフィルムあるい
はテープに撮影したものを上映に用いてきたという事情
が関係している。こういった動画生戊方法に釦いては，
発生時間の指定により動きの発生記述を行うのが一般的
である。

例えば第２図に模式的に示したように．丸い物体２１と
三角の物体２２とが移動して来で衝突した時に四角い物
体２３が動き始めるといった単純な動画を生成する場合
、各登場物の動作の開始時刻と初期位置及び動作の終了
時刻にかける位置を指定し，その間の各登場物の動き具
合を補間によーて一つひとつ憫洞ごとの位置として求め
て動画を作収する。この場合には、すべての登場物の動
の 作春発生時刻があらかじめ決定している必要かある。こ
の手法には局所的な修正が大域に影響する。

ユーザや他のアプリケーション等の外部との同期の表現
ができないといった問題点がある。これらの問題は上述
のような動画の記述方法が事象の発生時間を指定する記
述法である事に起因している。

しかし、近年、コンピュータの処理速度の向上により、
登場物の個々の動きだけでなくストーリ展開を記述する
ことによって、実時間アニメーションを実現する可能性
が高まってきた。ストーリ展開の記述とは，「何がどの
ような動きをどんなタイミングで行うか」の記述である
。動画のストーりを表現するためには、■動きの表現手
段，■動きの発生の表現手段が必要となる。

このような、動きをプログラムによーて記述し、そのプ
ログラムの実行結果として動画を生成する方法にＡＳＡ
Ｓ　（Ｒｅｙｎｏｌｄｓ．Ｃ．Ｗ．：ＣｏｍｐｕｔｅＡ
ｎｉｍａｔｉｏｎ　ｗｉｔｈ　　Ｓｃｒｉｐｔｓ　　ａ
ｎｄΔｒｔｎｖｃＣｎｍｎｕｔｅｒＧｒａＤｈｉｃｓ．
Ｖｏｌ．１６＆Ｓ，ｐｐ，２８９−２９６（１９８２）
）あるいはＰａｒａｄｉｓｅ　（内木、丸一、所：行動
シミュレーションに基ツいたアニメーションシステムＰ
ａｒａｄｉｓｅ．コンピュータソフトウエア，Ｖｏｌ．
４．逼２，ｐｐ，２４−３８（１９８７））といった手
法が提案されている。これらの方法では，動画の記述時
には決定できない動きの発生（イベント駆動な動き）を
記述することが可能である。

これらの方法では、動画を複数の登場物（オブジエクト
）が並行に動作する系が可視化されたも客 のととらえ、この並行動作系が記述する。動画に釦いて
は各オブジェクトが完全に並行動作するのではなく、表
示画像の生成のため基準時間に拘束された疑似並行動作
となる（互いに関連のないオブジェクトどうしであって
も，他のオブジェクトの処理の進行を無視して自分の処
理を進めることはできない）。

動きの発生の表現とは、複数オブジェクトの動きの同期
の表現であり，いずれの方法でもオブジ，−クトの同期
のためにメ・ンセージ通信を用いている。

ＡＳＡＳ及びＰａｒａｄｉｓｅに会けるメッセージ通信
は異ったモデルに基づいてレリ、異なった機能を持って
いる。ＡＳＡＳでは、メッセージを受信したオブジェク
トは、メッセージ名から一意に定１る手続きを実行する
。メッセージの送信オブジェクト（あるいは、記述を行
う人）は、受信オブジェクトの行う動作を知っていて、
メｌセージ送信により仕事の要求を行う〔仕事要求通信
モデルと呼ぶ）。一方．Ｐａｒａｄｉｓｅでは、メソセ
ージ名から一意に定する手続きは存在せず、受信オブジ
ェクトぱメリセージの内容を自由に操作できる。メ・セ
ージ送信の目的は、メノセージ内のデータを伝える事に
ある。（データ通信モデルと呼ぶ）。

ストーリにのっとった動画（事故等の状況説明を行う動
画や、テレビゲームのような動画）を記述するためには
，メフセージ名とその効果が対応し、記述した通りの動
きが実現する仕事要求通信モデルが適する。

一方、交差点にふ・ける自動車の渋滞のシミュレーショ
ン等、個別に行動様式を持ったオブジェクトの自律的な
行動からなる動画を表現するには、他からの命令により
動作を行う仕事要求通信よりも、データ通信モデルが適
する。

く発明が解決しようとする課題〉 虫 上記のような従来の動画圭底方式では，単一のメノセー
ジ通信方式しか使用していないために、ストーりにのっ
とった動画にわいて、個々のオブジェクトがそれぞれ個
別の行動様式を持った自律的な行動をするとい−た動画
を容易に記述することができないという問題があった。

唸た、ストーリ展開そのものを含めたオブジェクトを統
一的に記述することができないという問題もあ−た。

本発明は、上述の問題点に鑑みてなさｉ″Ｌだものであ
って，仕事要求通信モデルとデータ通信モデルとの２種
類のメノセージ通信を可能とするとともに、ストーり展
開そのものをも含めたオブジェクトを統一的に記述する
ことができるようになすことによって、動画として表現
したい事象を時間に対して非決定的に記述でき，！たユ
ーザ孝び他のアプリケーションからの入力を簡単に記述
して処理できるとともに表現したい事象に関する変更が
最少限の記述の変更で可能な動画生成方式を提供するこ
とを目的としている。

く課題を解決するための手段〉 上記の目的を達成するために本発明は、登場物あるいは
ストーリなどの動画のオブジェクトを統一的に表現する
ためのアクタが特定の時間間隔を単位として疑似並行動
作を行うことによって動画を生成する方式であって，前
記アクタは，該アクタが表現するものの属性値を定義す
るための属性部と、前記属性値の変化の具合，あるいは
、前記アクタの状態や事象の底立などを他のアクタに伝
達するデータ通信のためのイベントの発信あるいはイベ
ントの読み込み、及び、他の特定のアクタに対して動作
指令を伝達する仕事要求通信のためソ のデマンドの送信を記述するものであるメ享ンドン 部より構成され，上記メ＃・ド部に記述された仕事要求
通信のためのデマンド及びデータ通信のだめのイベント
によってメッセージ通信を行いなから疑似並行動作する
過程を可視化するようになしたことを特徴とする動画生
成方式である。

く作　用〉 本発明による動画生戊方式に釦いては、表現しようとす
る登場物の物質等が属性部に記述されたアクタが、仮想
的な時間の単位である１ティノクソ 毎にメ手ソト部に記述された仕事要求通信のためのデマ
ンドとデータ通信のためのイベントによーてメ・セージ
通信を行いながら疑似並行動作する過程を可視化するこ
とができる。

く実施例〉 昔ず本発明に係る動画生戒方式の主な構成要素の既容を
説明する。

Ｉ，アクタ アクタぱ、属性とメソノドにより定義される。

１．１　　属性 属性は，アクタを表示するための形状（空間にふ・ける
）、位置や色等からなる。

表現したい動画に応じて速度や大きさ等任意の属性を定
義できる。

ｌ，２　　メソフド メソッドは、アクタの属性値の変化の仕方Ｃ動き）の記
述である。

メン・ブドぱ、以下で定義される。

メンノド名：メソフドを特定するための名前 仮引数並び：アクタ外部からのパラメタを受け取るため
の変数 状態変数並び：動きの状態保持を行う変数動きの記述：
逐仄、繰り返し，条件分岐の制の構造を用いて，属性値
の 変化の仕方，デマンド送信、 イベント発信、イベント読み 込みを記述する。動きの記述 は、起動時実行部分と通常実 行部分からなる。

２．　デマンドとイベント デマンド、イベント共にメ・フセージを他のアクタに届
けるために用いられる。第１図にアクタ間のメノセーズ
のやり取りを模式的に示す。

メノセーズとは、 メッセージ名、 と パラメタ並び からなる。

デマンドはアククヘメソノドの実行を要求スるメノセー
ジ送信であり、イベントは、他のアクタが参照可能なデ
ータをメフセージとして送信するものである。

デマンド送信，イベント発信ともに、アククのメソッド
に記述する。

２，　ｌ　　デマンド 第１図の一点鎖線４で表わしてあるデマンド送信では，
送信先アククを指定してメノセージを送出する。デマン
ドは、送信先アクタに釦けるメソッドの実行（あるいは
中止）を要求するものである。各パラメタ並びはメソッ
ドの引数に対応する。

■　実行要求 メンノドの実行を要求するデマンド送信はｓｅｎｄ　（
送信先アクタ名．送り主アクタ名．パラメタ並び） と記述する。

■　実行中止 すでにアクタで稼働中のメソＩドの中止を要求するデマ
ンド送信は、 ｋｉｌｌ　（送信先アクタ名．メ・フセージ名）と記述
する。

これらの、デマンドは送信先アクタのデマンドブール１
に入れられる。

アクタのメソソド記述中で、ｓｅｎｄやｋｉｌｌの引数
として送信先アクタ名を直接記述するのは、アクタの独
立性を低下させる。

このため、アクタ名はデマンドのバラメタから、あるい
はイベントから取り込むように記述する。デマンドの具
体的な構造を第８図に示す。

２．２　　イベント 第１図の破線５で表わされるイベントは，他のアクタヘ
データを送信したり，動作のタイミングを知らせたりす
るメソセージの送信である。

イベントは、受信オブジェクトを指定せずに発信され，
複数個存在可能な大域的なイベントプール３に保持され
る。イベントプール８内のイベントは，任意のアクタが
読み込むことができる。すべてのイベントは、ｌティソ
クにかけるすべてのアクタの動作が完了すると消滅する
。

■　イベント発信 イベントプールへのイベントの発信は ｏｕｔ　（イベントプール名．メッセージ名．パラメタ
並び） と記述する。

■　イベント読み込み イベントプールからのイベントの読み込みは ｉｎ（イベントプール名．パターン並び）と記述する。

ここで、パターンは値か変数であり，ｉｎは、並びの順
番とかりに合致する（値と値ぱそれらが同じ値なら合致
する。変数と値は常に合致する。）イベントをイベント
ブールから読み込む。イベントの読み込みにより、イベ
ントプールの内容は変化しない。パターンが合致するイ
ベントがイベントプールに存在しなければ、読み込みは
失敗する。パターンが合致するイベントが複数ある時に
は，それらの集合が読み込ｉｎる。実際の動きの記述言
語では、デフォルトのイベントプールヲ準備し，イベン
トプール名を指定しない発信や読み込みはデフォルトの
イベントプールに対する操作とする。

イベントプールぱ機能別に複数個用意することにより、
記述の容易さや可読性が向上する。複数のイベントプー
ルの存在を許すと、アクタのメソフドの記述中でｉｎや
ｏｕｔ　の引数としてイベントプール名を直接書き込ん
だ場合，アクタがイベントプールの存在に従属するとい
う問題（この問題はイベントプールが一つしか存在しな
ければ起こらない）が起こる。この従属性の問題はイベ
ントプール名をデマンドの引数として渡すか、イベント
から取り込むことにより解消する。イベントの具体的な
構造を第４図に示す。

３．　テイノク（ｔｉｃｋ） 直接並行処理が記述できない逐次型のシステム上で並行
処理を疑似的に実現するためにテイフクという概念を導
入する。これはある一定の時間に対応するもので，例え
ば１テイツクは１／６０秒というように自由に設定でき
る。システムは１テイフク毎にシナリオ、アクタ、ウオ
Ｊチャの実行を順次行っていくが、それらに関する全て
の処理が終った時点で、その結果を画面に反映させる。

これによって１テイＪク中の動きは全て同時に行なわれ
ている物として扱うことができる。例えばＡというアク
タとＢというアクタが動作を行う場合、システムの内部
ではどちらかのアクタが実行してから残りのアクタの実
行が行なわれるが、その結果７５；画面に現われるのは
同じタイミングなので、テイソクの幅かあ１り大きくな
ければ、各アクタが並行して動作しているように扱える
。

４．アクタの動作 すべてのアクタは１テイツク内に一度動作する。各アク
タは、そのアクタ宛に発せられたデマンドを保持するデ
マンドプールと，実行中のメソッド（プロセス）を保持
するプロセステーブルを持つ。ここで、プロセステーブ
ルは，デマンドにより起動されたメソッドをプロセスと
して登録してわり，プロセス登録されたメソッドは、ア
クタの動作の度に実行される。一つのメンソドが複数の
プロセスとして登録されることはない。各テイフクに釦
けるアクタの動作は以下の４．１．４．２である。

４．１　　デマンドブールの処理 ■　デマンドプールからデマンドを一つ取り出す。

●デマンドが何もなければ，プロセステーブルにあるメ
ソッドの実行４．２を行う。

●デマンドのメッセージ名に対応するメンツ■ ドが存在しなければ、そのデマンドを無視し，次のデマ
ンドの処理■を行う。

デマンドが実行要求の場合 ●プロセステーブルに対応するメソ・７ドのプロセスが
存在しなければ、そのメソッドの状態を「新規」として
プロセス登録する。

●対応するメソノドのプロセスが存在して訃り、 ■ ・その状態が「新規」でなければ、そのプロセスの終了
処理を行った後，デマ ンドに従って新規登録する（複数のプ ロセスが同一のメソノドを実行するこ とを禁止する）。

・その状態が「新規」であれば（向じデマンドが複数到
着している場合）、何 もしない（最初に処理されたデマンド を優先する）。

●次のデマンド処理■を行う。

デマンドが実行中止要求の場合 ●プロセステーブルに対応するメン・Ｖ　｝”　＋７）
　７”ワセスが存在する場合 ・プロセスの状態が「新規」でない場合はプロセスの終
了処理を行う。

・プロセスの状態が「新規」の場合は何もしない（実行
要求デマンドを優先す る）。

●次のデマンドの処理■を行う。

４．２　　プロセステーブルにあるメソフドの実行の　
プロセステーブルの各プロセスに対して以下の処理を行
う。

●プロセスの状態が「新規」のものは、メソッドの動き
の記述部の起動時実行部分を実行したのち、プロセスの
状態を「通常」にする。

●プロセスの状態が「通常」のものは、メソソドの動き
の記述部の通常実行部分を夾行する。

以上の説明で明らかなように、アクタは他のアクタから
独立して単独動作可能である。またデマンドやイベント
によるメッセージ通信は他のアクタの存在を仮定してい
るが各アクタの動作には従属関係はない。

さて、上述の各構成要素を用いて動画のストーリを構築
するために、アクタをストリーを記述スるためのシナリ
オ及び実際の登場物を表現するキャラクタ、キャラクタ
の動きや事象の発生を監視するためのウオ゜Ｊチャに分
ける。以下各々について説明する。

Ｉ，　シナリオ シナリオは、動画のストーりを表現するアクタである。

通常のアクタが画面上での色々な動きを行う登場物とし
て再利用可能な部品であるのに対して，シナリオは表現
したい動画毎に記述するものである。

■　シナリオの属性 シナリオは属性として、 ●動画へ登場するキャラクタ，ウォ・チャ●イベント送
信に使用するイベントプールを持つ ■　シナリオのメソッド シナリオのメソノドでは動画のストーりを表現する。す
なわち，属性として登録してあるキャラクタ、ウオ゛ノ
チャに、どの様なタイミングで、どの様なデマンド送信
を行うか，という記述を行う。シナリオの各メソッドは
動画の１シーンを表現するものであり、複数のメン・ド
の同時動作は行わない。

ンナリオに従ってキャラクタ，ウオッチャを動作させる
には シナリオの動作 キャラクタ、ウオフチャの（可能なら並行）動作 ■　ティソクを進める を繰り返す。ただし、シナリオの送信するメノセージは
送信されたテイノクに釦いて処理対象トなり、キャラク
タ、ウオ・１チャの送信したメノセージは送信された次
のテイフクに釦いて処理対象となる。シナリオの記述例
を第５図に示す。

２．　キャラクタ キャラクタは映画で言うところの登場人物及び登場物に
相当する。キャラクタはさらに構造を持ち、各部分に相
当するサブキャラクタの集合として捉えることができる
。例えば、人間というキャラクタは腕．足．胴体．頭と
いうサブキャラクタから構成され、さらに頭は目．鼻．
口などのサブキャラクタから構成されるという構造を持
たすことができる。これらの構造はユーザが状況に応じ
て自由に構戒することができる。キャラクタは基本的な
動きのルールを持っている。しかし、キャラクタが自発
的に何らかの動作を行うことはな〈，常にシナリオ又は
上位のキャラクタからの司令によってのみ動作を始める
ことができる。會た、キャラクタは外界から情報を入手
してそれを元に判断を下して動作を変更したりすること
は無く，シナリオから動作の変更，停止の指示を受けて
動〈。第６図にキャラクタの記述例を示す。

キャラクタはそれぞれ一涸ずつ、プロセステーブルとデ
マンドプールを持つ。メソＪドの開始終了はデマンドプ
ールに送られてきたデマンドにより行われ，起動された
メソノドはプロセスとしてプロセステーブルに登録され
る。プロセステーブルは現在実行中のプロセスを管理し
ており、メソッド名やその引数の他、プロセスｉｄ（プ
ロセステーブル上のプロセスが記述されているアドレス
を用いる）、同一キャラクタ内あるいはサブキャラクタ
のメソッドの起動・被起動関係を示す親ポインタ・子ポ
インタ，状態を示すｓｔａｔｅ　ｂなどの情報を含んで
いる。

デマンドプールはキャラクタに対して送られてきたデマ
ンドを一時蓄えてわく所で、メソフド名．引数．状９　
（ｓｔａｔｅ　）．デマンド発信者名（ｆｒｏｍ）、メ
ソッド実行時刻（ｗｈｅｎ）．などの情報を含む。

このプロセステーブルとデマンドプールとの関係を第８
図に示す。同図に会いて８１がプロセステーブルを表現
している。プロセステーブルは要素からなる。メソソド
名８８には、メン・ドの名前が文字列で格納される。デ
マンドによってメソノドの立ち上げを指示する場合、こ
の名前で指定する。メソＪドの状態８４は、現在このメ
ソＪドがどのような状態にあるのかを示す。状態には以
下の３種類がある。

ＳＴＡＲＴ デマンドによってメン・プドを立ち上げるよう指示があ
った。すなわち、今口ｃｋにおいてこのメソッドを１つ
のプロセスとして起動する。

ＲＵＮＮＩＮＧ すでにメソノドぱプロセスとして実行されて現在も走行
状態である。

ＥＮＤ メソフドは終了状態で、今ｔｉｃｋにおいても実行は行
われない。

親プロセス８２は、メソノドはシナリオ、又は他の（自
分自身を含む）アクタからのデマンドによって起動され
る。このメソブドがどのプロセスによって立ち上げられ
たかを示すものである。子プロセス８５には、プロセス
中で他のメソノドを立ち上げた場合，そのメソッドを登
録しておく。

例えば人間の「走る」というメソフドが「手を振る」と
いうメソソドと「足を前後に出す」というメソッドの組
合せで実現されているとき「走り出せ」というデマンド
がシナリオから発せられた場合、第８図の（ａｌ，　ｆ
ｂｌ．　（ｃｌの順に推移する。最初にシナリオから「
走る」というデマンドが出力される。アクタはそのデマ
ンドをうけて，「走る」というメソノドの状態をＳ（Ｓ
ＴＡＲＴ）にし、その親プロセスとしてシナリオを登録
する。「走る」というメソッドの中から自分自身に対し
て「手をふる」と「足を動かす」というデマンドが出力
される。アクタは次のｔｉｃｋにこのデマンドを受けて
％２つのメソッドの状態をＳにする。これらのメソッド
は「走る」というメソッドから起動されたものなので、
３者間には図のような親子関係が登録される。このあと
、「走る」というメソフドが終了したなら，その親子関
係をたどって「手をふる」というメソノドと「足を動か
す」というメソノドは終了する（状態がＥＮＤになる）
。

３．　ウオッチャ シナリオはキャラクタの動作を見てなんらかの判断を下
すことが多い。そこで常に関係するキャラクタを監視し
、指定された条件を満すような事態が起ったときにだけ
シナリオにその旨を連絡するウオノチャを設ける。各ウ
オンチャのデマンドプールに届けら力、たデマンドに従
いメソノドの実行や，開始終了を処理する。ウオッチャ
はイメージを持たないこと以外はキャラクタと構造的に
ほぼ同一であるが、キャラクタのプリミティブな属性を
見ることができ、キャラクタの動きを監視して，キャラ
クタがある状態になったときにシナリオにイベントを送
ったり、キャラクタにデマンドを送るといったことを行
う。ウオノチャの記述例を第７図に示す。

以上シナリオ．キャラクタ．ウオ・フチャについて個々
に説明してきたが、ここで３者のメソセージ通信の関係
を第９図に示す。第９図に釦いて、符号４はデマンドを
，５−ぱイベントを表わしている。

ヂマンドは送り先を指定した１対１通信で、シナリオ９
１、アクタ９２、ウオＪチャ９８のいずれもが出力する
ことができる。シナリオはアクタ，ウオ・ンチャに対し
てデマンドを送ることができるが、アクタ及びウオノチ
ャがデマンドを送ることができるのはそれぞれアクタ、
ウオ・ノチャに対してのみである。イベントはシナリオ
、アクタ、ウオノチャのいずれもが出力することができ
，送り先は指定しない。

第１０図にはメノセージ通信の関係をユーザに１で拡大
した場合を図示してある。

外部１０１（ユーザや他のアプリケーションシステム）
からの入力と同期して動く動画は、動くマニュアルやコ
ンピュータゲーム，あるいはプラントのモニタ制御を行
うパネル等に応用できる。

上記のモデルで外部１０１と同期する動画を記述するに
は、外部交信専用のアクタを定義する。外部交信専用の
アクタは、１テイツク毎の動作で、外部からの入力を解
釈し、その結果をイベントとして発信、あるいは適当な
アクタヘデマンドとして送信する。ｉた，イベントプー
ルの状態を解釈し、外部へ適当なメ・フセージ出力を行
う。こハにより動画記述にわける外部との交信部分を局
所化できるとともに、動画の溝戊要素のすべてを統一的
に記述することが可能となる。

以上、シナリオ及びキャラクタ、ウオノチャ各々の機能
及び記述方法について説明した。

さて、第５図．第６図．第７図のように記述して作或さ
れたキャラクタ記述ファイル１１１と’７オノチャ記述
ファイル１１８は、第１１図に示すように、それぞれキ
ャラクタ記述言語解釈部１１４及びウオッチャ記述言語
解釈部１１５によってコンパイルされてキャラクタライ
ブラリ１１６及びウオソチャライブラリ１１７に保存さ
れる。一方シナリオ記述ファイル１１２はシナリオ記述
言語解釈部１１８によってキャラクタライブラリ１１６
及びウオッチャライブラリ１１７から必要なキャラクタ
，ウオッチャの情報を取り出しながらコンパイルされて
実行ファイルである動画制御プログラム１１９が作或さ
れる。この間の処理の流れを第１２図に示す。

こうして作或された動画制御プログラム１１９は動画生
戊実行部１２１によって、必要に応じて入力装置１２０
から入力されるユーザからの入力を受けながら処理され
て、ディスプレイ１２２に動画が表示される。

以下に動置生成実行部１２１による動画生成処理手順を
説明する。

処理手順は第１３図に示すように起動Ｃ初期化）１８１
、シナリオ処理１８２、キャラクタ処理１３８、ウオリ
チャ処理１８４，タイミングチェフク１３５の順に各々
処理された後ディスプレイ１２２への表示処理１８６を
行って、停止条件チェソク１８７を経てシナリオ処理１
８２へ戻る。

以上のループ処理を停止条件が満たされる筐で繰り返見
す。

各処理の詳細を説明する。

ｌ．起動（初期化） 起動（初期化）１８１は，シーンの初期化と動画の開始
処理を行う。動画をスタートさせるにはプログラムを起
動し，初期画像が現れたところで入力装置１２０から開
始コマンドを入力する。動画はキャラクタの動きとシー
ンの切り替えにより展開されるが、必要に応じて開始シ
ーンの指定やキャラクタの初期設定の変更ができる。特
に指定がなければデフォルド値ヲ用いる。プログラムが
起動されると、キャラクタテーブルが用意され、テーブ
ルにデフォルト値（Ｊｔは指定値）が代入され、これに
基づいて初期画像が描画される。

キャラクタテーブルとは１つのキャラクタが幾つかのサ
ブキャラクタの集合として構威されているとき、その構
成要素であるサブキャラクタの一覧表にあたる。具体的
には第１４図に模式的に示したようなサブキャラクタの
名前の一覧表である。例えば人間というキャラクタは頭
、胴体、両手、両足というサブキャラクタの集合体であ
ると定義したなら人間キャラクタのキャラクタテーブル
には頭、胴体、両手、両足が登録される。さらに頭とい
うサブキャラクタを目、耳，口２鼻、髪からなると定義
すればさらに階層的な構造をとることができる。

２．　シナリオの処理 シナリオの処理１８２ぱ条件部のチエ・フクと実行部の
評価すなわち実行とに分けられる。

２．１　　シナリオ条件部の処理 １ｔｉｃｋ＠のイベントと現在時刻のイベントがイベン
トプール上で干渉するのを防ぐため，１ず全でのｉｆ文
の条件部が評価され、ｉｆ文に実行フラグが立てられる
。その後、イベントプールをクリアして．実行フラグの
立っているｉｆ文はシナリオ実行部の処理に制御が渡さ
れる。

２．２　　シナリオ実行部の評価 シナリオ実行部ではシナリオ条件部で実行フラグが立て
られているｉｆ文のステートメントを評価する。シナリ
オ条件部評価の結果ｉｆ文に立てられた実行フラグを参
照しながら．シナリオ実行部を評価してゆく。シナリオ
実行部ではｏｕｔ文によるイベントプールへのイベント
送信、ｓｅｎｄ文ｒ　ｅｍｏ　ｖ　ｅ文によるキャラク
タのヂマンドプールへのデマンド送信などを行いシナリ
オやキャラクタを制御する。デマンドプールはシナリオ
条件部の評価が全て終わった時点でクリアされ、前のｔ
ｉｃｋのイベントは残っていない。新たにプールに書き
込まれるイベントは次のｔｉｃｋで評価されるべきもの
とする。

３．　キャラクタの処理（メソノドの実行）各キャラク
タのデマンドプールに届けられたデマンドに従い、メソ
ッドの実行や，開始終了を処理する。キャラクタの処理
に釦けるメソノド実行時刻はｔｉｃｋによる時刻を用い
、システムはグローバルに与えられるｔｉｃｋ時刻を参
照しながら、メソ１ドの発火時刻を判断する。

つのキャラクタは、まずデマンドプールヲ調べ，現在時
刻に釦いて実行可能なデマンドを全てプロセステーブル
に書き込み、続いてプロセステーブル上のメソッドを笑
行するという手順で処理が行われる。これが終わったら
別のキャラクタについて同様のことを行い、全部のキャ
ラクタについて処理が終わったところでウオッチャの処
理に移る。

４．　ウオッチャの処理 ウオッチャの処理１３４は，ウオッチャの構造がキャラ
クタと同じであるため，その処理はキャラクタに準じる
０ ５．　タイミングのチェック 先に説明したように，本システムはｔ　ｉｃｋという時
間概念によりｌｔｉｃｋｌサイクルを繰り返している。

このｔｉｃｋ数をもってメフセージの発火時刻などの制
御を行っているが実時間換算の単位時間ＡＪｔ−１　ｔ
ｉｃｋ　（第１５図ｖｃレいて符号１５１で表わしてい
る。）が別に定めている。システムは直前に表示１５２
を行ってから現時点渣で実際に経過した時間ａｐｔ１５
８を計測してシリ、この値とＡＪｔ　との比較により表
示のタイミングを制御する。すなわちｄｐｔ（ＡＪｔの
場合にはｄｐｔ−ＡＪｔとなる１で待ってから表示処理
１８６に制御を渡す。

またｄｐｔ≧Ａｌｔの場合には１３２から１３５までの
各処理が済みしだい表示処理１３６に制御を渡す。

なか，表示のｎ倍早送りはＡｊ２ｔの間にｎサイクルの
処理を行い、表示処理のみｎサイクル目に行うことによ
って行う。

６，表示１３６ キャラクタテーブル上のキャラクタのうちから必要に応
じて位置と形状の情報を読み取−てディスプレイに表示
する。

７．停止条件のチェフク１３７と停止処理１３８ｌサイ
クルの終りにユーザからのイベンドを取り込み、停止イ
ベントが来ていたら動画を停止させる。１た停止イベン
トが来ていなくても、●イベントデールにイベントが一
つもない●実行中のプロセスを持つキャラクタが一つも
ない ●アクティブなキャラクタに一つもデマンドが来ていな
い 場合には停止処理１３８が実施されて、表示は停止する
。

〈発明の効果〉 以上に説明してきたように本発明によれば、動画を登場
物の疑似並行動作系ととらえ，他に従属せずに動作する
独立性の高いアクタを属性部とメソノド部によって定義
し、このアクタの動きの同期のためにデマンドとイベン
トという２種類の通信機能を設けたことによって，動画
として表現したい事象を時間に対して非決定的に記述で
き、筐たユーザ及び池のアプリケーションからの入力ヲ
簡単に記述して処理できるとともに表現したい事象に関
する変更が最少限の記述の変更で可能な動画生成方式を
提供することができた．，１た，汎用性の高いアクタを
部品化してライブラリに保存することによって、動画の
構成要素を容易に再利用することができるようになった
。

【図面の簡単な説明】

第１図は本発明の動画生成方式のメフセージ通信の説明
図，第２図は動画例を表わす図、第８図はデマンドの構
造を表わす模式図、第４図はイベントの構造を表わす模
式図、第５図はシナリオの記述例を示す図，第６図はキ
ャラクタの記述例を示す図，第７図はウォソチャの記述
例を示す図、第８図はプロセステーブルの説明図、第９
図及び第１０図は本発明の実施例のメッセージ通信の説
明図，第１１図及び第１２図，第１３図は本発明の実施
例の処理手順の説明図、第１４図はキャラクタテーブル
の説明図、第１５図は表示周期の説明図である。 １・・・デマンドプール、１２・・・アクタ，３・・・
イベントプール、４・・・デマンド通信、５・・・イベ
ント通信。

Claims (1)

1. 【特許請求の範囲】 １、登場物あるいはストーリなどの動画のオブジェクト
   を統一的に表現するためのアクタが特定の時間間隔を単
   位として疑似並行動作を行うことによって動画を生成す
   る方式であって、 前記アクタは、 該アクタが表現するものの属性値を定義するための属性
   部と、 前記属性値の変化の具合、あるいは、前記アクタの状態
   や事象の成立などを他のアクタに伝達するデータ通信の
   ためのイベントの発信あるいはイベントの読み込み、及
   び、他の特定のアクタに対して動作指令を伝達する仕事
   要求通信のためのデマンドの送信を記述するものである
   メリッド部より構成され、 上記メリッド部に記述された仕事要求通信のためのデマ
   ンド及びデータ通信のためのイベントによってメッセー
   ジ通信を行いながら疑似並行動作する過程を可視化する
   ようにしたことを特徴とする動画生成方式。