【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、コンピュータを用いて３−Ｄシーンから得られる、レンダリング２−Ｄ画像製作のためのシステムに関する。 更に特定すれば、本発明は、ユーザに３Ｄシーン・データを更新させつつ、
同時に当該３Ｄシーンを連続的に更新した現実的レンダリングを表示する、オーサリング環境（authoring envi
ronment）を生成するシステムに関するものである。

【０００２】

【従来の技術】ムービーやコンピュータによって作成した美術作品においてしばしば見られるように、最近のコンピュータ・グラフィックスは、複雑な３−Ｄデータから得られる二次元（２−Ｄ）画像または画像シーケンス（ムービー）で構成する。 ３−Ｄシーン・データは、シーン内の各オブジェクトの３−Ｄ座標を含む。 シーンから得られる画像は、実際の３−Ｄオブジェクトの現実的表現を示すことを意図しているので、シーン・データは、各オブジェクトの表面およびボリューム・プロパティを表す、「シェーダ」（shader）と呼ばれる定義を含む。 シェーダは、光がオブジェクトによってどのように反射し、屈折し、更に散乱するかについて指示を与える。 また、シェーダは、空間のボリューム（例えば、煙のパフ）、またはシーン環境全体について定義することもでき、後者を環境シェーダと呼ぶ。

【０００３】現実的な画像（realistic image）を作成するためには、３−Ｄシーンにレンダリングを行う。 レンダリングのプロセスは、カメラの視点から見ることができる各画素の外見を決定する、レイ・トレーシング（ray tracing）を伴う。 レイ・トレーシングにおいて、シーン内における種々のオブジェクトおよびボリュームによる掩蔽、拡散および鏡面反射、屈折、および光の拡散の効果を決定する。 レイ・トレーシングは、光源から直接到来する光の反射、屈折および拡散である一次的効果だけでなく、二次的な反射も処理の対象とする。
後者は、他のオブジェクトからの一次光が、あるオブジェクトまたはボリュームを照明するかあるいは通過するときに得られる。 これらの二次効果は、元の光源とカメラとの間に多数の反射、屈折、または透過を伴う可能性があるので、画面内のあらゆる画素について光線をトレースしなければならないことを考慮し、更に、シェーダによっては、複雑な数値アルゴリズムを伴うものがあることも考慮すると、現在のコンピュータ技術では、レンダリングのプロセスに費やす時間は非常に長くなる可能性がある。

【０００４】図２を参照して、著作者が３Ｄシーンを作成し編集する際、著作者は３Ｄオブジェクトを定義するシーン・データを編集する。 典型的に、著作者に与えられるフィードバックは、シーンの非現実的なワイヤ・フレーム・ビュー（wire-frameview）である。 典型的な編集環境では、（表示画面１０上に）透視ワイヤ・フレーム・ビュー（perspective wire-frame view）４０を別個のウインドウ内に示すことができる。 別のワイヤ・フレーム・ビュー、例えば、平面図６０も示すことができる。 ワイヤ・フレーム・ビュー４０，６０は、オブジェクトを投影図３０，５０として見た場合、またはオブジェクトを平面図で見た場合のオブジェクトを示す。 また、編集環境の一部を形成するものに、シェーダやシーン内のその他のプロパティを定義するために用いる種々のツールがある。 例えば、あるオブジェクトを選択し、
シェーダ・エディタ２０を呼び出して、選択したオブジェクトに適用するシェーダの定義または修正を行う。 シェーダ・エディタは、オブジェクトの種々のシェーダ・
プロパティを調節する種々の制御部２５を有する。 シーン内で定義した種々のオブジェクトは、例えば、フレーム・ワイヤ上の制御点を用いることによって、移動させたり、それらのサイズを調節することも可能である。 また、ワイヤ・フレーム・ビューは、いわゆる「３Ｄマニピュレータ」の表示やその編集を可能にし、非物理的オブジェクトや３Ｄ属性を有する効果の編集を可能にする。 例えば、対応する３Ｄマニピュレータを操作することによって、光源の投射の円錐のサイズを変更したり、
移動させたり、回転させることができる。

【０００５】

【発明が解決しようとする課題】前述のオーサリング（または編集）コンテキスト（context）において作業している間、著作者は、ほぼリアル・タイムで、変化のいくつかの効果を見ることができる。 例えば、オブジェクトのワイヤ・フレームを動かすと、ワイヤ・フレームの画像は、直ちに更新される。 しかしながら、アーティストの作品のレンダリング効果を見るためには、アーティストは、シーン・データのレンダリングを要求しなければならない。 これは、ユーザ・インターフェースのコンテキストをプレビュー・コンテキスト７０に変更するが、その中では著作者は編集ツールから切り離されてしまう。 一旦著作者がレンダリング画像を待ちそして検査したなら、著作者は編集コンテキストに戻り、オブジェクト・マニピュレータ、シェーダ・エディタ等にアクセスすることができる。 この状況では、アーティストは１
つのコンテキスト、即ち、編集コンテキストにおいて作業し、別のコンテキストにおいて実際の画像を見ており、完全で即座のフィードバックをアーティストに与えるのではないので、障害（limiting）となる可能性がある。 例えば、歩く恐竜をモデリングし、皮膚のテクスチャに微妙な調節を行おうとする場合を想像してみる。 著作者は、皮膚がどのように見えたかを思い出し、いくつかのパラメータを引っ張り（tweak）、その結果を検査しなければならない。 編集環境によっては、著作者が多数の画像を格納し、それらを例えば別のフレームワーク、画像ビューアまたはエディタ内に並置することを可能にするものもある。 しかしながら、これは、編集のプロセスの低速化を招き、しかも著作者に多数の工程および異なる環境を行き来させることになる。

【０００６】現在、２Ｄ描画およびビットマップ編集プログラムならびにワード・プロセッサでは、開発者は、
修正の結果を殆ど直ちに示す環境で作業することができる。 これは、いわゆる「見ているものが得られるもの」
（WYSIWYG:what-you-see-is-what-you-get）機構である。 一見したところでは、複雑な３Ｄモデルを用いて作業するグラフィック・アーティストやアニメータにこの機構を提供することは、望ましいように思われるかもしれない。 しかしながら、レンダリング・プロセスは、著作者にこのような重要な情報を提供するものであり、非常にコンピュータ集約的なため、現在および近い将来（near term）のハードウエア技術の限界を考えると、
仮説的なＷＹＳＩＷＹＧ環境ではその処理能力は容認できない程に低下する。 画像が更新されるまで待つのでは、著作者が遂行する各工程間に遅れが生ずるであろう。

【０００７】一方、３Ｄシーンについては、従来のオーサリング環境は、ＷＹＳＩＷＹＧ環境において得られるものよりは、いくらか勝っている。 ワイヤ・フレーム・
ビューやオブジェクト・プロパティ定義ツールが、シーンに関する抽象化した情報を表示し、場合によっては、
現実的レンダリング以上の情報を与える。 例えば、レンダリングでは殆ど見ることができない３Ｄ属性を有するオブジェクトが、ワイヤ・フレーム・ビューでは明確に見ることができる。 また、ワイヤ・フレーム・ビューは、透視図を作成する際に有用となり得るガイドを示すこともできる。 レンダリングしたビューは、オブジェクトの境界において殆どコントラストを含まない場合が多い。 これは、ワイヤ・フレーム・ビューでは問題とならない。 したがって、ＷＹＳＩＷＹＧを３Ｄ編集環境に持ち込むというアイデアは、非実用的に思われるだけでなく、何らかの犠牲も伴うように思われる。 本発明は、従来技術のこれらの欠点双方に対処しようとするものである。

【０００８】

【課題を解決するための手段】コンピュータ３Ｄモデリングおよびアニメーション・システムは、アーティストに３Ｄシーン・データの変更を行わせつつ、同時に著作者に当該変更に対応するレンダリング画像を視認させるユーザ・インターフェースを与える。 実際、これは、Ｗ
ＹＳＩＷＹＧ環境のある種の利点を３Ｄモデリングおよびアニメーション・システムにもたらす。 前述のシステムは、通常３Ｄ編集コンテキストに伴う全ての編集ツール、および自動的に更新するレンダリング画像（render
ed image）を与えることができる。 これは、以下のデバイスの組み合わせによって達成する。

【０００９】１． レンダリング画像のフレームを複数の部分に断片化する。 シーン修正を入力し、古いレンダリングがメモリ内にある場合、再度レンダリングを行わなければならないレンダリングの部分のみを、ユーザ・インターフェースのサポートと並列に走るレンダリング・
タスクに引き渡す（submit）。 本発明の一実施形態では、レンダリングの下位部分（subportion）は、タイルと呼ばれる、隣接する規則的な形状である。

【００１０】２． レンダリングを維持するシーンの部分を、本発明の機構および実施形態にしたがって、種々の方法で正確に定義することができる。 例えば、ワイヤ・
フレーム図上にボックスを配置し、レンダリングすべきシーンのビューの正確な部分を定義することができる。
レンダリングの主題を更に狭めるために、特定のオブジェクトを識別し、残りのオブジェクトはレンダリングせずに放置しておくことも可能である。 このように、レンダリングの主題は、著作者が集中する特定のタスクに合せて自在に作成することができる。

【００１１】３． ユーザ・インターフェースは連続的にシーン修正を受け入れ、著作者の作業に応答して、ワイヤ・フレーム・ビューのような抽象化画像を更新する。
このユーザ・インターフェースの支援アクティビティは、高い優先度で独立して実行するので、レンダリングを更新する「背景」タスクによる低速化が生じない。 ユーザ・インターフェースは、レンダリングを完了するためにＣＰＵ時間が得られるようになるまで、レンダリングの古い部分を空白化することができる。 あるいは、古い構成（feature）を上書きし、各変更の前および後のレンダリングを、直ちに時間的に並置することも可能である。 尚、並列プロセッサ・システムでは、優先順位を決めることなく、単一プロセッサ・システムにおけるように、優先順位を決めずに同じ結果が得られることを注記しておく。

【００１２】４． シーンの修正に応答してレンダリング・プロセスを制御する前に、この修正をチェックし、これらがレンダ領域ビューにおいて何らかの視認可能な差異を明示するか否かについて判定を行う。 変更が当該領域内においてレンダリング画像に何ら変更を明示しない場合、レンダリング・プロセスを中断せず、レンダリング・プロセスに対する指示も行わない。

【００１３】５． レンダリング画像の構成部分は、更新に必要なレンダ領域の部分を再度レンダリングし終わるまで、順次背景タスクとして再度レンダリングする。 各部分のレンダリングを完了すると、その部分をレンダ・
キャッシュに引き渡し、レンダリング・プロセスと並列に走る別の高速背景プロセスが、キャッシュ内のタイルに彩色する。

【００１４】７． レンダリングが完了したなら、レンダリングしたタイルをキャッシュに格納する。 ８． キャッシュから有効なタイルを検索し、これらのタイルを検索しつつ彩色することによって表示をリフレッシュし、ユーザが入力したシーンの変更とレンダリング画像の表示との間の同期性（synchrony）を維持する。

【００１５】９． ユーザ定義の更新がこれらのタイルを無効化した場合、タイルのレンダリングを中断する。 １０． ユーザ定義の更新が、キャッシュ内に格納してあるタイルを無効化した場合、キャッシュの消去（empt
y）即ち無効化を行う。

【００１６】１１． 上述のタスクをマルチスレッド化し、ユーザの入力のエンティティにしたがって、ステップ［３−４−９−１０］またはステップ［３−４］で定義したシーケンス、ステップ［５−６−７］およびステップ［８］を独立して（非同期に）実行する。

【００１７】本発明は、３Ｄオーサリング・システムのコンテキストにＷＹＳＩＷＧＹを完全に実施する場合に以下の障壁があることを確認した。 （１）画像のレンダリングを行うのに要する時間は非常に長いので、現実的画像を表示するオーサリング・システムでは、各変更の後にレンダリングの更新を行う間著作者を待たせることになり、このようなシステムは非実用的である。 （２）
３Ｄシーンの作業を行うために必要な３Ｄマニュピレータの少なくともいくつかが、レンダリング画像のオプションを見えなくする。 あるいは、３Ｄマニュピレータの少なくともいくつかがこれらのオプションによって見えなくなり、シーンを編集することが難しくなる。 例えば、あるオーサリング・システムは、３Ｄマニピュレータおよび制御点を用いると、限定的な（少なくともワイヤ・フレームよりは現実的であるが、レンダリングという言葉と関連する計算集約的なレイ・トレーシングを行わない）レンダリング機能を行うだけとなる。 更に、３
Ｄ編集は非常に抽象的なプロセスであるので、従来技術はＷＹＳＩＷＹＧコンテキストを積極的に導入していない。 著作者が関係することの多くは、ビューアの目に向けられる光を変化させる、見えないオブジェクトである。 例えば、表面テクスチャ、ボリューム・シェーダ（例えば、霧や雨を表現するために用いるような、空間を通過する光の透過、散乱、および反射を修正するシェーダ）等は、レンダリングにおけるよりはむしろ、ワイヤ・フレームまたは制御パネルと同様、シーンの抽象的なビューにおいてより良い表現が得られる。 したがって、３Ｄオーサリングでは、ＷＹＳＩＷＹＧに対応するレンダリングは、オーサリングのプロセスとは別個と見なされるため、編集環境を除いて通常は不自由でない。

【００１８】本発明は、編集を妨害しない、レンダリング・ビュー（rendered view）を与える編集環境を作成する。 即ち、編集環境に通常関連する編集ツール全てに対するアクセスを可能とする。 編集環境はなおも３Ｄシーンの作業を行う際に有用な、抽象的ビュー、３Ｄマニピュレータ、および制御点を与えかつ維持する。 重要なことは、編集ツールへのアクセスが、レンダリング・プロセスの完了を待つ必要性によって阻害されないことである。 また、重要なことは、オーサリングのコンテキストにおいて実施するレンダリング・プロセスは、オーサリング・コンテキストと互換性があるものとして識別した、ある種のショートカット（shortcut）を定義し、実装することによって、従来のレンダリング・プロセスよりも更に迅速にプロセスを進行させることができる。 更に、オーサリング・コンテキストにおいて利用可能なレンダリングは、追加の工程やコンテキストの変更を必要とせず、しかも完全に自動である。

【００１９】上述の特徴は、多数のデバイスによって可能となる。 その内のいくつかを用いてもよく、いくつかを用いなくてもよく、それでもなお本発明の特徴の少なくとも一部分（subset）を提供する。 第１に、編集環境によって、著作者は、レンダリングするシーンの特定領域を指定し、更新することができる。 この領域は、例えば、著作者が作業中のシーンの特定の部分に対応する。
以下で説明するように、レンダリングは、自動的かつ連続的に行われ、しかも編集用ビュー（例えば、ワイヤ・
フレーム）を更新するプロセス、編集データの受け入れ等に対して非同期的に行われる。 したがって、特定の領域は、常に、（レンダリング・プロセスが著作者について行ける範囲において）著作者の原稿の編集に対応するレンダリング・ビューを示す。 好適な実施形態では、この領域は、ウインドウとして定義することができ、透視ワイヤ・フレーム・ビュー上で直接サイズの変更や再位置決めを行うことができる。 あるいは、この領域は、あるオブジェクトのシルエットに対する（subtend）視野のエリアとすることができる。 この場合、オブジェクトを選択し、オブジェクトの背景ではなく、その寸法データを用いて、その領域を定義することができる。

【００２０】レンダリングした領域は、例えば、冗長的な透視ワイヤ・フレーム・ビューの上に表示することができる。 これによって、著作者は、レンダリング・ビューを、ワイヤ・フレーム・ビュー内に表示した情報と比較し、相関付けることができる。 実際に、領域をワイヤ・フレーム・ビューの小部分として定義し、その上に直接重ね合わせることによって、著作者はレンダリング・
ビューについての展望を得ることができる。 これは、完全なレンダリング（full rendering）では、さほど容易に得ることはできない。 即ち、例えば、あるシーンの中の背景オブジェクトと前景オブジェクトとの間の色差またはコントラストが非常に低いことを想定し、更にこれらのオブジェクトが部分的にレンダ領域内まで達し、部分的にレンダ領域の外側まで達することを想定する。 このようなオブジェクトのワイヤ・フレーム画像は、（あらゆる制御点、および光源の投射の人工的な円錐のような、見えないコンポーネントと共に）明確にしかもコントラストが高く現れる。 同じオブジェクトのワイヤ・フレームとレンダリング画像との隣接性（adjacency）
は、著作者の適応力（orientation）、および著作者がレンダリング画像で見るものと著作者がワイヤ・フレーム画像で見るものを相関付ける能力を高めることができる。

【００２１】前述のように、レンダ領域におけるレンダリング画像の存在は、編集コンテキストに用いる編集ツールへの著作者のアクセスを全く妨害しないことを特記しておく。 著作者は、編集コンテキストに通常関連するあらゆる編集ツールにアクセスしつつ、同時にレンダリング領域（rendered region）を見ることができる。 また、コンテキストはそれでも、３Ｄシーンの作業を行うのに有用な抽象化したビュー、３Ｄマニピュレータ、および制御点を与えかつ維持する。 実際、これら同一の抽象化ビューは、レンダリング画像の抽象化画像との並置によって、一層効果的となる。 即ち、レンダリング画像を対応するワイヤ・フレーム画像の隣に置くことによって、例えば、著作者は、現実的画像においてシーン修正の効果を容易に見ることができる。 更に、変更を行う毎に、例えば、色に細かい調節を行う毎に、著作者はシーン修正の結果として、未編集シーン（または主題）の変化を見つつ、その領域を視認することができる。 即ち、
著作者は、時間的に並置して新旧のレンダリングを見ることができる。 これは、微調整を行う際に非常に役に立つ（conductive）。

【００２２】本発明は、他の編集プロセス、例えば、ワイヤ・フレーム・ビューのリフレッシングやシーン修正の入力に対して非同期的に、レンダ領域を更新するプロセスを行う。 通常の編集環境プロセスには、したがって、レンダ領域のリフレッシングよりも高い優先度を与えることができる。 更に、領域のリフレッシングは、従来のレンダリングよりも素早く行うことができる。 何故なら、レンダリングは、著作者に直接関与する小さな面積の領域に限定されるからである。

【００２３】好適な実施形態では、レンダリングを更新する速度は、レンダリングを必要とする領域の部分を識別し、再度レンダリングすることによって更に高められる。 例えば、あるオブジェクトの表面のテクスチャに変更を加える場合、オブジェクトの一次および二次レイに対応する領域の部分のみに再度レンダリングすればよい。 領域の他の部分は、そのまま、放置しておけばよい。 また、本発明は、更に別の特徴として、ある種のショートカットの使用を可能にする。 例えば、著作者が選択的に、全ての光源を面光（area light）ではなく、点光源として指定することを可能にする。 これによって、
レンダリングの大幅な高速化が可能となる。 これは、修正可能なデフォルト・プロパティとして実装することができる。

【００２４】オーサリング・コンテキストにおいて使用可能としたレンダリングは、追加の工程やコンテキストの変更を必要とせず、完全に自動化となる。 レンダ領域は、必要なときには常に編集画面上にある。 レンダリングを要求する必要はない。 また、コンテキストを、編集ツールにアクセス可能なコンテキストから、編集ツールが使用できないコンテキストに変更する必要もない。

【００２５】以下に記すのは一例であり、先に論じた機能的特徴およびこの明細書のいずれかの部分で論ずる機能的特徴を実施する唯一の方法を表すことを意図するものではない。 この特定の実施形態では、レンダ領域をその一部として有するビューをタイルに分解する。 レンダ領域の境界は、タイルの境界を横切っても、横切らなくてもよい。 しかしながら、ワイヤ・フレーム・ビュー全体の大部分に重なり合うようにサイズを決める場合、レンダ領域の境界は、多くのタイルを横切ることになろう。 したがって、レンダ領域は、多数のタイル、および多数のタイルの断片を含む場合がある。 この実施形態では、以下のオブジェクトを定義することができる。

【００２６】ユーザ・インターフェース：このオブジェクトは、処理の進行中に著作者のシーン修正を受け入れることを可能にする。 ユーザ・インターフェースは、従来よりオーサリング環境と関係する全ての機能を支援するという意味において、従来通りに応答する。 従来から逸脱するのは、レンダ・マネージャ・オブジェクトに使用可能としたこと、著作者の編集作業に応答するシーンの変更、ならびにレンダ領域ウインドウの呼び出し、再位置決め、およびサイズ変更に対応したことである。

【００２７】レンダ・マネージャ：このオブジェクトは、シーン変更を受け取り、その変更が、（オブジェクトの表面テクスチャの変更のような）レンダ領域の更新を必要とし得る形式のものであるか、あるいは、例えば、オブジェクトの名称、または他のオブジェクトとの集合化のような、表示不可能な変更であるかについて判定を行う役割を果たす。 また、レンダ・マネージャは、
レンダ・エンジンの起動および停止する機能も果たす。
この機能は、レンダリング・プロセスが、ユーザ・インターフェースを維持する従来の機能面（aspect）を妨害するのを防止する。 したがって、例えば、再位置決めの後ワイヤ・フレームをリフレッシュしている場合、レンダリングを中断することができる。 言い換えると、レンダ・スレッド（レンダリング・プロセス。以下で説明する）の作成、終了および同期化は、レンダ・マネージャによって中断することにより、編集用ユーザ・インターフェースの障害となるのを防止する。 また、レンダ・マネージャは、ユーザが入力するシーン修正をレンダ・エンジンに受け渡す。 また、レンダ・マネージャは、環境シェーダを編集する場合のように、シーン修正がレンダ領域全体の全面的な再レンダリングを必要とするか否かについての判定も行う。 この場合、レンダ・マネージャは、タイルのレンダリングを中断し、レンダ・キャッシュを消去するように、レンダ・エンジンにコマンドを発行する。 キャッシュを消去するコマンドは、高い優先度でレンダ・キャッシュに渡すので、遅延なく実行する。
レンダ・キャッシュを消去することの効果は、あらゆる非表示タイルを破棄（flush）し、コマンド以前に表示してあったもののみをレンダ領域が示すようにすることである。

【００２８】レンダ・エンジン：このオブジェクトは、
レンダ・マネージャから、レンダリングを開始および停止する命令を受け取る。 シーン・データは、シーン・データの中央記憶部である、シーン・マネージャから得る。 ユーザ入力からの更新は、レンダ・マネージャを通じて、レンダ・エンジンに供給する。 すると、レンダ・
エンジンは、レンダ領域のどの部分をリフレッシュしなければならないか判定し、必要なレンダリングを実行することができる。 特定の実施形態では、画像エリアをタイルに分解し、そのいくつか即ち部分を、レンダ領域と対応させることができる。 この場合、レンダ・エンジンは、タイルの寸法（座標）から、未だ進行中の特定のシーン修正を判定し、他のシーン・データから、再度レンダリングしなければならない特定のタイルを判定する。
また、レンダ・エンジンは、先に到達したシーン修正に対応するタイルのレンダリングの前に受け取った、後から到達したシーン修正のシーケンスを調和することも可能である。 例えば、ユーザが第１のシーン修正を入力した後、第２のシーン修正を入力したときに、レンダ・エンジンは第１のシーン修正を実施するために適切なタイルを未だレンダリングしている場合がある。 第２のシーン修正は、第１のシーン修正に応答して再度レンダリングする目的で、あらゆるタイルにレンダリングを行う場合に組み込まれる。 また、レンダ・エンジンは、レンダ・マネージャからのコマンドに応答して、進行中のレンダリングを中断することができる。 レンダ・エンジンは、タイルにレンダリングを行いつつ、連続的にレンダリングしたタイルをレンダ・キャッシュに供給する。

【００２９】レンダ・キャッシュ：このオブジェクトは、レンダ・エンジンから来るタイルを格納する。 また、レンダ・キャッシュは、レンダ・エンジンからの命令にしたがって、その中に格納されている古いタイルを捨てなければならない。 更に、レンダ・キャッシュはタイルをレンダ・ビュー・オブジェクトに供給する。 レンダ・キャッシュの内容は、レンダ領域において見ることができるものである。

【００３０】レンダ・ビュー：このオブジェクトは、レンダ領域のサイズおよび位置を指定するコマンドを受け取り、格納し、実施する。 このレンダ領域定義データは、レンダ・エンジンにも使用可能となっており、レンダ・エンジンはこれを用いて、レンダリングするタイルを決定することができる。 また、レンダ・ビュー・オブジェクトは、レンダリング・オプション、例えば、レンダリング・サンプリング、速度も格納する。 また、このオブジェクトは、レンダ領域を再定義するときに、あるタイルの新たなレンダリングの要求を発生することもできる。 後者の機能は、レンダ・マネージャによって処理することも可能である。 領域定義データは、レンダ・エンジンに供給してもよい（例えば、シーン修正または領域の再定義によって、どのタイルを更新する必要があるかを判定できるようにする）。 最後に、レンダ・ビュー・オブジェクトは、レンダ・キャッシュからタイルを検索し、新たにレンダリングしたタイルの受け取りに応答して、領域に彩色する役割も果たす。

【００３１】一実施形態によれば、本発明は、三次元シーンを編集するためのオーサリング・システムを提供する。 本発明は、以下のようにプログラムすることによって、汎用コンピュータ上に実装可能である。 第１および第２の同期スレッドを定義する。 第１のスレッドは、ユーザ・データを受け入れるスレッドであり、三次元シーンに対する変更をユーザが入力したときはいつでも、ある種のフィードバックを与える。 また、ユーザは、特定のワイヤ・フレーム・ビューを形成するために用いるカメラの方位のように、シーンをどのように表示するかを定義するデータを入力することができる。 第１のスレッドは、三次元シーンを維持し（ユーザ入力にしたがってこれを更新し）、ワイヤ・フレーム・ビューのような、
少なくとも抽象的なレンダリングを表示する。 第１のスレッドでは、データの入力、シーンの更新、および抽象化ビューの更新は、同期プロセスとして実行する。 第２
のスレッドは、第１のスレッドと並列に実行する。 第２
のスレッドは、レイ・トレーシングを伴う場合がある、
三次元シーンの現実的レンダリングを維持する。 レンダリング・プロセスは大量の時間を要し、したがって資源の消費を削減し第１のスレッドが生成するオーサリング環境を阻害しないように制御可能であるという考えである。 レンダリング画像は、オーサリング環境において連続的に表示しても、しなくてもよい。 第１および第２のスレッドは、実質的に同時に実行し、レンダリングがオーサリング環境のコンテキストにおいて表示できるようにする。 現実的レンダリングの角視野は、抽象的レンダリングの角視野と実質的に同一に維持する。 オプションとして、抽象的レンダリングの対応するエリアを覆うように、現実的レンダリングを表示し、抽象的レンダリングが、現実的レンダリングに視覚的方向付けを与えるようにする。 また、第１の抽象的レンダリングと実質的に同一の第２の抽象的レンダリングを同時に表示することができる。 第１および第２の抽象的レンダリングは、これらの抽象的レンダリングのビューを特徴化する視点を定義するカメラに関して、実質的に同じ角度方位で維持することができる。 好ましくは、抽象的レンダリングは、ワイヤ・フレーム画像である。 素早いレンダリングの更新を可能とするために、第１の同期スレッドは、現実的レンダリングにおいて現実的にレンダリングする特定のオブジェクトを識別するデータの入力を含むことができる。 これによって、レンダリングの範囲を制限し、
プロセスをより迅速に完了させることが可能となる。

【００３２】別の実施形態によれば、本発明は、三次元シーンを編集するためのオーサリング・システムを提供する。 本発明は、以下のようにプログラムすることによって、汎用コンピュータ上に実装可能である。 第１および第２の同期スレッドを定義する。 第１のスレッドは、
ユーザ・データを受け入れるスレッドであり、三次元シーンに対する変更をユーザが入力したときはいつでも、
ある種のフィードバックを与える。 また、ユーザは、特定のワイヤ・フレーム・ビューを形成するために用いるカメラの方位のように、シーンをどのように表示するかを定義するデータを入力することができる。 第１のスレッドは、三次元シーンを維持し（ユーザ入力にしたがってこれを更新し）、ワイヤ・フレーム・ビューのような、少なくとも抽象的なレンダリングを表示する。 第１
のスレッドでは、データの入力、シーンの更新、および抽象化ビューの更新は、同期プロセスとして実行する。
第２のスレッドは、第１と並列に実行する。 第２のスレッドは、レイ・トレーシングを伴う場合がある、三次元シーンの現実的レンダリングを維持する。 レンダリング・プロセスは大量の時間を要し、したがって資源の消費を削減し第１のスレッドが生成するオーサリング環境を阻害しないように制御可能であるという考えである。 レンダリング画像は、オーサリング環境において連続的に表示することも、しないことも可能である。 第１および第２のスレッドは、実質的に同時に実行し、レンダリングがオーサリング環境のコンテキストにおいて表示できるようにする。 現実的レンダリングの角視点は、抽象的レンダリングの角視点と実質的に同一に維持する。 第１
および第２の抽象的レンダリングは、これらの抽象的レンダリングのビューを定義する視点を定義するカメラに関して、実質的に同じ角度方位で維持することができる。 現実的レンダリングは、抽象的レンダリングの対応するエリア上の位置に置き、抽象的レンダリングが現実的レンダリングに関する視覚方位情報を与えるようにすることができる。 オプションとして、第１の同期スレッドは、第２の同期スレッドよりも低い優先度で実行可能であり、第１の同期スレッドの実行速度が、第２の同期スレッドによる影響を受けないようにする。 あるいは、
第１および第２の同期スレッドは、第１の同期スレッドが第２の同期スレッドによる影響を実質的に受けないように制御する。 その結果、第１の同期スレッドによって維持するユーザ・インターフェースは、現実的レンダリングを生成するための計算要求量によって生ずる遅延の増大を実質的に伴わずに実行する。 好ましくは、現実的レンダリングは、内部に含まれる画素数を変更するように調節可能なサイズ変更可能ウインドウに表示可能である。 これによって現実的レンダリングを維持するための計算要求量を制限する。 レンダリングのための計算要求量を制限する別の代替案は、現実的レンダリングの解像度をユーザに調節させることである。 一変形では、現実的レンダリングを複数の部分に再分割し、選択した部分に第２の同期スレッドによって順次レンダリングを行う。 選択した部分とは、更新データの結果として、外観を変更すると判定されたものである。 また、これは、レンダリングした部分を再生しないことによって、計算要求量を削減する。 別の変形では、更新データを受け取ったとき、第２のスレッドの実行を中断し、更新データが第２のスレッドのレンダリング・プロセスに使用可能となった後に、第２のスレッドの実行を再開させる。 これによって、更新データによって無効化したデータを、レンダリング・プロセスにおいて使用しないことを保証する。 無効化部分は、レンダリングに先立って、表示を空白化し、レンダリングの古い部分を決して表示しないようにする。 あるいは、更新部分が上書きするまで、古い部分を表示に残しておく。 これによって、著作者は、古い部分および新しい部分を並置して見ることができる。
レンダリング表示を更新する更に別の方法は、全ての部分を更新するまで待ち、単一ステップで表示に再度彩色を行うことである。 更に、何らかの方法で表示にマークを付け、上書きを行うまでそれが無効であることを明確にすることも可能である。 これを行うには、例えば、表示を黒（またはゼロ−アルファ画素）で点彩（stippl
e）し、古いレンダリングの古い画素で一時的に彩色し、次いで更新したレンダリングの更新画素で彩色すればよい。

【００３３】別の実施形態によれば、本発明は、三次元シーンを編集するためのオーサリング・システムを提供する。 本発明は、以下のようにプログラムすることによって、汎用コンピュータ上に実装可能である。 第１および第２の同期スレッドを定義する。 第１のスレッドは、
ユーザ・データを受け入れるスレッドであり、三次元シーンに対する変更をユーザが入力したときはいつでも、
ある種のフィードバックを与える。 また、ユーザは、特定のワイヤ・フレーム・ビューを形成するために用いるカメラの方位のように、シーンをどのように表示するかを定義するデータを入力することができる。 第１のスレッドは、三次元シーンを維持し（ユーザ入力にしたがってこれを更新し）、ワイヤ・フレーム・ビューのような、少なくとも抽象的なレンダリングを表示する。 第１
のスレッドでは、データの入力、シーンの更新、および抽象化ビューの更新は、同期プロセスとして実行する。
第２のスレッドは、第１と並列に実行する。 第２のスレッドは、レイ・トレーシングを伴う場合がある、三次元シーンの現実的レンダリングを維持する。 レンダリング画像は、オーサリング環境において連続的に表示することも、しないことも可能である。 第１および第２のスレッドは、実質的に同時に実行し、レンダリングがオーサリング環境のコンテキストにおいて表示できるようにする。 現実的レンダリングの角視点は、抽象的レンダリングの角視点と実質的に同一に維持し、第２の抽象的レンダリングを、第１の抽象的レンダリングと実質的に同一とする。 この実施形態では、現実的レンダリングは、抽象的レンダリングの対応するエリア上の位置に置き、抽象的レンダリングが現実的レンダリングに関する視覚方位情報を与えるようにする。 第１の抽象的レンダリングと実質的に同一の第２の抽象的レンダリングを同時に表示する。 第１および第２の抽象的レンダリングは、抽象的レンダリングのビューを特徴化する視点を定義するカメラに対して、実質的に同一角度方位で維持する。

【００３４】別の実施形態によれば、本発明は、三次元シーンを編集するためのオーサリング・システムを提供する。 本発明は、以下のようにプログラムすることによって、汎用コンピュータ上に実装可能である。 第１および第２の同期スレッドを定義する。 第１のスレッドは、
ユーザ・データを受け入れるスレッドであり、三次元シーンに対する変更をユーザが入力したときはいつでも、
ある種のフィードバックを与える。 また、ユーザは、特定のワイヤ・フレーム・ビューを形成するために用いるカメラの方位のように、シーンをどのように表示するかを定義するデータを入力することができる。 第１のスレッドは、三次元シーンを維持し（ユーザ入力にしたがってこれを更新し）、ワイヤ・フレーム・ビューのような、少なくとも抽象的なレンダリングを表示する。 第１
のスレッドでは、データの入力、シーンの更新、および抽象化ビューの更新は、同期プロセスとして実行する。
第２のスレッドは、第１と並列に実行する。 第２のスレッドは、レイ・トレーシングを伴う場合がある、三次元シーンの現実的レンダリングを維持する。 第１の同期スレッドは、第２の同期スレッドよりも低い優先度で実行可能であり、第１の同期スレッドの実行速度が、第２の同期スレッドによる影響を受けないようにする。 現実的レンダリングは、内部に含まれる画素数を変更するように調節可能なサイズ変更可能ウインドウに表示可能であり、これによって現実的レンダリングを維持するための計算要求量を制限する。

【００３５】別の実施形態によれば、本発明は、三次元シーンを編集するためのオーサリング・システムを提供する。 本発明は、以下のようにプログラムすることによって、汎用コンピュータ上に実装可能である。 第１および第２の同期スレッドを定義する。 第１のスレッドは、
ユーザ・データを受け入れるスレッドであり、三次元シーンに対する変更をユーザが入力したときはいつでも、
ある種のフィードバックを与える。 また、ユーザは、特定のワイヤ・フレーム・ビューを形成するために用いるカメラの方位のように、シーンをどのように表示するかを定義するデータを入力することができる。 第１のスレッドは、三次元シーンを維持し（ユーザ入力にしたがってこれを更新し）、ワイヤ・フレーム・ビューのような、少なくとも抽象的なレンダリングを表示する。 第１
のスレッドでは、データの入力、シーンの更新、および抽象化ビューの更新は、同期プロセスとして実行する。
第２のスレッドは、第１と並列に実行する。 第２のスレッドは、レイ・トレーシングを伴う場合がある、三次元シーンの現実的レンダリングを維持する。 更新データを受け取ったとき、第２のスレッドの実行を中断する。 更新データが第２のスレッドのレンダリング・プロセスに使用可能となった後に、実行を再開させる。 これを行って、更新データによって無効化したシーン・データの部分に対応する現実的レンダリングの部分のレンダリングを防止する。

【００３６】また、本発明は、三次元シーンのオーサリングを行うユーザ・インターフェースを生成する方法も提供する。 この方法は、３Ｄシーンをメモリに格納するステップと、著作者が入力する３Ｄシーンに対する編集を受け取るステップと、編集に応答して３Ｄシーンを更新するステップと、ＯｐｅｎＧＬライブラリ（例えば、
ワイヤ・フレーム、シェード等）に対応する表示モードを用いて、３Ｄシーンの最適化ビューを表示するステップと、ワイヤ・フレーム・ビューを表示するステップと同時に、３Ｄシーンのレンダリング・ビューも生成し、
レンダリング・ビューが３Ｄシーンのレイ・トレーシングの結果を示すステップと、ワイヤ・フレーム・ビューの方位と同一のレンダリング・ビューの方位を維持し、
ワイヤ・フレームの方位を変更した場合に、レンダリング・ビューの方位を自動的に共に変更するステップとを有する。

【００３７】また、本発明は、三次元シーンのオーサリングを行うためのユーザ・インターフェースを生成する方法を提供し、３Ｄシーンをメモリに格納するステップと、ユーザが供給する３Ｄシーンに対する編集を受け取るステップと、編集に応答して３Ｄシーンを更新するステップと、３Ｄシーンのワイヤ・フレーム・ビューを表示するステップと、ワイヤ・フレーム・ビューを表示するステップと同時に、３Ｄシーンのレンダリング・ビューも生成するステップと、ワイヤ・フレーム・ビューを受け取り、更新し、更に表示するステップの第２のプロセスと並列な第１のプロセスにおいて、レンダリング・
ビュー内で可視の３Ｄシーンの部分を連続的にレンダリングすることによって、編集に応答してレンダリング・
ビューの現行性（currency）を維持するステップであって、第１のプロセスが第２のプロセスに対して非同期であるステップとから成る。 前述の維持するステップは、
第２のプロセスが第１のプロセスによる影響を実質的に受けないように、第１および第２のプロセスを制御するステップを含む。 第２のプロセスは、第１のプロセスよりも低い優先度で実行可能である。

【００３８】本発明の別の実施形態は、三次元シーンのオーサリングを行うためのインターフェースを与える方法である。 そのステップは、３Ｄシーンをメモリに格納するステップと、ユーザが供給する３Ｄシーンに対する編集を受け取るステップと、編集に応答して３Ｄシーンを更新するステップと、３Ｄシーンの第１のワイヤ・フレーム・ビューを表示するステップと、ワイヤ・フレーム・ビューを表示するステップと同時に、３Ｄシーンのレンダリング・ビューも生成し、レンダリング・ビューが３Ｄシーンのレイ・トレーシングの結果を示すステップと、連続的かつ自動的にレンダリング・ビューを表示するステップと、第２のワイヤ・フレーム・ビューを表示するステップと、第１のワイヤ・フレーム・ビューの方位と実質的に同一の第２のレンダリング・ビューの方位を維持するステップと、第１のワイヤ・フレーム・ビューに対応するエリアでかつこれと同一のズーム・レベルで、第１のワイヤ・フレーム・ビュー上にレンダリング・ビューを表示し、ワイヤ・フレームがレンダリング・ビューを方向付けるように機能するステップとから成る。

【００３９】本発明の別の実施形態は、３Ｄシーンに対応する画像を生成する方法である。 そのステップは、メモリに３Ｄシーンを格納するステップ（ビューは、３Ｄ
シーンのカメラ・オブジェクトの位置および方位によって定義し、更にビューは、視野および倍率によって更に定義し、視野をタイルに分割する。 タイルとは、視野の隣接部分のことである）と、３Ｄシーンに対する修正を指定する更新データを受け入れるステップと、受け入れるステップに応答してレンダリング・プロセスを中断するステップと、レンダリング・プロセスが、無効タイルのリストにおいて識別したタイルに順次レンダリングを行い、レンダリング・プロセスが３Ｄシーンの少なくとも一部のレイ・トレーシングを含み、受け入れるステップに応答して、メモリに格納してある３Ｄシーンを更新するステップと、更新データによって無効としたタイルを識別し、それに応答して無効タイルのリストを更新するステップと、識別するステップにおいて更新したリストを用いて、レンダリング・プロセスを再開するステップとから成る。 オプションとして、前述の方法は、識別するステップにおいて無効として識別したタイルの各々の表示を空白化するステップを含む。 また、レンダリング・プロセスの結果を連続的かつ自動的に表示するステップを含んでもよい。 更に、更新データがいずれかのタイルの外観に影響を与えるか否かについて判定を行うステップと、判定するステップの結果が、更新データがいずれのタイルの外観にも影響を与えないことを示した場合、中断するステップを省略するステップとを含んでもよい。

【００４０】本発明の別の実施形態は、以下のステップを含む方法である。 即ち、メモリに３Ｄシーンを格納するステップと、３Ｄシーンのカメラ・オブジェクトの位置および方位によってビューを規定するステップと、視野と倍率によってビューを更に規定するステップと、視野をタイルに分割するステップであって、タイルを視野の隣接部分とするステップと、３Ｄシーンのレンダリングを行うステップと、３Ｄシーンに対する修正を指定する更新データを受け入れるステップと、更新データがいずれかのタイルの外観に影響を与えるか否かについて判定し、判定するステップの結果が、更新データはいずれかのタイルの外観に影響を与えることを示す場合、受け入れるステップに応答してレンダリングを行うステップを中断するステップと、レンダリング・プロセスが、無効タイルのリストにおいて識別したタイルに順次レンダリングを行い、レンダリング・プロセスが３Ｄシーンの少なくとも一部のレイ・トレーシングを含み、更新データによって無効としたタイルを識別し、それに応答して無効タイルのリストを更新するステップと、識別するステップにおいて更新したリストを用いて、レンダリング・プロセスを再開するステップとから成る。 前述の受け入れるステップとレンダリングを行うステップは、互いに対して非同期的に実行することができる。 また、前述のレンダリングを行うステップおよび受け入れるステップは、レンダリングを行うステップよりも高い優先度で実行してもよい。 前述のレンダリングを行うステップは、リスト内に識別したオブジェクトにレンダリングを制限し、ユーザが入力する画面エリア定義にしたがってレンダリングを行うステップの結果を構成する画素数を制限することによって、レンダリングを行うオブジェクトの範囲を限定するステップを含むことができる。 また、ワイヤ・フレーム・ビューを表示するステップと同時に、本方法は、レンダリングを行うステップから得られた３Ｄシーンのレンダリング・ビューを表示するステップを含み、レンダリング・ビューが３Ｄシーンのレイ・トレーシングを行った結果を示すようにしてもよい。
加えて、本方法は、更に、第２のワイヤ・フレーム・ビューを表示し、第１のワイヤ・フレーム・ビューの方位と実質的に同一の第２のワイヤ・フレーム・ビューの方位を維持するステップを含むことができる。 加えて、レンダリング・ビューを表示するステップは、第１のワイヤ・フレーム・ビューに対応するエリアでかつこれと同一のズーム・レベルで、第１のワイヤ・フレーム・ビュー上にレンダリング・ビューを表示するステップを含むことができ、ワイヤ・フレームはレンダリング・ビューを方向付けるように機能する。 また、レンダリング・ビューを表示するステップは、第１のワイヤ・フレーム・
ビューに対応するエリアでかつこれと同一のズーム・レベルで、第１のワイヤ・フレーム・ビュー上にレンダリング・ビューを表示するステップを含むことができ、ワイヤ・フレームがレンダリング・ビューを方向付けるように機能する。

【００４１】

【発明の実施の形態】図１を参照し、本発明を実施することができる、適切な計算機環境を示す。 図示のように、種々のコンピュータ・システム構成がある。 尚、本発明は、分散型計算機環境において実用化することができ、通信ネットワークを通じて、ローカルおよび／またはリモート記憶装置内に配置したプログラム・モジュールとリンクしたリモート処理装置によってタスクを処理することを注記しておく。 システムの一例は、従来のパーソナル・コンピュータ９００を含み、処理ユニット９
１０、システム・メモリ９２０、およびシステム・メモリないし処理ユニット９１０までを含むシステム・コンポーネントを相互接続するシステム・バス９３０を備えている。 システム・バス９３０は、メモリ・バスまたはメモリ・コントローラ、周辺バス、あるいはローカル・
バスを含むあらゆる構造とすることができる。 システム・メモリは、リード・オンリ・メモリ（ＲＯＭ）９４０
およびランダム・アクセス・メモリ（ＲＡＭ）９５０を含む。 起動中のように、パーソナル・コンピュータ９０
０内のエレメント間で情報を転送する際に役立つ基本ルーチンを収容した基本入出力システム（ＢＩＯＳ）９６
０が、ＲＯＭ９４０に記憶してある。 更に、パーソナル・コンピュータ９００は、ハード・ディスク・ドライブ９７０、リムーバブル磁気ディスク９９０を備えた磁気（例えば、フロッピ）ディスク・ドライブ９８０、およびリムーバブル光ディスク９９２を備えた光ディスク・
ドライブ９９１も含む。 ハード・ディスク・ドライブ９
７０、磁気ディスク・ドライブ９８０、および光ディスク・ドライブ９９１は、それぞれ、ハード・ディスク・
ドライブ・インターフェース９９２、磁気ディスク・ドライブ・インターフェース９９３、および光ディスク・
ドライブ・インターフェース９９４を介して、システム・バス９３０に接続してある。 磁気カセット、フラッシュ・メモリ・カード、デジタル・ビデオ・ディスク、ベルヌーイ・カートリッジ、ランダム・アクセス・メモリ（ＲＡＭ）、リード・オンリ・メモリ（ＲＯＭ）等のように、他の形式のコンピュータ読み取り可能媒体を用いてデータを格納してもよい。

【００４２】プログラム・モジュールは、ハード・ディスク、磁気ディスク９９０、光ディスク９９２、ＲＯＭ
９４０またはＲＡＭ９５０上に記憶すればよく、オペレーティング・システム９５０、１つ以上のアプリケーション・プログラム９９６、他のプログラム・モジュール９９７、およびプログラム・データ９９８を含む。 ユーザは、キーボード９０１およびポインティング・デバイス９０１のような入力装置を通じて、コマンドおよび情報をパーソナル・コンピュータ９００に入力することができる。 他の入力装置（図示せず）には、マイクロホン、ジョイスティック、ゲーム・パッド、サテライト・
パラボラアンテナ、スキャナ等も含まれる場合がある。
これらおよびその他の入力装置は、多くの場合、システム・バスに結合するシリアル・ポート・インターフェース４６を介して処理ユニット９１０に接続するが、パラレル・ポート、ゲーム・ポートまたはユニバーサル・シリアル・バス（ＵＳＢ）のようなその他のインターフェースを介して接続することも可能である。 モニタ９０７
またはその他の形式の表示装置も、ビデオ・アダプタ９
０８のようなインターフェースを介して、システム・バス９３０に接続してある。 モニタに加えて、パーソナル・コンピュータは、典型的に、スピーカやプリンタのような、その他の周辺出力装置（図示せず）も含む。

【００４３】パーソナル・コンピュータ９００は、リモート・コンピュータ９０９のような、１つ以上のリモート・コンピュータへの論理接続を用いたネットワーク状環境において動作することができる。 リモート・コンピュータ９０９は、別のパーソナル・コンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア・デバイス、またはその他の一般的なネットワーク・ノードとすることができ、典型的に、パーソナル・コンピュータ９００に関して先に記載したエレメントの多くまたは全てを含むが、図１にはＣＰＵ９１１のみを図示してある。 図１に示す論理接続は、ローカル・エリア・ネットワーク（Ｌ
ＡＮ）９１２およびワイド・エリア・ネットワーク（Ｗ
ＡＮ）９１３を含む。 このようなネットワーク状環境は、事務所、会社規模のコンピュータ・ネットワーク、
イントラネット、およびインターネットにおいては、目新しいものではない。

【００４４】ＬＡＮネットワーク状環境において用いる場合、パーソナル・コンピュータ９００は、ネットワーク・インターフェース即ちアダプタ９１４を介して、ローカル・ネットワーク９１２に接続する。 ＷＡＮネットワーク状環境において用いる場合、パーソナル・コンピュータ２０は、典型的に、モデム９１５またはインターネットのようなワイド・エリア・ネットワーク９１３を通じて通信を確立するその他の手段を含む。 モデム９１
５は、シリアル・ポート・インターフェース９０６を介して、システム・バス９３０に接続してある。 ネットワーク状環境では、プログラム・モジュール、またはその一部分は、リモート・メモリ記憶装置に記憶してある場合がある。 尚、図示のネットワーク接続は一例であり、
複数のコンピュータ間に通信リンクを確立するその他の手段も使用可能であることは認められよう。

【００４５】当業者は熟知しているであろうが、コンピュータ・システム９００は、更に、オペレーティング・
システムおよび少なくとも１つのアプリケーション・プログラムを含む。 オペレーティング・システムは、コンピュータ・システムの動作および資源の割り当てを制御する。 アプリケーション・プログラムは、オペレーティング・システムを通じて使用可能なコンピュータ資源を利用して、ユーザが所望するタスクを処理する１組のソフトウエアである。 双方共、図示のメモリ９２０または先に示唆したようなその他の記憶装置内に位置することができる。

【００４６】コンピュータ・プログラミングの技術における当業者の実務（practice）にしたがって、特に指示がない場合は、アクト（act）およびコンピュータ・システム９００が処理する動作シンボル表現を参照しながら、本発明の説明を行うことにする。 このようなアクトおよび動作は、ときとして、コンピュータ実行（comput
er-executed）と呼ぶことがある。 尚、アクトおよびシンボル表現した動作は、データ・ビットを表す電気信号のＣＰＵ９１０による操作を含む。 この操作によって、
結果としての電気信号表現の変換または減少、メモリ・
システム２２内のメモリ位置へのデータ・ビットの維持によるコンピュータ・システムの動作の再構成またはその他の方法による変更、あるいはその他の信号処理が行われる。 データ・ビットを維持するメモリ位置は、当該データ・ビットに対応する特定の電気的、磁気的、光学的、または有機的プロパティを有する物理的な位置である。

【００４７】本発明の例示的な実施形態では、コンピュータ・システム２０は、WindowsNT(登録商標)、Windows
95(登録商標)、Windows98(登録商標)のクライアント・
サーバ・オペレーティング・システムを用いることができる。 他のクライアント／サーバ・オペレーティング・
システム（例えば、ＩＢＭによるO/S2、MacOS、UNIX、Wind
ows CE等）も使用可能である。 クライアント／サーバ・
オペレーティング・システムとは、２つの異なる種類の多数のプロセスに分割したオペレーティング・システムのことであり、２つの異なる種類のプロセスとは、各々が典型的に１組のサービスを実現するサーバ・プロセスと、サービス・プロセスから種々のサービスを要求するクライアント・プロセスである。 オブジェクト指向プログラミングを用いて、クライアント／サーバ・オペレーティング・システム、および当該クライアント／オペレーティング・システムの下で走るアプリケーションを設計する。 ここでは、オブジェクトとはシステム資源を表す。

【００４８】例えば、Windows95クライアント／サーバ・オペレーティング・システムは、ファイル、メモリ、
プロセスおよびスレッドというような共有可能な資源を提供する。 これらは、「オブジェクト」として実装し、
「オブジェクト・サービス」を用いることによって、アクセスすることができる。 当技術分野では周知であるが、「オブジェクト」とはデータ構造のことであり、その物理的フォーマットが型定義の背後に隠されているものである。 データ構造とは、レコードまたはフォーマットとも呼ぶが、データに適用し、解釈可能としたり、当該データに対して特定の動作を実行可能とする、編成のスキーム（organization scheme）である。 このようなデータ構造は、コンピュータ・メモリ９２０内部に格納してあるデータの集合体に物理的な編成を課し、特定の電気的、磁気的または有機体的エレメントを表す。

【００４９】「オブジェクト型」とは、「オブジェクト・クラス」とも呼び、データ型、当該データ型のインスタンスにおいて動作するサービス、および１組のオブジェクト属性から成る。 「オブジェクト属性」とは、オブジェクトの状態を部分的に定義するオブジェクト内のデータの欄のことである。 「オブジェクト・サービス」
は、通常、オブジェクト属性を読み込みあるいは変更することにより、オブジェクトの実装および操作を行う。
「オブジェクト指向設計」とは、オブジェクトを用いてシステムまたはコンポーネントを表現する、ソフトウエア開発技法のことである。

【００５０】典型的に、オブジェクトは２つのコンポーネントを有する。 即ち、当該オブジェクトのクラスにおいて定義してある各オブジェクト・メンバ関数（即ち、
ときとしてオブジェクト・メソッドとして知られている）に対するポインタを含む関数テーブルと、各オブジェクト変数（即ち、ときとしてオブジェクト・プロパティとしても知られている、データ・メンバ）毎に現在の値を収容するデータ・ブロックである。 アプリケーションは、オブジェクト・ポインタを介して、あるオブジェクトに対して何らかの参照（reference）を有する。 アプリケーションは、何らかの型の関数コール（直接または黙示的）を用いることによって、このオブジェクト参照を得る。 関数コールにおいて、当該関数がオブジェクト・ブロックをコンピュータ・メモリ内に割り当て、関数テーブルを初期化し、コンピュータ・メモリに対する参照をアプリケーションに返す。 コンピュータ・メモリは、ローカルでも、リモート・コンピュータ上に分散してもよい。

【００５１】Windows95オペレーティング・システムは、それが実行すべき多くのタスクを「プロセス」に編成することにより、ユーザが２つ以上のプログラムを一度に実行できるようにする。 このオペレーティング・システムは、コンピュータの資源の一部を各プロセスに割り当て、適切な時点に適切な順序で、各プロセスのプログラムを実行のために発行することを保証する。

【００５２】本発明の例示的な実施形態では、プロセスをオブジェクトとして実装する。 プロセス・オブジェクトは、次のエレメントから成る。 実行可能プログラム、
専用アドレス空間、プログラムを実行する際にオペレーティング・システムがプロセスに割り当てるシステム資源（例えば、通信ポートやファイル）、および少なくとも１つの「実行のスレッド」である。 「スレッド」とは、オペレーティング・システム・カーネルが実行のためにスケジュールする、プロセス内のエンティティである。 当技術分野では周知であるが、各スレッドは、関連する「コンテキスト」を有する。 「コンテキスト」とは、スレッドの実行と関連する揮発性データである。 スレッドのコンテキストは、システム・レジスタの内容、
およびスレッド・プロセスに属する仮想アドレスを含む。 したがって、スレッド・コンテキストを構成する実際のデータは、実行するに連れて変化する。

【００５３】図４を参照すると、本発明の実施によって使用可能となり得るスクリーン・ショット１１０の一例は、シェーダ・エディタ・ウインドウ１２０、２つの透視３Ｄワイヤ・フレーム・ビュー１４０，１７０、および平面ワイヤ・フレーム・ビュー１６０を含む。 透視ワイヤ・フレーム・ビューの一方１７０は、移動およびサイズ変更が可能な、概略レンダ領域１７５を示す。 このレンダ領域の内側には、基礎となるワイヤ・フレーム・
オブジェクトが、完全にレンダリングされている。 即ち、レンダ領域１７５の境界によって定義するシーンの部分をレンダリングし、レンダ領域１７５のウインドウ内部の適所に示している。 したがって、ワイヤ・フレーム・ビュー１７０の殆どは、例えば、白黒の線として現れるが、レンダ領域１７５の内側のビューの部分は、レイ・トレーシング・アルゴリズムの適用後にレンダリングしたビューにおけるものとして現れる。

【００５４】著作者は、レンダリングの対象であるシーンの部分に対応するビュー１７０の部分の上に、レンダ領域１７５を配置する。 例えば、著作者が単一のオブジェクトのプロパティを編集している場合、著作者はレンダ領域１７５をこのオブジェクト上に置き、当該オブジェクトと隣接エリアの小部分、例えば、第１のオブジェクトが影を付ける別のオブジェクトの一部とを包囲するように、領域１７５のサイズを決定することができる。
レンダ領域をワイヤ・フレーム・ビューの上に置くことによって、著作者は、ワイヤ・フレーム・ビュー内に現れる、制御点、マニピュレータ、ガイド等のフレームワークに対して、レンダリングをより良く見ることができる。

【００５５】レンダ領域１７５のレンダリングは、著作者が編集制御部と双方向処理を行いながら、自動的かつ連続的に行われる。 したがって、レンダ領域は、レンダリング・プロセスが現行のまま残っていることができる範囲で、常に、著作者の現行の編集に対応するレンダリング・ビューを示す。

【００５６】図４に示すような編集環境では、従来のオーサリング・ツール全てが利用可能である。 この編集環境は、編集環境に通常関連する編集ツールに最大限アクセスすることを可能にする。 更に、この編集環境は、３
Ｄシーンの作業をする際に有用な、抽象化ビュー、３Ｄ
マニピュレータおよび制御点を与えかつ維持する。 重要なことは、編集ツールへのアクセスが、レンダリング・
プロセスの完了を待つ必要性によって阻害されないことである。 加えて、レンダ領域ウインドウ１７５のサイズ変更や再位置決めを行うツールが使用可能である。 好適な実施形態では、通常のオーサリング機能は、レンダ領域に更新画像を与える機能よりも高い優先度を有する。
これを可能にするために、ユーザが入力するシーン変更を受け入れるプロセスは、可能な限り最も新鮮なレンダリングを与えるプロセスと並列に、そしてこれよりも高い優先度で行う。 したがって、例えば、著作者がオブジェクト１３０を移動させる場合、ワイヤ・フレーム・ビューにおいてワイヤ・フレームに再度彩色を行い、その後にレンダ領域１７５の再レンダリングおよび再彩色を行う。 したがって、レンダ領域１７５のリフレッシングは、資源が使用可能になるに連れて進行する。 もちろん、ハードウエアの実現例によっては、レンダ領域１７
５をレンダリングする並列処理は、優先順位を決めることを不要とする資源（並列プロセッサのような）を使用する場合もあり、その場合レンダリングは、オーサリング・システムの従来の機構によって継続することになる。

【００５７】図４の実施形態では、レンダリング領域１
７５は、透視ワイヤ・フレーム・ビュー１４０の上に重なっており、透視ワイヤ・フレーム・ビュー１４０のビュー方位は、別のワイヤ・フレーム・ビュー１７０のそれと一致している。 これは、著作者が、別のワイヤ・フレーム・ビュー１４０に表示される情報を、レンダリングしたビューと比較し相関付ける際に役立つ。 領域をワイヤ・フレーム・ビューの小部分として定義し、その上に直接重ねることにより、領域１７５の位置およびサイズを定義する便利な機構を与えるだけでなく、著作者が、レンダリングしたビューに関する展望を得ることができる。 これは、ビュー全体をレンダリングする場合、
例えば、レンダリングの表示を、それ自体の完全にレンダリングしたビューで行う場合、これを容易に得ることはできない。 あるシーンの中の背景オブジェクトと前景オブジェクトとの間の色差またはコントラストが非常に低いことを想定する。 また、更にこれらのオブジェクトが部分的にレンダ領域１７５に覆われており、部分的にレンダ領域内まで達し、部分的にレンダ領域の外側まで達することを想定する。 これらのオブジェクトのコントラストが高いワイヤ・フレーム画像は、あらゆる制御点ならびに見ることができないガイドおよび／またはマニピュレータと共に見ることができ、著作者の適応力を高めると共に、著作者がオブジェクトを操作する際に役に立つ。 これは、レンダ領域１７５と同じビュー１７０において行うことができる。

【００５８】レンダ領域１７５に隣接するワイヤ・フレームによってもたらされる方向性（orientation）および明確性という重要な成果は、著作者がレンダ領域１７
５のサイズを最小化できることにある。 ワイヤ・フレームがそれを示すので、著作者は、レンダ領域１７５内のシーンの大きな割合を、参照の視覚フレームを得るために割く必要がない。

【００５９】尚、この明細書で用いる場合、「ビュー」
という用語は、カメラの有利性（camera vantage）から生成し得る画像に伴う倍率および視野（被写体深度は、
「ビュー」のコンテキストでは考慮しないと仮定する）
に全く言及することなく、カメラの位置および方位によって規定されるものを暗示するために用いる場合もあることを注記しておく。 したがって、異なる視野を有する魚眼ビューまたはズーム・ビューは、双方共同じカメラの有利性から得られるが、この広義の意味で用いる場合には同じ「ビュー」となる。 また、この明細書では、
［ビュー」という用語は、より具体的な何かを暗示するためにも用いる。 即ち、この用語は、場合によっては、
特定の視野を指定するため、おそらく、特定の倍率を一層狭く指定するにも用いられる。 これら可能な定義の特定の１つを具体的に示すことなく本明細書においてこの用語が用いられる場合、その用法のコンテキストがそれを明確にすること、またはこれらの意味のいずれでも適用可能であることと考える。 請求の範囲では、「ビュー」という用語は、請求の範囲において更なる限定によって定義を特定する即ち狭くする場合を除いて、その最も広義の意味で用いるものとする。

【００６０】図６を参照する。 本発明は、オブジェクト指向プログラムに実装可能である。 図６は、オブジェクト指向の実現例のためのフレームワークとして用いることができる、オブジェクトおよびデータ・フローの特定例を示す。 そのアーキテクチャは、例えば、Microsoft
のComponent Object Model（ＣＯＭ）（コンポーネント・オブジェクト・モデル技術）を基本とすることができ、カスタムＣＯＭインターフェースを用いてコンポーネント（オブジェクト）同士が相互動作を行う。 以下の説明は抽象化してあり、記載する各オブジェクトは実際には、多数のコンポーネント・オブジェクトから成り、
それらが相互動作することにより、記載する機能を行う。 このアーキテクチャは、通知モデル（notification
model）に基づくものである。 コンポーネントは非同期的に通信する。

【００６１】オブジェクト指向の実現例の例では、以下の３種類の別個のスレッドを定義する。 （１）ユーザ・
インターフェースのための支援、（２）レンダリング、
および（３）レンダリングした部分の画面彩色（screen
-painting）。 先に論じたように、ユーザ・インターフェースの支援機能には、より高い優先度を与えることができる。 あるいは、他の何らかの方法で別個のスレッドを制御し、レンダリング・スレッドによってユーザ・インターフェースが不当に低速化しないことを保証するようにしてもよい。

【００６２】ここで図５も参照すると、ある実施形態において、レンダ領域１７５がその一部であるビュー１７
０をタイル１７２に分解する。 レンダ領域１７５の境界は、タイル１７２の境界を横切っても、横切らなくてもよいが、ワイヤ・フレーム・ビュー１７０全体の大部分に領域１７５が重なり合うようにサイズを決める場合、
レンダ領域の境界は、多くのタイルを横切ることが予期される。 したがって、レンダ領域は、多数のタイル１７
２、および多数のタイル１７２の断片を含む場合がある。 この実施形態では、以下のオブジェクトを定義することができる。

【００６３】ユーザ・インターフェース・オブジェクト３０５は、ユーザ・インターフェースを支援する機能を扱う。 従来のユーザ・インターフェース機構の支援に加えて、ユーザ・インターフェース・オブジェクト３０５
は、レンダ領域の位置およびサイズを決めることができる。 シーン定義データおよび修正値を受け入れることに加えて、アルファ複合オプション（alpha compositing
option）や、レンダ領域に関連するその他いずれかのオプションのような、レンダリング・オプションのユーザ入力を支援する。 ユーザ・インターフェースは、従来の機能面では、レンダ領域を彩色するワイヤ・フレーム・
ビューの個別処理（tailoring）を行うことができる。
このデータは、レンダリングを実行する際に用いる。 ユーザ・インターフェース３０５は、従来よりオーサリング環境と関係する全ての機能を支援するという意味において、従来通りに応答する。 代替実施形態では、ユーザ・インターフェース・オブジェクト３０５は、ユーザに、レンダリングしたビューを呼び出したり閉じたりすることも可能にする。 レンダ領域を定義するデータは、
レンダ・ビュー・オブジェクトに供給することができ、
これを格納し、例えば、レンダ・エンジン・オブジェクト３２５に使用可能とすることもできる。

【００６４】レンダ・マネージャ：レンダ・マネージャ３１０は、レンダ・エンジンの起動および停止を行う機能を果たす。 このオブジェクトはシーン変更を受け取り、その変更が、（オブジェクトの表面テクスチャの変更のような）レンダ領域の更新を必要とし得る形式のものであるか、あるいは（オブジェクトの名称、または他のオブジェクトとの集合化のような）表示不可能な変更でないかについて判定を行う。 変更が表示可能と判定した場合、レンダ・マネージャは、レンダリング停止コマンドをレンダ・エンジンに送ることによって、レンダリングを中断する。 更新した内容をレンダ・エンジンに送り、どのタイルのレンダリングをし直さなければならないかについてレンダ・エンジンが判断できるようにする。 更新したシーン・データは、中央記憶部から得ることができ、あるいはレンダ・エンジンがそれを異なるフォーマットで要求する場合、レンダ・マネージャが構築することができる。

【００６５】レンダ・マネージャ３１０は、レンダリングに伴うタスクを定義する動作のスレッドを、作成し、
終了し、同期化する。 これは、編集用システムの障害となるのを防止する。 レンダ・マネージャ３１０は、システムの中央シーン・マネージャ３２０、即ち、シーンの現定義を格納してある中央記憶部に対するデータ通知シンク・インターフェース（data notification sink int
erface）を登録する。 シーン・データが変化したとき、
シーン・マネージャ３２０がレンダ・マネージャに通知する。 シーン・データの各変化を類別するために、ビット・フィールドを用いることができる。 このビット・フィールドは、変化が再度レンダリングを必要とするか否かについて判定する際に、類別を考慮に入れてもよい。

【００６６】レンダ・マネージャ３１０は、シーン・マネージャからシーン修正を受け取り、これらの修正を選択的にレンダ・エンジンに渡す。 シーン修正が性質上グローバルである場合、レンダ・マネージャは、シーン修正データをレンダ・エンジンに渡す前にこれを判定する。 グローバル・パラメータ、例えば、シーンの周辺光強度を修正する場合、シーンのレンダ領域部分のレンダリングを無効にする。 レンダ・マネージャは対応するコマンドを、レンダ・エンジンに発行し、あらゆるレンダリング・プロセスを中断するようにレンダ・エンジンを指揮する。 レンダ・エンジンは、コマンドをレンダ・キャッシュに渡し、キャッシュを消去する。 これによって、レンダ・エンジンおよびレンダ・キャッシュが無効のシーンの部分をレンダリングすることによる、不要な資源消費を防止する。 本実施形態では、レンダリング・
プロセスはタイル毎に進められる。 グローバル・パラメータ、即ち、レンダリングの外観全体に影響を及ぼすパラメータを変更する場合、レンダリング中断／キャッシュ消去コマンドの効果は、レンダ・エンジンがタイルのレンダリングを停止し、レンダ・キャッシュは、レンダリングしてレンダ・ビューが拾い上げるのを待っているあらゆるタイルを破棄し、レンダ領域の表示をリフレッシュすることである。

【００６７】ユーザが、レンダ領域を移動させるかあるいはそのサイズを変更するためのいずれかのコマンドを入力した場合、そのデータはユーザ・インターフェースからレンダ・ビューに送られる。 レンダ・ビューは、変更の指示をレンダ・マネージャに送り、レンダ・マネージャがそれに応じて再度レンダリングを開始できるようにする。 尚、レンダ領域の修正により、シーン修正と同じイベントのチェーンが発生する場合があることを注記しておく。 即ち、レンダ領域は、シーンを修正するときにそれを更新しなければならないのと同様に、当該領域を再定義するときに、更新しなければならない。

【００６８】レンダ・エンジン３２５：このオブジェクトは、レンダ・マネージャ３１０から、レンダリングを開始および停止する命令を受け取る。 シーン・データは、シーン・データの中央記憶部である、シーン・マネージャ３２０から得る。 シーン・マネージャは、レンダ・エンジンが用いるのとは異なるフォーマットで、シーン・データを格納する場合もある。 その場合、シーン・
マネージャは、必要に応じてフォーマットを変換する。
また、シーン・マネージャ３２０からのシーン・データと、シーン・マネージャ３２０によってレンダ・エンジン３２５から（ユーザ・インターフェース３０５から）
送信するシーン修正との同期は、レンダ・マネージャ３
１０が処理する。

【００６９】レンダ・マネージャ３１０を通じて、ユーザ入力の結果生ずるシーン修正をレンダ・エンジン３２
５に供給する。 すると、レンダ・マネージャ３１０は、
レンダ領域１７５のどの部分をリフレッシュし、必要なレンダリングを実行しなければならないかについて決定することができる。 好適な実施形態では、既に論じたように、画像エリアをタイル１７２に分解する。 したがって、レンダ・エンジンは、その場合、タイルの寸法（座標）および特定のシーン修正の座標から、再度レンダリングしなければならない特定のタイルを判定することができる。 次いで、レンダ・エンジン３２５は、これらのタイル１７２に順次レンダリングを行い、各タイルのレンダリングが完了する毎に、レンダリングしたタイルを定義するデータをレンダ・キャッシュ３３０に印加する。 このタイルにレンダリングを行うプロセスは、ユーザ・インターフェースの保守（シーン修正を受け入れ、
ワイヤ・フレーム・ビューを更新する等）、およびレンダ・マネージャ３１０が実行するシーン修正フィルタリング・プロセスと並行して進める。 著作者の修正による影響を受けるタイルのみを識別し、再度レンダリングすることによって、レンダリングを更新する速度は更に高まる。 例えば、オブジェクトの表面のテクスチャに変更を加える場合、いくつかのタイルのみ再度レンダリングすればよい場合がある。

【００７０】レンダ・エンジンは、タイルにレンダリングを行いつつ、レンダリングしたタイルをレンダ・キャッシュに連続的に供給する。 レンダ・エンジン３２５
は、レンダ・キャッシュ３３０にコマンドを送って無効のタイルを空白にし、有効なタイルをレンダ・キャッシュ３３０に供給して無効のものと置換するまで、対応する領域に何も表示しないようにすることも可能である。
あるいは、新しいタイルを受け取るまで、最後の有効なタイルを適所に残しておいてもよい。 これにより、「古い」バージョンおよび「新しい」バージョンの比較が改善する。 別のところでも論じたように、この並置は著作者にとって有用となり得るものである。 この機構は、レンダ・オプション（例えば、無効タイルの空白化、または更新時の上書き）の中に含ませてもよい。 他の代替案としては、全てのタイルについて再度レンダリングをする場合のみキャッシュを破棄し、特定のタイルにレンダリングが必要であると判定した場合には、タイルを上書きすることがあげられる。

【００７１】レンダ・キャッシュ３３０：このオブジェクトは、レンダ・エンジン３２５がタイルをレンダリングした後、レンダリングしたタイルを格納する。 また、
レンダ・キャッシュ３３０は、レンダ・マネージャ３２
５またはレンダ・エンジン３２５からのコマンドに応答して、その中に格納されている古いタイルを捨てることも可能である。 レンダ・キャッシュ３３０を消去すると、レンダ領域を空白にし、それぞれのタイルに有効なレンダリングが得られるまで、何もオブジェクトを表示しないようにするという効果がある。

【００７２】レンダ・ビュー３３５：このオブジェクトは、レンダ領域１７５のサイズおよび位置を指定するコマンドを受け取り、格納し、実施する。 このレンダ領域定義データは、レンダ・エンジン３２５にも入手可能となっており、レンダ・エンジン３２５はこれを用いて、
レンダリングするタイルを決定することができる。 また、レンダ・ビュー・オブジェクト３３５は、レンダリング・オプション、例えば、サンプリングおよび彩色速度を格納する。 レンダリング速度を更に高めることができるレンダリング・オプションの一例は、レンダリングの目的のために、全ての光を、面光ではなく点光としてレンダリングするように指定することである。 後者の方が、レンダリングに要する時間は少なくて済む。 これらのオプションは、レンダ・エンジンに供給しなければならない場合もある。 また、このオブジェクトは、レンダ領域を再定義する場合、ある種のタイルを新たにレンダリングする要求を発行することもできる。 後者の機能は、レンダ・マネージャが処理してもよい。 領域定義データは、レンダ・エンジンに供給することができる（例えば、シーン修正または領域の再定義によって変更する必要があるタイルを判定できるようにする）。 最後に、
レンダ・ビュー・オブジェクトは、新たにレンダリングしたタイルの受け取りに応答して、レンダ・キャッシュからタイルを検索し、領域に彩色する役割も担っている。

【００７３】本発明は、多数の異なる方法で実施可能である。 ここで、図７を参照すると、本発明を実施するプログラムの一実施形態を定義するフローチャートは、並列に実行する３つの独立したスレッドを有する。 ユーザ・インターフェース・スレッド（実際には、この実施形態では、ユーザ・インターフェース・タスクの大きい方の割合を、レンダリング・プロセスにリンクする中間プロセスであり、ユーザ・インターフェースの保守とは別個のスレッドとして動作することができる）は、図７に関連部分を示すが、最初のステップＳ１０においてシーン修正を受け取る。 ステップＳ２０において、受け取ったシーン修正が、表面シェーダ・プロパティのように、
レンダリングの外観に影響を与えるようなものである場合、制御はステップＳ３０に移る。 シーン修正が、シーン・オブジェクト集合化や名称の変更のように、表示してあるレンダリングに全く変更を要しないようなものである場合、制御はステップＳ１０に戻る。 ステップＳ３
０において、シーン修正が性質上グローバルである場合、即ち、レンダ領域１７５におけるあらゆるタイル１
７２に影響を与える場合、制御はステップＳ４０に移る。 その他の場合、制御はＳ５０にスキップする。 ステップＳ４０において、レンダリングを停止するコマンドを、ステップＳ９０におけるレンダリング・プロセスに適用する。 これについては以下で論ずる。 また、ステップＳ４０では、レンダリングしたタイルを格納してあるキャッシュを消去するコマンドも発行する。 これによって、レンダ領域は、空白化するか、あるいは古くなったレンダリングを表示する。 先に論じたように、キャッシュ消去コマンドは、レンダ領域ビュー・オプションに従属する場合があり、その場合、レンダ領域をそのまま残し、有効なタイルをレンダリングする際に、無効のタイルに単に上書きすればよい。 ステップＳ５０において、
レンダリングを停止する。

【００７４】レンダリング・スレッドでは、プロセスは、ステップＳ１００におけるシーン修正の受け取りから始まる。 制御は、ステップＳ６０に移り、ここで、レンダリングする必要のあるタイルを識別し、整列させる。 実際には、キューは、単に再度レンダリングする必要があるタイルのリストとすればよい。 例えば、領域を対応する寸法よりも小さい距離だけ移動させる場合、その領域の一部分のみ再度レンダリングすればよい。 この部分のタイルは、整列させない。 再度レンダリングするタイルを識別するには、例えば、特定のオブジェクトのシェーダを修正する場合に、シーンのどの小部分を再度レンダリングしなければならないかについて決定できるようにする、画素による二次反射をマップする既知の技術を利用するとよいことを注記しておく。 これを決定することができるのは、当該オブジェクトが、画素位置が過去のレンダリングから決定されている、ある他のオブジェクトのみにおいて二次反射を生成するからである。
この技法は、画素タッギング（pixel tagging）と呼び、本発明を実施するには好適なレンダリング技法である。

【００７５】ステップＳ７０において、最後から２番目のシーン修正に基づいてレンダリングすべきタイルの現在のキューを、最新の修正に基づいてレンダリングする必要があるタイルと調和させる。 次いで、制御はステップＳ８０に移り、キュー内の次の（または最初の）タイルのレンダリングを行う。 次に、制御はステップＳ９０
に移り、レンダリング停止コマンドを受け取ったか否かについて判定を行う。 受け取った場合、プロセスは、ステップＳ１００において、新たなシーン修正を待つ。 ステップＳ９０においてレンダリング停止コマンドを受け取らない場合、制御はステップＳ１１０に移り、いずれかのタイルがキューに残っているか否かについて判定を行う。 残っている場合、制御はステップＳ６０に戻り、
残っていない場合、ステップＳ１００に戻る。 レンダ・
スレッド・プロセスに、それを一時停止させる別のプロセスを追加して、レンダ領域の維持以外のユーザ・インターフェースの機能面を維持するために用いる資源を利用しないことを保証する。 これは、容易に実施されるため、図示しない。 また、このフローチャートはステップＳ１００においてシーン修正についてのみ述べているが、位置やサイズのように、レンダ領域に影響を与える変更も、同様に処理することを注記しておく。

【００７６】レンダ領域に示す画像を維持するために必要な最後の並列プロセスは、レンダ領域上への、レンダリングしたタイルのキャッシュの内容の彩色である。 このプロセスは、最新のレンダ領域定義をチェックし、実施することから成る。

【００７７】領域をオブジェクトと接続し、「フリップブック」(flipbook)を生成する際に、その領域がオブジェクトと共に移動し、アニメーション・シーケンスのより素早いプレビューを可能とすることができる。 ここで、図８ａないし図８ｃを参照して、一実施形態について説明する。 アニメーション・シーケンスのビュー４５
０は、３つの時間ステップで示す。 即ち、図８ａに対応する第１の時間ステップ、図８ｂに対応する第２の時間ステップ、および図８ｃに対応する第３の時間ステップである。 単一の三次元プリズム４１０／４２０／４３０
がシーン全体を移動する。 プリズムは、４１０において、第１の時間ステップに対応する位置に示す。 プリズムは、４２０において、第２の時間ステップに対応する位置に示す。 プリズムは、４４０において第３の時間ステップに対応する位置に示す。 カメラ位置を４７０に示す。 放射中央線を４０５で示す。 オブジェクトに対して固定した単一の点ｃを定義する。 移動するレンダ領域４
５５に対する別の単一点ａを定義する。 レンダ領域４５
５は、ビュー４５０に対して移動し、点ａが放射中央線４０５上に留まり、オブジェクト点ｃおよびカメラと結ばれるようにする。 プリズム４１０／４２０／４４０が順方向時間に移動するに連れ、回転し、カメラ４７０から遠ざかるように放射状に移動し、ｘ方向およびｙ方向が入れ替わる。 ビュー４５０およびレンダ領域４５５
は、矩形アパーチャとして図示してあり、カメラに対してどこにでも配置でき、画面上に表示した立体角領域（solid angular region）を表す。 線４００ａ〜４００
ｄは、レンダ領域４５５の角をカメラ４７０と接続する放射線を示す。 時間の進行に連れてプリズム４１０／４
２０／４４０が形状を変化させても、これは何ら問題を生じない。 何故なら、オブジェクトに対して座標系を定義することができ、点ｃは当該オブジェクトの座標系内に固定することができるからである。

【００７８】あるいは、レンダ領域アパーチャ４５５
は、選択したオブジェクトを示すのに十分大きくなるようにこれを生成することによって、移動するオブジェクト４１０／４２０／４００に対して、動的にサイズや位置を決めることができる。 コンピュータは、選択したオブジェクトにレンダリングを行うユーザからのコマンドに動的に応答して、これを行う。 また、例えば、オブジェクトの境界周囲に輝きまたは霞の効果を示すために、
マージンを含むように定義することも可能である。 後者の方法は、ユーザが当該領域を定義し、それをオブジェクトに関係付けるのを簡素化する。 しかしながら、評価する物体の部分のみを対象にする場合、これは便利ではない。 このように、オブジェクト自体の座標系において特定の点を識別することによって、時間が節約できる。

【００７９】レンダ領域のレンダリングは、含まれるシーン全体のレンダリングを含む必要はないことを注記しておく。 例えば、レンダ領域は、選択したオブジェクトまたは複数のオブジェクトのビューティ・パスだけであってもよい。 ビューティ・パスという用語は、レンダリングを特徴付けるものであり、選択したオブジェクト（複数のオブジェクト）のみに実際に現実的レンダリングを行い、残りの部分はレンダリングせずに置いておくか、あるいは抽象的にレンダリングする。

【００８０】本発明は、現実的レンダリングを３Ｄ編集用ユーザ・インターフェースの環境に統合化することを可能にする機構を提供する。 これらの機構は、（１）レンダリングの速度、（２）レンダリング画像の典型的な編集作業環境への相乗的統合（synergistic integratio
n）、（３）時間がかかるレンダリングのプロセスが、
編集用ユーザ・インターフェースを妨害しないことの保証、（４）レンダリングが最少のコンピュータ資源を利用することの保証、および（５）著作者の特定の要望にしたがってレンダリング機構を最適化することに関係する機構に波及効果がある。

【００８１】１）レンダリングの速度：ユーザは、編集の目的に必要な、正確に最も小さいレンダリング領域を定義することができる。

【００８２】レンダリングに影響を及ぼすパラメータの変更のみが、レンダリングを中断させる。 ３Ｄシーンの他の全てのプロパティ（例えば、オブジェクトの名称）
の変更は、進行中のレンダリングに影響を与えない。

【００８３】リフレッシングを必要とするレンダ領域の小部分がレンダリング・プロセスに引き渡され、同じまま残る小部分の再レンダリングを省略する。 レンダ領域画像にショートカットを備えて、レンダリングのプロセスを高速化する。 例えば、ユーザは全ての光源を面光ではなく点光源として処理させる、レンダ領域オプションを実装することができる。

【００８４】レンダリング・プロセスを中断し、新たな更新を、レンダリングのために整列してある以前のあらゆる更新と調和させることによって、冗長なレンダリングの潜在性をなくす。 シーン修正をレンダリング・スレッドに転送する場合、レンダリング・プロセスは、レンダリングしなければならないタイルを識別し、レンダリングのシーンとの対応付けを保証することができる。 これによって、これらのタイルを整列させる（キューは、
おそらく、再度レンダリングすべきタイルを列挙した単なるリストである）。 レンダリングするタイルの識別は、現シーン定義（それ自体のフォーマットで格納してあるか、あるいは共通のシーン定義データ構造から得る）を修正と比較することによって、行うことができる。 次に、レンダリング・プロセスは、シーン定義を更新し（または、これは、共通シーン定義およびレンダリングのプロセスで用いる更新データを維持する外部プロセスによって、行うことも可能である）、この更新データを用いてタイルにレンダリングを行うことができる。
もちろん、キューも更新し、再度レンダリングしなければならないタイルを反映しなければならない。 また、プロセスは、コマンドを発行し、レンダ・キャッシュから無効のタイルを除去し、それらが表示されないようにすることも可能である。 新たな修正をレンダリング・スレッドに送る毎に、現変更を現シーン・データに統合し、
レンダリングに用いるシーン・データが現行（curren
t）であることを確認するまで、レンダリング・スレッドを中断する。 これによって、タイルのレンダリングに使用可能な資源を常に最大効果で使用することが確実となる。

【００８５】２）編集環境へのシームレスかつ相乗的な統合 レンダリング・プロセスの実装により、ユーザ・インターフェースに中断のない優先度（uninterrupted priori
ty）を与えることができる。 これを得るには、レンダリング・プロセスを、並列な独立したプロセスとして分離する。 これによってレンダリング・プロセスがユーザ・
インターフェースのいずれの機構を阻害するのも防止する。

【００８６】レンダ領域は、ワイヤ・フレーム・ビューの上面上に制御点と共に表示することができる。 これは、方向付け（orientation）を与えると共に、領域のサイズ変更および再位置決めを行うための便利なコンテキストを与える。

【００８７】レンダリングは、ユーザによる工程を全く必要とせずに、自動的に表示することができる。 編集コンテキストにおいて通常使用可能な制御には、妨害や阻害を受けるものはない。 実際、レンダリング画像は選択的に呼び出したり隠したりすることができるように与えることができるので、必要であれば、編集画面上のみに提示する（レンダリングは、しかしながら、画面上で彩色しないように連続的に維持することができる）。

【００８８】レンダリングは、二重の並列なワイヤ・フレーム・ビューの一方において表示することができる。
レンダリング領域のないビューは、従来のワイヤ・フレーム・ビューの制御点、ガイド、およびマニピュレータ全てを表示する。 したがって、このビューは、透視図、
オブジェクト操作等を変更するために用いることができ、一方、同時に操作しているワイヤ・フレームと明確に対応する位置に、レンダ画像を表示する（第２のワイヤ・フレーム・ビューは同じシーン透視図を示すという事実のため）。

【００８９】３）レンダリングが編集用ユーザ・インターフェースを妨害しないことの保証 レンダリングは、ユーザ・インターフェースのための支援と並列に行う。 したがって、ユーザ・インターフェース支援タスクは、レンダリングが完了するのを待つ必要はない。

【００９０】ユーザ・インターフェース（従来の編集環境）を支援するスレッドは、レンダリングのリフレッシングを支援するスレッドよりも高い優先度で走る。 これによって、ユーザ・インターフェースが低速化するのを防ぐ。 あるいは、他の何らかの手段によって時間を割り当て、ユーザ・インターフェースが不当な遅延を招くことなく走るための、適切な支援を得ることを保証してもよい。

【００９１】編集環境は、レンダ領域の存在によって大幅に変わることはない。 従来の編集ツールは、従来の環境におけると同様、全て利用可能であり、レンダリング画像は、仮想環境に境目なく嵌め込むことができる。

【００９２】４）レンダリングが最少の資源を利用することの保証 本システムは、新たなシーン修正が入力された場合いつでもレンダリングを中断し、シーン定義を変更することにより、レンダリング装置が無効のシーン定義データのレンダリングによって資源を浪費することを防止する。

【００９３】レンダ領域は、別の場合には冗長となるワイヤ・フレーム・ビューの上に残して置くことができ、
あるいは単一のワイヤ・フレーム・ビュー上に置き、必要に応じて動作状態のままキー・インおよびキー・アウトすることができる。 この実施形態では、基礎となるレンダリング画像を維持し、ワイヤ・フレーム・ビュー上のレンダ領域のみを、呼び出し（invocation）によって彩色する。 この機構は、レンダリングを利用する画面の「面積」（real estate）を最少化する。 こうして、レンダリングしなければならない画素数を削減し、これによって、レンダリングを維持する計算上の要求量も減少させることができる。 レンダリングの解像度は、容易に調節し、レンダリングを維持する計算機の負担を軽減することもできる。 即ち、レンダリングは、多数の隣接する画素、例えば、正方形に集合化した画素で生成し、単一の画素として扱うことによって、レンダリングがモザイクの外見を有するようにすることができる。

【００９４】５）レンダリング機構を著作者の要望に合わせることに関する機構 レンダ領域は、ワイヤ・フレーム上に重ねた、熟知したウインドウを用いて定義する。 この領域は、オブジェクトのサイズ変更や再位置付けを行う、熟知した制御点を都合よく用いることによって、サイズおよび位置を調節することができる。 領域は、矩形または他の要求されたいずれの形状とすることもできる。

【００９５】本発明の特徴によれば、レンダリングは、
シーン内の選択したオブジェクトまたはレイヤに限定することができる。 したがって、レンダ領域は、これらのオブジェクトまたはレイヤ自体に対応する部分のみに、
現実的レンダリングを示し、他の部分は空白のまま残しておく。

【００９６】本発明の別の特徴によれば、レンダ領域のいずれかの部分にレンダリングを行わなかった場合（そして、生のアクション・ショットのようなビットマップ・シーンを、レンダリング領域の背後に表示することは望まないと仮定する）、レンダ領域のこれらの点は、下地の画面が透けて見えるように、彩色することができる。 したがって、レンダ領域がワイヤ・フレーム・ビュー上にある場合、ワイヤ・フレームは、レンダリング・
オブジェクトがないエリアにおいて透視することができる。 このプロセスを、「ゼロ−アルファ複合」と呼ぶ場合もある。 ゼロ−アルファの値は、画素が完全に透明であることを示す画素属性である。

【００９７】レンダリングは、著作者に何も行うことを要求せずとも、表示することができる。 レンダリングは自動的に更新し、それを呼び出すこともそれを更新することも不要である。

【００９８】オーサリング環境には、シーンの２つの並列更新ワイヤ・フレーム・ビューを備えることができる。 スクリーン・ビュー・アングルまたはその他のプロパティを変更し、他のシーンを更新してそれに一致させることができる。 レンダ領域は、これらワイヤ・フレーム・ビューの１つの上に置くことができるので、他のワイヤ・フレーム・ビューは、常に、制御点、ガイド、およびマニピュレータを示す。

【００９９】この明細書の教示を考慮して、種々の代替実施形態を得ることができるが、その多くはここでは論じていない。 例えば、前述の好適な実施形態では、レンダ領域はビューの小部分である。 この領域は、ワイヤ・
フレーム・ビューの一部に重なり、これを定義する。 レンダ領域は、ワイヤ・フレーム・ビューの別個の小部分として定義する必要はなく、別個のビュー内にそれ自体によって収容してもよい。 レンダリング・ビューには、
丁度あらゆるワイヤ・フレーム・ビューと同様に、ズーム、パンおよび回転が可能である。 このビューは、それを呼び出すために余分なステップや時間を必要とせずに、編集環境において視認可能であれば好ましいであろう。 このようなレンダリング・ビューは、別個のワイヤ・フレーム・ビューにリンクすることができるので、ワイヤ・フレーム・ビューのズーム、パンまたは回転を行う場合、レンダリング・ビューは同一のビュー方位を維持する。 また、例えば、レンダリング画像は、常に編集環境に留まっても留まらなくてもよいが、動作状態でキー・インするか、あるいは著作者の促進で他の何らかの方法で呼び出すことができる。 後者のコンテキストでは、レンダリングをメモリに維持しておき、著作者がレンダリング画像を視認することを要求したときにのみこれに彩色することができれば望ましいであろう。

【図面の簡単な説明】

【図１】従来技術による従来のコンピュータ・システムを示す図である。

【図２】２つのワイヤ・フレーム・ビューを、編集コンテキストにおけるシェーダ・エディタと共に表示した、
従来技術のオーサリング環境の一例を示す図である。

【図３】レンダリング画像をプレビュー・コンテキストで示す、従来技術のオーサリング環境の一例を示す図である。

【図４】３つのワイヤ・フレーム・ビューを、レンダリング・プレビュー領域毎に１つずつ、編集コンテキストにおけるシェーダ・エディタと共に表示した、本発明によるオーサリング環境の一例を示す図である。

【図５】本発明の特定の実施形態と共に用いるために、
ビューをどのようにタイルに分解するかを示すラインと共に、３Ｄシーンのワイヤ・フレーム・ビューを示す図である。

【図６】オブジェクトと、本発明の１つの可能なオブジェクト指向実現例に対応するオブジェクトの機能との間のデータ・フローを示すブロック図である。

【図７】本発明の一実施形態と対応付けた、並列プロセスを示すフローチャートである。

【図８】８ａ〜８ｃは、アニメーション・シーケンスおよびオブジェクト追従レンダ領域（object-following r
ender region）の発生を示す図である。

【符号の説明】

４０，６０ ワイヤ・フレーム・ビュー ３０，５０ 投影図 ２０ シェーダ・エディタ ２５ 制御部 １３０ オブジェクト １７０ ビュー １７２ タイル １７５ レンダ領域ウインドウ ３０５ ユーザ・インターフェース・オブジェクト ３１０ レンダ・マネージャ ３２５ レンダ・エンジン ３３０ レンダ・キャッシュ ３３５ レンダ・ビュー・オブジェクト ４０５ 放射中央線 ４１０／４２０／４４０ 三次元プリズム ４５０ アニメーションシーケンスのビュー ４５５ レンダ領域 ４７０ カメラ位置 ９００ パーソナル・コンピュータ ９０１ キーボード ９０１ ポインティング・デバイス ９０６ シリアル・ポート・インターフェース ９０７ モニタ ９０８ ビデオ・アダプタ ９０９ リモート・コンピュータ ９１０ 処理ユニット ９１２ ローカル・エリア・ネットワーク（ＬＡＮ） ９１３ ワイド・エリア・ネットワーク（ＷＡＮ） ９１４ ネットワーク・インターフェース ９１５ モデム ９２０ システム・メモリ ９３０ システム・バス ９４０ リード・オンリ・メモリ（ＲＯＭ） ９５０ ランダム・アクセス・メモリ（ＲＡＭ） ９６０ 基本入出力システム（ＢＩＯＳ） ９７０ ハード・ディスク・ドライブ ９８０ 磁気ディスク・ドライブ ９９０ リムーバブル磁気ディスク ９９１ 光ディスク・ドライブ ９９２ リムーバブル光ディスク ９９２ ハード・ディスク・ドライブ・インターフェース ９９３ 磁気ディスク・ドライブ・インターフェース ９９４ 光ディスク・ドライブ・インターフェース ９９６ アプリケーション・プログラム ９９７ プログラム・モジュール ９９８ プログラム・データ

───────────────────────────────────────────────────── フロントページの続き (71)出願人 397064117 Ｍｅｔｒｏｐｏｌｉｔａｎ Ｔｅｃｈｎｏ ｌｏｇｙ Ｐａｒｋ，Ｏｎｅ Ｐａｒｋ Ｗｅｓｔ，Ｔｅｗｋｓｂｕｒｙ，Ｍａｓｓ ａｃｈｕｓｅｔｔｓ 01876，Ｕｎｉｔｅ ｄ Ｓｔａｔｅｓ ｏｆ Ａｍｅｒｉｃａ (72)発明者 アラン・クアクニーヌ カナダ国エイチ４ダブリュー・１ジー８, ケベック，コート・サン・リュク，ゲルフ 7055 (72)発明者 アレクシス・スミルノフ カナダ国エイチ２ジェイ，ケベック，モン トリオール，セント・ポール・ストリー ト・ウエスト 367，アパートメント ２ (72)発明者 ジャン−マルク・クラトリ フランス共和国75019，パリ，リュー・ド ートプル 25