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

Description

制限付き著作権放棄
この特許書類の開示内容の一部は著作権保護の権利主張がなされる資料を含んでいる。著作権所有者は米国特許・商標局ファイルあるいは記録に見られるように特許開示の特許書類のいかなる者によるファクシミリ再生についても異議を持たないが、他のいかなるものであってもすべての権利を留保する。
背景
１．発明の分野
本発明は、グラフィックス・レンダリング・システム、一層詳しくは、グラフィックス・アプリケーション開発者をサポートするためのソフトウェア・ツールに関する。
２．関連技術の説明
グラフィックス・レンダリングとは、三次元幾何学的形状から二次元像（あるいは像の一部）を演算するプロセスである。オブジェクトのポイントをそれぞれ少なくとも３つの座標（オブジェクトが三次元全体で厚みを持つか持たないかによる）で指定された場合には、ここではオブジェクトは三次元であると考える。レンダラーとは、呼び出しに応じてグラフィックス・レンダリング作業を実施するツールのことである。いくつかのレンダラーはもっぱらソフトウェアであるが、或るものはもっぱらハードウェアであり、或るものはこれらの組み合わせを用いて実施される（たとえば、ハードウェアサポートまたはハードウェア加速を備えたソフトウェア）。レンダラーは、代表的には、画面をバッファにレンダリングし、それが後にグラフィカル出力装置に出力されるが、いくつかのレンダラーはそれらの二次元出力を出力装置に直接書き込むことができる。ここで用いるグラフィックス・レンダリング・システム（またはサブシステム）とは、アプリケーション・プログラムとグラフィカル出力装置の間の処理レベルのすべてを呼ぶ。多くの従来システムにおいて、グラフィックス・レンダリング・システムはレンダラーと同じ広がりを有する。すなわち、レンダラーは、なんらの介在処理層なしにアプリケーション・プログラムによって直接呼び出される。
グラフィックス・レンダリング・システムは、代表的には、アプリケーション・プログラムへの即時モード・インターフェイスまたは保存モード・インターフェイスを特徴とする。即時モード・インターフェイスとは、イメージをレンダリングしようとする毎にアプリケーション・プログラムが各幾何学的プリミティブをグラフィックス・レンダリング・システムに対して指定する正確な手続きインターフェイスである。レンダリング・システムが画面毎にモデル・データベースを保持することはなく、それを行うのはアプリケーション・プログラムである可能性がある。即時モード・インターフェイスは、モデルをフレーム毎に変える画面をレンダリングする場合、たとえば、シミュレーションの視覚化、アニメーション・シーケンスのプレビューあるいは１つのファイルからの一連のモデルの読み出しの場合に非常に魅力的である。一方、即時モード・インターフェイスでは、プロシジャを経て伝えられる全画面がフレーム毎にレンダラーに呼び出しをかけなければならず、その結果、アプリケーション・プログラムとレンダラーの間のデータ帯域幅が大きくなる。また、１つのモデルについてのファイル・フォーマットがモデルそれ自体と違って描画コマンドのストリームにすぎないことが多く、データ交換フォーマットとしての有効性が限られる。即時モード・インターフェイスは、また、アプリケーション・プログラムにツールキット・モデリング機能性を与えるには伝導性が低く、通常は、画面内のオブジェクトに働きかけるユーザ・インターフェイス・ツールキットの邪魔をする。
保存モード・システム（時に表示リスト・システムと呼ばれる）では、グラフィックス・レンダリング・システムは三次元モデルのデータベース表現を保持する。フレーム毎に、レンダリング・システムは保存モデル・データベースをトラバースし、それを描画する。これは、全画面を記述する描画呼び出しのストリームではなくて、アプリケーション・プログラムからグラフィックス・レンダリング・システムへのたった一回の呼び出しによって行われ得る。モデルが変わるとき、アプリケーション・プログラムはモデル・データベースを編集あるいは更新し、再びレンダリング・システムに問い合わせを行って画面をレンダリングする。保存モード・システムの利点は、アプリケーション・プログラムと任意のハードウェア・アクセラレータとの間の帯域幅を縮小するということである。モデル・データベースのファイル・フォーマットは、それが単なるプロシジャ呼び出しのリストではないので、データ交換フォーマットとしても使いやすい。オブジェクト・データベースの存在も、ユーザ・インターフェイス・ツールキット／モデリング機能を具現する付加的な方法を提供する。保存モデル・レンダラーはレンダリング情報もキャッシュできるし、画面移動の最適化のための情報もキャッシュできる。一方、保存モード・レンダリング・システムは画面データベースを編集するためのオーバーヘッドがより高く、画面をシステム定義データ構造、通常は、階層に強制することによってアプリケーション・プログラム・デザインを制限し、したがって、多くのアプリケーション・プログラムがモデルのコピーをそれ自体のフォーマットで保持しなければならない。
ここに参考資料として援用するMark A. Tarlton and P. Nong Tarlton, “A Framework for Dynamic Visual Applications”, Proceedings of the 1992 Symposium on Interactive 3D Graphics, Cambridge, MA, 1992, pp. 161-164には、汎用データベース・システムを備え、モデルを単一のシステム・階層に帰属させるのではなくてモデルを組織化する保存モード・レンダリング・システムが記載されている。この技術は欠点のない保存モード・システムの利点を得ることを試みている。
この高レベル機能は、すべてのアプリケーションについてのモデル組織化問題を解決することはできず、画面をフレーム毎に変える視覚化アプリケーションにとって最適でもない。
従来のグラフィックス・レンダリング・システムはいろいろな方法でそれらの有用性を制限する多数の付加的な問題を有する。以下のリストは現在入手可能なグラフィックス・レンダリング・システムのいくつかを示している。
ＧＬ ^TM ． Silicon GraphicsのＧＬは主として対話式グラフィックスのために用いられる即時モード・レンダラーである。ＧＬは、ここに参考資料として援用する“Graphics Library Programming Guide”, Silicon Graphics Computer Systems, 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”, Addison-Wesley, Reading, MA, 1990に記載されている。参考資料としてここに援用するTony Apodaca, “RenderMan Interface Specification Version 4.0 Beta”, January, 1992に記載されているように、RenderMan specificationの最近のバージョンが、現存のRenderMan呼び出しを大括弧でくくり、種々のレンダラーを使用可能とする新しいルーチンを提供している。レンダラーは画面をレンダリングする前にただ一回の呼び出しで指定され、それが全画面に作用する。また、個々に参考資料として援用するPixar, “Quick RenderMan Interface and Implementation Specification”,1992も参照されたい。
PHIGS． PHIGSは、ここに参考資料として援用するPHIGS Committee, A. van Dam, chair, “PHIGS Functional Description, Revision 3.0”, Computer Graphics, 22(3), 1988, pp. 125-218に記載されており、またここに参考資料として援用するInternational Standards Organization, “International Standard Information Processing Systems Computer Graphics-Graphical Kernel System 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-Windowsシステムの間でデータを伝送するためのもの）と、PHIGSから初めに導き出された１セットのセマンティクスとによって定義されるX-Windowsシステムの拡張である。PEXはいくつかの利用できるAPIを有し、これらすべてのAPIが描画、状態変更などを行うための保存モード、即時モード、混合モード機能呼び出しをサポートする。PEXは、ここに参考資料として援用する“PEX Protocol Specification, Version 5.0P-X Public Review Draft”, 14 September, 1990, Massachusetts Institute of Technologyに記載されている。
HOOPS ^TM ． Ithaca SoftwareのHOOPSは、ここに参考資料として援用するGarry Wiegand and Bob Covey, “HOOPS Reference Manual, Version 3.0”, Ithaca Software, 1991に記載されている。これは保存モード３−Ｄグラフィックス・システムであり、モデルを或る階層に組織化し、この階層のノードを、UNIXファイル・システムのファイルを参照するのとほとんど同じ方法でテキスト・ストリングを介してアクセスするのである。PHIGと同様に、HOOPSもただ１つのレンダラーをサポートする。しかしながら、HOOPSはPHIGSよりも広がりの大きい画面編集機能を提供する。

Kubotaの

は、オブジェクト指向デザインを持つ３−Ｄグラフィックス・システムの一例である。これは、ここに参考資料として援用する

に記載されている。

は、画面データを、PHIGSによって提供されるような単一のモノリシック・レンダラーではなくて、多種類のレンダラーによってレンダリングできるように設計されている。しかしながら、複数のレンダラーは、レンダリング方法をそのシステムに組み込んだときに

に自動的に追加され得ない。

では、レンダラーの選択は、

「ビュー・オブジェクト」内のカレント・レンダリング・スタイルを設定することによって指定される。また、

は、また、レンダリング前にビュー・オブジェクトにモデルを貼り付けるのにアプリケーション・プログラムを必要とする。これは

を一度に１つのレンダラーしか利用できないように制限する。

には、一度に１つのレンダラーしか使用できないように制限する他のデザイン状の問題もある。たとえば、レンダリング状態を維持するのに１セットの大域変数しか与えられないのである。

は保存モード・システムである。モデル階層を編集するのに伴う混乱のかなりの部分を軽減し、また、ダイナミック・データベースおよびユーザ対話を容易にするために、

はアプリケーション・コールバック・オブジェクトをサポートし、それによって、画面移動中にコールバック・オブジェクトに遭遇したときにアプリケーション・プログラムが呼び出されるべき機能を定義する。
Inventor ^TM ． InventorはＧＬグラフィックス・システムのトップに位置するオブジェクト指向型３−Ｄグラフィックス・ユーザ対話ツールキットである。

と同様に、Inventorは各オブジェクト・タイプ毎にレンダラー指定「レンダラー」方法を持たせることによって多数のレンダラーをサポートしている。Inventorは「scene graph」に全画面が存在する保存モード・システムである。Inventorは１つのパラメータとして１つのモデルを採用するレンダー・アクション・オブジェクトを有する。レンダラーは、モデルを描画するときに用いられるレンダリング・アクションによって選択される。レンダー・アクションは、モデルをトラバースし、オブジェクト毎に適切なレンダリング方法を呼び出すことによってモデル全体を描画する。通常のレンダー・アクションはＧＬレンダリング・モードである。Inventorは、ここに参考資料として援用するWerneche, “The Inventor Mentor”, Addison-Wasley（1994）に記載されている。
ここでの開示内容に関連した他の参考資料としては以下のものがあるが、これらはすべて本明細書に援用する。すなわち、Bergman, Fuchs and Grant, “Image 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 Department, University of Utah, Salt Lake City, UT, December, 1974; Chen, Rushmeier, Miller, and Turner, “A Progressive Multi-Pass Method for Global Illumination”, Computer Graphics, 25(4), 1991, pp. 165-174; Clark, “The Geometry Engine: A VLSI Geometry System for Graphics, ”Computer Graphics, 16(3), 1982, pp. 127-133; Foley, van Dam, Feiner, and Hughes, “Computer 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 using a Modified Scanline Algorithm”, Computer Graphics, 26(2), 1992, pp.241-248; Maillot, “Three-Dimensional Homogeneous Clipping of Triangle Strips”, Graphics Gems II, Academic Press, Inc., San Diego, CA, 1991, pp. 219-231; Newell, Newell, and Sancha, “A Solution to the Hidden Surface Problem”, Proceedings of the ACM National Conference, 1972, pp. 443-450; Potmesil and Hoffert, “FRAMES: Software Tools for Modeling, Rendering, and Animation of 3D Scenes”, Computer Graphics, 21(4), 1987, pp. 85-93; Saito and Takahashi, “Comprehensible Rendering of 3-D Shapes”, Computer Graphics, 24(4), 1990, pp. 197-206; Segal, Korobkin, van Widenfelt, Foran. and Haeberli, “Fast Shadows and Lighting Effects Using Texture Mapping”, Cemputer Graphics, 26(2), 1992. pp. 249-252; Sillion and Puech, “A General Two-Pass Method Integrating Specular and Diffuse Reflection”, Computer Graphics, 23(3), 1989, pp. 335-344; Snibbe, Herndon, Robbins, Conner, and van Dam, “Using Deformations to Explore 3D Widget Design”, Camputer Graphics, 26(2), 1992, pp. 351-352; Strauss and Carey, “An Object-Oriented 3D Graphics Toolkit”, Computer Graphics, 26(2), 1992, pp. 341-349; Turkowski, “Design Considerations for an object-Oriented [3D Graphics] Metafile”, Proceedings of the Third Eurographics Workshop on Object-Oriented Graphics, Charnpery, Switzerland, October, 1992, pp. 163-169; Venolia, “Facile 3D Direct Manipulation”, to appear in Proceedings of CHI '93, ACM/SIGCHI, Amsterdam. May, 1993; Venolia, “Automatic Alighnment in Two and Three Dimensions”, submitted to SIGGRAPH '93; Wanger, “The Effect of Shadow Quality on the Perception of Spatial Relationships in Computer Generate Imagery”, Proceedings of the 1992 Symposium on Interactive 3D Graphics, Cambridge, MA, 1992, pp. 3942である。
種々のレンダラーを用いてモデルを描画することができると望ましい。たとえば、三次元モデルの対話式編集を行えるアプリケーション・プログラムは、高速低品質ワイヤフレーム・レンダラーを用いてディスプレイ上に中間バージョンを描画することによって、また、高品質低速Ｚバッファ・レンダラーを用いてプリンタで最終バージョンを描画することによって利益を得ることができる。しかしながら、上記のレンダリング・システムを使用すると、レンダラーの互換性が最も扱いにくい。特に、上記レンダリング・システムのいくつかは２つ以上のレンダラーをサポートしておらず、それを行うもの、たとえば、

およびInventorは選ばれたレンダラーをシステム構成内に結合する。したがって、同じ三次元モデルについて異なった目的のために異なったレンダラーを使用できるような融通性の高いグラフィックス・レンダリング・システムが要望されている。
上記レンダリング・システムに伴う別の問題は、同時に活動状態にある２つ以上のレンダラーをサポートしないということである。ディスプレイとプリンタの両方に同時にイメージ出力することを含めて、多数のシチュエーションで１つのモデルを同時にレンダリングすることが望ましい。別の例として、同じディスプレイの２つの異なった部分に同時に１つのモデルの２つの異なったイメージをレンダリングすることが望ましい場合もある。同時レンダリングは、主として、アプリケーション・プログラムがレンダリング・システムに呼び出しの１シーケンスを行うことによってイメージを描画する即時モード・システムにおいて望ましいであろう。このようなシステムでは、多くのアプリケーション・プログラムが、１つのレンダラーのための呼び出しを別のレンダラーのための呼び出しシーケンスと一緒に点在させることによってより効果的に実行することができる。従来のシステムはこのような点在する呼び出しシーケンスを妨げる。
上記レンダリング・システムに伴うまた別の問題は、２つ以上のレンダラーをサポートしたこれらのシステムがすべてのレンダラーが少なくとも同じジェオメトリをサポートすることを要求するということである。たとえば、Inventorレンダリング・システムは点、線および或る種の他の予定義された形状をレンダリングすることができるレンダラーしかサポートできない。もっと単純なレンダラーはInventorと一緒には使用できない。少なくともフルセットのInventor幾何学的プリミティブをサポートしてるならば、もっと有能なレンダラーを使用できるが、これらのレンダラーが動的に追加されることはない。アプリケーション・プログラムは優先的にこれらのレンダラーに気がつかなければならないであろう。上記のレンダリング・システムは、レンダラーの特徴の自動検知、利用で多少の有能なレンダラーの「プラグイン」レンダリングを行えなかった。
上記レンダリング・システムに伴うまた別の問題は、マルチパス・レンダリングを良くサポートしないということである。すなわち、本質的に、即時モード・レンダリングおよび混合モード・レンダリングをサポートするシステムではないのである。マルチパス・レンダラーとは、画面データベースの多数回トラバースを必要とするように設計したものである。何故レンダラーを画面データベースについて多数回パスさせるように設計したかという理由は多数ある。たとえば、非常に高い解像度でレンダリングする場合にフレーム・バッファ全体をレンダリングするに充分なメモリがないかもしれないのである。レンダラーは、フレーム・バッファをストリップに分離し、各ストリップを個別のパスを経て画面データベースを通してレンダリングすることになる。別の例としては、イメージをそれぞれが異なった解像度の複数のデバイスにレンダリングしている場合（たとえば、１つのウィンドウが２つのモニタにまたがっているときあるいは１つのイメージをスクリーンと高解像度プリンタの両方にレンダリングしているとき）、レンダラーは一回の個別のパスで各デバイスをレンダリングすることができる。別の例として、漸進改善を行うレンダラーは画面データベースに対して複数回のパスを行って、プロセスがユーザ・アクションで停止させられるか、あるいはイメージが最高の品質になるまで最終的なイメージを連続的に改善することができる。また別の例としては、蓄積バッファやシャドウイング、ライティング・エフェクトを創り出すためのテクスチャ・マッピングの使用、２パス式グローバル・イルミネーション技術を必要とする高品質レンダリング・アルゴリズムがある。
保存モード・システムでは、アプリケーション・プログラムは、通常、レンダラーがそのレンダリングを完了するのに２回以上のパスを必要としているかどうかを知る必要がない。これは、アプリケーション・プログラムが１回だけの呼び出しを行ってレンダラーにモデルをレンダリングさせ、アプリケーション・プログラムに戻る前に必要なだけのパスをレンダラーが行えるからである。一方、即時モード・システムあるいは混合モード・システムでは、アプリケーション・プログラムはモデルをトラバースする際に一部を実施し、レンダラーに複数回の呼び出しを行ってただ１回のトラバースを達成する。したがって、多数回パス型レンダラーの場合、アプリケーション・プログラムは、画面を完成するにはモデルを何回トラバースするかを知っている必要がある。これには、レンダラーについての詳細な知識をアプリケーション・プログラムが持つことが必要であり、本質的に互換性のあるレンダラーをサポートするのは非常に難しくなる。
上記システムに伴うまた別の問題は、三次元モデルを表示のために画面内にレンダリングしようとしているとき、一方ではレンダリング作業の速度、他方では結果の品質で古典的なトレイドオフが存在するということである。たとえば、ワイヤフレーム・レンダリング作業は高速であるが、低品質の結果を作り出し、それに対して、レイ・トレイサーは同じモデルをレンダリングするのにかなり長い時間を要するが、結果はきわめて高品質であり得るということである。こうして、三次元モデルの対話編集を可能とするアプリケーション・プログラムは、ワイヤフレーム・レンダラーを用いてディスプレイ上に中間バージョンを描画し、レイ・トレイサー・レンダラーを用いて出力用の最終バージョンを描画することによって利益を得ることができる。しかしながら、レンダラーの互換性が上記のレンダリング・システムを用いると最も悪いことになる。さらに、或るレンダラーを別のレンダラーに交代させると、速度／品質トレイドオフ連続体上にグロス制御しか与えない。品質を少し犠牲にして速度を少し向上させる、あるいはその逆を行うためのアプリケーション・プログラムが望まれる。速度／品質トレイドオフ連続体に複数のグラデーションを与え、ユーザあるいはアプリケーション・プログラムがトレイドオフにおいて正確に所望の位置を選べることが望ましい。
過去において、アプリケーション・プログラムは、ユーザにレンダリング・プロセスの種々の副次的なパラメータについて制御を行わせ、ユーザは副次効果として速度／品質トレイドオフに影響を与えるオプションを選択することによってこの制御の利点を享受してきた。たとえば、或る光を一時的に切ることによって、ユーザは品質を犠牲にしてレンダリング・プロセスを進めることができる。同じ効果を達成するには、出力ウィンドウを小さくし、この選択を許すレンダラーについて塗りつぶしモードをエッジ・モードに切り替え、より粗いアンチエイリアシング・レベルを設定することによってレンダリング前に画面からオブジェクトを抜粋していた。いくつかのシステムでは、速度／品質トレイドオフに影響を与えるパラメータのいくつかがただ１つのダイアログ・ボックスにおいてユーザによるアクセスが可能となり、この場合、ユーザは制御可能なパラメータの各々についてオプションを選択できる。これは上記問題についての非常に断片的なアプローチである。他のアプリケーション・プログラムは、ユーザがレンダリングのためのグロス品質を選ぶことを許すが、通常は、このユーザの選択はプログラムに完全に異なったレンダラーを呼び出させるか、あるいは、少なくともレンダラーに非常に異なったレンダリング方法を使用させる。連続体に比較的精密な解像度を与えると共に、個々のレンダリング・パラメータと関係させることなく速度／品質レンダリング・トレイドオフ全体において所望の点をアプリケーション・プログラムあるいはユーザが選択できるようにした品質制御機構が必要である。
発明の概要
本発明によれば、大雑把に言って、グラフィックス・レンダリング・システムは、レンダラーの選択とは独立してモデルの保存モード構築および編集を行える。オブジェクトを描画するためにレンダリング・システムをアプリケーション・プログラム呼び出しすることによって描画すべきオブジェクトを指定するばかりでなく、レンダラーを使用してそれを行い得る。一実施例において、レンダラーはＡＰＩを通じてレンダリング・システムに識別されるより包括的な「ビュー・オブジェクト」の一部として指定される。こうして、モデルの構築あるいは編集中の任意の時点で異なったレンダラーへの切り替えがアプリケーション・プログラムのためのありふれた仕事となる。
本発明の別の局面において、グラフィックス・レンダリング・システムは、二つ以上のレンダラーを同時に活動状態にすることができる。一実施例において、これは、レンダリング・システムを呼び出して三次元オブジェクトを描画させるときにアプリケーション・プログラムが指定するそれぞれの「ビュー・オブジェクト（または複数のオブジェクト）」において各レンダラーについてのカレント・レンダリング状態を記憶することによって行われる。
本発明の別の局面においては、グラフィックス・レンダリング・システムは動的に登録したレンダラーをサポートするように拡張可能である。
本発明の別の局面においては、グラフィックス・レンダリング・システムは、ジェオメトリが選定されたレンダラーによってサポートされていないときにそれを自動的に検出し、このようなジェオメトリを複数の単純なジェオメトリのオブジェクトに自動的に分解する。この自動分解は、そのジェオメトリが選ばれたレンダラーによってサポートされたオブジェクトに到達するまで帰納的に実施され得る。
本発明の別の局面においては、グラフィックス・レンダリング・システムは、レンダラーが外面を完成するのに何回のパスを必要とするかを知る必要なしにアプリケーション・プログラムをモデルをレンダリングするために即時モード呼び出しあるいは保存モード呼び出しにすることができる。一実施例において、アプリケーション・プログラムはモデルを描画するのにレンダリング・サブシステムを呼び出し、このレンダリング・サブシステムがモデルのレンダリングが完了したかどうかを示すフラグ（ここでは、リトラバース・フラグと呼ぶ）を返す。もしこのフラグがレンダリングがまだ完了していないということを示す場合には、アプリケーション・プログラムはレンダリング・サブシステムを再び呼び出してモデルを描画することができる。好ましくは、レンダリング・サブシステムへの呼び出しはアプリケーション・プログラム内のループの中に置かれ、このループがリトラバース・フラグが完了を示すまで繰り返される。この技術は、ループがレンダリング・サブシステムへの多くの呼び出しを含むことができ、そのすべてがモデルそのものをトラバースする際にアプリケーション・プログラムによって行われるため、即時モード・レンダリング、混合モード・レンダリングをサポートする。リトラバース・フラグがレンダリングがまだ終わっていないことを示すとき、アプリケーション・プログラムは同じシーケンスの呼び出しを繰り返し、モデルを効果的にリトラバースする。
本発明の別の局面においては、アプリケーション・プログラムは、オブジェクトを描画するためにレンダリング・システムに行われるアプリケーション・プログラム呼び出しは描画すべきオブジェクトを特定するばかりでなく、レンダラーを使用してそれを行う。こうして、モデルの構築あるいは編集中の任意の時点での異なったレンダラーへの切り替えはアプリケーション・プログラムにとってありきたりの仕事となる。リトラバース・フラグの故に、アプリケーション・プログラムは、新しいレンダラーがレンダリングを完了するのに多数回のパスを必要とするかどうかに依存して、任意の付加的な割り当てをなす必要がない。
本発明の別の局面においては、グラフィックス・レンダリング・システムは、２つ以上のレンダラーを同時に活動状態にすることができる。一実施例において、これは、レンダリング・システムを呼び出して三次元オブジェクトを描画するときにアプリケーション・プログラムが指定するそれぞれの「ビュー・オブジェクト（あるいは複数のオブジェクト）」においてレンダラー毎にカレント・レンダリング状態を記憶することによって達成される。ここでふたたび、リトラバース・フラグは、１つまたはそれ以上の同時に活動状態のレンダラーがレンダリングを完了するのに複数回のパスを必要とする場合にアプリケーション・プログラムが特別の割り当てをなす必要性をなくす。
本発明の別の局面においては、グラフィックス・レンダリング・システムは、動的に登録されたレンダラーをサポートするように拡張できる。ここで再び、リトラバース・フラグのために、新しく登録されたレンダラーがただ１つのレンダラーあるいは多数回パスレンダラーとなるという制限がまったくない。
本発明のまた別の局面においては、連続体について比較的精密な解像度を持って、そして、個別のレンダリング・パラメータと関係することなく、速度／品質レンダリング・トレイドオフ全体においてアプリケーション・プログラムあるいはユーザが所望の点を選択できる機構を得ることができる。これを達成するグラフィックス・レンダリング・システムは品質制御データ・グループの連続体あるいは収集体を含み、その各々が複数の品質制御タイプ変数を含む。タイプ変数の各々は、レンダリング品質とレンダリング速度の間のそれぞれのトレイドオフにおいて複数のオプションを選択する値を含む。たとえば、品質制御データ・グループの各々は「詳細レベル」についての品質制御タイプ変数を含み得るし、これらのグループが品質連続体の下端でこれらの変数を「low」に設定し得るし、それに対して連続体のより高い端ではデータ・グループがこの変数を「high」に設定し得る。
本発明の別の局面においては、品質制御データ・グループの各々はそれぞれの品質インデックスと関連付けられる。こうすると、アプリケーション・プログラムは、品質制御インデックス値を選ぶだけで速度／品質レンダリング・トレイドオフ全体の１点を選ぶことができる。さらに、アプリケーション・プログラムは、たとえば、アイコニック「品質ノブ」として直感的な形態で品質制御インデックスをユーザ・アクセス可能とすることができる。品質ノブは複数の設定値、たとえば、０．０〜１．０の範囲の設定値を持つことができる。これらの設定値の各々は品質制御データ・グループのそれぞれに対応する。こうして、この機構により、ユーザは、個別のレンダリング・パラメータに対する調節に関係することなく、速度／品質レンダリング・トレイドオフについて精密な管理を行うことができる。
【図面の簡単な説明】
以下、本発明を特別な実施例に関連して説明し、図面も参照する。図面において、
第１図は、本発明を具現するコンピュータ・システムの簡略ブロック図である。
第２図は、本発明を具現するソフトウェア・アーキテクチャを示す。
第３図は、本発明を使用するプログラムの全体的な流れを示すフローチャートである。
第４図は、第３図のステップ３０８の詳細である。
第５、７、９、１１、１２図は、メモリ内のオブジェクト・データ構造を示す。
第６図は、本発明の一実施例で使用されるクラス・アーキテクチャを示す。
第８図は、本発明を使用するプログラム例によって作られるモデル階層を示す。
第１０図は、メモリ内の新しいオブジェクトの創作を示すフローチャートである。
第１３図は、品質コレクションをセットアップするアプリケーション・プログラム・プロシジャのフローチャートである。
第１４図は、所望の品質インデックスを得るためのアプリケーション・プログラム・プロシジャのフローチャートである。
第１５図は、表示アイコンの説明図である。
第１６図は、或るレンダラーに置ける或るプロシジャのフローシートである。
詳細な説明
第１図は本発明を具現するコンピュータ・システムの簡略ブロック図である。或る種のタイプのコンピュータ・アーキテクチャは他よりも良好な発明の利点を得ることができるが、本発明は事実上任意タイプのアーキテクチャについて実行することができる。第１図のアーキテクチャにおいて、ＣＰＵ１０２、メモリ１０４およびＩ／Ｏサブシステム１０６はすべてバス１０８に接続している。ＣＰＵ１０２は、メモリ１０４あるいはＩ／Ｏサブシステム１０６に対して読み出し、書き込みを行うためにバス１０８を通して信号を発行し、ここに説明する要領でデータを操作する。ＣＰＵは、メモリ１０４から得るソフトウェア命令に応答してこれらの信号を発行する。Ｉ／Ｏサブシステム１０６も、或る特定の実施例では、メモリ１０４にアクセスするためにバス１０８を通して信号を発行することができる。システムは、グラフィックス・コプロセッサ１１０も包含し得る。このコプロセッサはイメージをレンダリングするのに必要なメモリ集中作業の多くをＣＰＵ１０２からオフロードすることができる。このようなシチュエーションにおいて、第１図に１１４で示すディスプレイは、しばしば、Ｉ／Ｏサブシステム１０６によって駆動される。他のシステムでは、グラフィック・アクセラレータ１１２がバス１０８とディスプレイ１１４に接続してある。これらのシステムにおいて、ディスプレイ・バッファは、代表的には、グラフィック・アクセラレータ１１２の中に保持される。このアクセラレータは、ＣＰＵ１０２によって要求されたときとかにディスプレイ１１４の特定のピクセルに特定の属性（たとえば、カラー）を書き込むことができるばかりでなく、ＣＰＵ１０２のコマンドの下にディスプレイ１１４上により複雑なプリミティブを描画することもできる。
本発明は、本実施例では、Escherとここでは呼ぶ１セットのソフトウェア・ツールの形で実行される。これらのソフトウェア・ツールは、１セットのソフトウェア・プロシジャと１セットのヘッダ・ファイルと包含し、これらがプロシジャで使用される変数名称、データ構造を定義する。Escherは、記憶媒体（たとえば、磁気ディスクあるいは光ディスク）上のアプリケーション・プログラム・ディベロッパに与えられる。一実施例において、記憶媒体はEscherのためのソース・コードを含み、別の実施例では、記憶媒体はEscherのための或る種のソース・コードと或る種のオブジェクト・コードとを含む。アプリケーション・ディベロッパはアプリケーション・プログラムをEscherおよび１つまたはそれ以上のレンダラーでコンパイルし、それで得たオブジェクト・コードを記憶媒体上に保存する。組み合わせオブジェクト・コードは後に全体的にあるいはオーバーレイ様式でメモリ１０４に読み込まれ、CPU１０２によって実行される。
ここで、「メモリ」内にあるものとしてここで言及されるソフトウェアおよびデータが、任意の時点で、ディスクのような二次記憶媒体内に全体的あるいは部分的に実際に存在し得ることに注目されたい。このシチュエーションは、たとえば、オーバーレイ実行あるいは仮想メモリのようなアーキテクチャにより生じ得る。簡略化のために、ここでは、このようなソフトエアおよびデータのすべては、たとえ時には実際に一時的にどこかに存在し得るとしても、すべての適切な時点で「メモリ内」に存在すると考える。
第２図は、ソフトウェア・アーキテクチャ内のEscherの論理位置を示す。ここでわかるように、論理的に、Escherプロシジャ２０２はアプリケーション・プログラム２０４と複数のレンダラー２０６、２０８、２１０との間に配置してある。すなわち、アプリケーション・プログラム２０４はアプリケーション・プログラム・インターフェイス（ＡＰＩ）を経てEscherプロシジャにプロシジャ呼び出しを行い、Escher内の或る種のプロシジャ（特に、或る種のレンダラー呼び出しプロシジャ２１２）はレンダラー２０６、２０８、２１０にプロシジャ呼び出しを行う。レンダラー呼び出しプロシジャ２１２に呼び出しを行うとき、アプリケーション・プログラム２０４はレンダラー呼び出しプロシジャがどのレンダラーを使用すべきかを指定する。次いで、レンダラーは、ディスプレイ・バッファ・メモリ、グラフィックス・コプロセッサ１１０（もし存在するならば）、グラフィック・アクセラレータ１１２（もし存在するならば）などのようなプラットホームの他のハードウェア・コンポーネント２１４と連絡を取る。レンダラー呼び出しプロシジャ２１２に加えて、Escherプロシジャは、レンダラー・インストレーション・プロシジャ２１６、品質制御管理プロシジャ２１７、モデル構築・編集プロシジャ２１８、ビュー構築・編集プロシジャ２２０ならびに本発明の理解に関係しないいくつかの他の種類のプロシジャ（図示せず）も包含する。
第３図は、本発明を使用するプログラム例の全体的な流れを示すフローチャートである。ステップ３０２において、アプリケーション・プログラム２０４はEscher初期化プロシジャ（図示せず）を呼び出す。この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のためのレンダラーのインストレーションは、シェーダのような他の拡張をインストールするのにも用いられる一般化拡張機構を用いる。マッキントッシュ機器用の拡張は、データ・フォークおよびリソース・フォークと一緒に第１図のハードウェアに大容量で記憶されたファイルである。データ・フォークはEscherシステムによってロードされるべきコードを含み、リソース・フォークはデータ・フォーク内のコード断片を識別する。
アプリケーション・プログラム２０４がマッキントッシュで作動していてEscherプロシジャErInitialize()を呼び出したとき、Escherシステムはコンピュータ・システム上の拡張フォルダ内のすべての拡張ファイルを検索する。見つけ出された、滝せつなリソース情報を含むすべてのファイルはアプリケーション・プログラムで使用するために利用できると考えられる。拡張ファイルは初期化ルーチンを指定し、このルーチンは必要なステップのすべてを実施してそれがEscherシステムと共に提供するサービスならびに終了ルーチンを「登録する」。
Escher拡張はEscherランタイム環境において一般化オブジェクト階層構造にロードされる。Escherのオブジェクト階層は「オープン」アーキテクチャを有し、任意のアプリケーションが階層におけるいくつかのレベルのうちの任意のレベルにサブクラスを「プラグイン」することができる。レンダラーはサブクラスに分類され得るオブジェクト・クラスのうちの１つである。
Ａ．Escherオブジェクト・システム
Escherシステムにおけるオブジェクトは、２つのハンドル、すなわち、オブジェクト・クラスとオブジェクト・タイプとによって識別される。オブジェクト・クラスはタイプのポインタEtObjectClassPrivateであり、オブジェクト・タイプはロングワードである。Escherクラス階層内の各サブクラスのペアレント・クラスが或る種の動きを与えるため、Escherはオブジェクト・プライベート・データとオブジェクト・クラスを層状に記憶する。たとえば、レンダラー・クラスのサブクラスは、理論的に、第５図に示す要領でレイアウトされる。第５図はオブジェクト・「クラス」５０２を示す。これは、レンダラー、この場合、ワイヤフレーム（ＷＦ）レンダラーと関連付けられたすべての方法に対するポインタを含むメモリの隣接領域である。ワイヤフレーム・レンダラーがレンダラー・クラスからサブクラスに分類されるので、レンダラー・クラスは「共有オブジェクト」クラスからサブクラスに分類され、この「共有オブジェクト」クラスは一般化「オブジェクト」クラスからサブクラスに分類され、メソッド・テーブル５０２がオブジェクト・クラス（領域５０４）と関連付けられたメソッドを最初にリストに挙げる。これらのメソッドは、とりわけ、ディスポーズ・オブジェクト、複写オブジェクトおよび未登録オブジェクトを含む。すべてのオブジェクト・クラス・メソッド・テーブルは、これらのエントリが或る特定のメソッド・テーブル５０２において表現された派生クラスのうちの１つによって初期化時に無効にされない限り、これらのエントリにおける同じセットのEscherプロシジャを指示する。次に、クラス５０２は、「共有オブジェクト」クラスにおけるすべてのオブジェクトに対して適切な１セットのメソッドに対するポインタを含む領域５０６を含む。このとき、「共有オブジェクト」メソッドはまったくなく、この層にはスペースがまったく割り当てられない。領域５０６に続いて、すべてのレンダラーにとって適切な１セットのメソッドに対するポインタを含む領域５０８がある。Escherデザインの規則によってリーフ・クラスがそれ自体のメソッド・テーブルをまったく持たないので、特にワイヤフレーム・レンダラー・クラスのための層はない。
領域５１２はクラス５０２の事例のためにデータのすべてを記憶する。この領域は領域５０２と同じ要領で組織化される。特に、この領域は最初に領域５１４におけるオブジェクト・クラスの任意の事例にとって適切なデータのすべてを含み、次いで、領域５１６内の共有オブジェクト・クラスの任意の事例にとって適切なすべてのデータがあり、次いで、領域５１８内のレンダラー・オブジェクトの任意の事例にとって適切なすべてのデータがある。クラス・データ５０２と異なり、事例データ５１２は、ワイヤフレーム・レンダラー・オブジェクトの事例にとって適切なすべてのデータを含む領域５２０も含む。領域５１４内のオブジェクト・データは、ワイヤフレーム・レンダラー・オブジェクトのすべての事例に対して共通のメソッド・テーブル５０２に対するポインタのみを含む。領域５１６内の共有オブジェクト・データは参照カウントを含み、領域５１８内のレンダラー・オブジェクト・データおよび領域５２０内のワイヤフレーム・レンダラー・データを以下に説明する。
説明の目的のために、第５図には、ワイヤフレーム・レンダラー・クラスにおける或るオブジェクトの第２の事例が示してある。この第２事例は、領域５１２における第１事例のデータと同じフォーマットで、領域５２２に含まれるすべてのデータを有する。このデータの領域５２４におけるオブジェクト・データは、第１事例についてのオブジェクト・データと同じオブジェクト・クラス・メソッド・テーブル５０２を指し示す。ここで、第５図の第２事例がEscherオブジェクト機構におけるクラスと事例データの間の関係を説明するためにのみ挙げたものであることに注目されたい。特にワイヤフレーム・レンダラーの２つ以上の事例がこれまでにアプリケーション・プログラムのただ１回のインストレーションで共存したことはありそうもないが、これも排除しない。
このとき、Escherシステムで使用されるクラス階層を説明すると有効であろう。この階層は広大であるから、本発明の理解を助けるクラスのみを第６図に示す。第６図を参照してわかるように、EtObjectクラスは階層内のすべてのクラスに対するペアレント・クラスである。EtSharedObjectクラスは、ここでは関係のない他のクラスと同様に、EtObjectの下にサブクラスに分類される。EtSharedObjectの下にサブクラス化されたクラスは、EtSharedObjectクラス、EtRendererObjectクラス、EtSetObjectクラス、EtDrawContextクラス、EtViewObjectクラス、EtQualityCollectionObjectクラス、EtQualityGroupObjectクラスである。EtSharedObjectの下にサブクラス化されたクラスは、EtStyleObjectクラス、EtTransformObjectクラス、EtCameraObjectクラス、EtLightObjectクラス、EtGeometryObjectクラス、EtGroupObjectクラス、EtSharedObjectクラスであり、EtRendererObjectの下にサブクラス化されたクラスは、ZbufferクラスとWireFrameクラスである。EtStyleObjectの下にサブクラス化されたクラスは、特に、BackFacingStyleクラスである。EtTransformObjectの下にサブクラス化されたクラスは、特に、図示しないが、Rotateクラス、Scaleクラス、Translateクラスである。EtGeometryObjectの下にサブクラス化されたクラスは、特に、Line、Point、Polygon、PolyLine、Torus、Triangleのオブジェクトについてのクラスである。EtGroupObjectの下にサブクラス化されたクラスはEtlightGroupクラス、EtInfoGroupクラス、EtDisplayGroupクラスであり、この最後のクラスはサブクラスEtOrderedGroupとEtListGroupを有する。このクラス階層は、階層に含まれるクラスの各々についてのメソッド・テーブルおよび事例データの記憶を記述する。階層の両端のクラス（すなわち、ツリー構造の「リーブス」）は、「リーフ」クラスとして知られている。
Ｂ．レンダラーの登録
Escherにおけるオブジェクト・サブクラス化の根拠は、Escherが拡張機構を用いてシステム起動時に動的にそのメソッド・テーブルを構築するということにある。レンダラー・オブジェクト・クラスを含む、システム内のすべてのオブジェクト・クラスは、アプリケーション・プログラムによって呼び出されたEtInitializeプロシジャの制御の下に「登録」される。その結果、それらの機能を必要に応じて利用できる。各拡張がロードされる毎に、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のサブクラスであるクラスEtViewObjectの事例である。したがって、第５図のフォーマットに続いて、ビュー・オブジェクトはメモリ内に第７図のフォーマットを有する。特に、メモリ領域７０２はEtViewObjectクラスのメソッドに対するポインタを含むように割り当てられ、この領域７０２はオブジェクト・メソッドに対するポインタ７０４と共有オブジェクト・メソッドに対するポインタ７０６とを含む。EtViewObjectクラスはリーフ・クラスであり、Escher規則によれば、このクラスは特にビュー・オブジェクト・メソッドについてのメソッド・テーブルを省略している。ここでも、本実施例では、共有オブジェクト・メソッドがまったくないということに注目されたい。
この構造は、また、メモリ領域７１０におけるビュー・オブジェクトについての事例データも包含する。この領域は部分７１２（オブジェクト・クラス７０２を指し示す）におけるオブジェクト・クラスに特有の事例データを含み、部分７１４（参照カウントを含む）における共有オブジェクト・クラスに特有の事例データを含み、部分７１６におけるビュー・オブジェクトに特有の事例データを含む。ビュー・オブジェクト・データは以下に述べるタイプEtViewPrivateのデータ構造である。

明らかなように、ビュー・オブジェクトは、特に、現在の選択されたレンダラーのメソッドに対するポインタ（^* rendererClass）、カレント・レンダラーの事例データを示すポインタ（^* renderer）、ドロー・コンテキスト・オブジェクト、カメラ・オブジェクト、ライティング・オブジェクト（lights）、いくつかのシェーダ・オブジェクトおよび品質グループ・オブジェクトを含む。
EtRendererPrivate構造は以下の通りに定義される。

この構造はトラバーサルの現在の状態を示す一連のスタックに対するポインタを含む。以下により詳しく説明するように、これらの状態スタックは、Escherのトラバーサがモデル内の「グループ」オブジェクトを開く毎にプッシュされ、階層の次のレベルのトラバースを開始する。これらのスタックは、トラバーサがモデル階層のすべての下方レベルでその作業を完了し、「グループ」オブジェクトを閉じたときに先の状態までポップアップされる。
EtRendererClassデータ構造は次のように定義される。

ここで、上述したワイヤフレーム・レンダラーの初期化プロシジャが、Escherがレンダラー・クラスの或る種のメソッドをオーバーライドするように呼び出すことができるメタハンドラを確立することを想起されたい。Escherは、メタハンドラによって返された或るメソッドを、対応するメソッドのために先に定義されたEtRendererClass構造フィールドに置く。また、ワイヤフレーム・レンダラー初期化プロシジャが、ErRendererClass＿OverrideGeometryTypeDrawMethodプロシジャを用いて特に或る種のジェオメトリ・ドローイング・メソッドをオーバーライドすることも想起されたい。このプロシジャは指定されたレンダラー・プロシジャに対するポインタを^*geometryDrawMethosによって指し示されたメソッド・テーブルに書き込み、それによって、初期化時の最初にEscherシステムによってセットアップされたデフォルト・メソッドをオーバーライドする。EtMethodTableデータ構造は、ポインタの単なるリストであり、^*geometryDrawMethodsについては、テーブル内の各エントリが対応するジェオメトリ・タイプ、たとえば、点、線、三角などをレンダリングするためのプロシジャを指し示す。このテーブル内のロケーションとジェオメトリ・タイプの間の対応はコンパイル時には固定である。
メンショニングを支えるEtRendererClassデータ構造における他のフィールドとしては、geometryDrawMethodフィールドがある。このフィールドは、カレント・レンダラーがサポートしていないジェオメトリ・タイプを描画することが依頼されている場合にEscherが呼び出すことになるプロシジャに対するポインタを含む（すなわち、ジェオメトリのための^*geometryDrawMethodsにおけるメソッド・テーブル・エントリがNULLである）。このプロシジャは指定されたジェオメトリを同様のジェオメトリに分解する（これは後により詳しく説明する）。本実施例では、この分解プロシジャはオーバーライドされ得ない。しかしながら、本発明の別の実施例では、レンダラーがこの分解メソッドをオーバーライドしてプロセスを最適化することができる。
EtQualityGroupObject構造を以下に説明する。
Ｂ．プロシジャ
ステップ３０４（第３図）においてビュー・オブジェクトを構築するプロセスは、基本的に、ビュー・オブジェクト・データ構造に所望の情報を書き込むプロセスである。付録Ａのアプリケーション・プログラム例をこのプロセスを説明するために用いる。
１．ビュー・オブジェクトの創作
品質コレクションの初期化、設定の後、アプリケーション・プログラムはview = ErView＿New()を呼び出すことによって新しいビュー・オブジェクトを創作する。このプロシジャは、単に、EtViewObjectクラスにおけるオブジェクトの新規な事例を創作し、それをデフォルト・データで満たすだけである。
２．レンダラーの設定
レンダラーは、EscherプロシジャErView＿SetRendererを呼び出し、ビュー・オブジェクトおよびレンダラー・オブジェクト内を通すことによってビュー・オブジェクトに添付され得る。この呼び出しは通されたレンダラーの参照カウントを増分することになる。レンダラー・オブジェクトが既にセットされている場合には、その参照カウントは減分される。
レンダラーは、最初にレンダラー・オブジェクトの事例を得る必要なしにレンダラー・タイプによってもセットされ得る。この場合、アプリケーション・プログラムはEscherルーチンErView＿SetRendererByTipeを呼び出し、これが付録Ａのプログラム例によって呼び出されるプロシジャである。このプロシジャに通されるパラメータはビュー・オブジェクトとタイプ宛先であり、このタイプ宛先はレンダラーのタイプ（たとえば、ワイヤフレームあるいはＺバッファ）を示す４文字コードである。EscherプロシジャErView＿SetRendererByTypeは、指定されたタイプのどんなレンダラーが登録されるかを決定し、このようなレンダラーが登録されているならば、レンダラー事例データに対するポインタを指定ビュー・オブジェクトの適切なエントリに書き込む。
３．カメラの設定
カメラを設定する前に、カメラ・オブジェクトが創作され、初期化されなければならない。補遺Ａのプログラム例は、これを達成するのに、カメラ透視データを適切なperspectiveDataデータに書き込み、EscherプロシジャErViewAngleAspectCamera＿NewDataを用いてそれをカメラ・オブジェクトに割り当てる。ひとたびカメラ・オブジェクトが得られたならば、それをビュー・オブジェクトと関連付けるために、ビュー・オブジェクトおよびカメラ・オブジェクトを通るErView＿SetCameraを呼び出す。この呼び出しはそこを通るカメラ・オブジェクトの参照カウントを増分させる。カメラ・オブジェクトがすでにセットされているならば、この参照カウントは減分される。補遺Ａのプログラム例は、次いで、Escher機能ErObject＿Disposeを用いてカメラ・オブジェクトを廃棄する。カメラ・オブジェクトがもはや別個に必要ないからである。
４．ドローイング・コンテキストの設定
ドロー・コンテキストを設定する前に、ドロー・コンテキスト・オブジェクトを創作して、初期化しなければならない。補遺Ａにおけるプログラム例では、これを達成するために、適切なデータ構造pixmapDataをセットアップし、それをEscherプロシジャErPixmapDrawContext＿NewDataに通す。次いで、ドロー・コンテキスト・オブジェクトを、呼び出しErView＿SetDrawContextを用い、ビュー・オブジェクトおよびドロー・コンテキスト・オブジェクトに通してビュー・オブジェクトと関連付ける。補遺Ａのアプリケーション・プログラム例は、次に、Escher機能ErObject＿Disposeに通すことによってドロー・コンテキスト・オブジェクトを廃棄する。
ビューの他の特性、たとえば、ライティングおよびシェーダも同様にして指定され得る。
５．レンダリング品質レベルの選択
これは後により詳しく説明する。
明らかなように、１つのビュー・オブジェクトの構築、編集は別のビュー・オブジェクトの構築、編集から完全に分離しており、２つ以上のビュー・オブジェクト（同じあるいは異なったレンダラーを指定するものを含む）が互いに干渉することなく共存できる。
III．モデルの構築
Escherで使用されるモデリング・プログラムは、アップル・コンピュータから入手できる２つの現存の製品、すなわち、QuickDrawとQuickDraw GXを用いるモデリング・プログラムを比較することによって最も良く理解することができる。QuickDraw GXは、アップル・コンピュータ「QuickDraw GX Programmer's Overview」（１９９４）に記載されている。この文献は参考資料としてここに援用する。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およびQuickDraw 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プロシジャ２０２への呼び出しの注意深い順序づけによって、システム階層をシミュレートすることができる。この特徴は、複雑なアプリケーション特有の階層状データ構造を使用するアプリケーション・プログラム、たとえば、アニメーション・システムにとってきわめて有利であり、あるいは、既にそれ自体のデータ構造を有する現存のアプリケーション・プログラムをポーティングするときにきわめて有利である。PHIGSの従来システムおよび他の保存モード・システムは、モデル全体がただ１つの階層内に存在し、ＧＬが各オブジェクトを独立して処理することを要求する。一方、Escherでは混合が可能である。アプリケーション・プログラムは、状態をセットし、多数の独立した幾何学的オブジェクトを描画し、Escherシステムによってそのデータ構造内に構築され、記憶されたモデルをレンダリングさせ、次いでより多くの独立した幾何学的オブジェクトを描画させることなどができる。
第８図は、補遺Ａのアプリケーション・プログラム例によって構築される単純なモデル階層のグラフである。これは２つのレベル、すなわち、「group」と呼ばれるEtDisplayGroupObjectに内包される第１（ルート）レベルと、「subGroup」と呼ばれるEtDisplayGroupObjectに内包される第２レベルとを包含する。各EtDisplayGroupObjectは階層内のノードと考え得る。各ノードはそれに関連付けられたスタイル・オブジェクト、ジェオメトリ・オブジェクト、変換オブジェクトその他のグループ・オブジェクト（第８図にあるようなもの）ならびにシェード・オブジェクト、属性セット・オブジェクトを有し得る。
Escherは２種類のEtDisplayGroupObjects、すなわち、サブクラスEtorderedGroup、EtListGroupの２つをサポートする。EtListGroupクラスにおいて事例に添付されたオブジェクトはそれらがグループに加えられる順序を除いてなんら順序を持たない。トラバーサル中、Escherがリスト・グループ・オブジェクトに遭遇すると、リスト内の各オブジェクトはシーケンス通りに進められる（「実行される」）。このとき、それは初めにグループに追加される。第８図を参照して、ひとたびグループgroupがオープンされると、トラバーサル中に、EscherはbackfacingStyleを実行し、次いで、polygon、次いでline、次いでtransform、次いでsubGroupをこの順序で実行する。この順序がgroupに加えられた順序だからである。こうして、backfacingStyleによって生じたレンダリング状態への変更がsubGroup内のオブジェクトに対してのみ適用されることになる。EscherＡＰＩは、リストの初めあるいはリストの終わりまたは既にリス途上にあるオブジェクトの間でアプリケーション・プログラムにオブジェクトを加えさせる呼び出しを包含する。
サブクラスEtOrderedGroupのグループ・オブジェクトは、実行される前にタイプに従ったグループに添付したオブジェクトをトラバーサが分類することを除いて、リスト・グループ・オブジェクトに類似している。特に、オブジェクトは次の順序で実行される。すなわち、変換オブジェクト、スタイル・オブジェクト、属性セット・オブジェクト、シェーダ、ジェオメトリ、付加的グループの順である。
両方の種類のグループ・オブジェクトにとって、サブグループがオープンされたとき、レンダラーの次のカレント状態が受け継がれる。このサブグループ内のオブジェクトは引き続いて実行されるオブジェクトについての状態の任意の特性を変えることができるが、ペアレント・グループに戻った際に、状態はトラバーサがそのサブグループにエンターする前の状態に復帰する。
グループ・オブジェクトは、また、それらに関連付けられた「状態」も持つが、これはトラバーサの「状態」と混乱してはならない。或るグループの状態は、そのグループがどのように振る舞うかという様相を定義する単なるフラグの集まりである。これらのフラグの大部分は本発明を理解する上で重要ではないが、混用なフラグの内の１つ、すなわち「in-line」を理解するのに役に立つかも知れない。
モデリング・アプリケーションにおいては、１セットの材料あるいはスタイルを、モデルで何回か参照される可能性のあるバンドルにグループ別けすると時に役に立つ可能性がある。しかしながら、このようなバンドルが上述したようなトラバーサ状態の通常のプッシング、ポッピングを用いて創作された場合、これらのオブジェクトは、トラバーサによって実行された後にグループが状態をポップするときにモデルについて所望の効果を持つことはない。したがって、アプリケーション・プログラムはグループ・オブジェクトの「in-line」フラグをセットして、グループへのエントリ、グループからのイグジットがトラバーサの状態をプッシュあるいはポップすることがないように指定することができる。EscherＡＰＩはこのフラグのカレント値をセット、クリア、獲得するプロシジャ呼び出しを提供する。
Ａ．データ構造
ビューを構築するためのプロシジャと同様に、アプリケーション・プログラムが呼び出してモデルを構築することができるEscherプロシジャを説明する前に或る種のデータ構造を説明すると役立つであろう。
補遺Ａにあるアプリケーション・プログラム例では、グループgroup、subgroupは順序表示グループ・オブジェクトである。これらはタイプEtDisplayGroupを持ち、これは、第６図のクラス階層において、EtGroupObject、EtShapeObject、EtSharedObject、そして最終的にEtObjectのクラス先祖を有する。したがって、これらのオブジェクトは第９図に示すようにデータ構造でメモリ内に表現される。特に、順序表示グループ・クラス・メソッド・テーブルはメモリ・ブロック９０２内に含まれ、group、subgroupについての事例データはそれぞれブロック９０４、９０６内に含まれる。順序表示グループ・クラス９０２は、第５図の領域５０４と同様に、オブジェクト・メソッドに対するポインタを含む領域９０８で始まる。領域９０８に続く領域９１０は共有オブジェクト(本実施例にはない)に特有のすべてのメソッドに対するポインタを含む。これに続いて領域９１２があり、これはすべてのシェイプ・オブジェクト・メソッドに対するポインタを含み、これに続く領域９１４はグループ・オブジェクトに特有のメソッドに対するポインタを含む。この最後に述べたデータ構造EtGroupClassは以下のｔｙｐｅｄｅｆを持つ。

明らかなように、これは、とりわけ、グループの終わりにオブジェクトを加えるメソッド（add）および既にグループに割り当てられたオブジェクトのリスト内の或る特別のロケーションにオブジェクトを加えるメソッド（addBeforeとaddAfter）とを含めて、いくつかのメソッドに対するポインタについてのエントリを含む。
領域９１４の後、順序表示グループ・クラス・メソッド・テーブル９０２は、領域９１６に置ける表示グループに特有のメソッドに対するポインタを含む。このデータ構造EtDisplayGroupClassは次のように定義される。

EtDisplayGroupClassにおけるメソッドは本発明の理解には関係ないが、クラスが任意のドローイング・メソッドに対するポインタを含んでいないことに注目されたい。先に説明したように、これらのメソッドは、グループ・オブジェクトよりもむしろビュー・オブジェクトにおいて識別される。その結果、これらのメソッドはレンダラーによってオーバーライドされ得る。或るオブジェクトについてクラス内で識別される任意のドローイング・メソッドは構築されつつあるモデルの一部となり、モデルそれ自体と絡み合わせられることになり、アプリケーション・プログラムが異なったレンダラーを用いてモデルをレンダリングしようとするときに変更するのが難しくなる。このような構成は、また、先に説明したように２つ以上のレンダラーを同時に活動状態にするのを難しくする。
再びメソッド・テーブル９０２を参照して、クラス階層におけるリーフ・クラスに関するEscherシステムのデザイン（第６図）で典型的なように、テーブルは順序表示グループに特有のメソッドを含まない。
subGroupについての事例データのデータ構造はgroupについてのそれに同じであるから、groupについてのデータ構造のみを以下に説明する。第５図の事例データ・ブロック５１２のデータ構造と同様に、ブロック９０４は領域９２０内のオブジェクト・データ、特に、順序表示グループ・クラス・ブロック９０２に対するポインタで始まる。これに続く領域９２２は共有オブジェクト・データ、特に参照カウントを含む。これに続く領域９２４はシェイプ・オブジェクト・データ(これも非常に短い)を含む。このシェイプ・オブジェクト・データ領域９２４に続く領域９２６はグループ・オブジェクトについてのオブジェクト・データ（本実施例にはない）を含む。
領域９２６に続いて表示グループ・オブジェクトのための事例データを含む領域９２８がある。このデータは上記の「状態」フラグのみを含むものである。領域９２８に続いて領域９３０があり、この領域は順序表示グループ・オブジェクトの事例に特有のデータを含む。このデータは以下に定義するフォーマットを有し、ここで、EtDLListは二重にリンクしたリストのためのtypedefである。

明らかなように、領域９３０は６つの二重リンク・リストを含み、表示グループ・オブジェクトに加えることのできるオブジェクトのタイプの各々に対して１つの二重リンク・リストがある。完璧を求めるならば、ここで、groupが順序表示グループでなくてリスト表示グループである場合、差異は領域９３０の構造だけである。特に、EtListDisplayGroupPrivateとして定義される構造を持つことになる領域９３０は、表示グループに加えられるすべてのオブジェクトに対するただ１つの二重リンク・リストに対するポインタのみを含むことになる。
EtDisplayGroupObject構造に加えて、補遺Ａのアプリケーション・プログラム例は、EtStyleObjectデータ構造、EtGeometryObjectデータ構造およびEtTransformObjectデータ構造も使用する。これらの構造は、すべて、EtGroupObjectと同様にEtShapeObjectクラスからサブクラスに分類されるオブジェクトのクラスを参照する（第６図参照）。ここに説明した他のオブジェクトと同様に、各データ構造は第９図の９０２と同様のメソッド・テーブルを参照し、第９図の９０４あるいは９０６と同様にプライベート事例データを含む。これら３つのクラスは、各々、EtGroupObject（第６図参照）と同様に、同じペアレント・クラス（EtShapeObject）からサブクラスに分類され、したがって、クラス・データ、事例データ両方の最初に３つの層は第９図に示すものと同じ構造を持つことになる。EtStyleObjectクラスにおいてプログラム例で実際に用いられるリーフ・クラス（BackfacingStyle）はEtStyleObjectクラスのサブクラスとなり、そのオブジェクトについてのクラス・メソッドの４番目、最後の層がスタイル・オブジェクトに特有のメソッドを示すポインタを含むことになる。事例データの４番目の層は、もしあるとするならば、すべてのスタイル・オブジェクトにとって適切なプライベート・データを含み、５番目と最後の層は後向き（backfacing）スタイル・オブジェクトに対して適切なデータを含む。
同様に、EtTransformObjectクラスにおいてプログラム例で実際に使用されるリーフ・クラス（translate）はEtTransformObjectクラスのサブクラスであり（第６図参照）、したがって、変換オブジェクトについてのクラス・メソッドの４番目と最後の層は変換オブジェクトに特有のメソッドを示すポインタを含む。変換オブジェクトについての事例データの４番目の層は変換オブジェクト特有のデータを含み、５番目と最後の層は並進（translate）変換オブジェクトに特有のデータを含む。
プログラム例はジェオメトリ・オブジェクトである３つのオブジェクト（polygon、line、torus）を創作し、そのすべてはEtGeometryObjectクラスのサブクラスであるリーフ・クラス内にある（第６図参照）。こうして、これらのオブジェクトの各々についてのクラス・メソッド・テーブルの４番目、最後の層はジェオメトリ・オブジェクトに特有のメソッドを示すポインタを含む。これらのオブジェクトの各々についての事例データの４番目の層は任意のジェオメトリ・オブジェクトに特有のデータを含み、これらのオブジェクトの各々についての事例データの５番目と最後の層はポリゴン・オブジェクト、ライン・オブジェクト、トーラス・オブジェクトそれぞれに特有のデータを含む。
Escherでは、属性セット（拡散カラーのような属性を含む）が表面アピアランス特性を定義するのに対し、スタイルが幾何学的シェイプをどのように描画するかをレンダラーに知らせる。たとえば、或るポリゴンをべた塗りつぶしシェイプとしてあるいはそのエッジのみでレンダリングすることができる。別の例では、表面を滑らかにレンダリングするか、あるいは、切子面のあるアピアランスを持つようにレンダリングすることができる。後向き（backfacing）スタイル・オブジェクト（EtStyleObjectのサブクラス）によって示されるまた別の例は、カメラから離れた方に向いたシェイプを表示すべきかどうかを決定する。付録Ａのプログラム例で使用されるEcBackfacingStyle＿RemoveBackfacing特性は、カメラから離れた方を向いているシェイプは描画すべきでないと指定する。backfacingスタイル・オブジェクトについてのプライベート・データはロングワードを含み、このロングワードは、前向き、後向き両方の表面を描画すべきかどうか、あるいは、後向き表面を除くべきかどうか、あるいは、２面属性を持たない後向き表面に常にカメラに向くようにフリップ運動を与えられた常態を持たせるかどうかを示す定数を含む。アプリケーション・プログラムは、適切なスタイル・オブジェクトを創作し、それをモデルのグループ・オブジェクト内の所望の位置で加えることによってモデルのスタイル特性を指定する。
グループ・オブジェクトの場合、事例データの最後の層におけるプライベート・データは或る特定のジェオメトリを記述するのに必要な情報を含んでいる。たとえば、ポリゴン・オブジェクトの最後の層に或るプライベート・データは頂点の数を指定する。ここでは、頂点と或る種の属性は関係ないものとする。ライン・オブジェクトの最後の層にあるプライベート・データはラインの２つの端点の位置ならびに或る種の属性データを含み、トーラス・オブジェクトの最後の層にあるプライベート・データは起点、向き、大半径、小半径ならびに或る種の属性データを含む。
変換オブジェクトは、幾何学的シェイプを含む座標系を変えるのを可能とし、それによって、オブジェクトを空間内で位置決め、方向付けすることが可能となる。変換は、オブジェクトの幾何学的表現（シェイプを記述する頂点その他のデータ）を変えず、むしろ、レンダリング時間でマトリックスが空間内でオブジェクトを一時的に「移動させる」ように適用されるので、有用である。これにより、モデルにおける種々の変換で何回もただ１つのオブジェクトを参照することが可能となり、画面内の多くの異なったロケーションにオブジェクトを置くことができるようになる。アプリケーション・プログラムは、EtTransformObjectクラスのサブクラス（第６図）から適切な変換オブジェクトを創作し、それをモデル内の適切な位置で適切なグループに加えることによって変換を指定する。アプリケーション・プログラムによって指定された変換は、Escherが変換をグループ内の引き続くオブジェクトに適用される仮マトリックスに変換するレンダリング時点まで指定されたフォームに留まる。マトリックスは予めオブジェクトのベクトルに掛け合わされる。Escher変換は予めカレント変換マトリックスに掛けてあり、したがって、アプリケーション・プログラムは逆の順序で結びつけられるべき変換を指定する。これは階層内でのマトリックスの適用と一致している。すなわち、階層のトップで指定されたマトリックスは最後に適用され、オブジェクトの直前に指定されたマトリックスは最初に適用される。
Escherは数多くの異なった種類の変換をサポートしている。各変換はEtTransformObjectのそれぞれのサブクラスからのオブジェクトを使用することによって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」プロシジャ（アプリケーション・プログラムによって呼び出されるルーチン）は次の通りである。

明らかなように、このルーチンは、まず、そのペアレント・クラスEiDisplayGroup＿New()の「New」プロシジャを、順序表示グループ・クラス・メソッド・テーブルEgOrderedDisplayGroupClassを示すポインタおよび創作されつつあるオブジェクトについての事例データの最下層で必とされるプライベート・データ構造EtOrderedDisplayGroupPrivateのサイズと共に呼び出す。このプロシジャが戻るとき、事例データのブロックが割り当てられており、より高いレベルが初期化されている。或る種のエラー・チェッキングの後、EiOrderedDisplayGroup＿New()プロシジャは、割り当てられたブロックの順序表示グループ・プライベート・データ構造を示すポインタ（ordered）を獲得し、二重リンク・リストのすべてをNULLに初期化する。次いで、このプロシジャはアプリケーション・プログラムに戻り、新しく創作された事例データ・ブロックを示すポインタを返す。
表示グループ・クラスの「New」プロシジャは次の通りである。

明らかなように、このプロシジャは、最初に、オブジェクト・クラスを示すポインタを通すそれ自体のペアレント・クラスの「New」プロシジャEiGroup＿Newと、ペアレント・クラスの必要とするプライベート・データのサイズ＋グループ・クラス内のオブジェクトのプライベート・データ（EtDisplayGroupPrivate）にとって必要なメモリ・スペース量とによって与えられるデータサイズとを呼び出す。エラー・チェッキングの後、EiDisplayGroup＿New()はグループ・オブジェクトのプライベート・データを示すポインタgroupPrivateを獲得し、それを初期化する。次に、このプロシジャはその発呼者EiOrderedDisplayGroup＿New()に戻る。
EtGroupObjectクラスにおける「New」プロシジャは次の通りである。

上記のプロシジャは、表示グループ・クラスおよび順序表示グループ・クラスのための「New」プロシジャと同じアウトラインをたどるが、クラスEtGroupObjectに特有のプライベート・データがない点が異なる。こうして、EiGroup＿New()プロシジャは、なんらプライベート・データを初期化せず、それがペアレント・クラスの「New」プロシジャEiShape＿New()に移るデータサイズは、表示グループ・クラスの「New」プロシジャによってEiGroup＿New()に移されるデータサイズと同じである。
プロシジャはEtObjectクラスの「New」プロシジャを介して上へ続く。明らかなように、Escherはクラス階層のすべてのクラスにおいてオブジェクトを創作するのと同じ再帰的機構を使用する。さらに、明らかなように、Escherは多数のEscherＡＰＩ呼び出しの機能を実施するのと同じ再帰技術を使用する。
２．ErGroup AddObject()
ここで再び補遺Ａのアプリケーション・プログラム例を参照して、新しい順序表示グループ・オブジェクトgroupが創作された後、プログラムは後向きのスタイル・オブジェクトを創作し、それをグループに加える。プログラム例のこの部分は本発明の理解にとって重要ではないが、このようなオブジェクトをグループに加えることができるということを説明するためにだけ含まれる。
次に、プログラム例は、EscherプロシジャErPolygon＿New()を用いてポリゴン・オブジェクトpolygonを創作する。このプロシジャは、順序表示グループ・オブジェクトの創作に関して上述した「New」プロシジャと同様に動作するので、ここでは再度説明する必要はない。次に、プログラム例は、EscherＡＰＩ呼び出しErGroup＿AddObject()を用いてgroupにpolygonを加える。後者のプロシジャは次の通りである。

明らかなように、このプロシジャは、グループに加えるべきオブジェクトおよびそれが加えられるべきグループをアーギュメントとして受け取る。或る種のブックキーピング操作の後、プロシジャはEscherプロシジャEiGroup＿AcceptObject()を呼び出して、指定されたオブジェクトが指定された種類のグループ・オブジェクトに加えることができるタイプであるかどうか決定する。たとえば、指定オブジェクトがライト・オブジェクトである場合、それは順序表示グループに加えることができない。本ケースでは、ポリゴンをEtOrderedDisplayGroupオブジェクトに加えることができるので、結果は有効である。
次に、このプロシジャは、EtGroupObjectのペアレント・クラスの「サブクラス・メソッド獲得」プロシジャEtShapeObjectを呼び出すことによって、指定された順序表示グループ・オブジェクトについてのEtGroupObjectクラス・メソッド・テーブルを示すポインタgroupClassを得る。このプロシジャは、次に、このメソッド・テーブルを指し示す「オブジェクト追加」プロシジャを呼び出し、アプリケーション・プログラムに戻る。
指定された種類のグループ・オブジェクトのための「オブジェクト追加」プロシジャを示すメソッド・テーブルのポインタは、EtOrderedGroupクラスそのものが登録されたときに初期化中にそこに書き込まれる。指定された「オブジェクト追加」プロシジャは次の通りである。

このプロシジャを参照してわかるように、このプロシジャは、まず、順序表示グループ・クラスの「獲得」プロシジャを使用して指定された順序表示グループ・オブジェクトのプライベート・データを示すポインタgroupDataを得る。次に、このプロシジャは、追加すべき指定オブジェクトのタイプ（ジェオメトリ・オブジェクトである）を得、或る種のエラー・チェッキングの後に、EiOrderedDisplayGroup＿GetObjectList()を呼び出してジェオメトリ・オブジェクトのための順序表示グループ・オブジェクトの特定の二重リンク・リストを示すポインタtheListを得る。このプロシジャは、EiGroupPosition＿New()を呼び出して新しいリスト「位置」オブジェクトを創作し、EiDLList＿InsertNodeLast()を呼び出して二重リンク・リストの終わりにこの新しい「位置」オブジェクトを挿入する。次いで、このプロシジャはその発呼者EiGroup＿AddObject()に戻る。
完璧を期するならば、オブジェクトをリスト表示グループ・オブジェクトを加えるためのプロシジャは順序表示グループ・オブジェクトにオブジェクトを加えるプロシジャと非常に似ているが、ただし、リスト表示グループ・オブジェクトには１つの二重リンク・リストしかないという点で異なることを了解されたい。したがって、オブジェクトを追加しようとしている６つのリストのうちの１つを決定する必要はない。また、オブジェクト追加プロシジャに加えて、EscherＡＰＩも、グループのリスト内の指定位置の後にオブジェクトを加え、グループのリスト内の指定位置の前にオブジェクトを加え、グループのリスト内の指定位置からオブジェクトを取り除き、グループのリストを通して前後に繰り返すプロシジャならびに他のプロシジャを含んでいる。
３．ErObject＿Dispose()
グループにオブジェクトを加えた後、補遺Ａのプログラム例は、ポリゴン・オブジェクトを「廃棄」する。それがもはやアプリケーション・プログラムで必要とされないからである（創作されつつあるモデル内のその存在とは別）。アプリケーション・プログラムに関係する限り、ポリゴン・オブジェクトは削除されてしまっている。しかしながら、実際には、Escher ErObject＿Dispose()プロシジャは、この時点では、ポリゴン・オブジェクトを削除せず、メモリ・スペースの割り当てを取り消す。代わりに、polygonが共有オブジェクトであるから、Escherはそのポリゴン・オブジェクトのための共有オブジェクト・プライベート・データにおける参照カウントを減分するだけである。参照カウントは、polygonが創作されたときに１にセットされ、groupに加えられたときに１だけ増分される。こうして、アプリケーション・プログラムの呼び出したErObject＿Dispose()は、単に、参照カウントを２から１に減分するだけである。もし参照カウントの減分が０までになると、Escherが実際にオブジェクトを削除し、そのメモリ・スペースの割り当てを取り消す。
４．新しいライン・オブジェクト
次に、補遺Ａのプログラム例は新しいライン・オブジェクトlineを創作し、それを順序表示グループ・オブジェクトgroupに加え、次いでライン・オブジェクトlineを「廃棄」する。これを行うべきEscherプロシジャ呼び出しはポリゴン・オブジェクトpolygonに関して先に説明したものと類似しており、ここで繰り返す必要はない。
５．変換オブジェクトの追加
スタイル・オブジェクトおよび２つのジェオメトリ・オブジェクトを順序表示グループgroupに置いた後、補遺Ａのプログラム例は、並進変換オブジェクトを創作し、それをグループに加える。変換オブジェクトtransformは、先に述べたようにErOrderedDisplayGroup＿New()に類似する再帰要領で作動するEscherプロシジャErTranslateTransform＿New()を呼び出すことによって創作される。ErGroup＿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＿StartRendering()とErView＿EndRendering()との呼び出しの合間に行われる。これらのプロシジャは、単に、レンダリングに先だって関連したデータ構造を初期化し(トラバーサル・スタック上へ初期状態をプッシュすることを含む)、レンダリングの後に種々のブックキーピング情報を一掃する。これらのプロシジャは、また、レンダラー自体のスタート、エンド・プロシジャへの呼び出しも含み、その結果、レンダラーは同じことを行うことができる。レンダラーのスタート、エンド・プロシジャは、レンダラーの登録時にEscherに対して指定されており、適当なメソッド・テーブルにおいて識別される。特に、レンダラーのエンド・レンダリング・プロシジャは、EcMethodType＿EndRenderer定数で呼び出されることに応答してレンダラーのメタハンドラによって返される。
Escherは、それが２回以上モデルをトラバースし、そのたび毎に適切なレンダラー・プロシジャを呼び出す多数回レンダリングをサポートする。Escherは、状況フラグEcViewStatus＿ReTraverseをErView＿EndRendering()プロシジャから戻すことによって再トラバースが必要であることを指示する。アプリケーション・プログラムがErView＿EndRendering()を呼び出したとき、このプロシジャはレンダラーのエンド・レンダリング・プロシジャを呼び出す。ワイヤフレーム・レンダラーの場合、このプロシジャはErWF＿End()と呼ぶ。レンダラーは、逆トラバース・フラグをEscherのErView＿EndRendering()プロシジャへ返し、このプロシジャが同じものをEcViewStatus＿ReTraverseとしてアプリケーション・プログラムへ返す。したがって、好ましい技術は、アプリケーション・プログラムが、ErView＿EndRendering()がEcViewStatus＿ReTraverseを返す限り反復する実行ループ内にモデル・ドローイング呼び出しを置くことである。これは補遺Ａのプログラム例で用いられるフォーマットである。
ここで、ErView＿StartRendering()とErView＿EndRendering()への呼び出しがアーギュメントとしてビュー・オブジェクトviewを採用することに注目されたい。アプリケーション・プログラムは、或る特定のビュー・オブジェクトについてのErView＿EndRendering()への呼び出しが同じビュー・オブジェクトについてのErView＿StartRendering()への引き続く呼び出しであり、そのビューへのドローイング呼び出しのすべてが中に挟まれている限り、任意のシーケンスでこれらのプロシジャを呼び出し、種々のビュー・オブジェクトを指定する。また、中に挟まれた或る特定のビュー・オブジェクトについてのErView＿EndRendering()を呼び出すことなく同じのビュー・オブジェクトについて二回ErView＿StartRendering()を呼び出すことはエラーとなり、或る特定のビュー・オブジェクトについてのErView＿StartRendering()を最初に呼び出すことなく同じビュー・オブジェクトについてErView＿EndRendering()を呼び出すことはエラーとなる。しかしながら、異なったビュー・オブジェクトは、それらの事例データが別々なので、所望に応じて同じレンダラーを指定できる。付録Ａのアプリケーション・プログラム例は、特に先に定義された、ワイヤフレーム・レンダラーを指定するビュー・オブジェクトを用いてモデルを完全にレンダリングし、次いでビュー・オブジェクトにおけるレンダラーの選択を変えてＺバッファ・レンダラーを指し示し、同じあるが今や変更されているビュー・オブジェクトに対して再度完全にレンダリングを行うことによってモデルを二回レンダリングする際の非常に簡単な方針を採用している
ErView＿StartRendering()とErView＿EndRendering()への呼び出しの合間に、アプリケーション・プログラムは即時モードEscherドローイング・プロシジャか保存モードEscherドローイング・プロシジャのいずれか、あるいは、これら両方への呼び出しを行うことができる。即時モード・ルーチンはパラメータとしてデータ構造（たとえば、ポリゴン・データ構造）を採用し、それに対して、保存モードルーチンはパラメータとしてオブジェクト（たとえば、EtGeometryObject）を採用する。即時モード・ルーチンはいかなるモデルのトラバーサルも動かさないが、或る種の保存モード・ルーチン（たとえば、ErDisplayGroup＿Draw()はモデルのトラバーサルを起動する。
Ａ．モデルのトラバース
したがって、補遺Ａのアプリケーション・プログラム例は、Escherのレンダラー呼び出しプロシジャ２１２（第２図）へのただ一回の呼び出し、特にErDisplayGroup＿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によって指し示されるプロシジャはEiView＿OrderedDisplayGroup()であり、これは次の通りである。

明らかなように、上記プロシジャは、順序表示グループ・オブジェクトgroupのプライベート・データにおける６つの二重リンク・リストの異なったものに参照の際に移る毎に、一般化された表示グループ・リスト・ドローイング機能EiDisplayGroupList＿Draw()を６回呼び出す。特に、プロシジャは最初に変換のリストへの参照で、次いでスタイルのリストへの参照で、次いでシェードのリストへの参照で、次いでグループ内のジェオメトリのリストへの参照で、次いでグループ内のサブグループのリストへポインタでリスト・ドローイング・プロシジャを呼び出す。そのたび毎に、プロシジャはリスト・ドローイング・プロシジャを、リストにある種類のオブジェクトを描画する特定のプロシジャへの参照を通す。たとえば、変換のリストがEiDisplayGroupList＿Draw()へ通されると、EscherプロシジャEiTransform＿Draw()への参照も通される。別の例としては、ジェオメトリのリストがEiDisplayGroupList＿Draw()へ通されると、EscherプロシジャEiGeometry＿Draw()への参照も通される。
ここで、groupが順序表示グループ・オブジェクトではなくてリスト表示グループ・オブジェクトである場合、１回のみの呼び出しがEiDisplayGroupList＿Draw()に対して行われる。この呼び出しは、groupに添付されたオブジェクトの単一リストへの参照およびリスト上で出合う各オブジェクトのタイプを決定するプロシジャへの参照をパスし、そのタイプについての適切なEscherドローイング・プロシジャを呼び出す。
この一般化されたリスト・ドローイング・プロシジャは次の通りである。

明らかなように、このプロシジャは、単に、発呼者によって指定された二重リンク・リスト上のすべてのオブジェクトを通してループを作り、各オブジェクト毎にそれを発呼者の指定するドローイング・プロシジャに通すだけである。
リスト・ドローイング・プロシジャよって呼び出されるEscherオブジェクト・プロシジャのいくつかを以下に説明する。しかしながら、説明の便宜上、順序表示グループをレンダリングするときに呼び出される順序と異なる順序で説明する。
Ｂ．表示グループ・オブジェクトのドローイング・サブグループ・オブジェクト
Escherは再帰方法でモデルをトラバースし、この理由のために、ErView＿OrderedDisplayGroup()がグループ・オブジェクトgroupで出合うグループ・オブジェクト用のリスト・ドローイング・プロシジャに移るEscherプロシジャは単にEiDisplayGroup＿Draw()にすぎない。このプロシジャは先に説明した。
Ｃ．表示グループ・オブジェクトにおけるドローイング・ジェオメトリ・オブジェクト
ジェオメトリ・オブジェクトについてのリスト・ドローイング・ルーチンにEiView＿OrderedDisplayGroup()が識別するEscherプロシジャはEiGeometry＿Draw()であり、これは次の通りである。

明らかなように、上記のプロシジャは、単に、或る種のエラー・チェッキングを実施し、ジェオメトリ・クラスによって登録されたジェオメトリ・ドロー・メソッドを呼び出すだけである。このメソッドはすべてのジェオメトリ・オブジェクトにとって一般的であり、次の通りである。

エラー・チェッキング後、このルーチンは、まず、カレント・ビューのレンダラーがレンダリングされるべきタイプ（このケースでは、ポリゴン）のジェオメトリ・オブジェクトについて登録されたメソッドを示すポインタfuncを得る。もしfuncがNULLである場合、ジェオメトリ・オブジェクトの分解が後述する要領で生じる。しかしながら、本ケースでは、ワイヤフレーム・レンダラーはポリゴン・オブジェクトをレンダリングするプロシジャとしてErWF＿Geometry＿Polygon()を登録している。（ErWF＿Register()に関する上記の説明参照）。このプロシジャは補遺Ｂに記載してある。
Ｄ．分解を要求するドローイング・ジェオメトリ・オブジェクト
先のセクションで、ビューのレンダラーがジェオメトリ・オブジェクトのタイプ（すなわち、ポリゴン）に特有のルーチンを有するシチュエーションにおいて表示グループのジェオメトリ・オブジェクトをEscherにどのようにしてレンダリングさせるかは説明した。Escherと共に用いられるべきレンダラーは、少なくとも、点、線、三角をレンダリングするルーチンをサポートしていなければならず、また、より高いレベルのジェオメトリをレンダリングするルーチンもサポートすることができる。本発明に関して、レンダラーは、Escherがモデルの構築時にサポートするすべてのジェオメトリ・タイプをサポートする必要はない。むしろ、Escherは、或る特定のジェオメトリ・タイプについてのレンダリング・メソッドの不存在を自動的に検知し、ジェオメトリをより簡単な部分に分解することになる。次に、Escherはこのより簡単な形態においてそれらをレンダラーに再提供する。
本実施例のワイヤフレーム・レンダラーはポリゴン・オブジェクトをサポートするが、説明の目的のために、ここではそれが行えないと仮定する。ここでの説明は、Escherがポリゴンを分解するジェオメトリで明らかなように三角形をレンダリングするためのワイヤフレーム・レンダラーのメソッドがポリゴンをレンダリングする同じワイヤフレーム・レンダラー・プロシジャであるために、仮定のものである。すなわち、レンダラー・プロシジャErWF＿Geometry＿Polygon()はアーギュメントとして三角形あるいはポリゴンのいずれかを採用し、それがどれであるかを決定し、同じコードを用いてそれをレンダリングする。それにもかかわらず、この仮定はEscherの分解技術を説明するのに役立つであろう。
１．Escher初期化時に呼び出されるプロシジャ
レンダラーを登録するための初期化時のプロシジャは先に説明した。クラスおよびサブクラスは初期化中と同様にそれら自体を登録する。たとえば、ポリゴン・クラスは、最初、次の機能を呼び出すことによって登録される。

このルーチンはpolygonリーフ・クラスにおけるオブジェクトについてのクラス・メソッド・テーブルを創作する。先に述べた他の創作ルーチンと同様に、メモリのブロックは、層状化技術を用いて割り当てられ、初期化される。各クラスのクラス登録プロシジャは、まず、それ自体のメソッド・テーブルについて要求されるサイズをそのペアレント・クラスのクラス登録プロシジャに通す。polygonクラスはリーフ・クラスであり、その結果、そのメソッド・テーブルのサイズはゼロである。polygonクラス上方で、各プロシジャはそれ自体のメソッド・テーブルのサイズを加算し、そのペアレント・クラスのクラス登録プロシジャを再帰的に呼び出す。最終的なペアレント・クラスのクラス登録プロシジャは、メソッド・テーブルのブロック全体についてメモリを割り当て、それ自体の部分をそのデフォルト・メソッドを示すポインタで初期化し、呼び出しサブクラスのクラス登録プロシジャに戻る。
オリジナルの発呼者に戻る途中で、各クラスのクラス登録プロシジャはそれ自体のメソッド・テーブルをそれ自体のデフォルト・メソッドで初期化する。加えて、各クラスのクラス登録プロシジャはメソッドを指定してそのペアレント・クラスのクラス登録プロシジャをオーバーライドするが、ペアレント・クラスのオプションでのみである。これを達成するには、ペアレント・クラスのクラス登録プロシジャを呼び出すときに、メタハンドラを指定し、いくつかのクラスについて、呼び出しに対するアーギュメントとして仮想メタハンドラを指定する。これらのメタハンドラは、もし望むのであれば、ペアレント・クラスのクラス登録プロシジャによって呼び出され、メソッド・タイプを指定し、もし呼び出された場合には、メタハンドラは所望のプロシジャを示すポインタを返して指定タイプのペアレント・クラスのデフォルト・メソッドをオーバーライドする。クラスが或る特定のタイプのペアレント・クラスのデフォルト・メソッドをオーバーライドするプロシジャを持っていない場合には、メタハンドラはNULLを返す。
ポリゴン・クラス登録プロシジャの場合、メタハンドラだけがペアレント・クラスのクラス登録プロシジャに識別される。メタハンドラは次の通りである。

本明細書に対する特別の関連について、ジェオメトリ分解プロシジャについて依頼されたときに、メタハンドラがそれを、すなわち、EiPolygon＿Decomposeを返すことに注目されたい。このプロシジャは後述する。
ポリゴン・クラスのペアレント・クラスについてのクラス登録プロシジャ、EtGeometryObjectは次の通りである。

明らかなように、このプロシジャは、それ自体のペアレント・クラスのクラス登録プロシジャ、EiShapeClass＿Register()を呼び出し、メタハンドラおよび仮想メタハンドラを指定する。再帰が上記のプロシジャに戻った後、プロシジャは、それ自体のメソッド・テーブルをデフォルト・プロシジャを差し示すポインタで初期化することによって継続する。このプロシジャは、Escherプロシジャ、EiObjectClassData＿GetMethod()を用いてこれらのポインタを獲得する。このEscherプロシジャは、特に、サブクラスのメタハンドラを頼んで各所望のメソッドに対するポインタを提供する。プロシジャが識別すべきポリゴン・クラスのメタハンドラを求めるメソッドの１つは、分解メソッドであり、先に指摘したように、それが識別するメソッドはEiPolygon＿Decompose()である。
ここで、Escherでは、分解メソッドが各レンダラーではなくて各ジェオメトリ・タイプについてクラス・メソッド・テーブルにおいて識別されることは注目すべきである。こうすれば、分解メソッドが、レンダリングされるビューの一部ではなくてレンダリングされるべきモデルの一部あるいはレンダラーの一部として含まれる。ここで、別の実施例では、レンダラーが直接描画できないジェオメトリについて分解メソッドをオーバーライドすることができることは了解されたい。また別の実施例では、分解メソッドは、ジェオメトリ・サブクラスではなくてレンダラー・サブクラスに添付され得る。
ジェオメトリ・クラスのメタハンドラについての説明は本発明の理解には重要ではないが、ジェオメトリ・クラスの仮想メタハンドラを以下に説明する。

特に関連があるものとしては、EtShapeObjectクラスのクラス登録プロシジャによって呼び出されるときに、それがオブジェクト・ドローイング・プロシジャとしてEiGeometry＿Draw()を示すポインタを返すことになる。
２．レンダリング中に呼び出されるプロシジャ
上述のEiGeometry＿DrawMethod()に戻って、先に述べたように、レンダラーが与えられたタイプのジェオメトリを描画するためのプロシジャを登録していない場合（説明の目的のために、ここではポリゴンに関連するケースを仮定する）、このルーチンはジェオメトリをEiGeometry＿Decompose()に通すことになる。このプロシジャは次の通りである。

明らかなように、或る種のエラー・チェッキングの後、このプロシジャは、分解メソッドについてメソッド・テーブル内で識別されたメソッドにジェオメトリ・オブジェクトを通すだけである。ポリゴンの場合、このメソッドは上述したようにEiPolygon＿Decomposeとして先に登録されている。これは次の通りである。

上記プロシジャはEscherプロシジャEiPolygon＿Triangulate()を用いてポリゴンを三角形のバンドルに分解する。一実施例において、この三角形分割プロシジャは、新しい三角形のすべてを保持する新しいEtGroupObjectoを創作できる。しかしながら、エラー・チェッキングおよび再帰のレベルを短絡させるために、グループ内のすべてのオブジェクトがジェオメトリ・オブジェクトとなることが既に知られているので、この三角形分割プロシジャは新しい三角形のすべてをクラスEtGeometryBundleのオブジェクト内に置く。ジェオメトリ・バンドルはジェオメトリのリストのみを保持し得る内部ジェオメトリのみオブジェクトである。
上記プロシジャは、即時モードあるいは保存モードのいずれかで作動する。即時モードでは、プロシジャは分解の結果を保存せず、むしろ描画を簡単にする三角形分割プロシジャを知らせるフラグで三角形分割プロシジャを呼び出す。保存モードでは、上記のプロシジャは、分解を保存すべきであることを示すフラグを持ち、また、それを保存すべきフィールドへの参照を持つ三角形分割プロシジャを呼び出す。上記のプロシジャでは、三角形分割プロシジャがその結果のジェオメトリ・バンドル・オブジェクトについての参照を書き込むフィールドはPolyPriv->decompositionであり、上記のプロシジャは次にEiGeometry＿Draw()に移る。
EiGeometry＿Draw()は先に説明したが、先に説明した要領で、エラー・チェッキング後、ジェオメトリのタイプを描画するためにそれに通されるジェオメトリ・オブジェクトのメソッド・テーブルで識別されたメソッドを呼び出すだけである。通常は、これらはレンダラーによって登録されたメソッドとなるが、ジェオメトリ・バンドル・オブジェクトは周知のものではない。レンダラーはこれらのオブジェクトを描画するルーチンを登録しない。代わりに、メソッド・テーブルがジェオメトリ・バンドルについてのEscherのデフォルト・ドローイング・メソッドを示すポインタを含むことになる。これは次の通りである。

明らかなように、このプロシジャは、単に、それに提供されるジェオメトリ・バンドル・オブジェクトにおけるジェオメトリ・オブジェクトのリストを通して反復し、それぞれをEiGeometry＿Draw()に通すだけである。すべての三角形があるので、EiGeometry＿Draw()が分解時の各三角形についてのレンダラーの三角形ドローイング・プロシジャを呼び出すことになる。
Ｅ．表示グループ・オブジェクトにおけるドローイング変換オブジェクト
EiView＿OrderedDisplayGroup()が変換オブジェクトについてのリスト・ドローイング・ルーチンを識別するEscherプロシジャはEiTransform＿Draw()であり、これは次の通りである。

明らかなように、上記のプロシジャは、単に、EtTransformObjectについての変換ドロー・メソッドを呼び出すだけである。このメソッドはすべての変換オブジェクトについて一般的であり、次の通りである。

このルーチンは、エラー・チェッキング後、まず、実行されるべきタイプ（この場合、並進）の変換オブジェクトを実行するためにカレント・ビューのレンダラーのメソッド・テーブルが持つメソッドに対するポインタfuncを獲得する。E並進変換を実行するためのEscherのデフォルト・プロシジャは次の通りである。

Ｖ．品質コレクションの管理、使用
品質コレクション・オブジェクトは、品質グループ・オブジェクトのリンク・リストを含むデータ構造である。品質コレクション・オブジェクトは、第６図に示すようにクラスEtSharedObject（これ自体がクラスEtObjectのサブクラスである）のサブクラスであるクラスEtQualityCollectionObjectの事例である。したがって、第５図のフォーマットの次に、品質コレクション・オブジェクトは第１１図に示すようなメモリのフォーマットを有する。特に、メモリ領域１１０２はEtQualityCollectionObjectクラスのメソッドを指すポインタを含み、この領域１１０２はオブジェクト・メソッドを指すポインタ１１０４と共有オブジェクト・メソッド（これらはいずれもない）を指すポインタ１１０６を含む。EtQualityCollectionObjectクラスはリーフ・クラスであり、したがって、このクラスは特に品質コレクション・オブジェクト・メソッドについてのメソッド・テーブルを持たない。
この構造は、また、メモリ領域１１１０における品質コレクション・オブジェクトについての事例データも含む。この領域は、部分１１１２（オブジェクト・クラス１１０２を指し示している）におけるオブジェクト・クラスに特有の事例データ、部分１１１４（参照カウントを含む）における共有オブジェクト・クラスに特有の事例データ、部分１１６における品質コレクション・オブジェクト・クラスに特有の事例データを含む。品質コレクション・オブジェクト・データは品質グループ・オブジェクトのリンク・リストを開始するタイプEtQualityCollectionPrivateのデータ構造である。
品質グループ・オブジェクトは、品質制御タイプ変数のグループを含むデータ構造であり、各変数は、レンダリング品質とレンダリング速度の間のそれぞれのトレードオフにおける２つ以上のオプションをそれ自体が選ぶ値を含んでいる。品質グループ・オブジェクトは、第６図に示すようにクラスEtSharedObjectのサブクラスであるクラスEtQualityGroupObjectの事例である。品質グループ・オブジェクトは第１２図に示すフォーマットを有する。特に、メモリの領域１２０２はEtQualityGroundObjectクラスのメソッドを指すポインタを含む。この領域１２０２は、オブジェクト・メソッドを指すポインタ１２０４と、共有オブジェクト・メソッド（いずれもまったくない）を指すポインタ１２０６とを含む。この構造は、また、メモリの領域１２１０における品質グループ・オブジェクトについての事例データも含む。この領域は、部分１２１２（オブジェクト・クラス１２０２を示す）内のオブジェクト・クラスに特有の事例データ、部分１２１４（参照カウントを含む）内の共有オブジェクト・クラスに特有の事例データ、部分１２１６における品質グループ・オブジェクト・クラスに特有の事例データを含んでいる。品質グループ・オブジェクト・データは表Ｉに記載するフィールドを含むタイプEtQualityGroupObjectPrivateのデータ構造である。

明らかなように、品質コレクション・オブジェクトにおける他の品質グループ・オブジェクトについてのリンク・リスト・ポインタは別にして、品質グループ・オブジェクトは特定のグループと関連した品質インデックス値を記憶するフィールドを含む。一実施例において、品質インデックスはタイプ・フロートであり、０．０から１．０までの範囲にあり得るが、他の実施例では、品質インデックス値はたとえば整数であってもよい。ここで、現在説明している実施例では品質インデックス値は品質グループ・オブジェクトのフィールドに格納され、別の実施例では特定の品質グループに関連した品質インデックスは単なる計算値、たとえば、ｎ／Ｎ（ここで、ｎはコレクションのリンク・リスト内の特定の品質グループの位置であり、Ｎはコレクション内の品質グループの全数である）であってもよい。また別の実施例では、或る特定の品質グループと関連した品質インデックスは単にｎである。この場合、特定の品質グループは品質グループのコレクション・リスト内のｎ′番目の品質グループとなる。種々の実施例で、品質インデックス値をそれぞれの品質グループと関連付けるための他の多くの技術を使用し得る。
再び表Ｉを参照して、各品質グループ・オブジェクトは、また、品質タイプ・エントリのリストも含む。品質タイプ・エントリは１セットの変数であり、各変数はレンダリング品質とレンダリング速度の間のそれぞれのトレードオフにおける少なくとも２つのオプションを選ぶ値を含む。一実施例では、種々の品質制御変数およびこのパラメータに対して利用できる種々のオプションを示している。

種々の実施例が各品質グループにおける異なったセットのパラメータを含むことができ、テーブル内の各パラメータについて異なったオプションを含むことができることは了解されたい。
Ｂ．品質コレクションを確立するためのプロシジャ
補遺Ａを参照して、アプリケーション・プログラム例は、プロシジャExSetupQualityCollection(&qualityCollection)によって品質コレクションを確立する。このプロシジャは、アプリケーション・プログラムの一部であり、Escher提供プロシジャを用いて所望の要領で品質グループのコレクションを構築する。第１３図は、それぞれ品質インデックス０．２、０．４、０．６、０．８を持つ４つの品質グループを有する品質コレクションを確立するExSetupQualityCollection()のフローチャートである。
第１３図を参照して、ステップ１３０２において、このルーチンは、まず、新しい品質コレクション・オブジェクトを創作する。これは、EscherプロシジャErQualityCollectionObject＿New()に対する呼び出しで行われる。このEscherプロシジャが第１０図に関して先に説明したと同じ要領でスペースを割り当て、データ構造を初期化する。ErQualityCollectionObject＿New()は新しい品質コレクション・オブジェクトを指すポインタを返し、これを第１３図のプロシジャが変数qualityCollectionとして格納する。
ステップ１３０４において、第１３図のプロシジャは、qualityIndex=０．２でEscherルーチンErQualityGroup＿New（qualityIndex）を用いて新しい品質グループ・オブジェクトを創作する。このルーチンは、第１０図の技術を用いて新しい品質グループ・オブジェクトにメモリ・スペースを割り当て、品質グループの品質インデックス・フィールドを０．２に初期化する。
先に述べた実施例では、プロシジャErQualityGroupObject＿New()に対する呼び出しは新しいグループに対する品質インデックスを恒久的にセットする。グループ・オブジェクトが後に品質コレクションに加えられたとき、それを行うEscherプロシジャ（以下に説明する）が新しいグループを品質グループの品質インデックスによって決まる適切なシーケンスでコレクションのリンク・リスト内に置く。追加されるべきグループの品質インデックスがコレクション内に既にあるグループの品質インデックスを複写する場合、エラーが返される。
別の実施例においては、ErQualityGroupObject＿New()はアーギュメントを取らないが、むしろ、新しいグループの品質インデックス・フィールドをnull値に初期化する。Escherルーチンは、アプリケーション・プログラムが所望に応じて引き続いてグループの品質インデックスをセットするのに設けたものである。
第１３図を参照して、最初の新しい品質グループが創作された後、アプリケーション・プログラムは、ステップ１３０６において、所望に応じて第１グループにパラメータをセットする。現在説明している実施例では、上記の表IIに記載された品質タイプ・パラメータの各々はタイプErQualityTypeの独特の４文字コードを割り当てられる。将来の強化を可能とするために、アプリケーション・プログラムはパラメータ値を直接読み出したり書き込んだりすることはないが、或る種のEscherルーチンを介してのみそれを行う。さらに、アプリケーション・プログラムはEscherルーチンを使用してどの品質パレメータが特定のEscherバージョンによってサポートされるのかを決定することができる。品質タイプ・コードは、Apple Computer, Inc.に登録され、アプリケーション・プログラム・ディベロッパが利用でき、Escherの引き続くアップグレードを通じて首尾一貫している。表IIIに示すEscherルーチンは品質グループの内容を管理するためにアプリケーション・プログラムによって使用される。

或る特定の品質グループと関連付けられた品質インデックスを獲得するルーチンは、品質インデックス値がErQualityGroup＿GetTypeData()およびErQualityGroup＿SetTypeData()を用いてアクセスできる品質タイプの１つでないため、独立ルーチンとして与えられる。しかしながら、別の実施例では、或る特定の品質グループと関連付けられたインデックス値は、これらのルーチンを用いてアクセスできる品質タイプの１つとして含まれ得る。
ステップ１３０８において、第１３図のプロシジャは最初の品質制御グループ・オブジェクトをステップ１３０２で創作された品質コレクション・オブジェクトに加える。これは、表IVに記載するいくつかの品質コレクション・メインテナンス・プロシジャの１つであるEscherプロシジャErQualityCollection＿AddGroup()を用いて行われる。

明らかなように、ルーチンErQualityCollection＿AddGroup()は、新しい品質グループを品質インデックスに従ってソートした順序でコレクションに自動的に加える。もし新グループの品質インデックスが既にコレクション内の別のグループと関連付けられているならば、エラーが返される。しかしながら、別の実施例では、Escherルーチンはただ１つの品質コレクション内に同じ品質インデックスを有する２つ以上の品質グループの可能性を受け入れるように書くことができる。また、先に述べたように、アプリケーション・プログラムが所望に応じて或るグループと関連付けられた品質インデックスを変えることができる他の実施例も可能である。このような実施例では、品質インデックスが既に１つまたはそれ以上の品質コレクション・オブジェクト内の１つのグループに割れ当てられている場合には、或る種のブックキーピング機能を実施してソートした順序で各影響のある品質コレクションを維持したり、同じ品質コレクション内で複写品質インデックスを扱ったりする必要があるかもしれないことは了解されたい。
第１３図を参照して、第１の品質グループ・オブジェクトが品質コレクション・オブジェクトに加えられた後、プロシジャはステップ３１０において第２の新しい品質グループ・オブジェクトを創作する。このとき、０．４の品質インデックスを使用する。ステップ３１２において、プロシジャは所望に応じて第２の品質グループ・オブジェクト内にパラメータをセットし、ステップ１３１４において、第２の品質グループ・オブジェクトを先に述べた要領で品質コレクション・オブジェクトに加える。
ステップ１３１６、１３１８、１３２０において、品質インデックス０．６を持つ３番目のグループ・オブジェクトが創作され、所望に応じて修正され、品質グループ・オブジェクトに加えられる。同様に、ステップ１３２２、１３２４、１３２６においては、４番目の新しい品質コレクション・オブジェクトが０．８の品質インデックスを用いて創作され、この４番目の品質グループ・オブジェクトに適当にパラメータがセットされ、それが先に述べた要領で品質コレクション・オブジェクトに加えられる。これでアプリケーション・プログラム・プロシジャExSetupQualityCollection()が完了する（ステップ１３２８）。
ここで、別の実施例においては、各アプリケーション・プログラム自体の品質コレクションをセットアップする代わりに、Escherルーチンがデフォルト品質コレクションを創作するためだけのプロシジャを提供してもよいことは了解されたい。このようなデフォルトの品質コレクションは、４つまたは５つの品質グループを含むように予め定義し、各品質グループが品質タイプ値を充填され、最低の品質インデックスを持つ品質グループから最高の品質インデックスを持つ品質グループまでのプログレッション全体が品質／速度トレードオフ連続体全体で単調に向上する全品質と単調に低下する全速度をたどるようにしてもよい。
また、或る種のイメージをレンダリングするために、第１セットの品質タイプ値を有する第１品質グループが、第２セットの品質タイプ値を有する第２グループの場合よりも高い品質、低い速度でレンダリングしてもよく、それに対して、異なったイメージを、第１品質グループではより低い品質、より高い速度で、第２品質グループではより高い品質、より低い速度でレンダリングしてもよい。異なったレンダラーで実施されるレンダリングもこの同じ種類のリバーサルを経験する可能性がある。これらの可能性のために、Escherルーチンは品質タイプ値の順列をより低いあるいはより高い品質インデックスと関連付けなければならない属性概念をなんら押し付けない。アプリケーション・プログラムは、関連付けられた品質インデックス値とは無関係に、所与の品質グループ内に任意所望セットの品質タイプ値を自由に定めることができる。ここで、別の実施例では、このような関係が実際に強制されることになることは了解されたい。
Ｃ．品質グループを選び、獲得するためのプロシジャ
コレクション内にいくつかの品質グループを有し、各々がそれぞれの品質インデックス値を関連付けられていることの利点は、アプリケーション・プログラムがユーザに頼んで直感的な適切な機構を用いてレンダリング品質／速度トレードオフにおいて所望の点を選ばせることができるということである。再び補遺Ａのプログラム例を参照して、このアプリケーション・プログラムはアプリケーション・プログラム・ルーチンExGetDesiredQualityIndex()を用いてこれを行う。第１４図はこのようなプロシジャにおける主要ステップを示すフローチャートである。第１４図を参照して、ステップ１４０２において、プロシジャは品質ノブ・アイコンを表示する。このアイコンは第１５図に示してあり、そこからわかるように、ノブのように見える。このアイコンは品質インデックス値０．０を現在指し示しているニードルであり、ユーザはニードルの先端をクリックし、円まわりに回転するようにニードルをドラッグして０．０からほぼ１．０までの任意所望の品質インデックスを選ぶことができる。一実施例において、ノブの利用できる位置は連続的であり、ユーザは記憶用のバイナリ・レジスタの全細分性を持って品質インデックスを選ぶことができる。別の実施例では、個別の値しか選べない。
第１４図を参照して、ステップ１４０４において、プロシジャはユーザの品質インデックス選択を受け入れる。ステップ１４０６において、所望の品質インデックスが呼び出しルーチンに返される。
レンダラーは、一実施例ではレンダラー・オブジェクト、別の実施例ではビュー・オブジェクトに添付されていることによって選択した品質グループに気がつく。現在説明している実施例では、ビュー・オブジェクトに添付されている。Escherは、表Ｖに示す、品質グループ・オブジェクトを選び、獲得するルーチンを提供する。

補遺Ａのアプリケーション・プログラム例はEscherルーチンErView＿SelectQualityGroup()を用いて、ビュー・オブジェクトに対して、その品質インデックスがユーザの指定したものとマッチするかあるいはそれに最も近い品質グループを選択する。ここで、種々の実施例で、所望の品質インデックスが品質コレクション内の品質グループのうちの任意のものと関連付けられたもととマッチしない状況について種々のまるめ機能を使用し得ることは了解されたい。本実施例では、最も近い品質インデックス値を持つ品質コレクションが選ばれる。２つの品質グループと関連付けられた品質インデックスが所望の品質インデックスから等しく異なっている場合には、高い方の品質インデックスを持つグループが選ばれる。別の実施例では、所望の品質インデックスが常にラウンドアップされ、また別の実施例では、所望の品質インデックスが常にラウンドダウンされる。
Ｄ．レンダラー・プロシジャ
或る指定のビューにシェイプをレンダリングするために呼び出された各レンダラーは、ビュー・オブジェクトに現在割り当てられている品質グループにおける品質タイプの個々の値に応答して実行する。異なったレンダラーを選んで品質タイプ・パレメータの異なったものに応答させ、他を無視するようにしてもよい。第１６図は三角形をレンダリングするためのレイ・トレーサのErRT＿Geometry＿Triangle()プロシジャの関連概念のフローチャートである。
第１６図を参照して、ステップ１６０２において、プロシジャは、上記のEscherプロシジャErView＿GetQualityGroup()あるいはそれに類似したプロシジャを用いてビューに現在割り当てられている品質グループを指すポインタを獲得する。ステップ１６０４において、プロシジャはビューにレンダリングしようとしている三角形についてのデータを獲得する。ステップ１６０６、１６０８、１６１０において、プロシジャはカレント品質グループにおける２つの異なった品質タイプ・パラメータの値をルックアップして、三角形レンダリング・プロシジャのどのバージョンを使用すべきかを決定する。特に、ステップ１６０６において、EscherプロシジャErQualityGroup＿GetTypeData()を用いて、プロシジャは品質タイプ・パラメータ、「反射演算」についての値、を獲得する。この値が「オン」の場合には（高品質／低速度選択を表す）、制御はステップ１６０８に移る。「反射演算」が「オフ」の場合には、制御はステップ１６１０に移る。
ステップ１６０８は、次に、カレント品質グループにおける「シャドー演算」品質タイプ・パラメータの値を決定する。「シャドー演算」が「オン」の場合には、ステップ１６１２において、プロシジャは、品質タイプ・パラメータ「光線深度」についての値を用い、反射を用い、シャドーを用いて三角形をレンダリングする。もし「シャドー演算」が「オフ」の場合には、プロシジャは、指定光線深度、反射を用い、シャドーを用いずに三角形をレンダリングする（ステップ１６１４）。
もし「反射演算」が「オフ」の場合、ステップ１６１０において、プロシジャはステップ１６０８に類似した決定を行う。もし「シャドー演算」が「オン」の場合には、ステップ１６１６において、プロシジャは、指定光線深度、シャドー演算を用いるが、反射演算を用いずに三角形をレンダリングする。もしステップ１６１０で「シャドー演算」が「オフ」の場合には、ステップ１６１８において、プロシジャは、指定光線深度を用い、シャドー演算あるいは反射演算を用いずに三角形をレンダリングする。
明らかなように、説明を簡単にするために、第１６図のレンダラー・プロシジャは、カレント品質グループ・オブジェクトにおける「光線深度」、「反射演算」、「シャドー演算」品質タイプ・パラメータにのみ応答する。しかしながら、特別な種類のレンダラーにとって適切であると同様に、他のレンダラーもより多くの品質タイプ・パラメータに応答し得る。
本発明の好ましい実施例の上記の説明はまさに説明のために行ったものであり、発明を開示した形態そのものに限定するものではない。明らかに、当業者には多くの変更、修正が明らかであろう。これらの実施例は、発明の原理および実際の用途を最も良く説明するために選ばれ、説明されたものであり、当業者であれば特別に意図した用途に合わせるように種々の実施例、種々の変形例について本発明を理解できるであろう。本発明の範囲は以下の請求の範囲及びそれらの均等物によって定義されるものである。

Claims (14)

1. 指定されたレンダラーを用いて指定されたオブジェクトを指定されたシーンとしてレンダリングするオブジェクト描画サブシステムと共に使用される、複数のグラフィック出力装置上に可視像を創成する方法であって、
   オブジェクトの表現をメモリに提供する工程と
   前記オブジェクトのアイデンティフィケーションと第１のシーンのアイデンティフィケーションを、使用すべき第１レンダラーのアイデンティフィケーションと共に前記オブジェクト描画サブシステムを最初に呼び出す工程と、
   前記オブジェクトのアイデンティフィケーションと第２のシーンのアイデンティフィケーションを、使用すべき第２レンダラーのアイデンティフィケーションと共に前記オブジェクト描画サブシステムを２度目に呼び出す工程と、
   前記第１のシーンと第２のシーンとを前記複数のグラフィック出力装置の異なるものに出力する工程とを有することを特徴とする方法。
2. 第１レンダラーと共に用いる、グラフィック出力装置上に表示可能なシーンを創成する方法であって、
   前記第１レンダラーためのメソッド・テーブルに、特定のジオメトリをもつオブジェクトをレンダリングするために呼び出される前記第１レンダラーのメソッドの指示を書き込む工程と、
   前記シーンにレンダリングするため、第１ジオメトリをもつオブジェクトの指示を受ける工程と、
   前記第１レンダラーが前記第１ジオメトリのオブジェクトをレンダリングできるかどうかを決定する工程と、
   前記第１レンダラーが前記第１ジオメトリのオブジェクトをレンダリングすることができる場合に前記オブジェクトを前記シーンにレンダリングするように前記第１レンダラーを呼び出す工程と、
   前記第１レンダラーが前記第１ジオメトリのオブジェクトをレンダリングできないなら、前記オブジェクトを前記第１ジオメトリと異なるジオメトリを有する少なくとも１つのサブオブジェクトに分解する工程と、前記サブオブジェクトの各所与のサブオブジェクト毎に、前記第１レンダラーが前記所与のサブオブジェクトのジオメトリを有するオブジェクトをレンダリングできるなら、所与のサブオブジェクトを前記シーンにレンダリングするように前記第１レンダラーを呼び出す工程とを実行する工程とを有することを特徴とする方法。
3. さらに、前記オブジェクトの指示を受ける工程と協調して、前記第１レンダラーの指示を受け取る工程を有することを特徴とする請求項２に記載の方法。
4. 特定のジオメトリが前記第１ジオメトリであることを特徴とする請求項２に記載の方法。
5. 前記書き込む工程は、
   前記第１レンダラーがレンダリングできる各特定のジオメトリ毎に、前記第１レンダラーのためのメソッド・テーブルのそれぞれのエントリに、前記特定のジオメトリを有するオブジェクトをレンダリングするために呼び出されるべき前記第１レンダラーのそれぞれのメソッドの指示を書き込む工程を有することを特徴とする請求項２に記載の方法。
6. 前記第１レンダラーが前記第１ジオメトリのオブジェクトをレンダリングできるかどうかを決定する工程が、前記第１レンダラーについての前記メソッド・テーブルが前記第１ジオメトリを有するオブジェクトをレンダリングするために呼び出すべきメソッドの指示を含んでいるかどうかを決定する工程を有することを特徴とする請求項５に記載の方法。
7. 前記オブジェクトを前記シーンにレンダリングするように前記第１レンダラーを呼び出す工程が、前記第１ジオメトリのオブジェクトをレンダリングするために前記メソッド・テーブルによって指示されたメソッドを呼び出す工程を有することを特徴とする請求項５に記載の方法。
8. さらに第２レンダラーと共に使用するために、前記受け取る工程に先だって、さらに、
   前記第２レンダラーがレンダリングできる各サブジェクト・ジオメトリ毎に、前記第２レンダラーについてのメソッド・テーブルのそれぞれのエントリに、サブジェクト・ジオメトリを有するオブジェクトをレンダリングするために呼び出されるべき前記第２レンダラーのそれぞれのメソッドの指示を書き込む工程を有することを特徴とする請求項５に記載の方法。
9. グラフィック出力装置上に表示できるシーンを創成する方法であって、
   アプリケーション・プログラムの実行をスタートする工程と、
   第１レンダラーについて、それぞれのジオメトリを有するオブジェクトをレンダリングするために呼び出されるべき前記第１レンダラーの少なくとも１つのメソッドの指示を確立する第１の確立工程と、
   前記第１レンダラーがレンダリングすることができる第１ジオメトリを有するオブジェクトについて、前記第１ジオメトリを有するオブジェクトをレンダリングするための前記第１の確立工程で確立された前記第１レンダラーのメソッドを呼び出す工程と、を有し、
   前記第１の確立工程は、前記第１のレンダラーがレンダリングすることができる特定のジオメトリ毎に、前記第１レンダラーについてのメソッド・テーブルのそれぞれのエントリに、前記特定のジオメトリを有するオブジェクトをレンダリングするために呼び出されるべき前記第１レンダラーのそれぞれのメソッドの指示を書き込む工程を有することを特徴とする方法。
10. さらに、前記実行をスタートする工程の後に、
    第２レンダラーについて、それぞれのジオメトリを有するオブジェクトをレンダリングするために呼び出されるべき前記第２レンダラーの少なくとも１つのメソッドの指示を確立する第２の確立工程を有することを特徴とする請求項９に記載の方法。
11. さらに、前記呼び出す工程に先だって、
    前記第１及び第２の確立工程の後に、前記アプリケーション・プログラムの制御の下に、前記呼び出す工程について前記第２レンダラーに優先して前記第１レンダラーを選択する工程を有することを特徴とする請求項１０に記載の方法。
12. 前記第２の確立工程が、前記呼び出す工程の後に生じ、
    さらに、前記オブジェクトについて、前記第２の確立工程において確立された、前記第１ジオメトリを有するオブジェクトをレンダリングするためのメソッドを呼び出す工程を有することを特徴とする請求項１０に記載の方法。
13. さらに、前記第１の確立工程の後に、
    前記第１レンダラーがレンダリングすることのできない第２ジオメトリを有する第２オブジェクトを、それぞれが前記第２ジオメトリと異なるジオメトリを有する少なくとも１つのサブオブジェクトに分解する工程と、
    前記第１レンダラーがレンダリングできるジオメトリを有する前記サブオブジェクトのうちの所与のサブオブジェクト毎に、前記所与のサブオブジェクトのジオメトリを有するオブジェクトをレンダリングするために前記第１の確立工程で確立された前記第１レンダラーのメソッドを呼び出す工程とを有することを特徴とする請求項９に記載の方法。
14. グラフィック出力装置上に表示可能なシーンを創成する装置であって、
    アプリケーション・プログラムの実行をスタートさせる手段と、
    第１レンダラーについて、それぞれジオメトリを有するオブジェクトをレンダリングするための呼び出される前記第１レンダラーの少なくとも１つのメソッドの指示を確立する手段と、
    前記第１レンダラーがレンダリングすることができる第１ジオメトリを有するオブジェクトについて、前記第１ジオメトリを有するオブジェクトをレンダリングするために前記確立する手段によって確立された前記第１レンダラーのメソッドを呼び出す手段と、を有し、
    前記確立する手段は、前記第１レンダラーがレンダリングすることができる特定のジオメトリ各々について、前記特定のジオメトリをもつオブジェクトをレンダリングするために呼び出される前記第１レンダラーの各々のメソッドの指示を、前記第１のレンダラーについてのメソッド・テーブルの各エントリに書き込む手段を有することを特徴とする装置。

Images