JPH10511485A - 三次元グラフィックス・レンダリング・システム - Google Patents

Abstract

(57)【要約】 グラフィックス・レンダリング・システムは、レンダラーの選択と独立して、モデルの保存モード構築、編集を可能とする。アプリケーション・プログラムはオブジェクトを描画すべきレンダリング・システムに呼び出しをかけ、描画すべきオブジェクトのみならず、それを行うのに使用されるべきレンダラーも指定する。モデルのの構築あるいは編集中の任意の時点での異なったレンダラーへの切り替えは、アプリケーション・プログラムにとってありふれたことである。２つ以上のレンダラーが同時に活動状態となることができる。グラフィックス・レンダリング・システムは、動的に登録されるレンダラーをサポートするように拡張できる。このシステムは、ジェオメトリが選択されたレンダラーによってサポートされないときにはそれを自動的に決定し、それらのジェオメトリを複数のより簡単なジェオメトリのオブジェクトに分解する。このシステムは、画面を完成するのにレンダラーが何回のパスを必要とするかを知る必要なしに、アプリケーション・プログラムに即時モード呼び出しあるいは保存モード呼び出しを行わせてモデルをレンダリングさせる。アプリケーション・プログラムがレンダリング・サブシステムを呼び出してモデルを描画するとき、レンダリング・サブシステムは、モデルのレンダリングが完了したかどうかを示す再トラバース・フラグを返す。もしこのフラグがレンダリングがまだ完了していないことを示す場合には、アプリケーション・プログラムは、再び、レンダリング・サブシステムを呼び出してモデルを描画する。

Description

【発明の詳細な説明】 三次元グラフィックス・レンダリング・システム 制限付き著作権放棄 この特許書類の開示内容の一部は著作権保護の権利主張がなされる資料を含ん でいる。著作権所有者は米国特許・商標局ファイルあるいは記録に見られるよう に特許開示の特許書類のいかなる者によるファクシミリ再生についても異議を持 たないが、他のいかなるものであってもすべての権利を留保する。 背景 １．発明の分野 本発明は、グラフィックス・レンダリング・システム、一層詳しくは、グラフ ィックス・アプリケーション開発者をサポートするためのソフトウェア・ツール に関する。 ２．関連技術の説明 グラフィックス・レンダリングとは、三次元幾何学的形状から二次元像（ある いは像の一部）を演算するプロセスである。オブジェクトのポイントをそれぞれ 少なくとも３つの座標（オブジェクトが三次元全体で厚みを持つか持たないかに よる）で指定された場合には、ここではオブジェクトは三次元であると考える。 レンダラーとは、呼び出しに応じてグラフィックス・レンダリング作業を実施す るツールのことである。いくつかのレンダラーはもっぱらソフトウェアであるが 、或るものはもっぱらハードウェアであり、或るものはこれらの組み合わせを用 いて実施される（たとえば、ハードウェアサポートまたはハードウェア加速を備 えたソフトウェア）。レンダラーは、代表的には、画面をバッファにレンダリン グし、それが後にグラフィカル出力装置に出力されるが、いくつかのレンダラー はそれらの二次元出力を出力装置に直接書き込むことができる。ここで用いるグ ラフィックス・レンダリング・システム（またはサブシステム）とは、アプリケ ーション・プログラムとグラフィカル出力装置の間の処理レベルのすべてを呼ぶ 。多くの従来システムにおいて、グラフィックス・レンダリング・システムはレ ンダラーと同じ広がりを有する。すなわち、レンダラーは、なんらの介在処理層 な しにアプリケーション・プログラムによって直接呼び出される。 グラフィックス・レンダリング・システムは、代表的には、アプリケーション ・プログラムへの即時モード・インターフェイスまたは保存モード・インターフ ェイスを特徴とする。即時モード・インターフェイスとは、イメージをレンダリ ングしようとする毎にアプリケーション・プログラムが各幾何学的プリミティブ をグラフィックス・レンダリング・システムに対して指定する正確な手続きイン ターフェイスである。レンダリング・システムが画面毎にモデル・データベース を保持することはなく、それを行うのはアプリケーション・プログラムである可 能性がある。即時モード・インターフェイスは、モデルをフレーム毎に変える画 面をレンダリングする場合、たとえば、シミュレーションの視覚化、アニメーシ ョン・シーケンスのプレビューあるいは１つのファイルからの一連のモデルの読 み出しの場合に非常に魅力的である。一方、即時モード・インターフェイスでは 、プロシジャを経て伝えられる全画面がフレーム毎にレンダラーに呼び出しをか けなければならず、その結果、アプリケーション・プログラムとレンダラーの間 のデータ帯域幅が大きくなる。また、１つのモデルについてのファイル・フォー マットがモデルそれ自体と違って描画コマンドのストリームにすぎないことが多 く、データ交換フォーマットとしての有効性が限られる。即時モード・インター フェイスは、また、アプリケーション・プログラムにツールキット・モデリング 機能性を与えるには伝導性が低く、通常は、画面内のオブジェクトに働きかける ユーザ・インターフェイス・ツールキットの邪魔をする。 保存モード・システム（時に表示リスト・システムと呼ばれる）では、グラフ ィックス・レンダリング・システムは三次元モデルのデータベース表現を保持す る。フレーム毎に、レンダリング・システムは保存モデル・データベースをトラ バースし、それを描画する。これは、全画面を記述する描画呼び出しのストリー ムではなくて、アプリケーション・プログラムからグラフィックス・レンダリン グ・システムへのたった一回の呼び出しによって行われ得る。モデルが変わると き、アプリケーション・プログラムはモデル・データベースを編集あるいは更新 し、再びレンダリング・システムに問い合わせを行って画面をレンダリングする 。保存モード・システムの利点は、アプリケーション・プログラムと任意のハー ド ウェア・アクセラレータとの間の帯域幅を縮小するということである。モデル・ データベースのファイル・フォーマットは、それが単なるプロシジャ呼び出しの リストではないので、データ交換フォーマットとしても使いやすい。オブジェク ト・データベースの存在も、ユーザ・インターフェイス・ツールキット／モデリ ング機能を具現する付加的な方法を提供する。保存モデル・レンダラーはレンダ リング情報もキャッシュできるし、画面移動の最適化のための情報もキャッシュ できる。一方、保存モード・レンダリング・システムは画面データベースを編集 するためのオーバーヘッドがより高く、画面をシステム定義データ構造、通常は 、階層に強制することによってアプリケーション・プログラム・デザインを制限 し、したがって、多くのアプリケーション・プログラムがモデルのコピーをそれ 自体のフォーマットで保持しなければならない。 ここに参考資料として援用するMark A．Tarlton and P．Nong Tarlton，“A F ramework for Dynamic Visual Applications”,Proceedings of the 1992 Sympo sium on Interactive 3D Graphics，Cambridge，MA，1992，pp．161-164には、 汎用データベース・システムを備え、モデルを単一のシステム・階層に帰属させ るのではなくてモデルを組織化する保存モード・レンダリング・システムが記載 されている。この技術は欠点のない保存モード・システムの利点を得ることを試 みている。 この高レベル機構は、すべてのアプリケーションについてのモデル組織化問題 を解決することはできず、画面をフレーム毎に変える視覚化アプリケーションに とって最適でもない。 従来のグラフィックス・レンダリング・システムはいろいろな方法でそれらの 有用性を制限する多数の付加的な問題を有する。以下のリストは現在入手可能な グラフィックス・レンダリング・システムのいくつかを示している。ＧＬ^TM ． Silicon GraphicsのＧＬは主として対話式グラフィックスのために用 いられる即時モード・レンダラーである。ＧＬは、ここに参考資料として援用す る“Graphics Library Programming Guide”，Silicon Graphics Computer Syst ems，1991に記載されている。これは、Silicon Graphics IRIS レンダリング・ ハードウェアに対するインターフェイスとして設計されており、ファイル・ フォーマット、ハードコピー出力、モデリング能力あるいはユーザ・インターフ ェイス・ツールは用意していない。ＧＬはＧＬコマンドのシーケンスにとって本 質的にマクロである単純なディスプレイ・リストをサポートしている。ＧＬルー チンはＩＲＩＳハードウェアにコマンドを発行することによってレンダリング作 業を実施する。 StarBase^TM ． Hewlett-Packard のStarBaseは、ＧＬに非常に類似しており、 その特徴および欠陥の大部分を共有する即時モード・システムである。StarBase は、参考資料としてここに援用する“Starbase Graphics Techniques，Hewlett- Pachard Company”，1991 に記載されている。プロッタからハイエンド３Ｄグラ フィックス・ワークステーションまでの種々のグラフィックス出力装置でレンダ リングした（すなわち、二次元の）画面を出力するためにStarBaseでは数多くの デバイス・ドライバを利用できる。 RenderMan^TM ． PixarによるRenderMan は、主として高品質レンダリングをサ ポートするために設計された即時モード・システムである。RenderManは、ここ に参考資料として援用するSteve Upstill“The RenderMan Companion”，Addiso n-Wesley，Reading，MA，1990に記載されている。参考資料としてここに援用す るTony Apodaca，“RenderMan Interface Specification Version 4.0 Beta”， January，1992に記載されているように、RenderMan specificationの最近のバー ジョンが、現存のRenderMan呼び出しを大括弧でくくり、種々のレンダラーを使 用可能とする新しいルーチンを提供している。レンダラーは画面をレンダリング する前にただ一回の呼び出しで指定され、それが全画面に作用する。また、個々 に参考資料として援用するPixar，“Quick RenderMan Interface and Implement ation Specification”,1992も参照されたい。 PHIGS． PHIGS は、ここに参考資料として援用するPHIGS Committee，A．van Dam，chair，“PHIGS Functional Description，Revision 3.0”，Computer Gra phics，22(3)，1988，pp．125-218に記載されており、またここに参考資料とし て援用するInternational Standards Organization，“International Standard Information Processing Systems Computer Graphics-Graphical Kernel Syste m for Three Dimensions（GKS-3D）Functional Description”，ISO Document Number 8805:1988(E)，American National Standards Institute，New York，1988に記載されているＧＫＳ−３Ｄの派生である。PHIGSは対話式３−Ｄ グラフィックス表示の委員会設計システムである。PHIGSでは、モデル・データ ベース全体がただ１つの階層内に存在する。アプリケーション・プログラマーは 、システムを効果的に使用するためには編集・階層操作呼び出しのホストを学習 しなければならない。PHIGSは、その中で利用できるとして指定されたレンダリ ング・モードのすべてをサポートするただ１つのレンダラーを使用し、フォトリ アリズムその他のエフェクトのための代替レンダラーをサポートしない。 PEX． PEX は、シリアル・プロトコル（アプリケーション・プログラムとX-W indowsシステムの間でデータを伝送するためのもの）と、PHIGSから初めに導き 出された１セットのセマンティクスとによって定義されるX-Windows システムの 拡張である。PEXはいくつかの利用できるAPIを有し、これらすべてのAPIが描画 、状態変更などを行うための保存モード、即時モード、混合モード機能呼び出し をサポートする。PEX は、ここに参考資料として援用する“PEX Protocol Speci fication，Version 5.0P-X Public Review Draft”，14 September，1990，Mass achusetts Institute of Technologyに記載されている。HOOPS^TM ． Ithaca Software のHOOPS は、ここに参考資料として援用するGarry Wiegand and Bob Covey，“HOOPS Reference Manual，Version 3.0”，Ithaca S oftware，1991に記載されている。これは保存モード３−Ｄグラフィックス・シ ステムであり、モデルを或る階層に組織化し、この階層のノードを、UNIXファイ ル・システムのファイルを参照するのとほとんど同じ方法でテキスト・ストリン グを介してアクセスするのである。PHIGSと同様に、HOOPSもただ１つのレンダラ ーをサポートする。しかしながら、HOOPSはPHIGSよりも広がりの大きい画面編集 機能を提供する。 Programmer's Guide”，Release 5.0，Kubota Pacific Computer Inc.，1991に 記 モノリシック・レンダラーではなくて、多種類のレンダラーによってレンダリン グできるように設計されている。しかしながら、複数のレンダラーは、レンダリ レンダリング前にビュー・オブジェクトにモデルを貼り付けるのにアプリケーシ ように制限する他のデザイン状の問題もある。たとえば、レンダリング状態を維 持するのに１セットの大域変数しか与えられないのである。 なりの部分を軽減し、また、ダイナミック・データベースおよびユーザ対話を容 ートし、それによって、画面移動中にコールバック・オブジェクトに遭遇したと きにアプリケーション・プログラムが呼び出されるべき機能を定義する。 Inventor^TM ． InventorはＧＬグラフィックス・システムのトップに位置する オブジェクト指向型３−Ｄグラフィックス・ユーザ対話ツールキットである。 ー」方法を持たせることによって多数のレンダラーをサポートしている。 Inventorは「scene graph」に全画面が存在する保存モード・システムである。I nventorは１つのパラメータとして１つのモデルを採用するレンダー・アクショ ン・オブジェクトを有する。レンダラーは、モデルを描画するときに用いられる レンダリング・アクションによって選択される。レンダー・アクションは、モデ ルをトラバースし、オブジェクト毎に適切なレンダリング方法を呼び出すことに よってモデル全体を描画する。通常のレンダー・アクションはＧＬレンダリング ・モードである。Inventorは、ここに参考資料として援用するWerneche，“The Inventor Mentor”，Addison-Wasley（1994）に記載されている。 ここでの開示内容に関連した他の参考資料としては以下のものがあるが、これ らはすべて本明細書に援用する。すなわち、Bergman，Fuchs and Grant，“Imag e Rendering by Adaptive Refinement”，Computer Graphics，20(4)，1986，pp . 29-37; Catmull，“A Subdivision Algorithm for Computer Display of Curved Surfaces”，Ph.D．Thesis，Report UTEC-CSc-74-133，Computer Science Depa rtment，University of Utah，Salt Lake City，UT，December，1974; Chen，Ru shmeier，Miller，and Turner，“A Progressive Multi-Pass Method for Globa l Illumination”，Computer Graphics，25(4)，1991，pp．165-174; Clark，“ The Geometry Engine: A VLSI Geometry System for Graphics，”Computer Gra phics，16(3)，1982，pp．127-133; Foley，van Dam，Feiner，and Hughes，“C omputer Graphics: Principles and Practice”，Addison-Wesley，Reading，MA ，1990; Haaberli and Akeley,“The Accumulation Buffer: Hardware Support for High-Quality Rendering”，Computer Graphics,24(4)，1990，pp．309-318 ; Kelley，Winner，and Gould，“A Scalable Hardware Render Accelerator us inga Modified Scanline Algorithm”，Computer Graphics，26(2)，1992，pp． 241-248; Maillot，“Three-Dimensional Homogeneous Clipping of Triangle S trips”，Graphics Gems II，Academic Press，Inc.，San Diego，CA，1991，pp ．219-231; Newell，Newell，and Sancha，“A Solution to the Hidden Surfac e Problem”，Proceedings of the ACM National Conference，1972，pp．443-4 50; Potmesil and Hoffert，“FRAMES: Software Tools for Modeling，Renderi ng，and Animation of 3D Scenes”，Computer Graphics，21(4)，1987，pp．85 -93; Saito and Takahashi，“Comprehensible Rendering of 3-D Shapes”，Co mputer Graphics，24(4)，1990，pp．197-206; Segal，Korobkin，van Widenfel t，Foran．and Haeberli，“Fast Shadows and Lighting Effects Using Textur e Mapping”，Cemputer Graphics，26(2)，1992．pp．249-252; Sillion and Pu ech，“A General Two-Pass Method Integrating Specular and Diffuse Reflec tion”，Computer Graphics，23(3)，1989，pp．335-344; Snibbe，Herndon，Ro bbins，Conner，and van Dam，“Using Deformations to Explore 3D Widget De sign”，Camputer Graphics，26(2)，1992，pp．351-352; Strauss and Carey， “An Object-Oriented 3D Graphics Toolkit”，Computer Graphics，26(2)，19 92，pp．341-349; Turkowski，“Design Considerations for an object-Orient ed［3D Graphics］Metafile”，Proceedings of the Third Eurographics Works hop on Object-Oriented Graphics，Charnpery，Switzerland，October，1992，pp．163 -169; Venolia，“Facile 3D Direct Manipulation”，to appear in Proceedin gs of CHI’93，ACM/SIGCHI，Amsterdam．May，1993; Venolia，“Automatic Al ighnment in Two and Three Dimensions”，submitted to SIGGRAP’93; Wanger ，“The Effect of Shadow Quality on the Perception of Spatial Relationsh ips in Computer Generate Imagery”，Proceedings of the 1992 Symposium on Interactive 3D Graphics，Cambridge，MA，1992，pp．3942 である。 種々のレンダラーを用いてモデルを描画することができると望ましい。たとえ ば、三次元モデルの対話式編集を行えるアプリケーション・プログラムは、高速 低品質ワイヤフレーム・レンダラーを用いてディスプレイ上に中間バージョンを 描画することによって、また、高品質低速Ｚバッファ・レンダラーを用いてプリ ンタで最終バージョンを描画することによって利益を得ることができる。しかし ながら、上記のレンダリング・システムを使用すると、レンダラーの互換性が最 も扱いにくい。特に、上記レンダリング・システムのいくつかは２つ以上のレン は選ばれたレンダラーをシステム構成内に結合する。したがって、同じ三次元モ デルについて異なった目的のために異なったレンダラーを使用できるような融通 性の高いグラフィックス・レンダリング・システムが要望されている。 上記レンダリング・システムに伴う別の問題は、同時に活動状態にある２つ以 上のレンダラーをサポートしないということである。ディスプレイとプリンタの 両方に同時にイメージ出力することを含めて、多数のシチュエーションで１つの モデルを同時にレンダリングすることが望ましい。別の例として、同じディスプ レイの２つの異なった部分に同時に１つのモデルの２つの異なったイメージをレ ンダリングすることが望ましい場合もある。同時レンダリングは、主として、ア プリケーション・プログラムがレンダリング・システムに呼び出しの１シーケン スを行うことによってイメージを描画する即時モード・システムにおいて望まし いであろう。このようなシステムでは、多くのアプリケーション・プログラムが 、１つのレンダラーのための呼び出しを別のレンダラーのための呼び出しシーケ ン スと一緒に点在させることによってより効果的に実行することができる。従来の システムはこのような点在する呼び出しシーケンスを妨げる。 上記レンダリング・システムに伴うまた別の問題は、２つ以上のレンダラーを サポートしたこれらのシステムがすべてのレンダラーが少なくとも同じジェオメ トリをサポートすることを要求するということである。たとえば、Inventorレン ダリング・システムは点、線および或る種の他の予定義された形状をレンダリン グすることができるレンダラーしかサポートできない。もっと単純なレンダラー はInventorと一緒には使用できない。少なくともフルセットのInventor幾何学的 プリミティブをサポートしてるならば、もっと有能なレンダラーを使用できるが 、これらのレンダラーが動的に追加されることはない。アプリケーション・プロ グラムは優先的にこれらのレンダラーに気がつかなければならないであろう。上 記のレンダリング・システムは、レンダラーの特徴の自動検知、利用で多少の有 能なレンダラーの「プラグイン」レンダリングを行えなかった。 上記レンダリング・システムに伴うまた別の問題は、マルチパス・レンダリン グを良くサポートしないということである。すなわち、本質的に、即時モード・ レンダリングおよび混合モード・レンダリングをサポートするシステムではない のである。マルチパス・レンダラーとは、画面データベースの多数回トラバース を必要とするように設計したものである。何故レンダラーを画面データベースに ついて多数回パスさせるように設計したかという理由は多数ある。たとえば、非 常に高い解像度でレンダリングする場合にフレーム・バッファ全体をレンダリン グするに充分なメモリがないかもしれないのである。レンダラーは、フレーム・ バッファをストリップに分離し、各ストリップを個別のパスを経て画面データベ ースを通してレンダリングすることになる。別の例としては、イメージをそれぞ れが異なった解像度の複数のデバイスにレンダリングしている場合（たとえば、 １つのウィンドウが２つのモニタにまたがっているときあるいは１つのイメージ をスクリーンと高解像度プリンタの両方にレンダリングしているとき）、レンダ ラーは一回の個別のパスで各デバイスをレンダリングすることができる。別の例 として、漸進改善を行うレンダラーは画面データベースに対して複数回のパスを 行って、プロセスがユーザ・アクションで停止させられるか、あるいはイメージ が最高の品質になるまで最終的なイメージを連続的に改善することができる。ま た別の例としては、蓄積バッファやシャドウイング、ライティング・エフェクト を創り出すためのテクスチャ・マッピングの使用、２パス式グローバル・イルミ ネーション技術を必要とする高品質レンダリング・アルゴリズムがある。 保存モード・システムでは、アプリケーション・プログラムは、通常、レンダ ラーがそのレンダリングを完了するのに２回以上のパスを必要としているかどう かを知る必要がない。これは、アプリケーション・プログラムが１回だけの呼び 出しを行ってレンダラーにモデルをレンダリングさせ、アプリケーション・プロ グラムに戻る前に必要なだけのパスをレンダラーが行えるからである。一方、即 時モード・システムあるいは混合モード・システムでは、アプリケーション・プ ログラムはモデルをトラバースする際に一部を実施し、レンダラーに複数回の呼 び出しを行ってただ１回のトラバースを達成する。したがって、多数回パス型レ ンダラーの場合、アプリケーション・プログラムは、画面を完成するにはモデル を何回トラバースするかを知っている必要がある。これには、レンダラーについ ての詳細な知識をアプリケーション・プログラムが持つことが必要であり、本質 的に互換性のあるレンダラーをサポートするのは非常に難しくなる。 上記システムに伴うまた別の問題は、三次元モデルを表示のために画面内にレ ンダリングしようとしているとき、一方ではレンダリング作業の速度、他方では 結果の品質で古典的なトレイドオフが存在するということである。たとえば、ワ イヤフレーム・レンダリング作業は高速であるが、低品質の結果を作り出し、そ れに対して、レイ・トレイサーは同じモデルをレンダリングするのにかなり長い 時間を要するが、結果はきわめて高品質であり得るということである。こうして 、三次元モデルの対話編集を可能とするアプリケーション・プログラムは、ワイ ヤフレーム・レンダラーを用いてディスプレイ上に中間バージョンを描画し、レ イ・トレイサー・レンダラーを用いて出力用の最終バージョンを描画することに よって利益を得ることができる。しかしながら、レンダラーの互換性が上記のレ ンダリング・システムを用いると最も悪いことになる。さらに、或るレンダラー を別のレンダラーに交代させると、速度／品質トレイドオフ連続体上にグロス制 御しか与えない。品質を少し犠牲にして速度を少し向上させる、あるいはその逆 を 行うためのアプリケーション・プログラムが望まれる。速度／品質トレイドオフ 連続体に複数のグラデーションを与え、ユーザあるいはアプリケーション・プロ グラムがトレイドオフにおいて正確に所望の位置を選べることが望ましい。 過去において、アプリケーション・プログラムは、ユーザにレンダリング・プ ロセスの種々の副次的なパラメータについて制御を行わせ、ユーザは副次効果と して速度／品質トレイドオフに影響を与えるオプションを選択することによって この制御の利点を享受してきた。たとえば、或る光を一時的に切ることによって 、ユーザは品質を犠牲にしてレンダリング・プロセスを進めることができる。同 じ効果を達成するには、出力ウィンドウを小さくし、この選択を許すレンダラー について塗りつぶしモードをエッジ・モードに切り替え、より粗いアンチエイリ アシング・レベルを設定することによってレンダリング前に画面からオブジェク トを抜粋していた。いくつかのシステムでは、速度／品質トレイドオフに影響を 与えるパラメータのいくつかがただ１つのダイアログ・ボックスにおいてユーザ によるアクセスが可能となり、この場合、ユーザは制御可能なパラメータの各々 についてオプションを選択できる。これは上記問題についての非常に断片的なア プローチである。他のアプリケーション・プログラムは、ユーザがレンダリング のためのグロス品質を選ぶことを許すが、通常は、このユーザの選択はプログラ ムに完全に異なったレンダラーを呼び出させるか、あるいは、少なくともレンダ ラーに非常に異なったレンダリング方法を使用させる。連続体に比較的精密な解 像度を与えると共に、個々のレンダリング・パラメータと関係させることなく速 度／品質レンダリング・トレイドオフ全体において所望の点をアブリケーション ・プログラムあるいはユーザが選択できるようにした品質制御機構が必要である 。 発明の概要 本発明によれば、大雑把に言って、グラフィックス・レンダリング・システム は、レンダラーの選択とは独立してモデルの保存モード構築および編集を行える 。オブジェクトを描画するためにレンダリング・システムをアプリケーション・ プログラム呼び出しすることによって描画すべきオブジェクトを指定するばかり でなく、レンダラーを使用してそれを行い得る。一実施例において、レンダラー は ＡＰＩを通じてレンダリング・システムに識別されるより包括的な「ビュー・オ ブジェクト」の一部として指定される。こうして、モデルの構築あるいは編集中 の任意の時点で異なったレンダラーへの切り替えがアプリケーション・プログラ ムのためのありふれた仕事となる。 本発明の別の局面において、グラフィックス・レンダリング・システムは、二 つ以上のレンダラーを同時に活動状態にすることができる。一実施例において、 これは、レンダリング・システムを呼び出して三次元オブジェクトを描画させる ときにアプリケーション・プログラムが指定するそれぞれの「ビュー・オブジェ クト（または複数のオブジェクト）」において各レンダラーについてのカレント ・レンダリング状態を記憶することによって行われる。 本発明の別の局面においては、グラフィックス・レンダリング・システムは動 的に登録したレンダラーをサポートするように拡張可能である。 本発明の別の局面においては、グラフィックス・レンダリング・システムは、 ジェオメトリが選定されたレンダラーによってサポートされていないときにそれ を自動的に検出し、このようなジェオメトリを複数の単純なジェオメトリのオブ ジェクトに自動的に分解する。この自動分解は、そのジェオメトリが選ばれたレ ンダラーによってサポートされたオブジェクトに到達するまで帰納的に実施され 得る。 本発明の別の局面においては、グラフィックス・レンダリング・システムは、 レンダラーが外面を完成するのに何回のパスを必要とするかを知る必要なしにア プリケーション・プログラムをモデルをレンダリングするために即時モード呼び 出しあるいは保存モード呼び出しにすることができる。一実施例において、アプ リケーション・プログラムはモデルを描画するのにレンダリング・サブシステム を呼び出し、このレンダリング・サブシステムがモデルのレンダリングが完了し たかどうかを示すフラグ（ここでは、リトラバース・フラグと呼ぶ）を返す。も しこのフラグがレンダリングがまだ完了していないということを示す場合には、 アプリケーション・プログラムはレンダリング・サブシステムを再び呼び出して モデルを描画することができる。好ましくは、レンダリング・サブシステムへの 呼び出しはアプリケーション・プログラム内のループの中に置かれ、このループ がリトラバース・フラグが完了を示すまで繰り返される。この技術は、ループが レンダリング・サブシステムへの多くの呼び出しを含むことができ、そのすべて がモデルそのものをトラバースする際にアプリケーション・プログラムによって 行われるため、即時モード・レンダリング、混合モード・レンダリングをサポー トする。リトラバース・フラグがレンダリングがまだ終わっていないことを示す とき、アプリケーション・プログラムは同じシーケンスの呼び出しを繰り返し、 モデルを効果的にリトラバースする。 本発明の別の局面においては、アプリケーション・プログラムは、オブジェク トを描画するためにレンダリング・システムに行われるアプリケーション・プロ グラム呼び出しは描画すべきオブジェクトを特定するばかりでなく、レンダラー を使用してそれを行う。こうして、モデルの構築あるいは編集中の任意の時点で の異なったレンダラーへの切り替えはアプリケーション・プログラムにとってあ りきたりの仕事となる。リトラバース・フラグの故に、アプリケーション・プロ グラムは、新しいレンダラーがレンダリングを完了するのに多数回のパスを必要 とするかどうかに依存して、任意の付加的な割り当てをなす必要がない。 本発明の別の局面においては、グラフィックス・レンダリング・システムは、 ２つ以上のレンダラーを同時に活動状態にすることができる。一実施例において 、これは、レンダリング・システムを呼び出して三次元オブジェクトを描画する ときにアプリケーション・プログラムが指定するそれぞれの「ビュー・オブジェ クト（あるいは複数のオブジェクト）」においてレンダラー毎にカレント・レン ダリング状態を記憶することによって達成される。ここでふたたび、リトラバー ス・フラグは、１つまたはそれ以上の同時に活動状態のレンダラーがレンダリン グを完了するのに複数回のパスを必要とする場合にアプリケーション・プログラ ムが特別の割り当てをなす必要性をなくす。 本発明の別の局面においては、グラフィックス・レンダリング・システムは、 動的に登録されたレンダラーをサポートするように拡張できる。ここで再び、リ トラバース・フラグのために、新しく登録されたレンダラーがただ１つのレンダ ラーあるいは多数回パスレンダラーとなるという制限がまったくない。 本発明のまた別の局面においては、連続体について比較的精密な解像度を持っ て、そして、個別のレンダリング・パラメータと関係することなく、速度／品質 レンダリング・トレイドオフ全体においてアプリケーション・プログラムあるい はユーザが所望の点を選択できる機構を得ることができる。これを達成するグラ フィックス・レンダリング・システムは品質制御データ・グループの連続体ある いは収集体を含み、その各々が複数の品質制御タイプ変数を含む。タイプ変数の 各々は、レンダリング品質とレンダリング速度の間のそれぞれのトレイドオフに おいて複数のオプションを選択する値を含む。たとえば、品質制御データ・グル ープの各々は「詳細レベル」についての品質制御タイプ変数を含み得るし、これ らのグループが品質連続体の下端でこれらの変数を「low」に設定し得るし、そ れに対して連続体のより高い端ではデータ・グループがこの変数を「high」に設 定し得る。 本発明の別の局面においては、品質制御データ・グループの各々はそれぞれの 品質インデックスと関連付けられる。こうすると、アプリケーション・プログラ ムは、品質制御インデックス値を選ぶだけで速度／品質レンダリング・トレイド オフ全体の１点を選ぶことができる。さらに、アプリケーション・プログラムは 、たとえば、アイコニック「品質ノブ」として直感的な形態で品質制御インデッ クスをユーザ・アクセス可能とすることができる。品質ノブは複数の設定値、た とえば、0.0〜1.0の範囲の設定値を持つことができる。これらの設定値の各々は 品質制御データ・グループのそれぞれに対応する。こうして、この機構により、 ユーザは、個別のレンダリング・パラメータに対する調節に関係することなく、 速度／品質レンダリング・トレイドオフについて精密な管理を行うことができる 。 図面の簡単な説明 以下、本発明を特別な実施例に関連して説明し、図面も参照する。図面におい て、 第１図は、本発明を具現するコンピュータ・システムの簡略ブロック図である 。 第２図は、本発明を具現するソフトウェア・アーキテクチャを示す。 第３図は、本発明を使用するプログラムの全体的な流れを示すフローチャート である。 第４図は、第３図のステップ３０８の詳細である。 第５、７、９、１１、１２図は、メモリ内のオブジェクト・データ構造を示す 。 第６図は、本発明の一実施例で使用されるクラス・アーキテクチャを示す。 第８図は、本発明を使用するプログラム例によって作られるモデル階層を示す 。 第１０図は、メモリ内の新しいオブジェクトの創作を示すフローチャートであ る。 第１３図は、品質コレクションをセットアップするアプリケーション・プログ ラム・プロシジャのフローチャートである。 第１４図は、所望の品質インデックスを得るためのアプリケーション・プログ ラム・プロシジャのフローチャートである。 第１５図は、表示アイコンの説明図である。 第１６図は、或るレンダラーに置ける或るプロシジャのフローシートである。 詳細な説明 第１図は本発明を具現するコンピュータ・システムの簡略ブロック図である。 或る種のタイプのコンピュータ・アーキテクチャは他よりも良好な発明の利点を 得ることができるが、本発明は事実上任意タイプのアーキテクチャについて実行 することができる。第１図のアーキテクチャにおいて、ＣＰＵ１０２、メモリ１ ０４およびＩ／Ｏサブシステム１０６はすべてバス１０８に接続している。ＣＰ Ｕ１０２は、メモリ１０４あるいはＩ／Ｏサブシステム１０６に対して読み出し 、書き込みを行うためにバス１０８を通して信号を発行し、ここに説明する要領 でデータを操作する。ＣＰＵは、メモリ１０４から得るソフトウェア命令に応答 してこれらの信号を発行する。Ｉ／Ｏサブシステム１０６も、或る特定の実施例 では、メモリ１０４にアクセスするためにバス１０８を通して信号を発行するこ とができる。システムは、グラフィックス・コプロセッサ１１０も包含し得る。 このコプロセッサはイメージをレンダリングするのに必要なメモリ集中作業の多 くをＣＰＵ１０２からオフロードすることができる。このようなシチュエーショ ンにおいて、第１図に１１４で示すディスプレイは、しばしば、Ｉ／Ｏサブシス テム１０６によって駆動される。他のシステムでは、グラフィック・アクセラレ ータ１１２がバス１０８とディスプレイ１１４に接続してある。これらのシ ステムにおいて、ディスプレイ・バッファは、代表的には、グラフィック・アク セラレータ１１２の中に保持される。このアクセラレータは、ＣＰＵ１０２によ って要求されたときとかにディスプレイ１１４の特定のピクセルに特定の属性（ たとえば、カラー）を書き込むことができるばかりでなく、ＣＰＵ１０２のコマ ンドの下にディスプレイ１１４上により複雑なプリミティブを描画することもで きる。 本発明は、本実施例では、Escherとここでは呼ぶ１セットのソフトウェア・ツ ールの形で実行される。これらのソフトウェア・ツールは、１セットのソフトウ ェア・プロシジャと１セットのヘッダ・ファイルとを包含し、これらがプロシジ ャで使用される変数名称、データ構造を定義する。Escherは、記憶媒体（たとえ ば、磁気ディスクあるいは光ディスク）上のアプリケーション・プログラム・デ ィベロッパに与えられる。一実施例において、記憶媒体はEscherのためのソース ・コードを含み、別の実施例では、記憶媒体はEscherのための或る種のソース・ コードと或る種のオブジェクト・コードとを含む。アプリケーション・ディベロ ッパはアプリケーション・プログラムをEscherおよび１つまたはそれ以上のレン ダラーでコンパイルし、それで得たオブジェクト・コードを記憶媒体上に保存す る。組み合わせオブジェクト・コードは後に全体的にあるいはオーバーレイ様式 でメモリ１０４に読み込まれ、CPU１０２によって実行される。 ここで、「メモ」内にあるものとしてここで言及されるソフトウェアおよびデ ータが、任意の時点で、ディスクのような二次記憶媒体内に全体的あるいは部分 的に実際に存在し得ることに注目されたい。このシチュエーションは、たとえば 、オーバーレイ実行あるいは仮想メモリのようなアーキテクチャにより生じ得る 。簡略化のために、ここでは、このようなソフトエアおよびデータのすべては、 たとえ時には実際に一時的にどこかに存在し得るとしても、すべての適切な時点 で「メモリ内」に存在すると考える。 第２図は、ソフトウェア・アーキテクチャ内のEscherの論理位置を示す。ここ でわかるように、論理的に、Escherプロシジャ２０２はアプリケーション・プロ グラム２０４と複数のレンダラー２０６、２０８、２１０との間に配置してある 。すなわち、アプリケーション・プログラム２０４はアプリケーション・プログ ラ ム・インターフェイス（ＡＰＩ）を経てEscherプロシジャにプロシジャ呼び出し を行い、Escher内の或る種のプロシジャ（特に、或る種のレンダラー呼び出しプ ロシジャ２１２）はレンダラー２０６、２０８、２１０にプロシジャ呼び出しを 行う。レンダラー呼び出しプロシジャ２１２に呼び出しを行うとき、アプリケー ション・プログラム２０４はレンダラー呼び出しプロシジャがどのレンダラーを 使用すべきかを指定する。次いで、レンダラーは、ディスプレイ・バッファ・メ モリ、グラフィックス・コプロセッサ１１０（もし存在するならば）、グラフィ ック・アクセラレータ１１２（もし存在するならば）などのようなプラットホー ムの他のハードウェア・コンポーネント２１４と連絡を取る。レンダラー呼び出 しプロシジャ２１２に加えて、Escherプロシジャは、レンダラー・インストレー ション・プロシジャ２１６、品質制御管理プロシジャ２１７、モデル構築・編集 プロシジャ２１８、ビュー構築・編集プロシジャ２２０ならびに本発明の理解に 関係しないいくつかの他の種類のプロシジャ（図示せず）も包含する。 第３図は、本発明を使用するプログラム例の全体的な流れを示すフローチャー トである。ステップ３０２において、アプリケーション・プログラム２０４はEs cher初期化プロシジャ（図示せず）を呼び出す。このEscher初期化プロシジャは 、特に、レンダラー・インストレーション・プロシジャ２１６を用いて１つまた はそれ以上のレンダラーをインストールする。Escherの利点の１つは、アプリケ ーション・プログラムをコンパイルしたときに利用できなかったレンダラーを含 めて、種々のレンダラーをインストールすることができるということにある。 ステップ３０３において、アプリケーション・プログラムはEscherの品質制御 管理プロシジャ２１７を呼び出して１つまたはそれ以上の「品質コレクション・ オブジェクト」を構築する。各「品質コレクション・オブジェクト」は１つまた はそれ以上の「品質グループ・オブジェクト」を含むことができる。１つの品質 グループ・オブジェクトは、予定義されたデータ構造に従ってEscherシステムに よって作り出された１つのオブジェクトであり、これが多数の品質制御基準（た とえば、ライン・スタイル、シェーダのタイプ、イルミネーションのタイプ、詳 細レベル、アンチアライアシング・レベルなど）を一ヶ所に集める。 ステップ３０４において、アプリケーション・プログラムはEscherのビュー構 築／編集プロシジャ２２０を呼び出して１つまたはそれ以上の「ビュー・オブジ ェクト」を構築する。１つのビュー・オブジェクトは、予定義されたデータ構造 に従ってEscherシステムによって作り出された１つのオブジェクトであり、これ が多数のビューイング基準（たとえば、とりわけ、カメラ位置、イルミネーショ ン、二次元イメージがレンダリングされることになっているハードウェア宛先（ 「ドロー・コンテキスト」）ならびにレンダラーの選択）を一ヶ所に集める。ス テップ３０４は、また、レンダリング・プロセスで使用するための品質グループ を選ぶためにEscherプロシジャへの呼び出しも含み得る。 ステップ３０６において、アプリケーション・プログラムはEscherのモデル構 築／編集プロシジャ２１８への呼び出しを行って１つまたはそれ以上のモデルを 構築する。モデルは１つまたはそれ以上のオブジェクトの階層としてEscher内に 表現される。これらのオブジェクトの各々は、ジェオメトリ（形状）、材料属性 (表面の外観を記述する)、スタイル(塗りつぶし面、エッジのみ、点のみなど)、 変換（三次元オブジェクトの、ワールド・スペースに関する相対位置、向き、サ イズを記述する）あるいはグループ（階層の直ぐ下のレベルにおける別のオブジ ェクトを単に含むだけ）を記述する。ここで用いる「モデル」という用語は、な んら階層的に定義されたサブオブジェクトのないただ１つのオブジェクト、たと えば、ジェオメトリ・オブジェクトを示すにすぎない。 ステップ３０８において、アプリケーション・プログラムはレンダラー呼び出 しプロシジャ２１２を呼び出し、Escherをしてアプリケーション・プログラムの 作った１つまたはそれ以上のモデルをアプリケーション・プログラムの定義した １つまたはそれ以上のビューにレンダリングさせる。レンダラー呼び出しプロシ ジャ２１２は即時モード呼び出しと保存モード呼び出しの両方を含む。即時モー ド呼び出しの場合、アプリケーション・プログラムはレンダリングすべき非階層 データ構造のみを進む。Escherシステムは構造を指定レンダラーまで直接進み、 なんら中間結果をキャッシュしない。材料、スタイル、変換のオブジェクトにつ いて、Escherシステムは単にビューの現在の「状態」を調節するだけであり、そ れによって、それ以降に受け取られるジェオメトリのレンダリングに影響を与え る。レンダラー呼び出しプロシジャ２１２への保存モード呼び出しの場合、アプ リケーション・プログラム２０４の通過したオブジェクトは全体的に階層定義さ れたモデルとなり得る。レンダラー呼び出しプロシジャ２１２は自動的にこのモ デルをトラバースし、その適切な点で指定レンダラーに対して適切な呼び出しを 行う。 即時モード呼び出し、保存モード呼び出しの両方において、アプリケーション ・プログラム２０４は、レンダラー呼び出しプロシジャ２１２に対して、レンダ リングすべきオブジェクトとビュー・オブジェクトの両方を指定する。カレント ・レンダリング「状態」は、常に、ビュー・オブジェクトのデータ構造内に保持 され、それで、アプリケーション・プログラムが、１つのビュー・オブジェクト を指定する呼び出しと別のビュー・オブジェクトを指定する呼び出しとを点在さ せることだけで同じモデルを同時に２つ以上のビューにレンダリングすることが できる。これらの呼び出しが互いに干渉することはない（ただし、両方のビュー ・オブジェクトが同じドロー・コンテキストを示していなければならないのはも ちろんである）。２つのビュー・オブジェクトは同じあるいは異なったレンダラ ーのいずれを指定してもよく、ビュー・オブジェクトにおいて指定されたドロー ・コンテキストは同じ種類あるいは異なった種類の出力デバイス（たとえば、１ つのディスプレイ上の２つの異なったウィンドウあるいはディスプレイについて １つとプリンタについて１つ）への出力用であってもよい。さらに、アプリケー ション・プログラム２０４は同じビューについての即時モード呼び出しと保存モ ード呼び出しを混ぜ合わせることができる。それによって、アプリケーション・ ディベロッパが１つの画面の異なった部分の保存あるいはトラバースまたはこれ ら両方を違った方法で最適化することができる。 これらの可能性のいくつかが第４図に示すフローチャート例に示してある。ス テップ４０２において、アプリケーション・プログラムは第１モデルと第１ビュ ー・オブジェクトを指定するレンダラー呼び出しプロシジャ２１２を呼び出す。 ステップ４０４において、アプリケーション・プログラムは第１モデルと第２ビ ュー・オブジェクトを指定するレンダラー呼び出しプロシジャを呼び出す。ステ ップ４０６において、アプリケーション・プログラムは第２モデルと第１ビュー ・オブジェクトを指定するレンダラー呼び出しプロシジャを呼び出す。ステップ ４０８において、アプリケーション・プログラムは第２モデルと第２ビュー・オ ブジェクトを指定するレンダラー呼び出しプロシジャを呼び出す。ステップ４１ ０において、アプリケーション・プログラムは第３モデルと第１ビュー・オブジ ェクトを指定するレンダラー呼び出しプロシジャを呼び出す。以下同様に行われ る。 Escherビュー・オブジェクトの、レンダリングされるべきモデルからの独立性 （レンダラーの同定を含む）はアプリケーション・プログラム２０４によって実 施される動作シーケンスにおいて大きな融通性も与える。たとえば、レンダラー は、レンダラー呼び出しプロシジャ２１２の呼び出し（ステップ３０８）直前ま でインストールする（ステップ３０２）必要がない。ビュー・オブジェクトも、 モデルが作成された後（ステップ３０６）まで定義したり、完了したりする（ス テップ３０４）必要がない。こうして、アプリケーション・プログラムはモデル あるいはモデルの一部を構築することができ、後にのみユーザがレンダラーを選 択することができる。レンダラーの選択は、たとえば、ポップアップ走査ウィン ドウを用いて行うことができる。このウィンドウは、多数の既にインストールし たレンダラーを提示し、また、その時にユーザが別のレンダラーをインストール することができる。アプリケーション・プログラムは、選択されたレンダラーを 用いてモデル（単数または複数）をレンダリングし、次いで、そのモデルを編集 したり、新しいモデルを構築し、さらにまた、レンダラーを選び直し、再びモデ ル（単数または複数）をレンダリングするなど行うことができる。このような融 通性は、レンダラーの選択が構築されつつあるモデルにこだわらずに行われ、む しろアプリケーション・プログラムがEscherのレンダラー呼び出しプロシジャ２ １２に対するその呼び出しでレンダラーを指定するために、可能となった。 簡単なＣ言語アプリケーション・プログラム２０４が付録Ａに記載してある。 この例では、プログラムは、まず、Escher初期化ルーチンを呼び出し、これがワ イヤフレーム・レンダラーとＺバッファ・レンダラーの両方をインストールする 。次に、アプリケーション・ルーチンExSetupQualityCollection()が呼び出され て品質コレクション・オブジェクトをセットアップし、初期化する。このプロシ ジャは後にもっと詳しく説明する。 次に、ビュー・オブジェクト（「ビュー」）が創作され、或る特定のレンダラ ー（ワイヤフレーム・レンダラー）がこのビューと関連付けられる。カメラ・オ ブジェクトとドロー・コンテキスト・オブジェクトもこのビュー・オブジェクト と関連付けられる。次いで、プログラムはモデル（「グループ」）を創作し、ポ リゴン・オブジェクト（「ポリゴン」）、ライン・オブジェクト（「ライン」） 、変換・オブジェクト(「変換」)、グループ・オブジェクト（「サブグループ」 ）を加える。アプリケーション・プログラムは、次に、トーラス・オブジェクト （「トーラス」、ジェオメトリ・オブジェクトの１形態）をグループ・オブジェ クトに加える。次いで、ユーザ指定の品質インデックスがビュー・オブジェクト について定められ、モデルがビュー・オブジェクトにおいて指定されたレンダラ ーを用いてトラバースされ、レンダリングされる。ビュー・オブジェクトで指定 されたレンダラーは、次に、Ｚバッファ・タイプ・レンダラーに変えられ、同じ モデルがビュー・オブジェクトで指定されたレンダラーを用いて再びレンダリン グされる。 さらに続ける前に、本明細書に編入したＣ言語ソース・コードで用いられるネ ーミング規則を説明する必要があろう。本明細書では、プリフィクスEt（Escher タイプ）で始まるネームはEscherソース・コードで定義したデータ・タイプであ る。プリフィクスEc（Escher定数）で始まるネームはEscherソース・コードで定 義した定数である。プリフィクスEr（Escherルーチン）で始まるネームはアプリ ケーション・プログラムによって呼び出し可能なプロシジャ・ネームである。プ リフィクスEi（Escherインターナル）で始まるネームは他のEscherプロシジャに よってのみ呼び出される内部Escherプロシジャのネームである。これらのネーム の多くは、アプリケーション・プログラムによって呼び出され、対応するEiプロ シジャを呼び出すこと以外はほぼ何も行わないカウンタパートErプロシジャを有 する。この理由のために、Er、Eiプロシジャ・ネームはここでは互換性を持って 用いられる。最後に、プリフィクスEg（Escherグローバル）を持つネームは大域 変数である。 EscherルーチンのネームはEiまたはErで始まり、その後に大文字で始まるサブ ワードが続く。ここで用いられるようなたいていのEscherプロシジャ・ネームの 形はErFoo＿DoSomethingであり、ここで、Fooは機能が操作することになってい るデータのタイプであり、DoSomething はルーチンがこの種類のデータに実行す ることになっている動作である。たとえば、新しいポリゴン・オブジェクトを作 り出すプロシジャはErPolygon＿Newと命名される。他のネーミング規則はその都 度説明する。 第３図に示すようなアプリケーション・プログラムの種々のプライマリ・ステ ップを以下により詳しく説明する。 Ｉ．レンダラー・インストレーション Escherのためのレンダラーのインストレーションは、シェーダのような他の拡 張をインストールするのにも用いられる一般化拡張機構を用いる。マッキントッ シュ機器用の拡張は、データ・フォークおよびリソース・フォークと一緒に第１ 図のハードウェアに大容量で記憶されたファイルである。データ・フォークはEs cherシステムによってロードされるべきコードを含み、リソース・フォークはデ ータ・フォーク内のコード断片を識別する。 アプリケーション・プログラム２０４がマッキントッシュで作動していてEsch erプロシジャErlnitialize()を呼び出したとき、Escherシステムはコンピュータ ・システム上の拡張フォルダ内のすべての拡張ファイルを検索する。見つけ出さ れた、滝せつなリソース情報を含むすべてのファイルはアプリケーション・プロ グラムで使用するために利用できると考えられる。拡張ファイルは初期化ルーチ ンを指定し、このルーチンは必要なステップのすべてを実施してそれがEscherシ ステムと共に提供するサービスならびに終了ルーチンを「登録する」。 Escher拡張はEscherランタイム環境において一般化オブジェクト階層構造にロ ードされる。Escherのオブジェクト階層は「オープン」アーキテクチャを有し、 任意のアプリケーションが階層におけるいくつかのレベルのうちの任意のレベル にサブクラスを「プラグイン」することができる。レンダラーはサブクラスに分 類され得るオブジェクト・クラスのうちの１つである。 Ａ．Escher オブジェクト・システム Escherシステムにおけるオブジェクトは、２つのハンドル、すなわち、オブジ ェクト・クラスとオブジェクト・タイプとによって識別される。オブジェクト・ クラスはタイプのポインタEtObjectClassPrivateであり、オブジェクト・タイプ はロングワードである。Escherクラス階層内の各サブクラスのペアレント・クラ スが或る種の動きを与えるため、Escherはオブジェクト・プライベート・データ とオブジェクト・クラスを層状に記憶する。たとえば、レンダラー・クラスのサ ブクラスは、理論的に、第５図に示す要領でレイアウトされる。第５図はオブジ ェクト・「クラス」５０２を示す。これは、レンダラー、この場合、ワイヤフレ ーム（ＷＦ）レンダラーと関連付けられたすべての方法に対するポインタを含む メモリの隣接領域である。ワイヤフレーム・レンダラーがレンダラー・クラスか らサブクラスに分類されるので、レンダラー・クラスは「共有オブジェクト」ク ラスからサブクラスに分類され、この「共有オブジェクト」クラスは一般化「オ ブジェクト」クラスからサブクラスに分類され、メソッド・テーブル５０２がオ ブジェクト・クラス（領域５０４）と関連付けられたメソッドを最初にリストに 挙げる。これらのメソッドは、とりわけ、ディスポーズ・オブジェクト、複写オ ブジェクトおよび未登録オブジェクトを含む。すべてのオブジェクト・クラス・ メソッド・テーブルは、これらのエントリが或る特定のメソッド・テーブル５０ ２において表現された派生クラスのうちの１つによって初期化時に無効にされな い限り、これらのエントリにおける同じセットのEscherプロシジャを指示する。 次に、クラス５０２は、「共有オブジェクト」クラスにおけるすべてのオブジェ クトに対して適切な１セットのメソッドに対するポインタを含む領域５０６を含 む。このとき、「共有オブジェクト」メソッドはまったくなく、この層にはスペ ースがまったく割り当てられない。領域５０６に続いて、すべてのレンダラーに とって適切な１セットのメソッドに対するポインタを含む領域５０８がある。Es cherデザインの規則によってリーフ・クラスがそれ自体のメソッド・テーブルを まったく持たないので、特にワイヤフレーム・レンダラー・クラスのための層は ない。 領域５１２はクラス５０２の事例のためにデータのすべてを記憶する。この領 域は領域５０２と同じ要領で組織化される。特に、この領域は最初に領域５１４ におけるオブジェクト・クラスの任意の事例にとって適切なデータのすべてを含 み、次いで、領域５１６内の共有オブジェクト・クラスの任意の事例にとって適 切なすべてのデータがあり、次いで、領域５１８内のレンダラー・オブジェクト の任意の事例にとって適切なすべてのデータがある。クラス・データ５０２と異 なり、事例データ５１２は、ワイヤフレーム・レンダラー・オブジェクトの事例 にとって適切なすべてのデータを含む領域５２０も含む。領域５１４内のオブジ ェクト・データは、ワイヤフレーム・レンダラー・オブジェクトのすべての事例 に対して共通のメソッド・テーブル５０２に対するポインタのみを含む。領域５ １６内の共有オブジェクト・データは参照カウントを含み、領域５１８内のレン ダラー・オブジェクト・データおよび領域５２０内のワイヤフレーム・レンダラ ー・データを以下に説明する。 説明の目的のために、第５図には、ワイヤフレーム・レンダラー・クラスにお ける或るオブジェクトの第２の事例が示してある。この第２事例は、領域５１２ における第１事例のデータと同じフォーマットで、領域５２２に含まれるすべて のデータを有する。このデータの領域５２４におけるオブジェクト・データは、 第１事例についてのオブジェクト・データと同じオブジェクト・クラス・メソッ ド・テーブル５０２を指し示す。ここで、第５図の第２事例がEscherオブジェク ト機構におけるクラスと事例データの間の関係を説明するためにのみ挙げたもの であることに注目されたい。特にワイヤフレーム・レンダラーの２つ以上の事例 がこれまでにアプリケーション・プログラムのただ１回のインストレーションで 共存したことはありそうもないが、これも排除しない。 このとき、Escherシステムで使用されるクラス階層を説明すると有効であろう 。この階層は広大であるから、本発明の理解を助けるクラスのみを第６図に示す 。第６図を参照してわかるように、EtObjectクラスは階層内のすべてのクラスに 対するペアレント・クラスである。EtSharedObjectクラスは、ここでは関係のな い他のクラスと同様に、EtObjectの下にサブクラスに分類される。EtSharedObje ctの下にサブクラス化されたクラスは、EtSharedObjectクラス、EtRendererObje ctクラス、EtSetObject クラス、EtDrawContext クラス、EtViewObjectクラス、 EtQualityCollectionObject クラス、EtQualityGroupObjectクラスである。EtSh aredObjectの下にサブクラス化されたクラスは、EtStyleObjectクラス、EtTrans formObject クラス、EtCameraObjectクラス、EtLightObject クラス、 EtGeometryObjectクラス、EtGroupObjectクラス、EtSharedObjectクラスであり 、EtRendererObjectの下にサブクラス化されたクラスは、Zbuffer クラスとWire Frameクラスである。EtStyleObjectの下にサブクラス化されたクラスは、特に、 BackFacingStyleクラスである。EtTransformObjectの下にサブクラス化されたク ラスは、特に、図示しないが、Rotateクラス、Scaleクラス、Translateクラスで ある。EtGeometryObjectの下にサブクラス化されたクラスは、特に、Line、Poin t、Polygon、PolyLine、Torus、Triangleのオブジェクトについてのクラスであ る。EtGroupObjectの下にサブクラス化されたクラスはEtlightGroupクラス、EtI nfoGroup クラス、EtDisplayGroupクラスであり、この最後のクラスはサブクラ スEtOrderedGroupとEtListGroup を有する。このクラス階層は、階層に含まれる クラスの各々についてのメソッド・テーブルおよび事例データの記憶を記述する 。階層の両端のクラス（すなわち、ツリー構造の「リーブス」）は「リーフ」ク ラスとして知られている。 Ｂ．レンダラーの登録 Escherにおけるオブジェクト・サブクラス化の根拠は、Escherが拡張機構を用 いてシステム起動時に動的にそのメソッド・テーブルを構築するということにあ る。レンダラー・オブジェクト・クラスを含む、システム内のすべてのオブジェ クト・クラスは、アプリケーション・プログラムによって呼び出されたEtlnitia lizeプロシジャの制御の下に「登録」される。その結果、それらの機能を必要に 応じて利用できる。各拡張がロードされる毎に、Escherは拡張ファイルのリソー ス・フォークから拡張初期化機能のアドレスを得る。次いでその機能を呼び出す 。 以下に、ワイヤフレーム・レンダラー拡張によって使用されるErWF＿Register と呼ぶＣ言語初期化プロシジャを示す。 或るクラスが登録されたとき、それはクラスの事例の動作を決めるメソッドを 供給する。このクラスは、メタハンドラを経てEscherにこれらのメソッドを供給 する。メタハンドラとは、Escherメソッド・タイプを機能ポインタにマッピング する機能をいう。Escherはメタハンドラ機能に或るタイプのメソッドを与えるよ うに依頼し、メタハンドラがそのメソッド・タイプを知っているならば、それに 対応するメソッドを返す。メタハンドラが依頼されているメソッド・タイプを知 らない場合には、NULLを返す。ここでわかるように、ErWF＿Registerの第１ステ ップは、レンダラー・クラスの登録メソッドErRendererClass＿Registerプロシ ジャを呼び出すと共にアーギュメントとしてワイヤフレーム・レンダラーのメタ ハンドラErWF＿MetaHandlerの識別を行うことによって新しいワイヤフレーム・ サブクラスを登録する。ワイヤフレーム・レンダラーのメタハンドラは次の通り である。 Escherは、異なったワイヤフレーム・メソッドの識別をリクエストする毎にそ のメソッド・テーブル内の各エントリについて一度ずつメタハンドラを呼び出す ことになる。 EtRendererObjectクラスは幾何学的形状をレンダリングするためのメソッド・ テーブルを含む。すべてのレンダラーは少なくとも３つの基本的ジェオメトリ・ タイプ、すなわち、点、線、三角形をレンダリングするメソッドを提供しなけれ ばならない。レンダラーは同様により複雑なジェオメトリ・タイプをレンダリン グするためのメソッドを提供できる。こうして、メタハンドラを登録した後、上 記のワイヤフレームErWR＿Registerプロシジャはレンダラー・クラス・プロシジ ヤErRendererClass＿OverrideGeometryTypeDrawMethodを呼び出し、それがサポ ートするジェオメトリ・ドロー・メソッドを定める。ここでわかるように、ワイ ヤフレーム・レンダラーは、特に、タイプ・ポリゴン、三角形、線、ポリライン （つながった線のシーケンス）および点のジェオメトリをレンダリングするため のプロシジャを登録する。 ErWF＿Registerプロシジャは、レンダラー・クラスのメソッド・テーブル内の 或る種の変換・メソッドおよび属性セット・メソッドをオーバーライドする。 ここでわかるように、Escherのオブジェクト機構を通して、新しいレンダラー をEtRendererObjectクラスの下にサブクラス化するだけでEscherシステムにラン タイムで新しいレンダラーをインストールすることができる。 II．ビュー・オブジェクトの構築 Ａ．データ構造 上述したように、ビュー・オブジェクトは、特に、カメラ情報、ライティング 情報、トラバーサまたは状態情報ならびにレンダラーの選択の指示を含むデータ 構造である。ビュー・オブジェクトは、クラスEtObjectの下にサブクラスとなる 、第６図に示すように、クラスEtSharedObjectのサブクラスであるクラスEtView Objectの事例である。したがって、第５図のフォーマットに続いて、ビュー・オ ブジェクトはメモリ内に第７図のフォーマットを有する。特に、メモリ領域７０ ２はEtViewObjectクラスのメソッドに対するポインタを含むように割り当てられ 、この領域７０２はオブジェクト・メソッドに対するポインタ７０４と共有オブ ジェクト・メソッドに対するポインタ７０６とを含む。EtViewObjectクラスはリ ーフ・クラスであり、Escher規則によれば、このクラスは特にビュー・オブジェ クト・メソッドについてのメソッド・テーブルを省略している。ここでも、 本実施例では、共有オブジェクト・メソッドがまったくないということに注目さ れたい。 この構造は、また、メモリ領域７１０におけるビュー・オブジェクトについて の事例データも包含する。この領域は部分７１２（オブジェクト・クラス７０２ を指し示す）におけるオブジェクト・クラスに特有の事例データを含み、部分７ １４（参照カウントを含む）における共有オブジェクト・クラスに特有の事例デ ータを含み、部分７１６におけるビュー・オブジェクトに特有の事例データを含 む。ビュー・オブジェクト・データは以下に述べるタイプEtViewPrivateのデー タ構造である。 明らかなように、ビュー・オブジェクトは、特に、現在の選択されたレンダラ ーのメソッドに対するポインタ（^*rendererClass）、カレント・レンダラーの事 例データを示すポインタ（^*renderer）、ドロー・コンテキスト・オブジェクト 、カメラ・オブジェクト、ライティング・オブジェクト（lights）、いくつかの シェーダ・オブジェクトおよび品質グループ・オブジェクトを含む。 EtRendererPrivate構造は以下の通りに定義される。 この構造はトラバーサルの現在の状態を示す一連のスタックに対するポインタ を含む。以下により詳しく説明するように、これらの状態スタックは、Escherの トラバーサがモデル内の「グループ」オブジェクトを開く毎にプッシュされ、階 層の次のレベルのトラバースを開始する。これらのスタックは、トラバーサがモ デル階層のすべての下方レベルでその作業を完了し、「グループ」オブジェクト を閉じたときに先の状態までポップアップされる。 EtRendererClassデータ構造は次のように定義される。 ここで、上述したワイヤフレーム・レンダラーの初期化プロシジャが、Escher がレンダラー・クラスの或る種のメソッドをオーバーライドするように呼び出す ことができるメタハンドラを確立することを想起されたい。Escherは、メタハン ドラによって返された或るメソッドを、対応するメソッドのために先に定義され たEtRendererClass 構造フィールドに置く。また、ワイヤフレーム・レンダラー 初期化プロシジャが、ErRendererClass＿OverrideGeometryTypeDrawMethodプロ シジャを用いて特に或る種のジェオメトリ・ドローイング・メソッドをオーバー ライドすることも想起されたい。このプロシジャは指定されたレンダラー・プロ シジャに対するポインタを^*geometryDrawMethods によって指し示されたメソッ ド・テーブルに書き込み、それによって、初期化時の最初にEscherシステムによ ってセットアップされたデフォルト・メソッドをオーバーライドする。EtMethod Table データ構造は、ポインタの単なるリストであり、^*geometryDrawMethods については、テーブル内の各エントリが対応するジェオメトリ・タイプ、たとえ ば、点、線、三角などをレンダリングするためのプロシ ジャを指し示す。このテーブル内のロケーションとジェオメトリ・タイプの間の 対応はコンパイル時には固定である。 メンショニングを支えるEtRendererClass データ構造における他のフィールド としては、geometryDrawMethodフィールドがある。このフィールドは、カレント ・レンダラーがサポートしていないジェオメトリ・タイプを描画することが依頼 されている場合にEscherが呼び出すことになるプロシジャに対するポインタを含 む（すなわち、ジェオメトリのための^*geometryDrawMethods におけるメソッド ・テーブル・エントリがNULLである）。このプロシジャは指定されたジェオメト リを同様のジェオメトリに分解する（これは後により詳しく説明する）。本実施 例では、この分解プロシジャはオーバーライドされ得ない。しかしながら、本発 明の別の実施例では、レンダラーがこの分解メソッドをオーバーライドしてプロ セスを最適化することができる。 EtQualityGroupObject構造を以下に説明する。 Ｂ．プロシジャ ステップ３０４（第３図）においてビュー・オブジェクトを構築するプロセス は、基本的に、ビュー・オブジェクト・データ構造に所望の情報を書き込むプロ セスである。付録Ａのアプリケーション・プログラム例をこのプロセスを説明す るために用いる。 １．ビュー・オブジェクトの創作 品質コレクションの初期化、設定の後、アプリケーション・プログラムはvi ew＝ErView＿New()を呼び出すことによって新しいビュー・オブジェクトを創作 する。このプロシジャは、単に、EtViewObjectクラスにおけるオブジェクトの新 規な事例を創作し、それをデフォルト・データで満たすだけである。 ２．レンダラーの設定 レンダラーは、EscherプロシジャErView＿SetRenderer を呼び出し、ビュー ・オブジェクトおよびレンダラー・オブジェクト内を通すことによってビュー・ オブジェクトに添付され得る。この呼び出しは通されたレンダラーの参照カウン トを増分することになる。レンダラー・オブジェクトが既にセットされている場 合には、その参照カウントは減分される。 レンダラーは、最初にレンダラー・オブジェクトの事例を得る必要なしにレ ンダラー・タイプによってもセットされ得る。この場合、アプリケーション・プ ログラムはEscherルーチンErView＿SetRendererByTipe を呼び出し、これが付録 Ａのプログラム例によって呼び出されるプロシジャである。このプロシジャに通 されるパラメータはビュー・オブジェクトとタイプ宛先であり、このタイプ宛先 はレンダラーのタイプ（たとえば、ワイヤフレームあるいはＺバッファ）を示す ４文字コードである。EscherプロシジャErView＿SetRendererByType は、指定さ れたタイプのどんなレンダラーが登録されるかを決定し、このようなレンダラー が登録されているならば、レンダラー事例データに対するポインタを指定ビュー ・オブジェクトの適切なエントリに書き込む。 ３．カメラの設定 カメラを設定する前に、カメラ・オブジェクトが創作され、初期化されなけ ればならない。補遺Ａのプログラム例は、これを達成するのに、カメラ透視デー タを適切なperspectiveData データに書き込み、EscherプロシジャErViewAngleA spectCamera＿NewDataを用いてそれをカメラ・オブジェクトに割り当てる。ひと たびカメラ・オブジェクトが得られたならば、それをビュー・オブジェクトと関 連付けるために、ビュー・オブジェクトおよびカメラ・オブジェクトを通るErVi ew＿SetCamera を呼び出す。この呼び出しはそこを通るカメラ・オブジェクトの 参照カウントを増分させる。カメラ・オブジェクトがすでにセットされているな らば、この参照カウントは減分される。補遺Ａのプログラム例は、次いで、Esch er機能ErObject＿Dispose を用いてカメラ・オブジェクトを廃棄する。カメラ・ オブジェクトがもはや別個に必要ないからである。 ４．ドローイング・コンテキストの設定 ドロー・コンテキストを設定する前に、ドロー・コンテキスト・オブジェク トを創作して、初期化しなければならない。補遺Ａにおけるプログラム例では、 これを達成するために、適切なデータ構造pixmapDataをセットアップし、それを EscherプロシジャErPixmapDrawContext＿NewDataに通す。次いで、ドロー・コン テキスト・オブジェクトを、呼び出しErView＿SetDrawContextを用い、ビュー・ オブジェクトおよびドロー・コンテキスト・オブジェクトに通してビュー・オブ ジェクトと関連付ける。補遺Ａのアプリケーション・プログラム例は、次に、Es cher機能ErObject＿Disposeに通すことによってドロー・コンテキスト・オブジ ェクトを廃棄する。 ビューの他の特性、たとえば、ライティングおよびシェーダも同様にして指定 され得る。 ５．レンダリング品質レベルの選択 これは後により詳しく説明する。 明らかなように、１つのビュー・オブジェクトの構築、編集は別のビュー・オ ブジェクトの構築、編集から完全に分離しており、２つ以上のビュー・オブジェ クト（同じあるいは異なったレンダラーを指定するものを含む）が互いに干渉す ることなく共存できる。 III．モデルの構築 Escherで使用されるモデリング・プログラムは、アップル・コンピュータから 入手できる２つの現存の製品、すなわち、QuickDrawとQuickDraw GXを用いるモ デリング・プログラムを比較することによって最も良く理解することができる。 QuickDraw GXは、アップル・コンピュータ「QuickDraw GX Programmer'sOvervie w」（１９９４）に記載されている。この文献は参考資料としてここに援用する 。QuickDraw とQuickDraw GXは、共に、三次元処理ではなくて二次元グラフィッ クス処理を行う。QuickDraw 二次元グラフィックス・システムは、プロシジャ・ インターフェイスと大域グラフィックス状態を備え、この大域グラフィックス状 態は、このシステムが描画するシェイプのカラー、転送モード、パターンを定め る。QuickDrawシェイプ描画ルーチンが呼び出されたとき、QuickDrawはそのグラ フィックス状態内の変数に従ってシェイプを描画する。アプリケーション・プロ グラムは他の呼び出しをQuickDrawに用いることによってグラフィックス状態を 操作できる。 QuickDraw GXは、システム維持グラフィックス状態とのプロシジャ・インター フェイスではなくて、シェイプはそれらを描画するのに必要なすべての情報を内 包するオブジェクトとして表現される。システム維持グラフィックス状態はない 。シェイプがオブジェクトであるため、QuickDraw GXはQuickDraw のルーチンが イ メージをピクセル・マップにのみ描画するためにQuickDraw が描画できないシェ イプについて作動するユーティリティを提供することができる。QuickDraw GXは 「ヒット」テスティング幾何学的共通部分のようなシェイプについて動作する機 能を提供する。 QuickDraw GXにおける主データタイプは「シェイプ」であり、これはジェオメ トリその他のドローイング情報を内包する。シェイプは、「ビュー・デバイス」 座標にシェイプを変換する「ビュー・ポート」を介して描画される。シェイプが ドローイングのためにQuickDraw GXに通されたとき、シェイプはそれに添付され た各ビュー・ポートを介して描画される。ビュー・ポートはいくつかのビュー・ デバイスにオーバーラップすることができ、この場合、シェイプは正しい解像度 で各ビュー・デバイスに描画される。QuickDraw GXシェイプは「ピクチャ・シェ イプ」の使用によって階層状に組織され得る。各シェイプはそれと関連付けられ た「タイプ」を有する。これが線、ポリゴン、曲線などかどうかを示す。シェイ プへのアクセスはプロシジャ・インターフェイスおよびハンドルを介して行われ る。 QuickDraw GXのシェイプ描画プロシジャはシェイプを描画する任意の時点で呼 び出され得る。互いのトップに描画されるシェイプの順序は描画される順序に依 存する。内部キャッシュ情報についてを除いてドローイング・コマンド間には状 態情報はなんら保持されない。これは、各シェイプがビュー・ポート、ビュー・ デバイス、カラー、転送モードおよびドローイング・スタイルを含む、そのシェ イプを描画するのに必要なすべての情報を内包しているからである。 Escherシステムは、三次元レンダリング・アルゴリズムの性質および三次元モ デルを記述するのに必要な代表的な大量のデータによりQuickDraw およびQuickD raw GXからかなり異なる。 Escherシェイプはそれらを描画するのに必要なすべての情報を内包していない 。むしろ、Escherは、オリジナルのQuickDraw がグラフィックス・ポートにおい て前景カラーについてドローイング状態を維持すると同様に、シェイプをどのよ うにレンダリングすべきかについての付加的な情報を提供する「状態」を維持す る。Escher状態機構は、階層のより低いレベルでシェイプによって受け継がれる カラ ーまたはドローイング・スタイルのような情報を指定する階層モデルが構築され るのを可能とする。この機構は、画面において何回か使われるべきモデルを事例 とする際に融通性を高めるが、ジェオメトリを再指定することなく属性を変える 。Escherは、また、レンダリングのためのドローイング領域が、QuickDraw GXに おけるようにすべてのシェイプに添付されるのではなくて、ビュー・オブジェク トへの添付によってイメージのレンダリングするのに先だってEscherにおいて指 定されるという点でQuickDraw GXとも異なる。 Escherはモデル階層内のジェオメトリ、アピアランスを内包するいくつかのデ ータ・タイプを提供する。データ・タイプの一般的なクラスはジェオメトリ、「 属性セット」、スタイル、変換、グループである。三次元モデルの代表的な複雑 さにより、アピアランスをこの要領でいくつかのデータのタイプに分離すると有 利である。一様に単純な三次元シェイプは任意の現実的な外観を作るために数百 あるいは数千の幾何学的シェイプを必要とする。任意の複雑さを持つ現実的外観 の画面（たとえば、家の中の部屋）を作るには、数百あるいは数千または数百万 の幾何学的シェイプを必要とするかも知れない。この大きさのモデルを処理する とき、ただ１つのアピアランス特性を大きなグループの幾何学的シェイプに適用 し、メモリを節約し、このようなモデルの構築、編集を簡略化すると有利である ことが多い。上記のデータ・タイプはこれらの目標を容易にする。 QuickDraw GXモデル階層では、或る「ピクチャ・シェイプ」の変換マッピング は、シェイプのそれらが包含する変換マッピングと結びつけられると考えられる 。これは、二回以上同じシェイプをレンダリングし、変換・マッピングを用いて メモリ内に記憶されたそれの２番目のコピーを持つことなくシェイプを移動ある いは変換する手段を提供する。このような結びつきは、QuickDraw GXでは、モデ ル階層がトラバースされる時に「カレント変換マッピング」のレコードを保持す る状態機構を介して達成される。QuickDraw GXピクチャ階層はトップからボトム まで、左から右へトラバースされる。階層内でより低位にあるシェイプがトラバ ースされるとき、それらの変換マッピングはカレント変換マッピングと結びつけ られる。或るピクチャ・シェイプ内のすべてのシェイプが描画された後、トラバ ーサルは、もしあるならば先のピクチャを返し、そのシェイプのトラバーサルを 再 開する。これは「トップダウン・トラバーサル」と呼ばれる。トラバーサルから 返ると、カレント変換マッピングがピクチャ・シェイプが入力される前のものに 復帰される。この機構はトラバーサル中にプッシュ、ポップされるマッピングの スタックと考えることができる。ルート・ピクチャ・シェイプを描画し終わると 、カレント・マッピングはNULLとなる。 Escherは同様のトラバーサル機構を提供するが、三次元モデルが非常に複雑で あるために、変換マッピングのみよりも多くが受け継がれる。アピアランスおよ びスタイルも受け継がれる。 QuickDraw GXでは、そのシステムがピクチャをトラバースしていない限り「カ レント変換マッピング」はないのに対して、Escherでは、アプリケーション・プ ログラムが現在の状態そのものをプッシュ、ポップすることができる。事実、ア プリケーション・プログラムは、所望に応じて、アプリケーション特有の階層デ ータ構造でEscherシェイプを維持することができ、Escherプロシジャ２０２への 呼び出しの注意深い順序づけによって、システム階層をシミュレートすることが できる。この特徴は、複雑なアプリケーション特有の階層状データ構造を使用す るアプリケーション・プログラム、たとえば、アニメーション・システムにとっ てきわめて有利であり、あるいは、既にそれ自体のデータ構造を有する現存のア プリケーション・プログラムをポーティングするときにきわめて有利である。PH IGS の従来システムおよび他の保存モード・システムは、モデル全体がただ１つ の階層内に存在し、ＧＬが各オブジェクトを独立して処理することを要求する。 一方、Escherでは混合が可能である。アプリケーション・プログラムは、状態を セットし、多数の独立した幾何学的オブジェクトを描画し、Escherシステムによ ってそのデータ構造内に構築され、記憶されたモデルをレンダリングさせ、次い でより多くの独立した幾何学的オブジェクトを描画させることなどができる。 第８図は、補遺Ａのアプリケーション・プログラム例によって構築される単純 なモデル階層のグラフである。これは２つのレベル、すなわち、「group」と呼 ばれるEtDisplayGroupObjectに内包される第１（ルート）レベルと、「subGroup 」と呼ばれるEtDisplayGroupObjectに内包される第２レベルとを包含する。各Et DisplayGroupObjectは階層内のノードと考え得る。各ノードはそれに関連付け られたスタイル・オブジェクト、ジェオメトリ・オブジェクト、変換オブジェク トその他のグループ・オブジェクト（第８図にあるようなもの）ならびにシェー ド・オブジェクト、属性セット・オブジェクトを有し得る。Escherは２種類のEt DisplayGroupObjects、すなわち、サブクラスEtorderedGroup、EtListGroupの２ つをサポートする。EtListGroupクラスにおいて事例に添付されたオブジェクト はそれらがグループに加えられる順序を除いてなんら順序を持たない。トラバー サル中、Escherがリスト・グループ・オブジェクトに遭遇すると、リスト内の各 オブジェクトはシーケンス通りに進められる（「実行される」）。このとき、そ れは初めにグループに追加される。第８図を参照して、ひとたびグループgroup がオープンされると、トラバーサル中に、EscherはbackfacingStyleを実行し、 次いで、polygon、次いでline、次いでtransform、次いでsubGroupをこの順序で 実行する。この順序がgroup に加えられた順序だからである。こうして、backfa cingStyle によって生じたレンダリング状態への変更がsubGroup内のオブジェク トに対してのみ適用されることになる。EscherＡＰＩは、リストの初めあるいは リストの終わりまたは既にリス途上にあるオブジェクトの間でアプリケーション ・プログラムにオブジェクトを加えさせる呼び出しを包含する。 サブクラスEtOrderedGroupのグループ・オブジェクトは、実行される前にタイ プに従ったグループに添付したオブジェクトをトラバーサが分類することを除い て、リスト・グループ・オブジェクトに類似している。特に、オブジェクトは次 の順序で実行される。すなわち、変換オブジェクト、スタイル・オブジェクト、 属性セット・オブジェクト、シェーダ、ジェオメトリ、付加的グループの順であ る。 両方の種類のグループ・オブジェクトにとって、サブグループがオープンされ たとき、レンダラーの次のカレント状態が受け継がれる。このサブグループ内の オブジェクトは引き続いて実行されるオブジェクトについての状態の任意の特性 を変えることができるが、ペアレント・グループに戻った際に、状態はトラバー サがそのサブグループにエンターする前の状態に復帰する。 グループ・オブジェクトは、また、それらに関連付けられた「状態」も持つが 、これはトラバーサの「状態」と混乱してはならない。或るグループの状態は、 そ のグループがどのように振る舞うかという様相を定義する単なるフラグの集まり である。これらのフラグの大部分は本発明を理解する上で重要ではないが、混用 なフラグの内の１つ、すなわち「in-line」を理解するのに役に立つかも知れな い。 モデリング・アプリケーションにおいては、１セットの材料あるいはスタイル を、モデルで何回か参照される可能性のあるバンドルにグループ別けすると時に 役に立つ可能性がある。しかしながら、このようなバンドルが上述したようなト ラバーサ状態の通常のプッシング、ポッピングを用いて創作された場合、これら のオブジェクトは、トラバーサによって実行された後にグループが状態をポップ するときにモデルについて所望の効果を持つことはない。したがって、アプリケ ーション・プログラムはグループ・オブジェクトの「in-line」フラグをセット して、グループへのエントリ、グループからのイグジットがトラバーサの状態を プッシュあるいはポップすることがないように指定することができる。EscherＡ ＰＩはこのフラグのカレント値をセット、クリア、獲得するプロシジャ呼び出し を提供する。 Ａ．データ構造 ビューを構築するためのプロシジャと同様に、アプリケーション・プログラム が呼び出してモデルを構築することができるEscherプロシジャを説明する前に或 る種のデータ構造を説明すると役立つであろう。 補遺Ａにあるアプリケーション・プログラム例では、グループgroup、subgrou pは順序表示グループ・オブジェクトである。これらはタイプEtDisplayGroupを 持ち、これは、第６図のクラス階層において、EtGroupObject、EtShapeObject、 EtSharedObject、そして最終的にEtObjectのクラス先祖を有する。したがって、 これらのオブジェクトは第９図に示すようにデータ構造でメモリ内に表現される 。特に、順序表示グループ・クラス・メソッド・テーブルはメモリ・ブロック９ ０２内に含まれ、group、subgroupについての事例データはそれぞれブロック９ ０４、９０６内に含まれる。順序表示グループ・クラス９０２は、第５図の領域 ５０４と同様に、オブジェクト・メソッドに対するポインタを含む領域９０８で 始まる。領域９０８に続く領域９１０は共有オブジェクト(本実施例にはない)に 特有のすべてのメソッドに対するポインタを含む。これに続いて領域９１２が あり、これはすべてのシェイプ・オブジェクト・メソッドに対するポインタを含 み、これに続く領域９１４はグループ・オブジェクトに特有のメソッドに対する ポインタを含む。この最後に述べたデータ構造EtGroupClassは以下のｔｙｐｅｄ ｅｆを持つ。 明らかなように、これは、とりわけ、グループの終わりにオブジェクトを加え るメソッド(add)および既にグループに割り当てられたオブジェクトのリスト内 の或る特別のロケーションにオブジェクトを加えるメソッド（addBefore とaddA fter）とを含めて、いくつかのメソッドに対するポインタについてのエントリを 含む。 領域９１４の後、順序表示グループ・クラス・メソッド・テーブル９０２は、 領域９１６に置ける表示グループに特有のメソッドに対するポインタを含む。こ のデータ構造EtDisplayGroupClassは次のように定義される。 EtDisplayGroupClass におけるメソッドは本発明の理解には関係ないが、クラ スが任意のドローイング・メソッドに対するポインタを含んでいないことに注目 されたい。先に説明したように、これらのメソッドは、グループ・オブジェクト よりもむしろビュー・オブジェクトにおいて識別される。その結果、これらのメ ソッドはレンダラーによってオーバーライドされ得る。或るオブジェクトについ てクラス内で識別される任意のドローイング・メソッドは構築されつつあるモデ ルの一部となり、モデルそれ自体と絡み合わせられることになり、アプリケーシ ョン・プログラムが異なったレンダラーを用いてモデルをレンダリングしようと するときに変更するのが難しくなる。このような構成は、また、先に説明したよ うに２つ以上のレンダラーを同時に活動状態にするのを難しくする。 再びメソッド・テーブル９０２を参照して、クラス階層におけるリーフ・クラ スに関するEscherシステムのデザイン（第６図）で典型的なように、テーブルは 順序表示グループに特有のメソッドを含まない。 subGroupについての事例データのデータ構造はgroup についてのそれに同じで あるから、group についてのデータ構造のみを以下に説明する。第５図の事例デ ータ・ブロック５１２のデータ構造と同様に、ブロック９０４は領域９２０内の オブジェクト・データ、特に、順序表示グループ・クラス・ブロック９０２に対 するポインタで始まる。これに続く領域９２２は共有オブジェクト・データ、特 に参照カウントを含む。これに続く領域９２４はシェイプ・オブジェクト・デー タ(これも非常に短い)を含む。このシェイプ・オブジェクト・データ領域９２４ に続く領域９２６はグループ・オブジェクトについてのオブジェクト・データ（ 本実施例にはない）を含む。 領域９２６に続いて表示グループ・オブジェクトのための事例データを含む領 域９２８がある。このデータは上記の「状態」フラグのみを含むものである。領 域９２８に続いて領域９３０があり、この領域は順序表示グループ・オブジェク トの事例に特有のデータを含む。このデータは以下に定義するフォーマットを有 し、ここで、EtDLListは二重にリンクしたリストのためのtypedefである。 明らかなように、領域９３０は６つの二重リンク・リストを含み、表示グルー プ・オブジェクトに加えることのできるオブジェクトのタイプの各々に対して１ つの二重リンク・リストがある。完璧を求めるならば、ここで、group が順序表 示グループでなくてリスト表示グループである場合、差異は領域９３０の構造だ けである。特に、EtListDisplayGroupPrivate として定義される構造を持つこと になる領域９３０は、表示グループに加えられるすべてのオブジェクトに対する ただ１つの二重リンク・リストに対するポインタのみを含むことになる。 EtDisplayGroupObject構造に加えて、補遺Ａのアプリケーション・プログラム 例は、EtStyleObject データ構造、EtGeometryObjectデータ構造およびEtTransf ormObject データ構造も使用する。これらの構造は、すべて、EtGroupObjectと 同様にEtShapeObjectクラスからサブクラスに分類されるオブジェクトのクラス を参照する（第６図参照）。ここに説明した他のオブジェクトと同様に、各デー タ構造は第９図の９０２と同様のメソッド・テーブルを参照し、第９図の９０４ あるいは９０６と同様にプライベート事例データを含む。これら３つのクラスは 、各々、EtGroupObject(第６図参照)と同様に、同じペアレント・クラス(EtShap eObject)からサブクラスに分類され、したがって、クラス・データ、事例データ 両方の最初に３つの層は第９図に示すものと同じ構造を持つことになる。EtStyl eObject クラスにおいてプログラム例で実際に用いられるリーフ・クラス(Backf acingStyle)はEtStyleObjectクラスのサブクラスとなり、そのオブジェクトにつ いてのクラス・メソッドの４番目、最後の層がスタイル・オブジェクトに特有の メソッドを示すポインタを含むことになる。事例データの４番目の層は、もしあ るとするならば、すべてのスタイル・オブジェクトにとって適切なプライベート ・データを含み、５番目と最後の層は後向き（backfacing）スタイル・オブジェ クトに対して適切なデータを含む。 同様に、EtTransformObject クラスにおいてプログラム例で実際に使用される リーフ・クラス(translate)はEtTransformObject クラスのサブクラスであり（ 第６図参照）、したがって、変換オブジェクトについてのクラス・メソッドの４ 番目と最後の層は変換オブジェクトに特有のメソッドを示すポインタを含む。変 換オブジェクトについての事例データの４番目の層は変換オブジェクト特有のデ ータを含み、５番目と最後の層は並進(translate)変換オブジェクトに特有のデ ータを含む。 プログラム例はジェオメトリ・オブジェクトである３つのオブジェクト（poly gon、line、torus）を創作し、そのすべてはEtGeometryObjectクラスのサ ブクラスであるリーフ・クラス内にある（第６図参照）。こうして、これらのオ ブジェクトの各々についてのクラス・メソッド・テーブルの４番目、最後の層は ジェオメトリ・オブジェクトに特有のメソッドを示すポインタを含む。これらの オブジェクトの各々についての事例データの４番目の層は任意のジェオメトリ・ オブジェクトに特有のデータを含み、これらのオブジェクトの各々についての事 例データの５番目と最後の層はポリゴン・オブジェクト、ライン・オブジェクト 、トーラス・オブジェクトそれぞれに特有のデータを含む。 Escherでは、属性セット（拡散カラーのような属性を含む）が表面アピアラン ス特性を定義するのに対し、スタイルが幾何学的シェイプをどのように描画する かをレンダラーに知らせる。たとえば、或るポリゴンをべた塗りつぶしシェイプ としてあるいはそのエッジのみでレンダリングすることができる。別の例では、 表面を滑らかにレンダリングするか、あるいは、切子面のあるアピアランスを持 つようにレンダリングすることができる。後向き（backfacing）スタイル・オブ ジェクト(EtStyleObjectのサブクラス)によって示されるまた別の例は、カメラ から離れた方に向いたシェイプを表示すべきかどうかを決定する。付録Ａのプロ グラム例で使用されるEcBackfacingStyle＿RemoveBackfacing特性は、カメラか ら離れた方を向いているシェイプは描画すべきでないと指定する。backfacingス タイル・オブジェクトについてのプライベート・データはロングワードを含み、 このロングワードは、前向き、後向き両方の表面を描画すべきかどうか、あるい は、後向き表面を除くべきかどうか、あるいは、２面属性を持たない後向き表面 に常にカメラに向くようにフリップ運動を与えられた常態を持たせるかどうかを 示す定数を含む。アプリケーション・プログラムは、適切なスタイル・オブジェ クトを創作し、それをモデルのグループ・オブジェクト内の所望の位置で加える ことによってモデルのスタイル特性を指定する。 グループ・オブジェクトの場合、事例データの最後の層におけるプライベート ・データは或る特定のジェオメトリを記述するのに必要な情報を含んでいる。た とえば、ポリゴン・オブジェクトの最後の層に或るプライベート・データは頂点 の数を指定する。ここでは、頂点と或る種の属性は関係ないものとする。ライン ・オブジェクトの最後の層にあるプライベート・データはラインの２つの端点の 位置ならびに或る種の属性データを含み、トーラス・オブジェクトの最後の層に あるプライベート・データは起点、向き、大半径、小半径ならびに或る種の属性 データを含む。 変換オブジェクトは、幾何学的シェイプを含む座標系を変えるのを可能とし、 それによって、オブジェクトを空間内で位置決め、方向付けすることが可能とな る。変換は、オブジェクトの幾何学的表現（シェイプを記述する頂点その他のデ ータ）を変えず、むしろ、レンダリング時間でマトリックスが空間内でオブジェ クトを一時的に「移動させる」ように適用されるので、有用である。これにより 、モデルにおける種々の変換で何回もただ１つのオブジェクトを参照することが 可能となり、画面内の多くの異なったロケーションにオブジェクトを置くことが できるようになる。アプリケーション・プログラムは、EtTransformObject クラ スのサブクラス（第６図）から適切な変換オブジェクトを創作し、それをモデル 内の適切な位置で適切なグループに加えることによって変換を指定する。アプリ ケーション・プログラムによって指定された変換は、Escherが変換をグループ内 の引き続くオブジェクトに適用される仮マトリックスに変換するレンダリング時 点まで指定されたフォームに留まる。マトリックスは予めオブジェクトのベクト ルに掛け合わされる。Escher変換は予めカレント変換マトリックスに掛けてあり 、したがって、アプリケーション・プログラムは逆の順序で結びつけられるべき 変換を指定する。これは階層内でのマトリックスの適用と一致している。すなわ ち、階層のトップで指定されたマトリックスは最後に適用され、オブジェクトの 直前に指定されたマトリックスは最初に適用される。 Escherは数多くの異なった種類の変換をサポートしている。各変換はEtTransf ormObject のそれぞれのサブクラスからのオブジェクトを使用することによって Escherに指定される。これらのサブクラスのうちの３つが第６図に示してある（ Rotate、Scale、Translate）。EscherＡＰＩは、変換オブジェクトの創作、廃棄 、変換オブジェクトの即時モードでの描画、それらの内容の新しいデータへの設 定、変換オブジェクトのプライベート・データの獲得、変換オブジェクトのファ イルへの書き込みなどのプロシジャを提供する。並進変換オブジェクトについて の事例データの最下層におけるプライベート・データ（補遺Ａのプログ ラム例で使用されるリーフ・クラス）は並進座標ｘ、ｙ、ｚを指定する。 Ｂ．プロシジャ １．ErOrderedDisplayGroup ＿New() 補遺Ａおよび第８図を参照して、アプリケーション・プログラム例は、まず プロシジャErOrderedDisplayGroup＿New()を用いて新しい順序表示グループ・オ ブジェクトgroupを創作することによってグループ８０２のモデルを構築するこ とを始める。Escherオブジェクト創作機構は、第１０図のフローチャートに全体 的に示す再帰的機構である。ここで、順序表示グループ・クラスについてのクラ ス・メソッド・テーブルが順序表示グループ・クラスの再登録の際に初期化中に 創作され、その結果、新しいオブジェクト機構では事例データのブロックだけを 捜索し、初期化すればよいということに注目されたい。 第１０図を参照して、まず、ステップ１００２において、リーフ・クラスの 「New」プロシジャが、そのペアレント・クラス「New」プロシジャを、（ａ）リ ーフ・クラスが登録されたときに、リーフ・クラスのメソッド・テーブルのトッ プを示す静的変数と、（ｂ）リーフ・クラスのプライベート・データ構造のサイ ズと共に呼び出す。ステップ１００４において、もっと高いクラスのそれぞれの 「New」プロシジャが、そのそれぞれのペアレント・クラスの「New」プロシジャ を、（ａ）それに通されるオブジェクト・クラス・ポインタと、（ｂ）これまで すべての派生クラスで必要とされていたサイズ＋カレントクラスのプライベート ・データ構造によって必要とされるサイズと共に呼び出す。ステップ１００６に おいて、最終的なペアレント・クラスの「New」プロシジャ（EiObject＿New()） が、（ａ）それ自体のプライベート・データ＋すべての派生クラスのためのプラ イベート・データにとって必要なプライベート・データ構造に対してメモリ・ス ペースを割り当てる。このスペースは新しく創作されたオブジェクトについての 事例データのブロック全体を含むことになる。次いで、このプロシジャは、（ｂ ）それ自体のプライベート・データ構造を初期化し（これはそこに通されるオブ ジェクト・クラス・ポインタを新しく割り当てられたメモリ・ブロックのトップ に書き込むことによって行う）、そして、（ｃ）その発呼者(次に低い方のクラ スの「New」プロシジャである)に戻り、新しく割り当てられたメモリ・ブロック を 示すポインタを返す。ステップ１００８において、低い方の各クラスの「New」 プロシジャは、次に、（ａ）それ自体のGetプロシジャを呼び出して新しく割り 当てられた事例データ・ブロック内のカレントクラス自体のプライベート・デー タ構造を示すポインタを獲得し、（ｂ）それ自体のプライベート・データ構造を 初期化し、（ｃ）その発呼者(次に低いクラスの「New」プロシジャである)に戻 り、新しく割り当てられたメモリ・ブロックを示すポインタを返す。リーフ・ク ラスの「New」プロシジャも同じことを行うが、ただし、ここでは、発呼者は、 普通、サブクラスの「New」プロシジャではなくてアプリケーション・プログラ ムである。 Escherの「New」プロシジャの２、３の例を、それがどのように行われるのか について以下に説明する。順序表示グループ・オブジェクトについての「New」 プロシジャ（アプリケーション・プログラムによって呼び出されるルーチン）は 次の通りである。 明らかなように、このルーチンは、まず、そのペアレント・クラスEiDisplayG roup＿New()の「New」プロシジャを、順序表示グループ・クラス・メソッド・テ ーブルEgOrderedDisplayGroupClassを示すポインタおよび創作されつつあるオブ ジェクトについての事例データの最下層で必とされるプライベート・ データ構造EtOrderedDisplayGroupPrivateのサイズと共に呼び出す。このプロシ ジャが戻るとき、事例データのブロックが割り当てられており、より高いレベル が初期化されている。或る種のエラー・チェッキングの後、EiOrderedDisplayGr oup＿New()プロシジャは、割り当てられたブロックの順序表示グループ・プライ ベート・データ構造を示すポインタ(ordered)を獲得し、二重リンク・リストの すべてをNULLに初期化する。次いで、このプロシジャはアプリケーション・プロ グラムに戻り、新しく創作された事例データ・ブロックを示すポインタを返す。 表示グループ・クラスの「New」プロシジャは次の通りである。 明らかなように、このプロシジャは、最初に、オブジェクト・クラスを示すポ インタを通すそれ自体のペアレント・クラスの「New」プロシジャEiGroup＿New と、ペアレント・クラスの必要とするプライベート・データのサイズ＋グループ ・クラス内のオブジェクトのプライベート・データ(EtDisplayGroupPrivate)に とって必要なメモリ・スペース量とによって与えられるデータサイズとを呼び出 す。エラー・チェッキングの後、EiDisplayGroup＿New()はグループ・オブジェ ク トのプライベート・データを示すポインタgroupPrivateを獲得し、それを初期化 する。次に、このプロシジャはその発呼者EiOrderedDisplayGroup＿New()に戻る 。 EtGroupObjectクラスにおける「New」プロシジャは次の通りである。 上記のプロシジャは、表示グループ・クラスおよび順序表示グループ・クラス のための「New」プロシジャと同じアウトラインをたどるが、クラスEtGroupObje ct に特有のプライベート・データがない点が異なる。こうして、EiGroup＿New( )プロシジャは、なんらプライベート・データを初期化せず、それがペアレント ・クラスの「New」プロシジャEiShape＿New()に移るデータサイズは、表示グル ープ・クラスの「New」プロシジャによってEiGroup＿New()に移されるデータサ イズと同じである。 プロシジャはEtObjectクラスの「New」プロシジャを介して上へ続く。明らか なように、Escherはクラス階層のすべてのクラスにおいてオブジェクトを創作す るのと同じ再帰的機構を使用する。さらに、明らかなように、Escherは多数のEs cherＡＰＩ呼び出しの機能を実施するのと同じ再帰技術を使用する。 ２．ErGroup AddObject() ここで再び補遺Ａのアプリケーション・プログラム例を参照して、新しい順 序表示グループ・オブジェクトgroupが創作された後、プログラムは後向きのス タイル・オブジェクトを創作し、それをグループに加える。プログラム例のこの 部分は本発明の理解にとって重要ではないが、このようなオブジェクトをグルー プに加えることができるということを説明するためにだけ含まれる。 次に、プログラム例は、EscherプロシジャErPolygon＿New()を用いてポリゴン ・オブジェクトpolygonを創作する。このプロシジャは、順序表示グループ・オ ブジェクトの創作に関して上述した「New」プロシジャと同様に動作するので、 ここでは再度説明する必要はない。次に、プログラム例は、EscherＡＰＩ呼び出 しErGroup＿AddObject()を用いてgroupにpolygonを加える。後者のプロシジャは 次の通りである。 明らかなように、このプロシジャは、グループに加えるべきオブジェクトおよ びそれが加えられるべきグループをアーギュメントとして受け取る。或る種のブ ックキーピング操作の後、プロシジャはEscherプロシジャEiGroup＿AcceptObjec t()を呼び出して、指定されたオブジェクトが指定された種類のグループ・オブ ジェクトに加えることができるタイプであるかどうか決定する。たとえば、指定 オブジェクトがライト・オブジェクトである場合、それは順序表示グループに加 えることができない。本ケースでは、ポリゴンをEtOrderedDisplayGroupオブジ ェクトに加えることができるので、結果は有効である。 次に、このプロシジャは、EtGroupObjectのペアレント・クラスの「サブクラ ス・メソッド獲得」プロシジャEtShapeObjectを呼び出すことによって、指定さ れた順序表示グループ・オブジェクトについてのEtGroupObjectクラス・メソッ ド・テーブルを示すポインタgroupClassを得る。このプロシジャは、次に、この メソッド・テーブルを指し示す「オブジェクト追加」プロシジャを呼び出し、ア プリケーション・プログラムに戻る。 指定された種類のグループ・オブジェクトのための「オブジェクト追加」プロ シジャを示すメソッド・テーブルのポインタは、EtOrderedGroupクラスそのもの が登録されたときに初期化中にそこに書き込まれる。指定された「オブジェクト 追加」プロシジャは次の通りである。 このプロシジャを参照してわかるように、このプロシジャは、まず、順序表示 グループ・クラスの「獲得」プロシジャを使用して指定された順序表示グループ ・オブジェクトのプライベート・データを示すポインタgroupDataを得る。次に 、このプロシジャは、追加すべき指定オブジェクトのタイプ（ジェオメトリ・オ ブジェクトである）を得、或る種のエラー・チェッキングの後に、EiOrderedDis playGroup＿GetObjectList()を呼び出してジェオメトリ・オブジェクトのための 順序表示グループ・オブジェクトの特定の二重リンク・リストを示すポインタth eListを得る。このプロシジャは、EiGroupPosition＿New()を呼び出して新しい リスト「位置」オブジェクトを創作し、EiDLList＿InsertNodeLast()を呼び出し て二重リンク・リストの終わりにこの新しい「位置」オブジェクトを挿入する。 次いで、このプロシジャはその発呼者EiGroup＿AddObject()に戻る。 完璧を期するならば、オブジェクトをリスト表示グループ・オブジェクトを加 えるためのプロシジャは順序表示グループ・オブジェクトにオブジェクトを加え るプロシジャと非常に似ているが、ただし、リスト表示グループ・オブジェクト には１つの二重リンク・リストしかないという点で異なることを了解されたい。 したがって、オブジェクトを追加しようとしている６つのリストのうちの１つを 決定する必要はない。また、オブジェクト追加プロシジャに加えて、EscherＡＰ Ｉも、グループのリスト内の指定位置の後にオブジェクトを加え、グループのリ スト内の指定位置の前にオブジェクトを加え、グループのリスト内の指定位置か らオブジェクトを取り除き、グループのリストを通して前後に繰り返すプロシジ ャならびに他のプロシジャを含んでいる。 ３．ErObject ＿Dispose() グループにオブジェクトを加えた後、補遺Ａのプログラム例は、ポリゴン・ オブジェクトを「廃棄」する。それがもはやアプリケーション・プログラムで必 要とされないからである（創作されつつあるモデル内のその存在とは別）。アプ リケーション・プログラムに関係する限り、ポリゴン・オブジェクトは削除され てしまっている。しかしながら、実際には、Escher ErObject＿Dispose()プロシ ジャは、この時点では、ポリゴン・オブジェクトを削除せず、メモリ・スペース の割り当てを取り消す。代わりに、polygonが共有オブジェクトであるから、 Escherはそのポリゴン・オブジェクトのための共有オブジェクト・プライベート ・データにおける参照カウントを減分するだけである。参照カウントは、polygo n が創作されたときに１にセットされ、group に加えられたときに１だけ増分さ れる。こうして、アプリケーション・プログラムの呼び出したErObject＿Dispos e()は、単に、参照カウントを２から１に減分するだけである。もし参照カウン トの減分が０までになると、Escherが実際にオブジェクトを削除し、そのメモリ ・スペースの割り当てを取り消す。 ４．新しいライン・オブジェクト 次に、補遺Ａのプログラム例は新しいライン・オブジェクトlineを創作し、 それを順序表示グループ・オブジェクトgroup に加え、次いでライン・オブジェ クトlineを「廃棄」する。これを行うべきEscherプロシジャ呼び出しはポリゴン ・オブジェクトpolygon に関して先に説明したものと類似しており、ここで繰り 返す必要はない。 ５．変換オブジェクトの追加 スタイル・オブジェクトおよび２つのジェオメトリ・オブジェクトを順序表 示グループgroup に置いた後、補遺Ａのプログラム例は、並進変換オブジェクト を創作し、それをグループに加える。変換オブジェクトtransform は、先に述べ たようにErOrderedDisplayGroup＿New()に類似する再帰要領で作動するEscherプ ロシジャErTranslateTransform＿New()を呼び出すことによって創作される。ErG roup＿AddObject(group，transform)およびErObject＿Dispose(transform)への プログラム例の引き続く呼び出しは上述したように作動する。ここで、プログラ ム例が変換オブジェクトを順序表示グループ・オブジェクトが２つのジェオメト リ・オブジェクトを既に加えた後にこの順序表示グループ・オブジェクトに加え るが、順序表示グループの性質がジェオメトリ・オブジェクトに先だって実行さ れるべき変換オブジェクトを呼び出すことであることに注目されたい。Escherは この特性を保証するために、もっぱら変換のための順序表示グループ・オブジェ クトgroup 内の個別の二重リンク・リスト上に変換オブジェクトを置き、もっぱ らジェオメトリ・オブジェクトのための二重リンク・リスト内にジェオメトリ・ オブジェクトを置く。レンダリングの際、後述するように、Escherはジェオメ トリ・オブジェクト・リストをトラバースする前に変換オブジェクト・リストを トラバースする。 ６．subGroup の創作および追加 変換オブジェクトを順序表示グループ・オブジェクトgroup を加えた後、補 遺Ａのプログラム例はErOrderedDisplayGroup＿New()を呼び出すことによって新 しい順序表示グループsubGroupを創作する。このプロシジャは上述した。次に、 プログラム例は、これも先に述べたErGroup＿AddObject()Escherプロシジャを用 いて、subGroupを先に創作した順序表示グループ・オブジェクトgroup に加える 。プログラム例は、こうして、第８図に示す階層を創作する。次に、プログラム 例は、EscherプロシジャErTorus＿New()（これも同様に上述したErPolygon＿New ()に作動する）を用いて新しいジェオメトリ・オブジェクト、特にトーラス・ジ ェオメトリ・オブジェクトtorus を創作する。次に、ErGroup＿AddObject()を用 いてtorusをsubGroupに加え、ErObject＿Dispose()を用いてtorus、subGroupの 両方を廃棄する。この時点で、第８図に示すモデルぜんたいが構築され、プログ ラム例はステップ３０８（第３図）に移動し、モデルをビューにレンダリングす る。 IV．モデルのビューへのレンダリング Escherにおいては、オブジェクトのビューへのレンダリングは、ErView＿Star tRendering()とErView＿EndRendering()との呼び出しの合間に行われる。これら のプロシジャは、単に、レンダリングに先だって関連したデータ構造を初期化し (トラバーサル・スタック上へ初期状態をプッシュすることを含む)、レンダリン グの後に種々のブックキーピング情報を一掃する。これらのプロシジャは、また 、レンダラー自体のスタート、エンド・プロシジャへの呼び出しも含み、その結 果、レンダラーは同じことを行うことができる。レンダラーのスタート、エンド ・プロシジャは、レンダラーの登録時にEscherに対して指定されており、適当な メソッド・テーブルにおいて識別される。特に、レンダラーのエンド・レンダリ ング・プロシジャは、EcMethodType＿EndRenderer 定数で呼び出されることに応 答してレンダラーのメタハンドラによって返される。 Escherは、それが２回以上モデルをトラバースし、そのたび毎に適切なレンダ ラー・プロシジャを呼び出す多数回レンダリングをサポートする。Escherは、状 況フラグEcViewStatus＿ReTraverseをErView＿EndRendering()プロシジャから戻 すことによって再トラバースが必要であることを指示する。アプリケーション・ プログラムがErView＿EndRendering()を呼び出したとき、このプロシジャはレン ダラーのエンド・レンダリング・プロシジャを呼び出す。ワイヤフレーム・レン ダラーの場合、このプロシジャはErWF＿End()と呼ぶ。レンダラーは、逆トラバ ース・フラグをEscherのErView＿EndRendering()プロシジャへ返し、このプロシ ジャが同じものをEcViewStatus＿ReTraverseとしてアプリケーション・プログラ ムへ返す。したがって、好ましい技術は、アプリケーション・プログラムが、Er View＿EndRendering()がEcViewStatus＿ReTraverseを返す限り反復する実行ルー プ内にモデル・ドローイング呼び出しを置くことである。これは補遺Ａのプログ ラム例で用いられるフォーマットである。 ここで、ErView＿StartRendering()とErView＿EndRendering()への呼び出しが アーギュメントとしてビュー・オブジェクトviewを採用することに注目されたい 。アプリケーション・プログラムは、或る特定のビュー・オブジェクトについて のErView＿EndRendering()への呼び出しが同じビュー・オブジェクトについての ErView＿StartRendering()への引き続く呼び出しであり、そのビューへのドロー イング呼び出しのすべてが中に挟まれている限り、任意のシーケンスでこれらの プロシジャを呼び出し、種々のビュー・オブジェクトを指定する。また、中に挟 まれた或る特定のビュー・オブジェクトについてのErView＿EndRendering()を呼 び出すことなく同じのビュー・オブジェクトについて二回ErView＿StartRenderi ng()を呼び出すことはエラーとなり、或る特定のビュー・オブジェクトについて のErView＿StartRendering()を最初に呼び出すことなく同じビュー・オブジェク トについてErView＿EndRendering()を呼び出すことはエラーとなる。しかしなが ら、異なったビュー・オブジェクトは、それらの事例データが別々なので、所望 に応じて同じレンダラーを指定できる。付録Ａのアプリケーション・プログラム 例は、特に先に定義された、ワイヤフレーム・レンダラーを指定するビュー・オ ブジェクトを用いてモデルを完全にレンダリングし、次いでビュー・オブジェク トにおけるレンダラーの選択を変えてＺバッファ・レ ンダラーを指し示し、同じであるが今や変更されているビュー・オブジェクトに 対して再度完全にレンダリングを行うことによってモデルを二回レンダリングす る際の非常に簡単な方針を採用している ErView＿StartRendering()とErView＿EndRendering()への呼び出しの合間に、 アプリケーション・プログラムは即時モードEscherドローイング・プロシジャか 保存モードEscherドローイング・プロシジャのいずれか、あるいは、これら両方 への呼び出しを行うことができる。即時モード・ルーチンはパラメータとしてデ ータ構造（たとえば、ポリゴン・データ構造）を採用し、それに対して、保存モ ードルーチンはパラメータとしてオブジェクト（たとえば、EtGeometryObject） を採用する。即時モード・ルーチンはいかなるモデルのトラバーサルも動かさな いが、或る種の保存モード・ルーチン（たとえば、ErDisplayGroup＿Draw()はモ デルのトラバーサルを起動する。 Ａ．モデルのトラバース したがって、補遺Ａのアプリケーション・プログラム例は、Escherのレンダラ ー呼び出しプロシジャ２１２（第２図）へのただ一回の呼び出し、特にErDispla yGroup＿Draw()への呼び出しを行う。アプリケーション・プログラムは、レンダ リングすべきモデル（モデル階層のルート・ノードを形成する順序表示グループ ・オブジェクトgroupによって表現される）およびモデルをパスし、レンダリン グしようとしているビューをパスする（ビュー・オブジェクトviewをパスするこ とによって）。アプリケーション・プログラムは、このとき、同じビューに付加 的なオブジェクト（付加的なモデルを含む）をレンダリングするためにEscherの レンダラー呼び出しプロシジャ２１２への付加的な呼び出しも行うことができる 。ErDisplayGroup＿Draw()プロシジャは次の通りである。 上記プロシジャを参照して、或る種のエラー・チェッキングの後、プロシジャ は、まず、group をEscherプロシジャEiDisplayGroup＿GetTypeIndex()に通すこ とによってgroup が順序表示グループであるかどうかを決定する。次に、このプ ロシジャは、順序表示グループ・クラスが初期化中に順序表示グループ・オブジ ェクトについてのEtDisplayGroupクラス・メソッド・テーブルと共に登録された ドローイング・メソッドに対するポインタfuncを得る。このオブジェクトgroup に対して「インライン」フラグがセットされている場合、プロシジャは次にfunc によって指し示されるプロシジャを呼び出し、groupおよびグループがレンダリ ングされることになっているビュー・オブジェクトをパスする。 オブジェクトgroupについての「インライン」フラグがセットされていない場 合には、EiDisplayGroup＿Draw()プロシジャがfuncによって識別されたプロシジ ャを呼び出す前にトラバーサル状態を「プッシュ」し、トラバーサル状態を後方 に「ポップ」する。 一実施例において、トラバーサル状態は、プッシュされ、ポップされ得るスタ ック内のカレント位置として表現され、レベル毎にそのレベルに先立つ変換マト リックスのすべての連接、カレント・スタイル特性、カレント・シェーダ特性、 カレント属性セットを含む。トラバーサル状態が「プッシュ」される毎に、新し いレベルが創作され、この情報はすべてスタックの先のレベルからカレント・レ ベルにコピーされる。さらに、この実施例では、変換マトリックスの連接は、変 換オブジェクトとトラバーサル中に出合ったときに各マトリックス予乗算を実際 に実行することによって生じる。 しかしながら、好ましい実施例では、カレント変換、カレント・スタイル特性 、カレント属性セットおよびカレント・シェーダ特性が複数のスタックに格納さ れ、各スタックは必要なときにのみプッシュされる。マスタ「状態」スタックは レコードを各レベルで維持し、トラバーサル状態全体がそのレベルからポップさ れたときにコンポーネント・スタックがポップされる必要がある。たとえば、カ レント変換状態は、カレント「local-to-world」マトリックス・スタック、逆マ トリックス・スタックなどを用いて表現される。しかしながら、トラバーサル状 態全体の各プッシュ毎にこれらのマトリックスを計算する代わりに、最後に計算 されたマトリックスからモデルのトラバーサルにおけるカレント位置までの変換 マトリックスのシーケンスのみが記録される。実際の計算は、それが実際に必要 とされない限りおよびそれが実際に必要とされるまで実施されない。こうして、 大量のマトリックス演算が回避される。 ここで、保存モードにおいて、Escherは、モデルのトラバーサル中に必要とな るなどしてプッシュ、ポップすることに注目されたい。即時モードでは、アプリ ケーション・プログラムはEscherプッシュ、ポップ・ルーチンも呼び出して、呼 び出しの注意深い順序づけによって、アプリケーション・プログラムはそれ自体 のモデル・データベースのそれ自体のトラバーサルを実施することができる。 EiDisplayGroup＿Draw()に戻って、funcによって指し示されるプロシジャはEi View＿OrderedDisplayGroup()であり、これは次の通りである。 明らかなように、上記プロシジャは、順序表示グループ・オブジェクトgroup のプライベート・データにおける６つの二重リンク・リストの異なったものに参 照の際に移る毎に、一般化された表示グループ・リスト・ドローイング機能EiDi splayGroupList＿Draw()を６回呼び出す。特に、プロシジャは最初に変換のリス トへの参照で、次いでスタイルのリストへの参照で、次いでシェードのリストへ の参照で、次いでグループ内のジェオメトリのリストへの参照で、次いでグ ループ内のサブグループのリストへポインタでリスト・ドローイング・プロシジ ャを呼び出す。そのたび毎に、プロシジャはリスト・ドローイング・プロシジャ を、リストにある種類のオブジェクトを描画する特定のプロシジャへの参照を通 す。たとえば、変換のリストがEiDisplayGroupList＿Draw()へ通されると、Esch erプロシジャEiTransform＿Draw()への参照も通される。別の例としては、ジェ オメトリのリストがEiDisplayGroupList＿Draw()へ通されると、Escherプロシジ ャEiGeometry＿Draw()への参照も通される。 ここで、group が順序表示グループ・オブジェクトではなくてリスト表示グル ープ・オブジェクトである場合、１回のみの呼び出しがEiDisplayGroupList＿Dr aw()に対して行われる。この呼び出しは、groupに添付されたオブジェクトの単 一リストへの参照およびリスト上で出合う各オブジェクトのタイプを決定するプ ロシジャへの参照をパスし、そのタイプについての適切なEscherドローイング・ プロシジャを呼び出す。 この一般化されたリスト・ドローイング・プロシジャは次の通りである。 明らかなように、このプロシジャは、単に、発呼者によって指定された二重リ ンク・リスト上のすべてのオブジェクトを通してループを作り、各オブジェクト 毎にそれを発呼者の指定するドローイング・プロシジャに通すだけである。 リスト・ドローイング・プロシジャよって呼び出されるEscherオブジェクト・ プロシジャのいくつかを以下に説明する。しかしながら、説明の便宜上、順序表 示グループをレンダリングするときに呼び出される順序と異なる順序で説明する 。 Ｂ．表示グループ・オブジェクトのドローイング・サブグループ・オブジェク ト Escherは再帰方法でモデルをトラバースし、この理由のために、ErView＿Orde redDisplayGroup()がグループ・オブジェクトgroupで出合うグループ・オブジェ クト用のリスト・ドローイング・プロシジャに移るEscherプロシジャは単にEiDi splayGroup＿Draw()にすぎない。このプロシジャは先に説明した。 Ｃ．表示グループ・オブジェクトにおけるドローイング・ジェオメトリ・オブ ジェクト ジェオメトリ・オブジェクトについてのリスト・ドローイング・ルーチンにEi View＿OrderedDisplayGroup()が識別するEscherプロシジャはEiGeometry＿Draw( )であり、これは次の通りである。 明らかなように、上記のプロシジャは、単に、或る種のエラー・チェッキング を実施し、ジェオメトリ・クラスによって登録されたジェオメトリ・ドロー・メ ソッドを呼び出すだけである。このメソッドはすべてのジェオメトリ・オブジェ クトにとって一般的であり、次の通りである。 エラー・チェッキング後、このルーチンは、まず、カレント・ビューのレンダ ラーがレンダリングされるべきタイプ（このケースでは、ポリゴン）のジェオメ トリ・オブジェクトについて登録されたメソッドを示すポインタfuncを得る。も しfuncがNULLである場合、ジェオメトリ・オブジェクトの分解が後述する要領で 生じる。しかしながら、本ケースでは、ワイヤフレーム・レンダラーはポリゴン ・オブジェクトをレンダリングするプロシジャとしてErWF＿Geometry＿Polygon( )を登録している。（ErWF＿Register()に関する上記の説明参照）。このプロシ ジャは補遺Ｂに記載してある。 Ｄ．分解を要求するドローイング・ジェオメトリ・オブジェクト 先のセクションで、ビューのレンダラーがジェオメトリ・オブジェクトのタイ プ（すなわち、ポリゴン）に特有のルーチンを有するシチュエーションにおいて 表示グループのジェオメトリ・オブジェクトをEscherにどのようにしてレンダリ ングさせるかは説明した。Escherと共に用いられるべきレンダラーは、少なくと も、点、線、三角をレンダリングするルーチンをサポートしていなければならず 、また、より高いレベルのジェオメトリをレンダリングするルーチンもサポート することができる。本発明に関して、レンダラーは、Escherがモデルの構築時に サポートするすべてのジェオメトリ・タイプをサポートする必要はない。むしろ 、 Escherは、或る特定のジェオメトリ・タイプについてのレンダリング・メソッド の不存在を自動的に検知し、ジェオメトリをより簡単な部分に分解することにな る。次に、Escherはこのより簡単な形態においてそれらをレンダラーに再提供す る。 本実施例のワイヤフレーム・レンダラーはポリゴン・オブジェクトをサポート するが、説明の目的のために、ここではそれが行えないと仮定する。ここでの説 明は、Escherがポリゴンを分解するジェオメトリで明らかなように三角形をレン ダリングするためのワイヤフレーム・レンダラーのメソッドがポリゴンをレンダ リングする同じワイヤフレーム・レンダラー・プロシジャであるために、仮定の ものである。すなわち、レンダラー・プロシジャErWF＿Geometry＿Polygon()は アーギュメントとして三角形あるいはポリゴンのいずれかを採用し、それがどれ であるかを決定し、同じコードを用いてそれをレンダリングする。それにもかか わらず、この仮定はEscherの分解技術を説明するのに役立つであろう。 １．Escher 初期化時に呼び出されるプロシジャ レンダラーを登録するための初期化時のプロシジャは先に説明した。クラスお よびサブクラスは初期化中と同様にそれら自体を登録する。たとえは、ポリゴン ・クラスは、最初、次の機能を呼び出すことによって登録される。 このルーチンはpolygon リーフ・クラスにおけるオブジェクトについてのクラ ス・メソッド・テーブルを創作する。先に述べた他の創作ルーチンと同様に、メ モリのブロックは、層状化技術を用いて割り当てられ、初期化される。各クラス のクラス登録プロシジャは、まず、それ自体のメソッド・テーブルについて要求 されるサイズをそのペアレント・クラスのクラス登録プロシジャに通す。polygo nクラスはリーフ・クラスであり、その結果、そのメソッド・テーブルのサイズ はゼロである。polygon クラス上方で、各プロシジャはそれ自体のメソッド・テ ーブルのサイズを加算し、そのペアレント・クラスのクラス登録プロシジャを再 帰的に呼び出す。最終的なペアレント・クラスのクラス登録プロシジャは、メソ ッド・テーブルのブロック全体についてメモリを割り当て、それ自体の部分をそ のデフォルト・メソッドを示すポインタで初期化し、呼び出しサブクラスのクラ ス登録プロシジャに戻る。 オリジナルの発呼者に戻る途中で、各クラスのクラス登録プロシジャはそれ自 体のメソッド・テーブルをそれ自体のデフォルト・メソッドで初期化する。加え て、各クラスのクラス登録プロシジャはメソッドを指定してそのペアレント・ク ラスのクラス登録プロシジャをオーバーライドするが、ペアレント・クラスのオ プションでのみである。これを達成するには、ペアレント・クラスのクラス登録 プロシジャを呼び出すときに、メタハンドラを指定し、いくつかのクラスについ て、呼び出しに対するアーギュメントとして仮想メタハンドラを指定する。これ らのメタハンドラは、もし望むのであれば、ペアレント・クラスのクラス登録プ ロシジャによって呼び出され、メソッド・タイプを指定し、もし呼び出された場 合には、メタハンドラは所望のプロシジャを示すポインタを返して指定タイプの ペアレント・クラスのデフォルト・メソッドをオーバーライドする。クラスが或 る特定のタイプのペアレント・クラスのデフォルト・メソッドをオーバーライド するプロシジャを持っていない場合には、メタハンドラはNULLを返す。 ポリゴン・クラス登録プロシジャの場合、メタハンドラだけがペアレント・ク ラスのクラス登録プロシジャに識別される。メタハンドラは次の通りである。 本明細書に対する特別の関連について、ジェオメトリ分解プロシジャについて 依頼されたときに、メタハンドラがそれを、すなわち、EiPolygon＿Decomposeを 返すことに注目されたい。このプロシジャは後述する。 ポリゴン・クラスのペアレント・クラスについてのクラス登録プロシジャ、Et GeometryObjectは次の通りである。 明らかなように、このプロシジャは、それ自体のペアレント・クラスのクラス 登録プロシジャ、EiShapeClass＿Register()を呼び出し、メタハンドラおよび仮 想メタハンドラを指定する。再帰が上記のプロシジャに戻った後、プロシジャは 、それ自体のメソッド・テーブルをデフォルト・プロシジャを差し示すポインタ で初期化することによって継続する。このプロシジャは、Escherプロシジャ、Ei ObjectClassData＿GetMethod()を用いてこれらのポインタを獲得する。このEsch erプロシジャは、特に、サブクラスのメタハンドラを頼んで各所望のメソッドに 対するポインタを提供する。プロシジャが識別すべきポリゴン・クラスのメタハ ンドラを求めるメソッドの１つは、分解メソッドであり、先に指摘したように、 それが識別するメソッドはEiPolygon＿Decompose()である。 ここで、Escherでは、分解メソッドが各レンダラーではなくて各ジェオメトリ ・タイプについてクラス・メソッド・テーブルにおいて識別されることは注目す べきである。こうすれば、分解メソッドが、レンダリングされるビューの一部で はなくてレンダリングされるべきモデルの一部あるいはレンダラーの一部として 含まれる。ここで、別の実施例では、レンダラーが直接描画できないジェオメト リについて分解メソッドをオーバーライドすることができることは了解されたい 。また別の実施例では、分解メソッドは、ジェオメトリ・サブクラスではなくて レンダラー・サブクラスに添付され得る。 ジェオメトリ・クラスのメタハンドラについての説明は本発明の理解には重要 ではないが、ジェオメトリ・クラスの仮想メタハンドラを以下に説明する。 特に関連があるものとしては、EtShapeObjectクラスのクラス登録プロシジャ によって呼び出されるときに、それがオブジェクト・ドローイング・プロシジャ としてEiGeometry＿Draw()を示すポインタを返すことになる。 ２．レンダリング中に呼び出されるプロシジャ 上述のEiGeometry＿DrawMethod()に戻って、先に述べたように、レンダラーが 与えられたタイプのジェオメトリを描画するためのプロシジャを登録していない 場合（説明の目的のために、ここではポリゴンに関連するケースを仮定する）、 このルーチンはジェオメトリをEiGeometry＿Decompose()に通すことになる。こ のプロシジャは次の通りである。 明らかなように、或る種のエラー・チェッキングの後、このプロシジャは、分 解メソッドについてメソッド・テーブル内で識別されたメソッドにジェオメトリ ・オブジェクトを通すだけである。ポリゴンの場合、このメソッドは上述したよ うにEiPolygon＿Decomposeとして先に登録されている。これは次の通りである。 上記プロシジャはEscherプロシジャEiPolygon＿Triangulate()を用いてポリゴ ンを三角形のバンドルに分解する。一実施例において、この三角形分割プロシジ ャは、新しい三角形のすべてを保持する新しいEtGroupObjectoを創作できる。し かしながら、エラー・チェッキングおよび再帰のレベルを短絡させるために、グ ループ内のすべてのオブジェクトがジェオメトリ・オブジェクトとなることが既 に知られているので、この三角形分割プロシジャは新しい三角形のすべてをクラ スEtGeometryBundleのオブジェクト内に置く。ジェオメトリ・バンドルはジェオ メトリのリストのみを保持し得る内部ジェオメトリのみオブジェクトである。 上記プロシジャは、即時モードあるいは保存モードのいずれかで作動する。即 時モードでは、プロシジャは分解の結果を保存せず、むしろ描画を簡単にする三 角形分割プロシジャを知らせるフラグで三角形分割プロシジャを呼び出す。保存 モードでは、上記のプロシジャは、分解を保存すべきであることを示すフラグを 持ち、また、それを保存すべきフィールドへの参照を持つ三角形分割プロシジャ を呼び出す。上記のプロシジャでは、三角形分割プロシジャがその結果のジェオ メトリ・バンドル・オブジェクトについての参照を書き込むフィールドはPolyPr iv->decompositionであり、上記のプロシジャは次にEiGeometry＿Draw()に移る 。 EiGeometry＿Draw()は先に説明したが、先に説明した要領で、エラー・チェッ キング後、ジェオメトリのタイプを描画するためにそれに通されるジェオメトリ ・オブジェクトのメソッド・テーブルで識別されたメソッドを呼び出すだけであ る。通常は、これらはレンダラーによって登録されたメソッドとなるが、ジェオ メトリ・バンドル・オブジェクトは周知のものではない。レンダラーはこれらの オブジェクトを描画するルーチンを登録しない。代わりに、メソッド・テーブル がジェオメトリ・バンドルについてのEscherのデフォルト・ドローイング・メソ ッドを示すポインタを含むことになる。これは次の通りである。 明らかなように、このプロシジャは、単に、それに提供されるジェオメトリ・ バンドル・オブジェクトにおけるジェオメトリ・オブジェクトのリストを通して 反復し、それぞれをEiGeometry＿Draw()に通すだけである。すべての三角形があ るので、EiGeometry＿Draw()が分解時の各三角形についてのレンダラーの三角形 ドローイング・プロシジャを呼び出すことになる。 Ｅ．表示グループ・オブジェクトにおけるドローイング変換オブジェクト EiView＿OrderedDisplayGroup()が変換オブジェクトについてのリスト・ドロ ーイング・ルーチンを識別するEscherプロシジャはEiTransform＿Draw()であり 、 これは次の通りである。 明らかなように、上記のプロシジャは、単に、EtTransformObjectについての 変換ドロー・メソッドを呼び出すだけである。このメソッドはすべての変換オブ ジェクトについて一般的であり、次の通りである。 このルーチンは、エラー・チェッキング後、まず、実行されるべきタイプ（こ の場合、並進）の変換オブジェクトを実行するためにカレント・ビューのレンダ ラーのメソッド・テーブルが持つメソッドに対するポインタfuncを獲得する。E 並進変換を実行するためのEscherのデフォルト・プロシジャは次の通りである。 Ｖ．品質コレクションの管理、使用 品質コレクション・オブジェクトは、品質グループ・オブジェクトのリンク・ リストを含むデータ構造である。品質コレクション・オブジェクトは、第６図に 示すようにクラスEtSharedObject（これ自体がクラスEtObjectのサブクラスであ る）のサブクラスであるクラスEtQualityCollectionObject の事例である。した がって、第５図のフォーマットの次に、品質コレクション・オブジェクトは第１ １図に示すようなメモリのフォーマットを有する。特に、メモリ領域１１０２は EtQualityCollectionObjectクラスのメソッドを指すポインタを含み、この領域 １１０２はオブジェクト・メソッドを指すポインタ１１０４と共有オブジェクト ・メソッド（これらはいずれもない）を指すポインタ１１０６を含む。EtQualit yCollectionObjectクラスはリーフ・クラスであり、したがって、このクラスは 特に品質コレクション・オブジェクト・メソッドについてのメソッド・テーブル を持たない。 この構造は、また、メモリ領域１１１０における品質コレクション・オブジェ クトについての事例データも含む。この領域は、部分１１１２（オブジェクト・ クラス１１０２を指し示している）におけるオブジェクト・クラスに特有の事例 データ、部分１１１４（参照カウントを含む）における共有オブジェクト・クラ スに特有の事例データ、部分１１６における品質コレクション・オブジェクト・ クラスに特有の事例データを含む。品質コレクション・オブジェクト・データは 品質グループ・オブジェクトのリンク・リストを開始するタイプEtQualityColle ctionPrivateのデータ構造である。 品質グループ・オブジェクトは、品質制御タイプ変数のグループを含むデータ 構造であり、各変数は、レンダリング品質とレンダリング速度の間のそれぞれの トレードオフにおける２つ以上のオプションをそれ自体が選ぶ値を含んでいる。 品質グループ・オブジェクトは、第６図に示すようにクラスEtSharedObjectのサ ブクラスであるクラスEtQualityGroupObjectの事例である。品質グループ・オブ ジェクトは第１２図に示すフォーマットを有する。特に、メモリの領域１２０２ はEtQualityGroundObjectクラスのメソッドを指すポインタを含む。この領域１ ２０２は、オブジェクト・メソッドを指すポインタ１２０４と、共有オブジェ クト・メソッド（いずれもまったくない）を指すポインタ１２０６とを含む。こ の構造は、また、メモリの領域１２１０における品質グループ・オブジェクトに ついての事例データも含む。この領域は、部分１２１２（オブジェクト・クラス １２０２を示す）内のオブジェクト・クラスに特有の事例データ、部分１２１４ （参照カウントを含む）内の共有オブジェクト・クラスに特有の事例データ、部 分１２１６における品質グループ・オブジェクト・クラスに特有の事例データを 含んでいる。品質グループ・オブジェクト・データは表Ｉに記載するフィールド を含むタイプEtQualityGroupObjectPrivateのデータ構造である。 明らかなように、品質コレクション・オブジェクトにおける他の品質グループ ・オブジェクトについてのリンク・リスト・ポインタは別にして、品質グループ ・オブジェクトは特定のグループと関連した品質インデックス値を記憶するフィ ールドを含む。一実施例において、品質インデックスはタイプ・フロートであり 、0.0から1.0までの範囲にあり得るが、他の実施例では、品質インデックス値は たとえば整数であってもよい。ここで、現在説明している実施例では品質インデ ックス値は品質グループ・オブジェクトのフィールドに格納され、別の実施例で は特定の品質グループに関連した品質インデックスは単なる計算値、たとえば、 ｎ／Ｎ（ここで、ｎはコレクションのリンク・リスト内の特定の品質グループの 位置であり、Ｎはコレクション内の品質グループの全数である）であってもよい 。また別の実施例では、或る特定の品質グループと関連した品質インデックスは 単 にｎである。この場合、特定の品質グループは品質グループのコレクション・リ スト内のｎ´番目の品質グループとなる。種々の実施例で、品質インデックス値 をそれぞれの品質グループと関連付けるための他の多くの技術を使用し得る。 再び表Ｉを参照して、各品質グループ・オブジェクトは、また、品質タイプ・ エントリのリストも含む。品質タイプ・エントリは１セットの変数であり、各変 数はレンダリング品質とレンダリング速度の間のそれぞれのトレードオフにおけ る少なくとも２つのオプションを選ぶ値を含む。一実施例では、種々の品質制御 変数およびこのパラメータに対して利用できる種々のオプションを示している。 種々の実施例が各品質グループにおける異なったセットのパラメータを含むこ とができ、テーブル内の各パラメータについて異なったオプションを含むことが できることは了解されたい。 Ｂ．品質コレクションを確立するためのプロシジャ 補遺Ａを参照して、アプリケーション・プログラム例は、プロシジャExSetupQ ualityCollection(&qualityCollection)によって品質コレクションを確立する。 このプロシジャは、アプリケーション・プログラムの一部であり、Escher提供プ ロシジャを用いて所望の要領で品質グループのコレクションを構築する。第１３ 図は、それぞれ品質インデックス0.2、0.4、0.6、0.8を持つ４つの品質グループ を有する品質コレクションを確立するExSetupQualityCollection()のフローチャ ートである。 第１３図を参照して、ステップ１３０２において、このルーチンは、まず、新 しい品質コレクション・オブジェクトを創作する。これは、EscherプロシジャEr QualityCollectionObject＿New()に対する呼び出しで行われる。このEscherプロ シジャが第１０図に関して先に説明したと同じ要領でスペースを割り当て、デー タ構造を初期化する。ErQualityCollectionObject＿New()は新しい品質コレクシ ョン・オブジェクトを指すポインタを返し、これを第１３図のプロシジャが変数 qualityCollectionとして格納する。 ステップ１３０４において、第１３図のプロシジャは、qualityIndex=0.2でEs cherルーチンErQualityGroup＿New(qualityIndex)を用いて新しい品質グループ ・オブジェクトを創作する。このルーチンは、第１０図の技術を用いて新しい品 質グループ・オブジェクトにメモリ・スペースを割り当て、品質グループの品質 インデックス・フィールドを0.2に初期化する。 先に述べた実施例では、プロシジャErQualityGroupObject＿New()に対する呼 び出しは新しいグループに対する品質インデックスを恒久的にセットする。グル ープ・オブジェクトが後に品質コレクションに加えられたとき、それを行うEsch erプロシジャ（以下に説明する）が新しいグループを品質グループの品質インデ ックスによって決まる適切なシーケンスでコレクションのリンク・リスト内に置 く。追加されるべきグループの品質インデックスがコレクション内に既にあるグ ループの品質インデックスを複写する場合、エラーが返される。 別の実施例においては、ErQualityGroupObject＿New()はアーギュメントを取 らないが、むしろ、新しいグループの品質インデックス・フィールドをnull値に 初期化する。Escherルーチンは、アプリケーション・プログラムが所望に応じて 引き続いてグループの品質インデックスをセットするのに設けたものである。 第１３図を参照して、最初の新しい品質グループが創作された後、アプリケー ション・プログラムは、ステップ１３０６において、所望に応じて第１グループ にパラメータをセットする。現在説明している実施例では、上記の表IIに記載さ れた品質タイプ・パラメータの各々はタイプEtQualityType の独特の４文字コー ドを割り当てられる。将来の強化を可能とするために、アプリケーション・プロ グラムはパラメータ値を直接読み出したり書き込んだりすることはないが、或る 種のEscherルーチンを介してのみそれを行う。さらに、アプリケーション・プロ グラムはEscherルーチンを使用してどの品質パレメータが特定のEscherバージョ ンによってサポートされるのかを決定することができる。品質タイプ・コードは 、Apple Computer，Inc.に登録され、アプリケーション・プログラム・ディベロ ッパが利用でき、Escherの引き続くアップグレードを通じて首尾一貫している。 表IIIに示すEscherルーチンは品質グループの内容を管理するためにアプリケー ション・プログラムによって使用される。 或る特定の品質グループと関連付けられた品質インデックスを獲得するルーチ ンは、品質インデックス値がErQualityGroup＿GetTypeData()およびErQualityGr oup＿SetTypeData()を用いてアクセスできる品質タイプの１つでないため、独立 ルーチンとして与えられる。しかしながら、別の実施例では、或る特定の品質グ ループと関連付けられたインデックス値は、これらのルーチンを用いてアクセス できる品質タイプの１つとして含まれ得る。 ステップ１３０８において、第１３図のプロシジャは最初の品質制御グループ ・オブジェクトをステップ１３０２で創作された品質コレクション・オブジェク トに加える。これは、表IVに記載するいくつかの品質コレクション・メインテナ ンス・プロシジャの１つであるEscherプロシジャErQualityCollection＿AddGrou p()を用いて行われる。 明らかなように、ルーチンErQualityCollection＿AddGroup()は、新しい品質 グループを品質インデックスに従ってソートした順序でコレクションに自動的に 加える。もし新グループの品質インデックスが既にコレクション内の別のグルー プと関連付けられているならば、エラーが返される。しかしながら、別の実施例 では、Escherルーチンはただ１つの品質コレクション内に同じ品質インデックス を有する２つ以上の品質グループの可能性を受け入れるように書くことができる 。また、先に述べたように、アプリケーション・プログラムが所望に応じて或る グループと関連付けられた品質インデックスを変えることができる他の実施例も 可能である。このような実施例では、品質インデックスが既に１つまたはそれ以 上の品質コレクション・オブジェクト内の１つのグループに割れ当てられている 場合には、或る種のブックキーピング機能を実施してソートした順序で各影響の ある品質コレクションを維持したり、同じ品質コレクション内で複写品質インデ ックスを扱ったりする必要があるかもしれないことは了解されたい。 第１３図を参照して、第１の品質グループ・オブジェクトが品質コレクション ・オブジェクトに加えられた後、プロシジャはステップ３１０において第２の新 しい品質グループ・オブジェクトを創作する。このとき、0.4の品質インデック スを使用する。ステップ３１２において、プロシジャは所望に応じて第２の品質 グループ・オブジェクト内にパラメータをセットし、ステップ１３１４において 、第２の品質グループ・オブジェクトを先に述べた要領で品質コレクション・オ ブジェクトに加える。 ステップ１３１６、１３１８、１３２０において、品質インデックス0.6を持 つ３番目のグループ・オブジェクトが創作され、所望に応じて修正され、品質グ ループ・オブジェクトに加えられる。同様に、ステップ１３２２、１３２４、１ ３２６においては、４番目の新しい品質コレクション・オブジェクトが0.8の品 質インデックスを用いて創作され、この４番目の品質グループ・オブジェクトに 適当にパラメータがセットされ、それが先に述べた要領で品質コレクション・オ ブジェクトに加えられる。これでアプリケーション・プログラム・プロシジャEx SetupQualityCollection()が完了する（ステップ１３２８）。 ここで、別の実施例においては、各アプリケーション・プログラム自体の品質 コレクションをセットアップする代わりに、Escherルーチンがデフォルト品質コ レクションを創作するためだけのプロシジャを提供してもよいことは了解された い。このようなデフォルトの品質コレクションは、４つまたは５つの品質グルー プを含むように予め定義し、各品質グループが品質タイプ値を充填され、最低の 品質インデックスを持つ品質グループから最高の品質インデックスを持つ品質グ ループまでのプログレッション全体が品質／速度トレードオフ連続体全体で単調 に向上する全品質と単調に低下する全速度をたどるようにしてもよい。 また、或る種のイメージをレンダリングするために、第１セットの品質タイプ 値を有する第１品質グループが、第２セットの品質タイプ値を有する第２グルー プの場合よりも高い品質、低い速度でレンダリングしてもよく、それに対して、 異なったイメージを、第１品質グループではより低い品質、より高い速度で、第 ２品質グループではより高い品質、より低い速度でレンダリングしてもよい。異 なったレンダラーで実施されるレンダリングもこの同じ種類のリバーサルを経験 する可能性がある。これらの可能性のために、Escherルーチンは品質タイプ値の 順列をより低いあるいはより高い品質インデックスと関連付けなければならない 属性概念をなんら押し付けない。アプリケーション・プログラムは、関連付けら れた品質インデックス値とは無関係に、所与の品質グループ内に任意所望セット の品質タイプ値を自由に定めることができる。ここで、別の実施例では、このよ うな関係が実際に強制されることになることは了解されたい。 Ｃ．品質グループを選び、獲得するためのプロシジャ コレクション内にいくつかの品質グループを有し、各々がそれぞれの品質イン デックス値と関連付けられていることの利点は、アプリケーション・プログラム がユーザに頼んで直感的な適切な機構を用いてレンダリング品質／速度トレード オフにおいて所望の点を選ばせることができるということである。再び補遺Ａの プログラム例を参照して、このアプリケーション・プログラムはアプリケーショ ン・プログラム・ルーチンExGetDesiredQualityIndex()を用いてこれを行う。第 １４図はこのようなプロシジャにおける主要ステップを示すフローチャートであ る。第１４図を参照して、ステップ１４０２において、プロシジャは品質ノブ・ アイコンを表示する。このアイコンは第１５図に示してあり、そこからわかるよ うに、ノブのように見える。このアイコンは品質インデックス値0.0を現在指し 示しているニードルであり、ユーザはニードルの先端をクリックし、円まわりに 回転するようにニードルをドラッグして0.0からほぼ1.0までの任意所望の品質 インデックスを選ぶことができる。一実施例において、ノブの利用できる位置は 連続的であり、ユーザは記憶用のバイナリ・レジスタの全細分性を持って品質イ ンデックスを選ぶことができる。別の実施例では、個別の値しか選べない。 第１４図を参照して、ステップ１４０４において、プロシジャはユーザの品質 インデックス選択を受け入れる。ステップ１４０６において、所望の品質インデ ックスが呼び出しルーチンに返される。 レンダラーは、一実施例ではレンダラー・オブジェクト、別の実施例ではビュ ー・オブジェクトに添付されていることによって選択した品質グループに気がつ く。現在説明している実施例では、ビュー・オブジェクトに添付されている。Es cherは、表Ｖに示す、品質グループ・オブジェクトを選び、獲得するルーチンを 提供する。 補遺Ａのアプリケーション・プログラム例はEscherルーチンErView＿SelectQu alityGroup()を用いて、ビュー・オブジェクトに対して、その品質インデックス がユーザの指定したものとマッチするかあるいはそれに最も近い品質グループを 選択する。ここで、種々の実施例で、所望の品質インデックスが品質コレクショ ン内の品質グループのうちの任意のものと関連付けられたもととマッチしない状 況について種々のまるめ機能を使用し得ることは了解されたい。本実施例では、 最も近い品質インデックス値を持つ品質コレクションが選ばれる。２つの品質グ ループと関連付けられた品質インデックスが所望の品質インデックスから等しく 異なっている場合には、高い方の品質インデックスを持つグループが選ばれる。 別の実施例では、所望の品質インデックスが常にラウンドアップされ、また別の 実施例では、所望の品質インデックスが常にラウンドダウンされる。 Ｄ．レンダラー・プロシジャ 或る指定のビューにシェイプをレンダリングするために呼び出された各レンダ ラーは、ビュー・オブジェクトに現在割り当てられている品質グループにおける 品質タイプの個々の値に応答して実行する。異なったレンダラーを選んで品質タ イプ・パレメータの異なったものに応答させ、他を無視するようにしてもよい。 第１６図は三角形をレンダリングするためのレイ・トレーサのErRT＿Geometry＿ Triangle()プロシジャの関連概念のフローチャートである。 第１６図を参照して、ステップ１６０２において、プロシジャは、上記のEsch erプロシジャErView＿GetQualityGroup()あるいはそれに類似したプロシジャを 用いてビューに現在割り当てられている品質グループを指すポインタを獲得する 。ステップ１６０４において、プロシジャはビューにレンダリングしようとして いる三角形についてのデータを獲得する。ステップ１６０６、１６０８、１６１ ０において、プロシジャはカレント品質グループにおける２つの異なった品質タ イプ・パラメータの値をルックアップして、三角形レンダリング・プロシジャの どのバージョンを使用すべきかを決定する。特に、ステップ１６０６において、 EscherプロシジャErQualityGroup＿GetTypeData()を用いて、プロシジャは品質 タイプ・パラメータ、「反射演算」についての値、を獲得する。この値が「オン 」の場合には（高品質／低速度選択を表す）、制御はステップ１６０８に 移る。「反射演算」が「オフ」の場合には、制御はステップ１６１０に移る。 ステップ１６０８は、次に、カレント品質グループにおける「シャドー演算」 品質タイプ・パラメータの値を決定する。「シャドー演算」が「オン」の場合に は、ステップ１６１２において、プロシジャは、品質タイプ・パラメータ「光線 深度」についての値を用い、反射を用い、シャドーを用いて三角形をレンダリン グする。もし「シャドー演算」が「オフ」の場合には、プロシジャは、指定光線 深度、反射を用い、シャドーを用いずに三角形をレンダリングする（ステップ１ ６１４）。 もし「反射演算」が「オフ」の場合、ステップ１６１０において、プロシジャ はステップ１６０８に類似した決定を行う。もし「シャドー演算」が「オン」の 場合には、ステップ１６１６において、プロシジャは、指定光線深度、シャドー 演算を用いるが、反射演算を用いずに三角形をレンダリングする。もしステップ １６１０で「シャドー演算」が「オフ」の場合には、ステップ１６１８において 、プロシジャは、指定光線深度を用い、シャドー演算あるいは反射演算を用いず に三角形をレンダリングする。 明らかなように、説明を簡単にするために、第１６図のレンダラー・プロシジ ャは、カレント品質グループ・オブジェクトにおける「光線深度」、「反射演算 」、「シャドー演算」品質タイプ・パラメータにのみ応答する。しかしながら、 特別な種類のレンダラーにとって適切であると同様に、他のレンダラーもより多 くの品質タイプ・パラメータに応答し得る。 本発明の好ましい実施例の上記の説明はまさに説明のために行ったものであり 、発明を開示した形態そのものに限定するものではない。明らかに、当業者には 多くの変更、修正が明らかであろう。これらの実施例は、発明の原理および実際 の用途を最も良く説明するために選ばれ、説明されたものであり、当業者であれ ば特別に意図した用途に合わせるように種々の実施例、種々の変形例について本 発明を理解できるであろう。本発明の範囲は以下の請求の範囲及びそれらの均等 物によって定義されるものである。

───────────────────────────────────────────────────── フロントページの続き (31)優先権主張番号 ０８／４８２，０１６ (32)優先日 1995年６月７日 (33)優先権主張国 米国（ＵＳ） (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，Ｍ Ｃ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ， ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＬＳ，ＭＷ，ＳＤ，ＳＺ，Ｕ Ｇ)，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＢＢ，ＢＧ，ＢＲ，Ｂ Ｙ，ＣＡ，ＣＨ，ＣＮ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ ，ＦＩ，ＧＢ，ＧＥ，ＨＵ，ＩＳ，ＪＰ，ＫＥ，ＫＧ， ＫＰ，ＫＲ，ＫＺ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，Ｌ Ｖ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ， ＳＫ，ＴＪ，ＴＭ，ＴＴ，ＵＡ，ＵＧ，ＵＺ，ＶＮ (72)発明者 シュナイダー フィリップ ジェイ アメリカ合衆国 カリフォルニア州 95006 ボールダー クリーク メドー ドライヴ ７ 【要約の続き】 ングさせる。アプリケーション・プログラムがレンダリ ング・サブシステムを呼び出してモデルを描画すると き、レンダリング・サブシステムは、モデルのレンダリ ングが完了したかどうかを示す再トラバース・フラグを 返す。もしこのフラグがレンダリングがまだ完了してい ないことを示す場合には、アプリケーション・プログラ ムは、再び、レンダリング・サブシステムを呼び出して モデルを描画する。

Claims (1)

1. 【特許請求の範囲】 １． グラフィック出力装置上に表示可能な画面の表現を創作する方法で あって、 第１のオブジェクトの表現をメモリ内で用意する段階と、 前記第１オブジェクトのアイデンティフィケーションと、前記第１オブ ジェクトを描画するのに使用する第１レンダラーのアイデンティフィケーション とでもってオブジェクト描画サブシステムを呼び出す段階とを包含し、 前記オブジェクト描画サブシステムが前記識別されたレンダラーを用い て前記画面に前記識別されたオブジェクトをレンダリングすることを特徴とする 方法。 ２． 請求の範囲第１項記載の方法において、前記第１オブジェクトが 少なくとも１つのサブオブジェクトを包含し、前記オブジェクト描画サブシステ ムは前記識別されたレンダラーを用いて前記グラフィック出力装置に出力するた めに前記画面に前記サブオブジェクトの各々を描画することを特徴とする方法。 ３． 請求の範囲第１項記載の方法において、さらに、 第２のオブジェクトの表現をメモリに用意する段階と、 前記第２オブジェクトのアイデンティフィケーションおよび前記第１レ ンダラーのアイデンティフィケーションでもって前記オブジェクト描画サブシス テムを呼び出す段階と を包含することを特徴とする方法。 ４． 請求の範囲第３項記載の方法において、さらに、前記第１、第２ のオブジェクトを前記画面にレンダリングした後に前記画面を出力する段階を包 含することを特徴とする方法。 ５． 指定されたレンダラーを用いて指定されたオブジェクトを画面に レンダリングするオブジェクト描画サブシステムと一緒に用いることができる、 少なくとも１つのグラフィック出力装置上に可視像を創作する方法であって、 オブジェクトの表現をメモリに用意する段階と、 一回目に前記オブジェクトのアイデンティフィケーションと使用すべき 第１レンダラーのアイデンティフィケーションとでもって前記オブジェクト描画 サブシステムを呼び出す段階と、 二回目に前記オブジェクトのアイデンティフィケーションと使用すべき 第２レンダラーのアイデンティフィケーションとでもって前記オブジェクト描画 サブシステムを呼び出す段階と を包含することを特徴とする方法。 ６． 請求の範囲第５項記載の方法において、前記オブジェクト描画サ ブシステムが前記指定されたオブジェクトをレンダリングする画面も前記オブジ ェクト描画サブシステムに対して指定され、前記オブジェクト描画サブシステム の前記一回目の呼び出しが第１画面を前記オブジェクト描画サブシステムに対し て指定し、前記オブジェクト描画サブシステムの前記二回目の呼び出しが前記オ ブジェクト描画サブシステムに対して第２画面を指定することを特徴とする方法 。 ７． 請求の範囲第６項記載の方法において、さらに、前記第１、第２ の画面を前記グラフィック出力装置のそれぞれ異なったものに出力する段階を包 含することを特徴とする方法。 ８． 請求の範囲第６項記載の方法において、さらに、前記第１、第２ の画面を前記グラフィック出力装置の同じものに出力する段階を包含することを 特徴とする方法。 ９． 第１レンダラーと共に用いるために、グラフィック出力装置上に 表示できる画面を創作する方法であって、 オブジェクトの指示を受けて前記画面にレンダリングする段階で、前記 オブジェクトが第１ジェオメトリを有する段階と、 前記第１レンダラーが前記第１ジェオメトリのオブジェクトをレンダリ ングできるかどうかを決定する段階と、 前記第１レンダラーが前記第１ジェオメトリのオブジェクトをレンダリ ングすることができる場合に前記オブジェクトを前記画面にレンダリングするよ うに前記第１レンダラーを呼び出す段階と、 前記第１レンダラーが前記第１ジェオメトリのオブジェクトをレンダリ ングできない場合に以下の段階、すなわち、 前記オブジェクトを前記第１ジェオメトリと異なるジェオメトリを有す る少なくとも１つのサブオブジェクトに分解する段階と、前記サブオブジェクト の各所与のサブオブジェクト毎に、前記第１レンダラーが前記所与のサブオブジ ェクトのジェオメトリを有するオブジェクトをレンダリングできる場合に所与の サブオブジェクトを前記画面にレンダリングするように前記第１レンダラーを呼 び出す段階とを実行する段階と を包含することを特徴とする方法。 １０．請求の範囲第９項記載の方法において、さらに、レンダリングす べきオブジェクトの指示を受ける前記段階と協調して、前記第１レンダラーの指 示を受け取る段階を包含することを特徴とする方法。 １１．請求の範囲第９項記載の方法において、さらに、前記受け取る段 階に先だって、前記第１レンダラーのメソッド・テーブルに、或る特定のジェオ メトリを有するオブジェクトをレンダリングするために呼び出されるべき前記第 １レンダラーのメソッドの指示を書き込む段階を包含することを特徴とする方法 。 １２．請求の範囲第１１項記載の方法において、前記特定のジェオメト リが前記第１ジェオメトリであることを特徴とする方法。 １３．請求の範囲第９項記載の方法において、さらに、前記受け取る段 階に先だって、 前記第１レンダラーがレンダリングできる各特定のジェオメトリ毎に、 前記第１レンダラーのためのメソッド・テーブルのそれぞれのエントリに、この 特定のジェオメトリを有するオブジェクトをレンダリングするために呼び出され るべき前記第１レンダラーのそれぞれのメソッドの指示を書き込む段階を包含す ることを特徴とする方法。 １４．請求の範囲第１３項記載の方法において、前記第１レンダラーが 前記第１ジェオメトリのオブジェクトをレンダリングできるかどうかを決定する 前記段階が、前記第１レンダラーについての前記メソッド・テーブルが前記第１ ジェオメトリを有するオブジェクトをレンダリングするために呼び出すべきメソ ッドの指示を含んでいるかどうかを決定する段階を包含することを特徴とする方 法。 １５．請求の範囲第１３項記載の方法において、前記レンダラーを呼び 出して前記オブジェクトをレンダリングする前記段階が、前記第１ジェオメトリ のオブジェクトをレンダリングするために前記メソッド・テーブルによって指示 されたメソッドを呼び出す段階を包含することを特徴とする方法。 １６．請求の範囲第１３項記載の方法において、さらに第２レンダラー と共に使用するために、さらに、前記受け取る段階に先だって、 前記第２レンダラーがレンダリングできる各サブジェクト・ジェオメト リ毎に、前記第２レンダラーについてのメソッド・テーブルのそれぞれのエント リに、サブジェクト・ジェオメトリを有するオブジェクトをレンダリングするた めに呼び出されるべき前記第２レンダラーのそれぞれのメソッドの指示を書き込 む段階を包含することを特徴とする方法。 １７．グラフィック出力装置上に表示できる画面を創作する方法であっ て、順番に、 アプリケーション・プログラムの実行をスタートする段階と、 第１レンダラーについて、それぞれのジェオメトリを有するオブジェク トをレンダリングするために呼び出されるべき前記第１レンダラーの少なくとも １つのメソッドの指示を確立する段階と、 前記第１レンダラーがレンダリングすることができる第１ジェオメトリ を有するオブジェクトについて、前記第１ジェオメトリを有するオブジェクトを レンダリングするための前記確立段階で確立された前記第１レンダラーのメソッ ドを呼び出す段階と を包含することを特徴とする方法。 １８．請求の範囲第１７項記載の方法において、前記確立段階が、前記 第１レンダラーがレンダリングすることができる各特定のジェオメトリ毎に、前 記第１レンダラーについてのメソッド・テーブルのそれぞれのエントリに、この 特定のジェオメトリを有するオブジェクトをレンダリングするために呼び出され るべき前記第１レンダラーのそれぞれのメソッドの指示を書き込む段階を包含す ることを特徴とする方法。 １９．請求の範囲第１７項記載の方法において、さらに、前記実行をス タートする段階の後に、第２レンダラーについて、それぞれのジェオメトリを有 するオブジェクトをレンダリングするために呼び出されるべき前記第２レンダラ ーの少なくとも１つのメソッドの指示を確立する段階を包含することを特徴とす る方法。 ２０．請求の範囲第１９項記載の方法において、さらに、前記呼び出し 段階に先だって、前記両確立段階の後に、前記アプリケーション・プログラムの 制御の下に、前記呼び出し段階について前記第２レンダラーに優先して前記第１ レンダラーを選択する段階を包含することを特徴とする方法。 ２１．請求の範囲第１９項記載の方法において、第２レンダラーについ ての前記確立段階が、前記呼び出し段階の後に生じ、さらに、前記オブジェクト について、第２レンダラーについての前記確立段階において確立された、前記第 １ジェオメトリを有するオブジェクトをレンダリングするためのメソッドを呼び 出す段階を包含することを特徴とする方法。 ２２．請求の範囲第１７項記載の方法において、さらに、前記確立段階 の後に、 前記第１レンダラーがレンダリングすることのできない第２ジェオメト リを有する第２オブジェクトを、それぞれが前記第２ジェオメトリと異なるジェ オメトリを有する少なくとも１つのサブオブジェクトに分解する段階と、 前記第１レンダラーがレンダリングできるジェオメトリを有する前記サ ブオブジェクトのうちの所与のサブオブジェクト毎に、前記所与のサブオブジェ クトのジェオメトリを有するオブジェクトをレンダリングするために前記確立段 階で確立された前記第１レンダラーのメソッドを呼び出す段階と を包含することを特徴とする方法。 ２３．グラフィック出力装置上に表示可能な画面の表現を創作する方法 であって、 第１オブジェクトの表現をメモリに用意する段階と、 前記第１オブジェクトのアイデンティフィケーションでもってオブジェ クト描画サブシステムを呼び出し、このオブジェクト描画サブシステムが前記画 面へ前記第１オブジェクトをレンダリングする段階の少なくとも１部を実施し、 前記第１オブジェクトの前記レンダリングが完了したかどうかを示すフラグを返 す段階と、 前記フラグが前記第１オブジェクトの前記レンダリングが完了していな いことを示す場合に前記呼び出し段階を繰り返す段階と を包含することを特徴とする方法。 ２４．請求の範囲第２３項記載の方法において、前記第１オブジェクト が複数のサブオブジェクトを含むモデルを包含することを特徴とする方法。 ２５．請求の範囲第２３項記載の方法において、さらに、前記呼び出し 段階の後に、第２オブジェクトのアイデンティフィケーションでもって前記オブ ジェクト描画サブシステムをさらに呼び出し、前記オブジェクト描画サブシステ ムが前記画面への前記第２オブジェクトのレンダリングの少なくとも１部を実施 することを特徴とする方法。 ２６．請求の範囲第２５項記載の方法において、前記オブジェクト描画 サブシステムは前記両呼び出し段階の後にのみ前記フラグを返すことを特徴とす る方法。 ２７．請求の範囲第２３項記載の方法において、前記呼び出し段階が、 まず前記第１オブジェクトの前記アイデンティフィケーションでもって 前記オブジェクト描画サブシステムを呼び出し、このオブジェクト描画サブシス テムがこの一回目の呼び出しに応答して前記画面への前記第１オブジェクトのレ ンダリングの前記少なくとも１部を実施する段階と、 次に前記オブジェクト描画サブシステムの終了レンダリング・プロシジ ャを呼び出し、このオブジェクト描画サブシステムがこの引き続く呼び出しに応 じて前記フラグを返す段階と を包含することを特徴とする方法。 ２８．請求の範囲第２７項記載の方法において、さらに、前記一回目の 呼び出し段階の後で前記引き続く呼び出し段階の前に、第２オブジェクトのアイ デンティフィケーションでもっと前記オブジェクト描画サブシステムの二回目の 呼び出しを行う段階を包含し、前記オブジェクト描画サブシステムがこの二回目 の呼び出しに応じて前記画面への前記第２オブジェクトのレンダリングの少なく とも一部を実施することを特徴とする方法。 ２９．請求の範囲第２３項記載の方法において、前記オブジェクト描画 サブシステムが前記第１オブジェクトの前記レンダリングが完了していないこと を示す前記フラグを返すことを特徴とする方法。 ３０．請求の範囲第２３項記載の方法において、オブジェクト描画サブ システムを呼び出す前記段階が、第１レンダラーのアイデンティフィケーション でもってさらに前記オブジェクト描画サブシステムを呼び出して前記第１オブジ ェクトを描画するのに使用する段階を包含し、前記オブジェクト描画サブシステ ムが前記第１レンダラーを使用してレンダリングの前記少なくとも一部を実施す ることを特徴とする方法。 ３１．請求の範囲第２３項記載の方法において、さらに、前記画面を前 記グラフィック出力装置に出力する段階を包含することを特徴とする方法。 ３２．請求の範囲第２３項記載の方法において、前記繰り返す段階が、 前記フラグが前記第１オブジェクトの前記レンダリングが完了したことを示すま で前記呼び出し段階を繰り返す段階を包含することを特徴とする方法。 ３３．グラフィック出力装置上に表示可能な画面を創作する方法であっ て、順番に、 アプリケーション・プログラムの実行をスタートする段階と、 第１レンダラーについて、それぞれジェオメトリを有するオブジェクト をレンダリングするための呼び出されるべき前記第１レンダラーの少なくとも１ つのそれぞれのメソッドの指示を確立する段階と、 前記第１レンダラーがレンダリングすることができる第１ジェオメトリ を有するオブジェクトについて、前記第１ジェオメトリを有するオブジェクトを レンダリングするために前記確立段階で確立された前記第１レンダラーのメソッ ドを呼び出す段階であり、前記第１レンダラーが前記第１オブジェクトのレンダ リングが完了したかどうかを示すフラグを返す段階と、 前記フラグが前記第１オブジェクトの前記レンダリングが完了していな いことを示す場合に前記呼び出し段階を繰り返す段階と を包含することを特徴とする方法。 ３４．グラフィック出力装置上に表示可能な画面の表現を創作する方法 であって、 第１オブジェクトの表現を用意する段階と、 複数の品質制御データ・グループを用意し、各品質制御データ・グルー プが複数の品質制御タイプ変数を有し、これらタイプ変数の各々がレンダリング 品質とレンダリング速度の間のそれぞれのトレードオフにおいて複数のオプショ ンを選ぶ値を含んでいる段階と、 オブジェクト描画サブシステムに対する前記品質制御データ・グループ の選んだものを選択する段階と、 前記オブジェクト描画サブシステムを呼び出して前記第１オブジェクト を前記画面にレンダリングする段階とを包含し、 前記オブジェクト描画サブシステムが前記選ばれた品質制御データ・グ ループの前記タイプ変数の各々における値に従って前記画面に前記第１オブジェ クトをレンダリングすることを特徴とする方法。 ３５．請求の範囲第３４項記載の方法において、前記第１オブジェクト が複数のサブオブジェクトを含むモデルを包含することを特徴とする方法。 ３６．請求の範囲第３４項記載の方法において、複数の品質制御データ ・グループを用意する前記段階が、 各々が前記複数の品質制御タイプ変数を有する複数の予備的品質制御デ ータ・グループを用意する段階と、 品質制御タイプ変数のうちの所望のもの、前記品質制御データ・グルー プのうちの所望のものおよび前記所望グループ内の前記所望変数に書き込むべき 所望値のアイデンティフィケーションでもって値設定プロシジャを呼び出す段階 とを包含し、 前記値設定プロシジャが前記所望値を前記所望グループの前記所望変数 に書き込むことを特徴とする方法。 ３７．請求の範囲第３４項記載の方法において、複数の品質制御グルー プを用意する前記段階が、 前記品質制御データ・グループの予備的複数を用意する段階と、 データ・グループ追加プロシジャを呼び出して前記品質制御データ・グ ループの所望の新しいデータ・グループを前記予備的複数の品質制御データ・グ ループに加える段階と を包含することを特徴とする方法。 ３８．請求の範囲第３７項記載の方法において、前記予備的複数の品質 制御データ・グループ内の前記品質制御データ・グループの各々がそれに関連付 けられた異なるインデックス値を有し、 前記複数の品質制御データ・グループを用意する前記段階が、さらに、 所望の新しいインデックス値を前記所望の新しい品質制御データ・グループと関 連付ける段階を包含し、前記所望の新しいインデックス値が前記予備的複数の品 質制御データ・グループ内の前記品質制御データ・グループの各々と関連付けら れたインデックス値と異なっていることを特徴とする方法。 ３９．請求の範囲第３４項記載の方法において、前記複数の品質制御デ ータ・グループ内の前記品質制御データ・グループの各々がそれぞれと関連付け られたインデックス値を有し、 前記品質制御データ・グループの選択したものを選ぶ前記段階が、所望 のインデックス値でもってデータ・グループ選択プロシジャを呼び出す段階を包 含し、 このデータ・グループ選択プロシジャが前記所望インデックス値に応じ て前記品質制御データ・グループの前記選ばれたものを選ぶ ことを特徴とする方法。 ４０．請求の範囲第３９項記載の方法において、前記データ・グループ 選択プロシジャが、前記品質制御データ・グループの選択されたものを、関連付 けられたインデックス値が前記所望のインデックス値に最も近い、前記複数の品 質制御データ・グループ内の前記品質制御データ・グループの１つとして選ぶこ とを特徴とする方法。 ４１．請求の範囲第３４項記載の方法において、前記品質制御タイプ変 数の１番目のものが、（ａ）シェーダが高品質メソッドによって演算されるべき かどうか、（ｂ）シェーダが高速メソッドによって演算されるべきかどうか、（ ｃ）シェーダが演算されるべきでないかどうかを選ぶ値を含んでいることを特 徴とする方法。 ４２．請求の範囲第３４項記載の方法において、前記品質制御タイプ変 数の１番目のものが、前記オブジェクト描画サブシステムが前記第１オブジェク トを前記画面にレンダリングすべき詳細レベルを選ぶ値を含んでいることを特徴 とする方法。 ４３．請求の範囲第３４項記載の方法において、前記複数の品質制御タ イプ変数が、 （ａ）ライン・スタイルのonまたはoffで前記オブジェクト描画サブシ ステムが前記第１オブジェクトを前記画面にレンダリングすべきかどうか示す値 を含むライン・スタイル変数； （ｂ）シェーダのoff、fastまたはonで前記オブジェクト描画サブシス テムが前記第１オブジェクトを前記画面にレンダリングすべきかどうかを示す値 を含むシェーダ変数； （ｃ）前記オブジェクト描画サブシステムがイルミネーションのoff,fa stまたはonで前記第１オブジェクトを前記画面にレンダリングすべきかどうかを 示す値を含むイルミネーション変数； （ｄ）詳細レベルがonまたはoffで前記オブジェクト描画サブシステム が前記第１オブジェクトを前記画面にレンダリングすべきかどうかを示す値を含 む詳細レベル変数； （ｅ）前記第１オブジェクトを前記画面にレンダリングするときに前記 オブジェクト描画サブシステムがシャドーを演算すべきかどうかを示す値を含む シャドー演算変数； （ｆ）前記第１オブジェクトを前記画面にレンダリングするときに前記 オブジェクト描画サブシステムが透明性を演算すべきかどうかを示す値を含む透 明性演算変数； （ｇ）前記第１オブジェクトを前記画面にレンダリングするときに前記 オブジェクト描画サブシステムが反射を演算すべきかどうかを示す値を含む反射 演算変数； （ｈ）後向き除去がonまたはoffで前記オブジェクト描画サブシステム が前記第１オブジェクトを前記画面にレンダリングすべきかどうかを示す値を含 む後向き除去変数； （ｉ）flat、gouraudまたはphong補間で前記オブジェクト描画サブシス テムが前記第１オブジェクトを前記画面にレンダリングすべきかどうかを示す値 を含む補間変数； （ｊ）漸次改善がonまたはoffで前記オブジェクト描画サブシステムが 前記第１オブジェクトを前記画面にレンダリングすべきかどうかを示す値を含む 漸次改善変数； （ｋ）前記オブジェクト描画サブシステムが前記第１オブジェクトを前 記画面にレンダリングすべきアンチェイリアシング・レベルを示す値を含むアン チェイリアシング・レベル変数； （ｌ）前記オブジェクト描画サブシステムが前記オブジェクトを前記画 面にレンダリングすべき光線深度を示す値を含む光線深度変数 からなるグループのうち少なくとも２つを含むことを特徴とする方法。 ４４．ソフトウェアを実行することによってアクセスできるデータを記 憶するメモリを有し、このメモリに品質コレクション・オブジェクト・データ構 造が記憶されており、この品質コレクション・オブジェクト・データ構造が複数 の品質制御データ・グループを含み、各品質制御データ・グループが複数の品質 制御タイプ変数を有し、各タイプ変数がグラフィックス・レンダリング品質とグ ラフィックス・レンダリング速度の間のそれぞれのトレードオフにおける複数の オプションを選択する値を含んでいることを特徴とするデータ処理システム。 ４５．請求の範囲第４４項に記載のデータ処理システムにおいて、前記 メモリには、さらに、前記品質制御データ・グループの各々と関連付けられた品 質制御インデックス値が記憶してあることを特徴とするデータ処理システム。 ４６．請求の範囲第４４項に記載のデータ処理システムにおいて、前記 メモリには、さらに、実行時に前記品質制御データ・グループの選択したものを オブジェクト描画サブシステムに対して選ぶソフトウェア命令が記憶してあるこ とを特徴とするデータ処理システム。 ４７．請求の範囲第４４項に記載のデータ処理システムにおいて、さら に、呼び出されたときに、前記品質制御データ・グループのうちの選ばれたもの の前記タイプ変数の各々における値に従って第１オブジェクトを画面にレンダリ ングするオブジェクト描画サブシステムを包含することを特徴とするデータ処理 システム。 ４８．請求の範囲第４７項に記載のデータ処理システムにおいて、前記 メモリには、さらに、実行時に、前記品質制御データ・グループのうちの前記選 ばれたものを前記オブジェクト描画サブシステムに対して選ぶソフトウェア命令 が記憶してあることを特徴とするデータ処理システム。 ４９．請求の範囲第４８項に記載のデータ処理システムにおいて、前記 メモリに、さらに、前記品質制御データ・グループの各々と関連付けられた品質 制御インデックス値が記憶されており、 前記メモリには、さらに、前記選択ソフトウェア指令を所望の品質制御 インデックス値の指示で呼び出すアプリケーション・ソフトウェア命令が記憶し てあり、 前記選択ソフトウェア命令が、実行時に、前記アプリケーション・ソフ トウェア命令によって指示された前記所望の品質制御インデックス値に応答して 前記選ばれた品質制御データ・グループを選ぶ命令を含んでいる ことを特徴とするデータ処理システム。 ５０．メモリ、アプリケーション・プログラム、オブジェクト描画サブ システムおよびグラフィック出力装置を有するデータ処理システムと一緒に使用 するための情報担持媒体であり、前記アプリケーション・プログラムによって呼 び出され得る複数のソフトウェア・プロシジャを記憶している情報担持媒体にお いて、 前記アプリケーション・プログラムの呼び出しに応答して、複数の品質 制御データ・グループを提供し、各品質制御データ・グループが複数の品質制御 タイプ変数を有し、各タイプ変数がレンダリング品質とレンダリング速度の間の トレードオフにおいて複数のオプションを選択する値を含む少なくとも１つのプ ロシジャと、 前記アプリケーション・プログラムの呼び出しに応答して、前記品質制 御データ・グループのうちの選択したものをオブジェクト描画サブシステムに対 して選ぶデータ・グループ選択プロシジャと、 前記アプリケーション・プログラムの呼び出しに応答して、前記オブジ ェクト描画サブシステムを呼び出して第１オブジェクトを前記グラフィック出力 装置上に表示可能な画面にレンダリングするプロシジャとを包含し、 前記オブジェクト描画サブシステムが前記選択された品質制御データ・ グループ内の前記タイプ変数の各々の値に従って前記第１オブジェクトを前記画 面にレンダリングする ことを特徴とする情報担持媒体。 ５１．請求の範囲第５０項記載の媒体において、前記第１オブジェクト が複数のサブオブジェクトを含むモデルを包含することを特徴とする媒体。 ５２．請求の範囲第５０項記載の媒体において、複数の品質制御データ ・グループを提供する前記少なくとも１つのプロシジャが、 前記アプリケーション・プログラムの呼び出しに応答して、各々が前記 複数の品質制御タイプ変数を有する複数の予備的品質制御データ・グループを提 供するプロシジャと、 品質制御タイプ変数のうちの所望のもの、前記品質制御データ・グルー プのうちの所望のものおよび前記所望グループ内の前記所望の変数に書き込むべ き所望の値のアイデンティフィケーションでの前記アプリケーション・プログラ ムの呼び出しに応答して、前記所望値を前記所望グループ内の前記所望変数に書 き込む値設定プロシジャと を包含することを特徴とする媒体。 ５３．請求の範囲第５０項記載の媒体において、複数の品質制御データ ・グループを提供する前記少なくとも１つのプロシジャが、 前記アプリケーション・プログラムの呼び出しに応答して、前記品質制 御データ・グループの予備的複数を提供するプロシジャと、 前記アプリケーション・プログラムによる呼び出しに応答して、前記品 質制御データ・グループのうちの所望の新しい品質制御データ・グループを前記 予備的複数の品質制御データ・グループに加えるデータ・グループ追加プロシジ ャと を包含することを特徴とする媒体。 ５４．請求の範囲第５０項記載の媒体において、前記複数の品質制御デ ータ・グループ内の前記品質制御データ・グループの各々がそれぞれと関連付け られたインデックス値を有し、 前記データ・グループ選択プロシジャが所望のインデックス値でもって 前記アプリケーション・プログラムによって呼び出され、 前記データ・グループ選択プロシジャが、前記所望のインデックス値に 応答して前記品質制御データ・グループのうちの前記選択されたものを選択する ことを特徴とする媒体。 ５５．請求の範囲第５４項記載の媒体において、前記データ・グループ 選択プロシジャが、前記品質制御データ・グループのうちの前記選択されたもの を、関連付けられたインデックス値が前記所望のインデックス値に最も近い、前 記複数の品質制御データ・グループ内の前記品質制御データ・グループの１つと して選ぶことを特徴とする媒体。