JP2006127556A - シェーダ駆動による描画アセットの編集を実施するためのシステムおよび方法 - Google Patents

Abstract

【課題】シェーダ駆動のコンパイル手法を用いることによってアートアセット描画動作を最適化するシステムおよび方法を提供すること。
【解決手段】幾何データは、関連シェーディングプログラムの知識を用いて、コンパイル処理において処理される。データは、対象ハードウェアプラットフォームを直接の対象とするデータ構造に変換され、これらのデータ構造を描画するのに必要な動作を記述するコードストリームがアセンブルされる。コンパイラは、プラットフォームとは独立した形態のシェーダおよび三次元モデリングパッケージから出力された幾何データおよび属性（アートアセット）を読み取ってプラットフォームから独立した最適化を行うように構成されたフロントエンド（図1,番号20）と、プラットフォーム固有の最適化を行ってプラットフォームを対象としたデータ構造およびコードストリームを生成するように構成されたバックエンド（図1,番号40）とを含む。
【選択図】図１

Description

（関連出願の相互参照）
本出願は、２００２年３月８日出願の米国仮出願番号６０／３６３，０４９の利益を主張するものであり、その内容はすべて、あらゆる目的のために、本願に包含される。

（発明の背景）
本発明は、一般的には描画システムに関し、より特定的には、シェーダ駆動によるコンパイル方法に基づくアートアセット描画に関する。

ビデオゲームなどの一般消費者向けのアプリケーションでは、ほとんどの図形要素の配置は固定されているが、エイリアス｜ウェーブフロント社（Ａｌｉａｓ｜Ｗａｖｅｆｒｏｎｔ）のマヤ（Ｍａｙａ）（商標）、ソフトイメージ社（ＳｏｆｔＩｍａｇｅ）のエックスエスアイ（ＸＳＩ）（商標）、および３Ｄスタジオマックス（３Ｄ Ｓｔｕｄｉｏ Ｍａｘ）（商標）などのモデリングアプリケーションの場合は別である。ハードウェア設計者は、ゲームコンソールおよびグラフィックス・アクセレレータ・チップセットの設計には共にこれを利用して、個々のポリゴンを描画する場合よりも、多数の一定の図形の集合を描画する場合に最も効率的となるようにハードウェアを設計してきた。このことは、利用されている典型的なＡＰＩに反映されており、例えば、マイクロソフト社のダイレクトトエックス（ＤｉｒｅｃｔＸ）８およびオープン・ジーエル（ＯｐｅｎＧＬ）１．１以降のバージョン（例えば、ＯｐｅｎＧＬ：１９９９）は共に、入力データ（頂点、色、および他の頂点毎の属性、ならびにインデックスリスト）のアレイを設定するための呼び出しに対応している。さらに、ポリゴン群および他の描画属性を表示リストに収集して、今後のアトミック送信を単一のポリゴン送信よりもはるかに高い性能で行えるようすることができる。

一般消費者向けのアプリケーションでは、アートアセットのオーサリングは、開発過程の一部をなすものである。なんらかのツールのセットを用いてアセットを前処理して、アプリケーションのハードウェアおよびソフトウェアアーキテクチャの両方に適した形式する。このデータ前処理は、典型的には、幾何要素のみを操作する。描画状態の他の要素、例えば、ライティング、頂点および画素シェーダの選択、ラスター化制御、変換行列など、ならびに頂点バッファおよび頂点レイアウトの選択の設定は、ランタイムエンジンで取り扱われる。これには、コードに常駐してアートアセットをプログラマに対して密接に関連付ける、アートアセットの利用についての多くの知識が必要である。プログラマは、このコードを一般化して複数のアセットを取り扱おうとしがちだが、そうすると効率が犠牲となってしまう。シェーダコンパイラがこの問題の部分的解決策として考察されてきてはいるが、描画を体系的に最適化するためにシェーダの知識を利用した者はこれまでいない。

アートアセットコンパイラについての考察に関連した２つの研究がある。第１には、コンパイリングシェーディング言語についての最近の研究である。第２には、表示リストに関するものである。

（シェーディング言語）
シェーディング言語は、クックのシェードツリー（Ｒ・Ｌ・クック（Ｃｏｏｋ，Ｒ．Ｌ）著、１９８４年、「シェードツリー（Ｓｈａｄｅ Ｔｒｅｅｓ）」、コンピュータグラフィックス（Ｃｏｍｐｕｔｅｒ Ｇｒａｐｈｉｃｓ）（１９８４年米国コンピュータ学会コンピュータグラフィックス分科会（ＳＩＧＧＲＡＰＨ）議事録）、第１８巻、２２３〜２３１）およびパーリンの画素ストリーム言語（Ｋ．パーリン（Ｐｅｒｌｉｎ，Ｋ）著、１９８５年、「イメージシンセサイザ（Ａｎ Ｉｍａｇｅ Ｓｙｎｔｈｅｓｉｚｅｒ）」、コンピュータグラフィックス（Ｃｏｍｐｕｔｅｒ Ｇｒａｐｈｉｃｓ）（１９８５年ＳＩＧＧＲＡＰＨ議事録）、第１９巻、２８７〜２９６）の成果である。これらは現在最も一般的に用いられており、レンダーマン・シェーディング言語（ＲｅｎｄｅｒＭａｎ Ｓｈａｄｉｎｇ Ｌａｎｇｕａｇｅ）という形態を取る（Ｐ．ハンラハン（Ｈａｎｒａｈａｎ，Ｐ）およびＪ．ローソン（Ｌａｗｓｏｎ，Ｊ）著、１９９０年、「シェーディングおよびライティング計算のための言語（Ａ Ｌａｎｇｕａｇｅ ｆｏｒ Ｓｈａｄｉｎｇ ａｎｄ Ｌｉｇｈｔｉｎｇ Ｃａｌｃｕｌａｔｉｏｎｓ）」、コンピュータグラフィックス（Ｃｏｍｐｕｔｅｒ Ｇｒａｐｈｉｃｓ）（１９９０年ＳＩＧＧＲＡＰＨ議事録）、第２４巻、２８７〜２９６、ＩＳＢＮ０−２０１−５０９３３−４およびＡ．Ａ．アポダカ（Ａｐｏｄａｃａ，Ａ．Ａ）およびＭ．Ｗ．マントル（Ｍａｎｔｌｅ，Ｍ．Ｗ）、１９９０年、「レンダーマン：グラフィックスの将来を追求して（Ｒｅｎｄｅｒｍａｎ：Ｐｕｒｓｕｉｎｇ ｔｈｅ Ｆｕｔｕｒｅ ｏｆ Ｇｒａｐｈｉｃｓ）」、米国電気・電子通信学会（ＩＥＥＥ）コンピュータグラフィックスおよびアプリケーション１０（ＩＥＥＥ Ｃｏｍｐｕｔｅｒ Ｇｒａｐｓｈｉｃｓ ＆ Ａｐｐｌｉｃａｔｉｏｎｓ １０），４（７月）、４４〜４９）。シェーディング言語は、リアルタイム描画グラフィックスハードウェアアプリケーションに近年採用されるようになっている。

オラーノおよびラストラ（Ｍ．オラーノ（Ｏｌａｎｏ，Ｍ）およびＡ．ラストラ（Ｌａｓｔｒａ，Ａ）著、１９９８年、「グラフィックス・ハードウエア上のシェーディング言語：ピクセルフロー・シェーディングシステム（Ａ Ｓｈａｄｉｎｇ Ｌａｎｇｕａｇｅ
ｏｎ Ｇｒａｐｈｉｃｓ Ｈａｒｄｗａｒｅ：Ｔｈｅ Ｐｉｘｅｌｆｌｏｗ Ｓｈａｄｉｎｇ Ｓｙｓｔｅｍ）」、１９９８年ＳＩＧＧＲＡＰＨ議事録、エーシーエム（ＡＣＭ）ＳＩＧＧＲＡＰＨ／アディソン・ウェズリー（Ａｄｄｉｓｏｎ Ｗｅｓｌｅｙ）、フロリダ州オーランド、コンピュータグラフィックス議事録、年次総会シリーズ、１５９〜１６８、ＩＳＢＮ０−８９７９１−９９９−８）が、特定のグラフィックスハードウェアを対象としたコンパイルを行うレンダーマンのような言語を説明した最初であり、その対象とは、彼らの場合はピクセルフロー（ＰｉｘｅｌＦｌｏｗ）システムであった（Ｓ．モルナー（Ｍｏｌｎａｒ，Ｓ）、Ｊ．バイルズ（Ｂｙｌｅｓ，Ｊ）、およびＪ．プルトン（Ｐｏｕｌｔｏｎ，Ｊ）著、１９９２年、「ピクセルフロー：画像構成を用いた高速描画（Ｐｉｘｅｌｆｌｏｗ：Ｈｉｇｈ−Ｓｐｅｅｄ Ｒｅｎｄｅｒｉｎｇ Ｕｓｉｎｇ Ｉｍａｇｅ Ｃｏｍｐｏｓｉｔｉｏｎ）」、コンピュータグラフィックス（Ｃｏｍｐｕｔｅｒ Ｇｒａｐｈｉｃｓ）（１９９２年ＳＩＧＧＲＡＰＨ議事録）、第２６巻、２３１〜２４０、ＩＳＢＮ０−２０１−５１５８５−７）。ピクセルフローは、プログラム可能なシェーディングに元来十分に適してはいるが、今日の一般消費者レベルのハードウェアとは非常に異なるものである。

アイディー・ソフトウェア社（ｉｄ Ｓｏｆｔｗａｒｅ）のクエーク（Ｑｕａｋｅ）ＩＩＩという商品は、クエークシェーダ言語を内蔵している。ここで、シェーダの仕様は、ＯｐｅｎＧＬ状態のマシンを制御するために利用される。シェーダ言語は、テクスチャ部に係わるマルチパス描画効果を特定することを目標としており、アプリケーション変数を様々なパスのパラメータに結合することができる。

ピアーシー（Ｐｅｅｒｃｙ）は、ＯｐｅｎＧＬ状態マシンを単一命令多重データ（ＳＩＭＤ）プロセッサとして扱うことによって、レンダーマンのシェーディング言語をコンパイルするフレームワークが得られることに注目した。レンダーマンシェーダを一連の描画パスに分解して、フレームバッファにまとめた（Ｍ．Ｓ．ピアーシー（Ｐｅｅｒｃｙ，Ｍ
．Ｓ）、Ｍ．オラーノ（Ｏｌａｎｏ，Ｍ）、Ｊ．エアリー（Ａｉｒｅｙ，Ｊ）、およびＰ．Ｊ．アンガー（Ｕｎｇａｒ，Ｐ．ｊ）著、「インタラクティブ・マルチパス・プログラマブル・シェーディング（Ｉｎｔｅｒａｃｔｉｖｅ Ｍｕｌｔｉ−Ｐａｓｓ Ｐｒｏｇｒａｍｍａｂｌｅ Ｓｈａｄｉｎｇ）」、２０００年（７月）ＳＩＧＧＲＡＰＨ議事録、４２５〜４３２、ＩＳＢＮ１−５８１１３−２０８−５）。

近年では、プラウドフット（Ｋ．プラウドフット（Ｐｒｏｕｄｆｏｏｔ，Ｋ）、Ｗ．Ｒ．マーク（Ｍａｒｋ，Ｗ．Ｒ）、Ｓ．ツヴェコフ（Ｔｚｖｅｔｋｏｖ，Ｓ）、およびＰ．ハンラハン（Ｈａｎｒａｈａｎ，Ｐ）著、２００１年、「プログラマブル・グラフィックス・ハードウェアのためのリアルタイム手順のシェーディングシステム（Ａ Ｒｅａｌ−Ｔｉｍｅ Ｐｒｏｃｅｄｕａｌ Ｓｈａｄｉｎｇ Ｓｙｓｔｅｍ ｆｏｒ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇｒａｐｈｉｃｓ Ｈａｒｄｗａｒｅ）」、２００１年ＳＩＧＧＲＡＰＨ議事録、エーシーエムプレス（ＡＣＭ Ｐｒｅｓｓ）／ＡＣＭ ＳＩＧＧＲＡＰＨ、コンピュータグラフィックス議事録、年次総会シリーズ、１５９〜１７０ ＩＳＢＮ１−５８１１３−２９２−１）は、シェーダ言語コンパイラを開発しており、このコンパイラは、ＤｉｒｅｃｔＸ８およびエヌヴィディア社（ＮＶＩＤＩＡ）のエヌヴィー（ＮＶ）頂点プログラムのＯｐｅｎＧＬ拡張版（Ｅ．リンドーム（Ｌｉｎｄｈｏｌｍ，Ｅ），Ｍ．Ｊ．キルガード（Ｋｉｌｇａｒｄ，Ｍ．Ｊ）、およびＨ．モレトン（Ｍｏｒｅｔｏｎ，Ｈ）著、２００１年、「ユーザ・プログラマブル頂点エンジン（Ａ Ｕｓｅｒ−Ｐｒｏｇｒａｍｍａｂｌｅ Ｖｅｒｔｅｘ Ｅｎｇｉｎｅ）」、エーシーエムプレス（ＡＣＭ Ｐｒｅｓｓ）／ＡＣＭ ＳＩＧＧＲＡＰＨ、コンピュータグラフィックス議事録、年次総会シリーズ、１４９〜１５８ ＩＳＢＮ１−５８１１３−２９２−１）において利用可能な、プログラム可能な頂点シェーダと、最新のテクスチャ合成ハードウェアによって実現される断片毎の動作を利用している。彼らは、仕様が生ずる複数のレベル（オブジェクトレベル、頂点レベル、またはピクセルレベル）を考慮することにより、これらのレベルにおけるハードウェアの特徴をうまく活用している。

すべての上記シェーダコンパイラにおいて、幾何データは、レンダーマンモデルに従って、基礎となるグラフィックスアプリケーションインターフェイス（ＡＰＩ）を介して、シェーダに伝達される。レンダーマンにおいて、幾何学形状およびそのシェーダとの結合は、レンダーマンインターフェイス仕様を用いた手順を踏んで特定される。同様に、オラーノおよびラストラのシステムならびにプラウドフットのシステムは、ＯｐｅｎＧＬのＡＰＩを用いて、シェーダを幾何学形状に対して結合する。これには、シェーダの幾何学形状との結合を管理するための外部システムおよび結合を管理するためのアートアセット毎の明示的なアプリケーションコードのいずれかが必要となる。これらのプログラムは、一見したよりも複雑である。なぜならば、結合を管理するためのランタイムコードおよびランタイムに適切なデータを生成するための同期ツールコードの両方が必要だからである。

（表示リスト）
アートアセットは、典型的には、３次元モデリングおよび動画パッケージにおいて作成される。これらのパッケージは、通常、幾何データおよび結果オブジェクトのオフライン描画のインタラクティブな操作に向けられている。これらは、典型的には、幾何、トポロジー、シェーディング、および動画の操作のための一連の豊かな特徴を有する。しかしながら、未処理の出力モデルは、一般消費者レベルのハードウェアに適していることは稀である。アセットは、リアルタイムの一般消費者レベルのアプリケーションにおける最終的な利用を意識して製作されなければならない。アセットは、パッケージに格納された豊かな記述から変換されるだけではなく、アプリケーションのハードウェアおよびソフトウェアのアーキテクチャに向けて最適化されなければならない。このような前処理の範囲は、単純なデータ変換から、複雑な再順序付けおよび最適化タスクまでに及ぶ。

ホップは、三角片の頂点を再順序付けすることによって、ハードウェア頂点キャッシュを活用したより効率的な描画が可能になりうることを示した（Ｈ．ホップ（Ｈｏｐｐｅ，Ｈ）著，１９９９年、「透明頂点キャッシングのためのメッシュ位置の最適化（Ｏｐｔｉｍｉｚａｔｉｏｎ ｏｆ Ｍｅｓｈ Ｌｏｃａｌｉｔｙ ｆｏｒ Ｔｒａｎｓｐａｒｅｎｔ Ｖｅｒｔｅｘ Ｃａｃｈｉｎｇ）」、１９９９年（８月）ＳＩＧＧＲＡＰＨ議事録、２６９〜２７６、ＩＳＢＮ０−２０１４８−５６００−５、カリフォルニア州ロサンゼルスにて開催）。ボゴムジャコフおよびゴツマンは、アプリオリにキャッシュのサイズを知らなくても、三角片の代わりに頂点メッシュを用いて頂点キャッシュを活用する方法を示した（Ａ．ボゴムジャコフ（Ｂｏｇｏｍｊａｋｏｖ，Ａ）およびＣ．ゴツマン（Ｇｏｔｓｍａｎ，Ｃ）著，２００１年、「進行型メッシュのための透明頂点キャッシング（Ｔｒａｎｓｐａｒｅｎｔ Ｖｅｒｔｅｘ Ｃａｃｈｉｎｇ ｏｆ Ｐｒｏｇｒｅｓｓｉｖｅ Ｍｅｓｈｅｓ）」、２００１年グラフィックス・インターフェイス議事録、８１〜９０）。これらの両取り組みにより、従来の入力データを用いるよりも描画性能が２倍向上した。

しかしながら、幾何的な最適化がどのようなレベルであっても、何らかのレベルのグラフィックスハードウェア設定および描画送信の最適化が、最高の性能を得るには必要である。初期のグラフィックスＡＰＩは、一般的に、各ポリゴンを描くことに向けられていた（Ｋ．Ｆ．バレル（Ｂａｒｒｅｌｌ，Ｋ．Ｆ）著、１９８３年、「グラフィカル・カーネル・システム―コアの代用（Ｔｈｅ Ｇｒａｐｈｉｃａｌ Ｋｅｒｎｅｌ Ｓｙｓｔｅｍ―Ａ Ｒｅｐｌａｃｅｍｅｎｔ ｆｏｒ Ｃｏｒｅ）」、第１回コンピュータグラフィックスに関するオーストララシア会議（Ｆｉｒｓｔ Ａｕｓｔｒａｌａｓｉａｎ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｃｏｍｐｕｔｅｒ Ｇｒａｐｈｉｃｓ）、２２〜２６）。ＯｐｅｎＧＬの初版は、同様に限界があり、ポリゴン送信における関数呼び出しの高いオーバヘッドが生じていた。ＯｐｅｎＧＬ１．１のＧＬアレイ（ＧＬＡｒｒａｙ）機構は、ポリゴンの一括指定ができることにより、このオーバヘッドの大半を排除していた（例えば、ＯｐｅｎＧＬアーキテクチャ論評委員会、Ｍ．ウー（Ｗｏｏ，Ｍ）、Ｊ．ナイダー（Ｎｅｉｄｅｒ，Ｊ）、Ｔ．デービス（Ｄａｖｉｓ．Ｊ）、およびＤ．シュライナー（Ｓｈｒｅｉｎｅｒ，Ｄ）著、１９９９年、「ＯｐｅｎＧＬ・プログラミング・ガイド：ＯｐｅｎＧＬ学習公式ガイド（ＯｐｅｎＧＬ Ｐｒｏｇｒａｍｍｉｎｇ Ｇｕｉｄｅ：Ｔｈｅ Ｏｆｆｉｃｉａｌ Ｇｕｉｄｅ ｔｏ Ｌｅａｒｎｉｎｇ ＯｐｅｎＧＬ）」、第１．２版、アディソン−ウェズリー（Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ）参照）。ＤｉｒｅｃｔＸ８の頂点ストリームは、同様の原理で動作している（例えば、「ＤｉｒｅｃｔＸ８・プログラマ・リファレンス（ＤｉｒｅｃｔＸ ８ Ｐｒｏｇｒａｍｍｅｒ‘ｓ Ｒｅｆｅｒｅｎｃｅ）」、マイクロソフト・プレス、参照）。

頂点アレイは幾何データの送信を迅速化させるが、それでもなお、ＯｐｅｎＧＬおよびＤｉｒｅｃｔＸ８における様々な状態設定関数は、多数のオーバヘッドが必要となる。両方とも、表示リストをサポートするものであり、表示リストは、後のアトミック再送信のための幾何および状態設定呼び出しを収集するために利用される。これらの表示リストは、ドライバレベルにおける多大な最適化の可能性を有してはいるが、ランタイムでの構成は、その結果生じる性能限界とともに、表示リストの最適化が利用される度合いを制限する。特に、パラメータ化された表示リストには問題がある。単一の表示リストはパラメータ化できないが、表示リストは、元の表示リストから再構築された１つ以上の表示リストを呼び出して、簡易のパラメータ化ができるようになっていてもよい。しかしながら、このアーキテクチャでは、ドライバは、このような入れ子になった表示リスト呼び出しの状態変化を最適化することができない。なぜならば、新たに定義されたリストは、親表示リストで設定された状態のいずれかに影響を与えるかもしれないからである。

したがって、上記の方法論に関連した欠点のない、アートアセット描画動作を最適化する新規のシステムおよび方法を提供することが望ましい。

（発明の簡単な要旨）
本発明は、シェーダ駆動のコンパイル手法を用いることによってアートアセット描画動作を最適化するシステムおよび方法を提供する。

一般消費者向けグラフィックスハードウェアの描画性能は、前処理の幾何データからの恩恵を受けて、基礎となるＡＰＩおよびハードウェア向けの形態をとる。その後、様々な幾何データ要素がシェーディングプログラムにランタイムで結合され、アセットを描画する。

本発明によれば、幾何データが関連シェーディングプログラムの知識とともに処理されるコンパイル処理において前処理が、行われるシステムおよび方法を提供する。データは、対象ハードウェアプラットフォームを直接対象としたデータ構造に変換され、これらのデータ構造を描画するのに必要な操作を記述したコードストリームがアセンブルされる。本発明のコンパイラは、プラットフォームに依存しない形態の３次元モデリングパッケージおよびシェーダから出力された幾何データおよび属性（以後アートアセットと称する）を読み出して、プラットフォームに依存しない最適化を行うように構成されたフロントエンドと、プラットフォームに固有の最適化を行って、プラットフォームに特化したデータ構造およびコードストリームを生成するように構成されたバックエンドとを含む。

有利なのは、コンパイラのバックエンドは、様々なプラットフォームを対象とすることができ、４つのプラットフォームを対象とした場合には、そのうちの３つが互いに完全に異なっていた。すべてのプラットフォーム上で、コンパイルされたアセットの描画性能は、実際の使用状況では、主導で符号化されたアセットよりもはるかに上回る。

ソニーのプレイステーション２（ＰｌａｙＳｔａｔｉｏｎ２）（商標）、マイクロソフト社のエックスボックス（ＸＢｏｘ）（商標）、および任天堂のゲームキューブ（ＧａｍｅＣｕｂｅ）（商標）ならびにパーソナルコンピュータなどで見受けられる、一般消費者レベルのグラフィックスハードウェアの直近の世代は、ハイエンドのリアルタイムグラフィックスを消費者全般に与えている。このハードウェアは、ビデオゲームでの利用のために存在し、このことが、ハードウェアのアーキテクチャに反映されている。

本発明のシステムは、以下の要請に応えるものである。
−固定されたトポロジーオブジェクトを固定されたシェーディング効果を用いて効率的に描画すること
−描画したオブジェクトに対するランタイム修正に対応していること、但し、必ずしもトポロジー図形を修正するものではないこと、
−頂点プログラムおよび画素合成器などのハードウェア機能を活用すること、および
−ユーザコードおよびアートアセットが、互いに異なるハードウェアプラットフォームに渡って移植可能とすることである。

本発明は、リアルタイム描画システムであって、移植可能なＡＰＩを有する小型で効率的なランタイムエンジンと、モジュラー式の再対象化可能なアートアセットコンパイラとを備える。ランタイムエンジンは、既存のグラフィックスＡＰＩの先端およびドライバレベルで共に実現される。アートアセットは、何らかの幾何モデリングパッケージ、たとえばエイリアス｜ウェーブフロント社のＭａｙａ、３Ｄ Ｓｔｕｄｉｏ Ｍａｘ、またはソフトイメージ社のＸＳＩで制作される。アセットは、好ましくは、幾何図形、頂点毎の属性、ならびに素材（表面の特性、色、テクスチャマップの使用法など）およびアセットの
テクスチャの集合体を含む。アセットの記述が十分になされているので、プログラマを介在させずに、最終的な利用において表現されるようにオブジェクトを描画することができる。

ある局面において、アーキテクチャは、シェーダプログラムだけではなくシェーダにとっての入力データの意味規則をも記述するシェーダ言語を用いて、描画原始記述をランタイムから分離することに基づく。これらの補強されたシェーダは、描画メソッドと称され、単一のアートアセットが、多数を参照してもよい。逆に、単一の描画メソッドが、１以上のアートアセットによって利用されてもよい。

本発明の一実施例では、幾何図形のシェーダへの結合は、アートアセットコンパイラで明示的に管理される。これにより、多くの利点が与えられる。例えば、明示的に明らかなランタイムシェーダパラメータがある場合にのみ、特定のアセットに固有のユーザコードが必要となる。さらに、上述したことの当然の結果として、アーティストは、対象プラットフォームにおいて、プログラマの介在なしに、アートアセットを迅速に反復することができる。さらには、すべての幾何図形の特定化および結合が好ましくはオフラインで行われるので、ランタイムＡＰＩが劇的に簡略化される。

一実施例において、描画オブジェクトはオフラインで構築され、これらのオブジェクトのパラメータ化は、外部変数の描画オブジェクトとのランタイム結合を通じて、オブジェクトの様々な部分をランタイムに修正用にエクスポートすることによって対処される。これらの方法により、本発明のモデルのパラメータ化された要素周辺を積極的に最適化することができる。

結果生じたシステムは、高速かつ柔軟性を有する。このシステムは、既存の従来の描画エンジンと同様またはそれ以上に高速であることを自ら示している。本発明のシステムを新規のプラットフォームへの移植することは、従来のゲームエンジンおよびツールのセットを新規のハードウェアに移植することよりも、はるかに高速に行われる。

本発明のある局面によれば、アートアセットをコンピュータにおいてランタイムで描画するための最適化されたコードを生成するための方法が提供される。本方法は、典型的には、アートアセットおよび当該アートアセットに関連する１以上の描画メソッドをコンパイラのフロントエンドに提供することと、１以上のパケットをコンパイラのフロントエンドで生成することとを含み、各パケットは、アートアセットの断片および１以上の描画メソッドのうちの１つの個別呼び出しを表す。また、本発明は、最適化されたコードおよびデータストリームを、１以上のパケットを用いてコンパイラのバックエンドにおいて生成することを典型的には含み、最適化されたコードおよびデータストリームを用いて、アートアセットをディスプレイ上でランタイムで描画する。

図面および請求項を含む、明細書の残りの部分を参照すれば、本発明の他の特徴や利点が理解されるであろう。本発明のさらなる特徴および利点を、本発明の様々な実施例の構成および動作と共に、添付図面に関連して、以下に詳細に説明する。図面において、同様の参照符号は、同一または機能的に同様の構成要素を示す。

（発明の詳細な説明）
本発明のシステムの一実施例を、図１に示す。図示のように、アートアセット１０と、シェーダ入力変数およびオフライン計算の宣言を含みかつこれらの変数をアートアセットから生成する描画メソッドと称されるシェーダの仕様の拡張機能１５とが、アートアセットコンパイラのフロントエンド２０に具備される。コンパイラのフロントエンド２０は、例えばポリゴン幾何データおよびモデル変数といった、アートアセット１０および描画メ
ソッド１５を入力とし、描画メソッドの個別呼び出しを表すセグメント化され幾何学的に最適化されたパケットと称されるアセット断片３０を作成する。本発明の教示を用いて、スプライン表面や粒子システムとしての非幾何図形データに対応するために、他のフロントエンドが構築されてもよいことが理解されるべきである。アセットコンパイラのバックエンド４０は、フロントエンドで生成されたパケット３０を用いて、最適化されたコードおよびデータストリーム５０、ハードウェア固有のデータ構造５５、ならびにランタイムでアセットを描画するために用いられるシェーダ６０を生成する。

本発明の一実施例では、幾何図形のシェーダへの結合が、アートアセットコンパイラで明示的に管理される。これにより、多くの利点がもたらされる。例えば、特定のアセットに固有のユーザコードは、明示的に表されたランタイムシェーダパラメータ（例えば、下記の変数部を参照）がある場合にのみ、必要とされる。さらに、上述したことの当然の帰結として、アーティストは、対象プラットフォームにおいて、プログラマの介在なしに、アートアセットを迅速に反復することができる。さらには、すべての幾何図形の特定化および結合が好ましくはオフラインで行われるのでので、ランタイムＡＰＩが劇的に簡略化される（ランタイムでの結合を生成するためのツールが具備されるが、この利用は一般的に推奨されない。そのようなダイナミックモデルはコンパイルされたモデルよりもはるかに効率が低いからである（例えば、下記のＡＰＩ部を参照）。

一実施例において、描画オブジェクトはオフラインで構築され、これらのオブジェクトのパラメータ化は、外部変数の描画オブジェクトとのランタイム結合を通じて、オブジェクトの様々な部分をランタイムに修正用にエクスポートすることによって対処される。（例えば、下記の変数部を参照）これらの方法により、本発明のモデルのパラメータ化された要素周辺を積極的に最適化することができる。

（ランタイム環境）
アートアセットコンパイラに関する考察を具体的なものとするために、対象のランタイム環境について、以下に簡単に説明する。図６は、本発明が有用なハードウェアプラットフォーム１００の典型的な構成要素を示す。図示のように、プラットフォーム１００はＣＰＵ１１０を含み、ＣＰＵ１１０は、ＧＰＵ１２０にシステムバス１３０を介して接続されている。ＣＰＵ１１０およびＧＰＵ１２０は、それぞれ、典型的には、ローカル・オンチップ・メモリ、例えばＣＰＵ ＲＡＭキャッシュ１１５およびＧＰＵ ＲＡＭキャッシュ１２５を含む。また、プラットフォーム１００は、典型的には、ハードドライブまたはたのメモリなどのメモリ部１４０と、１以上の既知のＣＤ、ＤＶＤ、およびフロッピー（登録商標）ディスク媒体などの様々な媒体１５５を収容するように構成された媒体装置１５０とを含む。１以上のユーザ入力装置１６０をプラットフォーム１００に接続することができる。ユーザインターフェイス装置の例としては、キーボード、ジョイスティック、マウスなどがある。プラットフォーム１００およびその様々な構成要素は、典型的には、動作することによって画像を生成または描画して、モニタ、テレビジョン画面、ＬＣＤディスプレイなどのディスプレイ装置１７０に表示させる。ディスプレイ１７０との通信のために、ディスプレイドライバ１６５が典型的には具備される。

（ハードウェア環境の影響）
コンパイラが対象とする環境は、特定のハードウェア描画プラットフォームを含むと共に、そのプラットフォーム上でのランタイムライブラリも含む。本発明のランタイムライブラリおよびコンパイラは、様々なプラットフォーム上で実施可能であり、例えば、ソニーのＰｌａｙＳｔａｔｉｏｎ２（商標）（ＰＳ２）、マイクロソフト社のＸＢＯＸ（商標）、任天堂のＧａｍｅＣｕｂｅ（商標）（ＮＧＣ）、およびＤｉｒｅｃｔＸ８のパーソナルコンピュータプラットフォームなどがある。これらのアーキテクチャは実質的に互いに異なるが（例えば、Ｍ．スズオキ、Ｋ．クタラギ、Ｔ．ヒロイ、Ｈ．マゴシ、Ｓ．オカモト、Ｍ．オカ、Ａ．オオバ、Ｙ．ヤマモト、Ｍ．フルハシ、Ｍ．タナカ、Ｔ．ユタカ、Ｔ．オカダ、Ｍ．ナガマツ、Ｙ．ウラカワ、Ｍ．フニュウ、Ａ．クニマツ、Ｈ．ゴトウ、Ｋ．ハシモト、Ｎ．イデ、Ｈ．ムラカミ、Ｙ．オオタグロ、およびＡ．アオノ著、１９９０年、「１２８ビットＣＰＵを有するマクロプロセッサ、１０浮動小数点マックの４浮動小数点デバイダ、およびＭＰＥＧ−２デコーダ（Ａ Ｍｉｃｒｏｐｒｏｃｅｓｓｏｒ ｗｉｔｈ １２８−Ｂｉｔ ＣＰＵ，Ｔｅｎ Ｆｌｏａｔｉｎｇ−Ｐｏｉｎｔ Ｍａｃ‘ｓ，Ｆｏｕｒ−Ｆｌｏａｔｉｎｇ−Ｐｏｉｎｔ Ｄｉｖｉｄｅｒｓ，ａｎｄ ａｎ ＭＰＥＧ−２ Ｄｅｃｏｄｅｒ）」，固体回路ＩＥＥＥジャーナルの１９９９年ＩＳＳＣＣ固体回路協会：デジタル、メモリおよび信号処理に関する特別号（ＩＥＥＥ Ｊｏｕｒｎａｌ ｏｆ Ｓｏｌｉｄ−Ｓｔａｔｅ Ｃｉｒｃｕｉｔｓ：Ｓｐｅｃｉａｌ Ｉｓｓｕｅ ｏｎ １９９９ ＩＳＳＣＣ：Ｄｉｇｉｔａｌ，Ｍｅｍｏｒｙ ａｎｄ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｉｎｇ）、１６０８、およびＥ．リンドルム（Ｌｉｎｄｈｏｌｍ，Ｅ）、Ｍ．Ｊ．キルガード（Ｋｉｌｇａｒｄ，Ｍ．Ｊ）、およびＨ．モレトン（Ｍｏｒｅｔｏｎ，Ｈ）著、２００１年、「ユーザ・プログラマブル頂点エンジン（Ａ Ｕｓｅｒ−Ｐｒｏｇｒａｍｍａｂｌｅ Ｖｅｒｔｅｘ Ｅｎｇｉｎｅ）」，２００１年ＳＩＧＧＲＡＰＨ議事録、エーシーエムプレス（ＡＣＭ Ｐｒｅｓｓ）／ＡＣＭ ＳＩＧＧＲＡＰＨ、コンピュータグラフィックス議事録、年次総会シリーズ、１４９〜１５８、ＩＳＢＮ１−５８１１３−２９２−１参照）、いくつかの基本的な特徴を共有する。この特徴に含まれるのは、以下のとおりである。
−ＣＰＵおよびＧＰＵが別個のプロセッサであり、比較的幅の狭いバスで接続されていること（なお、ＸＢＯＸは、統合メモリアーキテクチャを有してはいるが、ＧＰＵに対するバス帯域には制限がある）。
−ＧＰＵが、ユーザがプログラム可能であること（これは、任天堂のＧａｍｅＣｕｂｅにつては、厳密に言えば正確ではないが、所定の計算要素の組が豊富に利用可能である）。−プラットフォームはテクスチャ合成を支援するの様々なレベルを有しているが、すべてのテクスチャ合成は、ＧＰＵの次の段階として生じ、ＧＰＵまたはＣＰＵへのフィードバックはない（このようなフィードバックは可能であり、プラットフォームによっては、本発明のシェーダによって活用することもできるが、アートアセットコンパイル処理の外で管理されなければならない）。

これらの特徴を念頭に置いて、静的頂点の送信のバストラフィックの少なくとも３倍を要する読み出し／計算／書き込み／ＧＰＵに対する送信という形態のＣＰＵ動作を回避するのが望ましい。したがって、一実施例において、本発明は、幾何図形に対して、静的頂点およびトポロジーの利点を与える。また、本発明は、動画も支援しており、例えば、ＣＰＵを必要とせずに、多くの変形をＧＰＵや画素合成器に対して適用して、入力データを修正することができる。特に、本発明は、階層座標フレーム動画に完全に支援おり（例えば、Ｇ．スターン（Ｓｔｅｒｎ，Ｇ）著、１９８３年、「ビーボップ−−３次元キーフレームフィギュア動画（Ｂｂｏｐ−−３Ｄ Ｋｅｙｆｒａｍｅ Ｆｉｇｕｒｅ Ａｎｉｍａｔｉｏｎ）」、１９８３年ＳＩＧＧＲＡＰＨ用の「コンピュータ動画入門、講座解説７（Ｉｎｔｒｏｄｕｃｔｉｏｎ ｔｏ Ｃｏｍｐｕｔｅｒ Ａｎｉｍａｔｉｏｎ，Ｃｏｕｒｓｅ Ｎｏｔｅｓ ７ ｆｏｒ ＳＩＧＧＲＡＰＨ８３）」、２４０〜２４３参照）、任意の数の座標フレームを用いており、これには重み付けされたスキニングが含まれる（たとえば、Ｄ．テルゾポウロス（Ｔｅｒｚｏｐｏｕｌｏｓ，Ｄ）、Ｊ．プラット（Ｐｌａｔｔ，Ｊ）、Ａ．バー（Ｂａｒｒ，Ａ）、およびＫ．フライシャー（Ｆｌｅｉｓｃｈｅｒ，Ｋ）著、１９８７年、「伸縮自在に変形可能なモデル（Ｅｌａｓｔｉｃａｌｌｙ Ｄｅｆｏｒｍａｂｌｅ Ｍｏｄｅｌｓ）」、コンピュータグラフィックス（Ｃｏｍｐｕｔｅｒ Ｇｒａｐｈｉｃｓ）（１９８７年ＳＩＧＧＲＡＰＨ議事録）、第２１巻、２０５〜２１４およびＪ．ランダー（Ｌａｎｄｅｒ，Ｊ）著、１９９８年、「徹底的にスキニング（スキン・ゼム・ボーンズ）：ウェブ世代のゲームプログラミング（Ｓｋｉｎ Ｔｈｅｍ Ｂｏｎｅｓ：Ｇａｍｅ Ｐｒｏｇｒａｍｍｉｎｇ ｆｏｒ ｔｈｅ Ｗｅｂ Ｇｅｎｅｒａｔｉｏｎ）、ゲームデベロッパーマガジン（Ｇａｍｅ Ｄｅｖｅｌｏｐｅｒ Ｍａｇａｚｉｎｅ）、１１〜１６参照）。

（ランタイムＡＰＩ）
本発明のランタイム環境は、モデルを基本オブジェクトとして描くための例えば小規模Ｃ＋＋ＡＰＩのようなＡＰＩをユーザに提示する。モデルは、所定の効果を伴って描画するために必要なシェーダと結びつけた幾何図形の基本形状（例えば、三角形、ｂ−スプライン、点など）および状態オブジェクト（描画状態、テクスチャなど）の集合体である。モデルは、幾何図形にセグメント化され、各幾何図形は、それぞれ独立してオンまたはオフできる。幾何図形およびモデルは、コンパイラに入力されたアートアセットに直接マッピングされる。各一連のアートアセットコンパイラは、１つ以上の幾何図形を含む単一のモデルを生成する。モデルは、制御変数の組をユーザに公開する（下記の変数部を参照）。必要な制御変数を設定して、モデルのｖｅｒｂ＋Ｄｒａｗ＋メソッドを呼び出す。制御変数を設定することが必要なのは、システムがその値を保持しているうちにその値が変化した場合のみである。これは、動画および他の動的描画効果を制御するのに利用される機構である。

ＡＰＩは、好ましくは、ポリゴン描画呼び出しを公開しない。ユーザは、ＯｐｅｎＧＬのＧＬアレイ構成に類似したＡＰＩを用いて、手順を踏んでモデルを構成することができる。これらは、動的モデルと称され、本発明のコンパイルされたモデルよりも描画性能が悪い。

モデル描画とは別に、本発明は、描画のためのハードウェアの設定などのハウス・キーピング動作も管理する。本発明は、ハードウェア状態オブジェクトおよびテクスチャを操作するユーティリティ機能も提供する。なお、これらのオブジェクトは、コンパイルされたモデルに常駐するが、ユーザには公開されない。本発明は、ユーザに対して便利なように、オプションの視点およびカメラ抽象化も提供する。さらに、本発明は、公開された制御変数を介してモデルのインターフェイスとなる動画エンジンを提供する。

（描画メソッド）
描画メソッドは、変数一式の仕様と、これら変数を用いるシェーダプログラムとを含む。描画メソッドは、十分に抽象的なので、幅広いアートアセットに対して同じ描画メソッドを用いることができる。逆に、描画メソッドの中には、特定のアートアセットでの問題に対処するために書かれたものもある。本発明のコンパイラアーキテクチャにより、描画メソッドを、シェーダ入力変数を満足するのに必要なデータを有するいずれのアートアセットに対しても適用することができる。

図２は、ＰＳ２プラットフォームにおけるグローシェーディングを実施する簡易例を示す。

（型）
描画メソッドは任意の幾何図形データをシェーダに結合するために用いられるので、入力部および変数部の両方における変数は、タイプされている。これにより、シェーダに与えられたデータは必要な形式であることが保証される。型はユーザが拡張可能で、描画メソッド仕様で与えられている。型定義は、プラットフォームに固有であり、ＣＰＵメモリ内のオブジェクトのサイズ、ＧＰＵメモリ内のサイズ、型をＣＰＵからＧＰＵへ転送するのに必要なハードウェア状態などの特性を含む。型についての情報により、コンパイラは、アートアセットの要素を仮定に基づくことなく操作することができる。本発明は、一実施例において、すべてのプラットフォームに対して基礎となる型の同一の組を提供する。

（入力）
入力部は、描画メソッドに必要なデータ要素の型を宣言する。これらは入力変数と称される。この例では、座標入力変数は、Ｃｏｏｒｄｉｎａｔｅ４と宣言される。その後、この変数は、例えばコンバータまたは変数部のデータ画像を構築するために実行される他のデータ操作プログラムで参照することができる。入力宣言は、アートアセットがそのような入力を与えるものではない場合に用いられる変数に割り当てる明示値を伴うことができる。アートアセットからの入力データは、それぞれの入力変数に名前で結合される。コンパイラによって与えられた変数には、アートアセットからの頂点および素材データとともに、ユーザが頂点および素材に付与した任意のデータが含まれる。これにより、ユーザデータを描画メソッド入力に結合する簡易な名前付け表記法によって、コンパイラの機能を容易に拡張することができる。

（変数）
変数部は、計算に利用可能なデータを宣言する。変数は、アレイ仕様としての特定の型および多数の要素をタグ付けされる。アレイ仕様がない場合には、１の長さが想定される。簡易制約システムがハードウェアの制約内で要素の数を最大限にするには、特別のアレイ長ｎＥｌｅｍが有用である。

すべての変数（非アップロードキーワードによって一時的なものとしてタグ付けされたものを除く）は、入力部で宣言された入力から派生した値を有する。明示コンバータが＝Ｃｏｎｖｅｒｔｅｒ（ｐａｒａｍｅｓ，．．．）という構文を用いて指定される場合には、（ユーザが拡張可能なライブラリから動的にロードされた）コンバータ機能が、所定のパラメータと共に実行される。パラメータは、それ自身、変換機能の結果または入力変数である。明示的なコンバータの仕様がない場合には、単位コンバータが想定される。コンバータ機構により、データ要素のコンパイル時間操作を簡単に行うことができる。典型的な使用としては、データパッキング動作および様々な再インデックス化タスク、ならびに従法線ベクトル生成または色の釣り合いを取るなどの様々な前処理動作が含まれる。シェーダは、本発明のコンパイラを介してアートアセットと緊密に結合されているので、シェーダ固有の前処理は、好ましくはできるだけこれらのコンバータ内に移動して、様々なアセットおよびシェーダに対してアート変換処理ができるだけ均一であるようにするのがよい。

しかしながら、シェーダで用いられる変数のすべてが、コンパイラ処理によって利用可能になるわけではない。たとえば、変換マトリックスのようなデータはコンパイル時には利用可能ではない。これらは、暗黙変数として通信される。これにより、ユーザは、そのような変数の組を拡張するのに制約を受けることになる。一局面によれば、描画メソッド仕様は、外部リンク機構を介して拡張される。外部キーワードを変数宣言に追加すると共に、＝ｖａｒｉａｂｌｅ＿ｎａｍｅという名称の形式を割り当てることにより、ｖａｒｉａｂｌｅ＿ｎａｍｅという名の外部変数が参照される。図２の一例では、ランタイムは、Ｖｉｅｗｐｏｒｔ：ＸＦｏｒｍＰｒｏｊｅｃｔという名称の変数に対する未解決の参照を、この変数の実際のランタイムアドレスへのポインタに置き換える役割を担う。この外部参照は、アセットがロードされると解決される。アセットは、好ましくは、ＥＬＦフォーマット（例えば、ツールインターフェイス標準（Ｔｏｏｌ Ｉｎｔｅｒｆａｃｅ Ｓｔａｎｄａｒｄｓ）、１９９８年、「ＥＬＦ：実行可能かつリンク可能なフォーマット（ＥＬＦ：Ｅｘｅｃｕｔａｂｌｅ ａｎｄ ｌｉｎｋａｂｌｅ ｆｏｒｍａｔ）」，ｆｔｐ：／／ｆｔｐ．ｉｎｔｅｌ／ｐｕｂ／ｔｉｓ）で格納され、ＥＬＦ動的ローダを介して外部リンク機構を提供する。ライブラリは、多数の変数を動的ローダと共に登録しており、例えば変換マトリックスを描画メソッドで利用可能にする。ユーザは、また、ランタイムで、自身の変数を登録してもよい。

ＧＰＵ１２０およびＣＰＵ１１０は並行して動作してもよいので、外部にリンクされた変数のＣＰＵ上での変更によって、乱調状態となる場合がある。過度の固定制限を導入することなく乱調状態を取り除くには、そのような乱調を生じさせるようなデータ要素をコピーするのが望ましい。しかしながら、すべてのそのような変数データをコピーすると、オーバヘッドが必要となるので望ましくない。代わりに、本発明の一局面では、そのような乱調を引き起こすような要素であって一時的なキーワードを伴うものに、フラグが立てられる。ユーザは、キーワードを省略してもよく、コピーというよりはむしろ参照による使用となり、より効率的に実行できる。外部にリンクした変数上の一時的なキーワードを省略することは、通常危険を伴い、そのような変数に対する許可された修正を制御できなくなる。

この変数の別の重要な局面は、一般的に、ランタイムが不明瞭であることである。コンパイルされたアートアセット内部の変数を調査したり設定したりすることは可能でない。なぜならば、コンパイラは、データ要素を再順序付け、簡素化、またはそうでなければ隠してしまっているかもしれないからである。この制約は、描画効率を高めるものではあるが、十分に柔軟性があるとはいえないかもしれない。モデル内に格納されたデータを調査する必要性が頻繁にあるのは、描画メソッド内というよりはむしろＣＰＵ上である。多くの場合、外部変数とは異なり、アートアセットと共にかつその内部に常駐している制御変数をエクスポートするのが有用である。この場合、ユーザは、これらの変数の構築、登録、および管理をランタイムで行う必要がない。

変数は、宣言の前にキーワードエクスポートをつけることによって、描画メソッド内にて宣言およびエクスポートされる。エクスポートされたとして印付けされたデータをコンパイラが放出すると、変数に対するＥＬＦシンボル参照などの参照を、その名称と共に、各モデルに関連付けられた辞書に追加する。ランタイムでは、ユーザはモデル辞書に問い合わせて、特定の変数のアドレスを見つけることができる。これは、一般的に、同一名称の多数の変数に対して繰り返される。変数が同一の名称と２値画像とを共有している場合には、その変数の１つのバージョンのみが辞書に追加される。２値画像は異なるが名称が同じ場合には、同じ名称で両方とも追加される。これらの名称は同一の描画メソッドでコンパイルされた各パケットで生じているので、これらを区別するには何らかのシステムが必要である。

これらの変数をユーザが区別できるようにするためには、名称拡張機構が具備される。好ましくは、列変数が変数名内で参照されて、変数名をコンパイル時に拡張する。例えば、図２において、状態変数が列変数ｇｅｏｍｅｔｒｙ＿ｎａｍｅの内容で拡張されている。これらの状態変数は、他のいずれの入力と同一の機構を用いて通信され、コンパイラのフロントエンドで生成され、または素材または入力モデルに添付されたユーザデータ列である。この名称拡張機構を用いて、変数用のスコーピングシステムを実現することができる。コンパイラのフロントエンドは、Ｍｏｄｅｌ，Ｇｅｏｍｅｔｒｙ，およびパケットのレベルでスコーピングを提供する。ユーザは、元のオーサリングパッケージ内のアートアセットにタグ付けすることによって、スコーピングの追加レベルを容易に管理することができる。

エクスポートされた変数辞書は、エクスポートされた変数へのポインタを返すが、コンパイルされたデータ修正許可に関連するコストが生ずる。例えば、ＰＣ級のアーキテクチャ上では、頂点データは複製されて、ＣＰＵから効率的なアクセスができないがＧＰＵでは非常に高速であるメモリに入れられる。したがって、このデータに対してＣＰＵが修正を行うには、データを再びコピーする必要がある。このような性能コストを回避または減少するためには、一実施例における本発明では、ランタイムで要素が修正可能であるとい
う正式な宣言をし、修正可能なキーワードを用い、そのようにフラグ付けされていないデータの修正を禁止することが必要である。辞書は、変数の修正可能である状態を示すフラグを保持し、例えばＣ＋＋のｃｏｎｓｔメカニズムを用いて、修正に対して制限を行う。修正可能なフラグの使用は、一時的なフラグに対して直交する。これは、適切な場合（大きなデータ構造に対する頻度の低い変更）には、エクスポートされた修正可能なデータの参照による使用が可能であり、必要な場合（互いに異なるパラメータ設定で同一のフレーム内のモデルの再使用および頻度の高い変更）には、コピーによる使用が可能であるので、有用である。この修正機構は、パラメータ化された表示リストと同等で、コンパイラ内でオフラインで構築されかつ適切に最適化された機能性を提供する。

一局面によれば、エクスポートされた変数の辞書によって可能となった簡易の拡張機能は、エクスポートされた変数の遠隔閲覧および修正を行うランタイムＧＵＩツールである。これにより、アーティストまたはプログラマは、アートアセットを再コンパイルすることなく、モデルの外観や動きを微調整することができる。その結果、コンパイラは、このツールからの保管データを、同一のアートアセットまたは類似のレイアウトの別のアートアセットを後でコンパイルする際の入力とすることができる。

（計算）
新たなシェーダ言語を導入するよりはむしろ、本発明の一実施例においては、各対象のプラットフォーム上の固有のシェーディング言語およびマクロ拡張システムを用いて、変数をシェーダプログラムに結合する。描画メソッドをより簡単に書くには、複雑なシェーダを再利用可能なパラメータ化されたマクロに分解する。マクロは、外部ファイルで定義され、マシン固有のシェーダプログラムに連結およびアセンブルされる。パラメータの受け渡し規則は、変数および該当の型情報をマクロのパラメータに結合する。これにより、ユーザは、既存のプログラム断片を用いて、迅速に新しい効果を試験的に生み出すことができる。しかしながら、高度に最適化されたシェーダは、手作業によって作成されたシェーダプログラムが必要である。プラウドフット他またはピアーシー他のようなシェーダコンパイラは、このアーキテクチャにこのレベルで採用される。

（コンパイラのフロントエンド）
図１を再度参照して、アセットコンパイラのフロントエンド２０は、アートアセット１０および描画メソッド１５を取り込み、アートアセットを描画するのに必要な一連のパケット３０を構築する。一局面において、この例のフロントエンド２０は、ポリゴンからなるアートアセットに限って取り扱うが、本発明の教示を用いて、例えばスプライン面、粒子システム、特定用途向けの地形メッシュ、および特定用途向けの都市描画システムなどの他の種類のデータを取り扱うための他のフロントエンドを作成することも可能である。

コンパイラのフロントエンド２０は、アートアセット１０をアーティストが定義した幾何図形に分ける。各幾何図形内において、ポリゴンがこのましくは収集されて、素材および頂点特性によって分類される。

素材は、利用するアセット編集パッケージに固有であり、ユーザが定義した任意のデータおよび標準の予め定義された素材特性を含むことができる。一局面において、フロントエンドは、実際は同一である素材を識別して、それらをマージする役割も果たす。

頂点は、座標、テクスチャ座標、法線、および他の既知のものなどの特性を含むが、ユーザが定義した任意のデータを含むこともできる。

ポリゴンをクラスにグループ分けした後、コンパイラは、描画メソッドを選択して、各クラスに関連付ける。各クラスは、それぞれ名称が付された素材特性の組、名称が付され
たデータ要素の組を含む頂点の集合、および頂点からなるポリゴンの集合を含む。一実施例において、描画メソッドは、当該クラスで利用可能なデータによって満足することができる未定義の入力がある描画メソッドを見つけるまで、利用可能な描画メソッドのリストを繰り返すことによって選択される。より細かな制御を提供するためには、要求された描画メソッドで素材をタグ付けすることもできる。要求された描画メソッドの未定義の入力を利用可能なデータで満足させることができない場合には、デフォルトのメカニズムが適用され、警告が出される。

いったんクラスが描画メソッドに関連付けられれば、コンパイラは、当該クラスのデータから１以上のパケットを構築する。ある局面において、データを切断してより小さいパケットにすることは、ＧＰＵへ転送可能な数字データ要素を制限する恐れのあるハードウェア上の制約に基づく。例えば、あるプラットフォームでは、これはＧＰＵメモリのサイズに基づく厳しい制約であり、他のプラットフォームでは、試験的に定めた最良の効率点である。プラットフォームの中には、データのストリームおよび定数要素を区別する。これは、セグメント化計算に反映される。一旦構築されると、パケットは、パケットコンパイラ層に渡される。

クラス内のデータをパケットにパーティション化する処理は、基本となるポリゴンの効率的な描画のための三角形ストリッピングまたはメッシュ再順序付け（例えば、Ｈ．ホップ（Ｈｏｐｐｅ，Ｈ）著，１９９９年、「透明頂点キャッシングのためのメッシュ位置の最適化（Ｏｐｔｉｍｉｚａｔｉｏｎ ｏｆ Ｍｅｓｈ Ｌｏｃａｌｉｔｙ ｆｏｒ Ｔｒａｎｓｐａｒｅｎｔ Ｖｅｒｔｅｘ Ｃａｃｈｉｎｇ）」、１９９９年（８月）ＳＩＧＧＲＡＰＨ議事録、２６９〜２７６、ＩＳＢＮ０−２０１４８−５６００−５、カリフォルニア州ロサンゼルスにて開催）を含み、１以上のパケット内で現れなければならない頂点データのクローニングが必要な場合もある。

本発明のパケット化処理の第１のステップは、複数の座標フレームを頂点に関連付けることである。キャラクタ動画システムは、各頂点を、座標フレームの大きなセットのうちの１つに付属させることができる。その結果、これらの座標フレームは、動画の骨格を示す座標フレームのより小さなセットの一次結合から構築される。ＧＰＵ上のメモリの制約のため、各パケットに現れる固有の座標フレームの数は、好ましくは制限される。座標フレームのこのセットを、マトリックスパレットと称す。これにより、メッシュ最適化ステップを多次元最適化問題に変える、すなわち、ハードウェア上で要求される頂点変換の数と、生じたマトリックスパレットの数とを同時に最小化する。特定の三角形で断片を拡張することができないことがしばしばあるが、これは、パケットが必要とするマトリックスパレットが、パレットサイズを超えてしまうからである。

（パケットコンパイラ）
ランタイムで解釈されたパケットのリストの放出により、ランタイム性能が悪くなる場合がある。そのような方法を最適化するための２つの取り組みがある。第１の取り組みは、ランタイム環境を最適化して、ハードウェア状態の修正を最小限化したり、描画に対してテクスチャを用いて再順序付けをしたり、計算結果をキャッシングして再利用したりするといった方策を実行することである。しかしながら、描画すべきデータが事前にわかっているので、このような最適化の多くはオフラインで行われる。

パケットコンパイラは、フロントエンドで生成されたパケットを、アートアセットを描画するためにプログラマによる外部からの介在なしで実行できるデータおよび関連コードに変換する役割を担う。パケットコンパイラによって生成されたコードは、入力アートアセットを正確に描画することに特化した、最適化されたプログラムである。なお、パケットコンパイラは、トポロジーに関する情報は用いない。したがって、ポリゴンのデータセ
ットだけではなく、任意のデータセットをコンパイルするためにも利用できる。

出力形式は、互いに異なるプラットフォームによって完全に異なる場合がある。このような相違にもかかわらず、コンパイラのバックエンドに共通の構造がある。例えば、バックエンドは、以下のものを包含するモデルオブジェクトを常に生成する。すなわち、モデルを描画するために実行されなければならないバイトコードストリーム、モデルを表すパケットで用いた描画メソッドからエクスポートされたデータを示す辞書、およびロード時に解釈されてポインタとなるインポートデータに対する外部参照である。これらはバイトコード内またはハードウェアに固有のデータ構造内で生じる場合がある。さらに、バイトコードは、描画に必要な情報を包含した、ハードウェアに固有のデータ構造への参照を包含する。

各プラットフォームでは、生成されたバイトコードおよびデータ構造に対して、ハードウェアに固有の最適化が描画速度に関して行われる。これらの最適化が依拠する知見とは、モデルの描画はアトミック動作として扱うことが可能であり、したがって、ハードウェアの状態は、モデルの描画においてハードウェアに送られた各パケット間で完全に制御されるというものである。

一実施例において、バックエンドは、以下のようないくつかのパスで動作するように構成される。

パス１：パケットの順序付け
パス２：変数データの構築
パス３：蓄積データのエクスポート
パス６：データ構造の生成
パス５：コードの生成
パス６：データ構造およびコードの一括最適化
パス７：コードおよびデータの放出
（パス１―パケットの順序付け）
基本となるハードウェアを効率的に利用するには、パケットに対して再順序付けを行って、ハードウェアの状態についてのコストの多大な変更を最小限にする。最順序付けにより、ユーザは、描画順序に対する制御を保持することができる。特に、モデルの幾何図形がアートアセットで現れる順番で描画されることが保証される。一実施例では、簡易な発見法が実施されて、コストの多大な状態変更を最小限にしている。パケットはまず幾何図形毎にグループ化され、その後、描画メソッド、テクスチャ、そして最後にマトリックスパレットによってグループ化される。一局面では、例えば、より高性能のコンパイラが生成されたコードストリームを調査して、その動作のコストをモデリングし、最良のデータ順序付けを決定する。

（パス２―変数データの構築）
フロントエンドは、パケットとのリストを提供し、各パケットは、関連付けられた描画メソッドと、入力データのセットとを有する。入力データは、最終的にシェーダに与えられるもののようにはなっていないので、パケットに関連付けられた描画メソッドの変数部に定義されたデータに変換されなければならない。これは、描画メソッドによって特定されたコンバータ機能を実行することによって達成される。結果生じるのは、インスタンス化されたパケットである。インスタンス化されたパケットにおいては、各変数のデータが既知か、またはランタイムで当該データのメモリ位置がわかる外部の記号参照が既知である。参照は、ハードデータとして完全に既知のデータ内容を有する変数のために作成される。外部宣言（インポートされたデータ）によって定義されるだけの変数は、ソフトデータと称される。この段階で、コンパイラは、記号名をすべての変数データに割り当てる。
このような記号名は、データを包含するメモリ位置を参照するために用いられ、データの直接の参照を生成しなければならない場合にはいつでも、残りのパス内に作成される。ソフトデータの場合は、記号名は、描画メソッド内の外部宣言によって定義された名称を用いる。

一局面では、この時点で、記号名がデータの各ブロックに割り当てられたが、データ自体は、放出もされていないし、特定のデータ構造内に置かれたりもしていない。これは、好ましくは、後のパスにおいて行われる。

（パス３―蓄積データのエクスポート）
このパスは、ランタイムで利用可能なモデルに関連付けられた辞書データ構造を蓄積して、エクスポートされた変数を見つける。前のパスでデータに割り当てられた記号名はここで用いられて、結果生じた辞書内に充填される。

（パス４―データ構造の生成）
このパスでは、インスタンス化されたパケットによって参照されるハードおよびソフトデータを保持する描画データ構造を作成する。対処となるプラットフォームの多くにおいて、基礎となる描画ハードウェアをできる限り直接与えるのが望ましい。これにより、有利なことに、デバイスドライバのオーバヘッドおよびデータの不必要な操作を回避することができる。これは、データ構造をできるだけ元の形式のままで構築することによって達成される。

たとえば、ＰＳ２プラットフォームにおいては、連鎖ダイレクト・メモリ・アクセス（ＤＭＡ）が、ＣＰＵの動作と並行して、ＧＰＵに対してデータを与える。ＤＭＡ部は、手続呼び出しに大変よく似た、入れ子状のＣＡＬＬ構造を支援している。これにより、ＤＭＡ鎖の多数の断片を、ＤＭＡ鎖に埋め込まれた描画データで前もって構築しておくことができる。この利点としては、これらの予めアセンブルされたＤＭＡ断片内のデータをＣＰＵは触れる必要が全くなく、描画時にＣＡＬＬ動作をＤＭＡ断片につなげるだけである。他の利点としては、データの余分のコピーを必要としないので、モデル送信に必要なメモリオーバヘッドが減少する。

ＧａｍｅＣｕｂｅプラットフォームにおいては、ハードウェアに直接与えられる同様のデータ構造が構築される。ＸＢＯＸおよびＰＣプラットフォームにおいては、頂点バッファおよびハードウェアコマンドストリームが、事前にアセンブルされる。

（パス５―コードの生成）
コード生成パスにおいて、パケットに包含されるデータを描画するのに必要なＣＰＵ動作のセットを行うインスタンス化された各パケットに対して、バイトコードプログラムが生成される。次のパスにおいて、バイトコードプログラムは連結されて、一括最適化が、結果のプログラムに対して行われる。

バイトコードは、好ましくは、固有のアセンブリ命令というよりもむしろ、これらのプログラムを表すために用いられる。バイトコードを解釈する際のオーバヘッドは最小で、バイトコードインタプリタがＣＰＵ上の命令キャッシュにｋ適合するという事実によって、相殺される。ハードウェアによっては、バイトコード解釈がインラインの機械命令のストリームを実行するよりも早いものもある。これは、命令キャッシュミスおよび手続呼び出しの減少によるものである。さらに、バイトコードは２つの主な利点を有する。第１に、バイトコードのプログラムは非常に小型である。第２に、本発明のバイトコードの命令セットはとても小さい（例えば、プラットフォームに基づいて、１０〜２０の命令）ので、バイトコードのためのオプティマイザを書き込むのが容易である。

プラットフォームの命令セットは、基礎となるハードウェアに依存する。例えば、ＰＳ２プラットフォームにおいては、単一のＤＭＡ鎖が、場面全体の描画の符号化を行うハードウェアに送られる。このハードウェア上のバイトコード命令は、このＤＭＡ鎖をアセンブルすることを目的とした単純な動作を行うとともに、ＣＰＵを多用してＤＭＡ鎖において必要なデータを生成する何らかの動作をも行う。前者の動作の例としては、ＤＭＡデータの固定された一定のまとまりを鎖に呼び出す動作、および一時的なデータをコ鎖にピーする動作などがある。後者の例としては、新規の頂点シェーダプログラムをハードウエアにアップロードする動作、および動いているオブジェクトのマトリックスパレットセットを動画データから計算する動作などがある。コンパイラおよびハードウェア間のＡＰＩのものをさらに有するプラットフォームにおいては、バイトコードは基礎となる描画ＡＰＩへの呼び出しに緊密に対応しており、例えば、頂点ストリーム設定、状態設定呼び出し、および描画送信命令などがある。

（パス６―一括最適化）
このパスにおいて行われる特定の最適化は、対象となるプラットフォームの性質に依存する。このような最適化は、２つの種類、すなわち、データ転送最適化および冗長コード除去である。

データ転送最適化を行う際には、ＧＰＵへのデータの冗長な転送を序今日するのが望ましい。これは、冗長コード除去の非常に特別な例である。これは、一実施例において、モデル描画実行中にＧＰＵメモリの内容をシミュレートして、メモリ画像を変更しないアップロードを確認することによって行われる。例えば、この最適化ステップは、変換マトリックスの冗長設定をあるパケットから次のパケットへ除去する。

ＧＰＵの実行を詳細にはシミュレートしておらず、データのＧＰＵへのアップロードだけなので、ＧＰＵがいつメモリ位置の内容を修正するであろうことを伝える示唆が与えられ、アップロードが当該位置に置かれるようになる。描画メソッドにタグ付けするためのオプィマイザへの示唆としての２つのキーワードには、ｎｏｕｐｌｏａｄおよびｔｒａｎｓｉｅｎｔが含まれる。ｎｏｕｐｌｏａｄキーワードは、変数がＧＰＵによって必要に応じて用いられる一時的な変数であることを示す。ｔｒａｎｓｉｅｎｔキーワードは、シェーダプログラムの前に設定しなければならない変数はｒｕｎであるが、シェーダプログラムの実行によって修正されることを示す。

データアップロード最適化とともに、マシンのレジスタ設定命令およびバイトコード命令について同様の最適化を行うが望ましい。例えば、ＰＳ２プラットフォームにおいて重要なのは、バイトコード内にＣＡＬＬ命令だけを有して生じかつＤＭＡ鎖をパケットのためにマージする連続パケットである。

他の例としては、ＰＳ２プラットフォームにおいて、データ転送機構が、それ自体データがＧＰＵに与えられると復号するように適切に設定されていなければならない状態マシンである場合である。この場合には、データ転送ハードウェアはシミュレートされて、データ転送ハードウェアを所望の状態に設定するのに必要最低限のレジスタ変更のセットを求める。これにより、ＰＳ２において、描画時間を２０％も減少することができる。

他の多くの特定の最適化が、当業者にとって明らかな様々な対応プラットフォーム上で用いられる。

図３ａ，３ｂ，３ｃは、本発明のシステムの性能値を示し、毎秒のポリゴンおよび毎秒送信される頂点インデックスの単位は１００万である。選手像は、３９９８のポリゴンモ
デルであり、テクスチャまたはライティングなし、テクスチャおよびライティングあり、およびテクスチャおよびライティングありでスキニングされて描かれた。ウサギのモデルは、６９４５１個のポリゴンを含む（ウサギのモデルはスタンフォード・コンピュータ・グラフィックス・ラボラトリ（Ｓｔａｎｆｏｒｄ Ｃｏｍｐｕｔｅｒ Ｇｒａｐｈｉｃｓ
Ｌａｂｏｒａｔｏｒｙ）提供。ＰＣは、ＡＴＩラデオン（Ｒａｄｅｏｎ）８５００グラフィックスアクセレレータを用いた１．４ＧＨｘｚのＡＭＤアスロン（Ａｔｈｌｏｎ）である）。

図４は、本発明に係るシステムを用いたＰＳ２アプリケーションの画像取り込みを示し、キャラクタ、ライティングされたスタジアム、およびカスタマイズされた群集描画器のためのスキニングを示しており、これらは描画メソッドして実施される。

図５は、本発明に係るシステムを用いた他の場面を示し、ユーザが開発した代わりのコンパイラのフロントエンドおよび粒子システムによって生成された都市風景を示す。

図３ａは、本発明に係るシステムによって達成された典型的な性能値の概要を示す。この数値は、アートアセット生成のために持続可能なスループット比である。比較のため、スタンフォードのウサギモデルについての数値も含まれている。ＣＰＵは、この例ではおおむねアイドル状態であり、ＣＰＵの対話型アプリケーションの利用を考慮して必要となる。これらのシステムにおける障害は、通常ＧＰＵへのバスならびに変換およびラスタライズエンジン内にある。場合によっては、ＣＰＵの集中利用によって良好な性能地を得ることができるが、これは、必要な利用形態を表すものではない。本発明のシステムによって達成される性能は、それに置き換わるものとされるカスタマイズされた描画エンジンよりも、スループットに関しては同等またはより良好、ＣＰＵでの利用の場合にはさらに良好である。

システムは、新規で異なるアーキテクチャを簡単に移植することを示した。本発明を利用する製品を、あるプラットフォームから別のものに移植するのは簡単であった。たった１週間というターンアラウンドタイムが、全製品について達成された。より一般的には、製品の移植には約１ヶ月かかり、プラットフォーム性能の差を考慮してアートアセットに対する必要な変更を行うことを含む。

また、ユーザが自身の描画メソッドを書くことによって、システムの機能性を大幅に拡張するできるので、この描画メソッド例はうまくいくことがわかった。これには、（図４に示す）群集描画システムおよび多数の粒子システム（一例を図５に示す）のような特徴、ならびに特別のマルチテクスチャおよびマルチパス効果をも含んでいた。

さらに、コンパイラのフロントエンドの意味規則が、ユーザの要請を支援するには十分でない場合には、本発明の教示を利用して新たなフロントエンドを開発してもよい。たとえば、新たなフロントエンドを開発して、うまくいった。例えば、図５に示す都市風景は、貴下データの重要な部分を共有する多数のオブジェクトを包含している。このデータをモデルで共有できるように、外部にリンクされた変数に与えられたフックを用いて、カスタマイズされたフロントエンドを書いた。

本願明細書に含まれるすべての引例は、その内容全体を本願明細書に引用したものとする。

本願のすべてまたは一部を実施するためのコードは、ＣＤ、ＤＶＤ、またはフロッピー（登録商標）媒体ディスクなどのコンピュータが読み取り可能な媒体上に格納または提供して頒布することができる。そのようなコードは、プラットフォームの知能（例えば、Ｃ
ＰＵ１１０および／またはＧＰＵ１２０）を制御するための命令を含み、本願明細書で教示したコンパイルの局面および描画の局面を含む本発明の様々な特徴および局面のいくつかまたは全体を実施する。

例示的に具体的な実施例で本発明を説明したきたが、本発明は、開示された実施例に限定されるものではないことが理解されるべきである。逆に、上記検討されたものに加えて、当業者にとって明らかな様々な変形や同様の仕組みを含むことが意図されている。したがって、添付の請求項の範囲は、すべてのそのような変形や同様の仕組みを包含するように、最も広い解釈に従うものとされなければならない。

図１は、本発明の一実施例に係るコンパイラを含むシステムの実施例を示す。 図２は、ＰＳ２上でのグローシェーディングを実施する簡易例を示す。 図３ａは、本発明の性能値を示し、毎秒のポリゴンおよび毎秒送信される頂点インデックスの単位は１００万であり、図３ａは、本発明に係るシステムによって達成される典型的ないくつかの性能数値の概要を示す。 図３ｂは、本発明の性能値を示し、毎秒のポリゴンおよび毎秒送信される頂点インデックスの単位は１００万である。 図３ｃは、本発明の性能値を示し、毎秒のポリゴンおよび毎秒送信される頂点インデックスの単位は１００万である。 図４は、本発明に係るシステムを用いたＰＳ２アプリケーションの画像取り込みを示し、キャラクタ、ライティングされたスタジアム、およびカスタマイズされた群集描画装置のスキニングを示しており、これらは描画メソッドして実施される。 図５は、本発明に係るシステムを用いた他の場面を示し、代わりのコンパイラのフロントエンドおよび粒子システムによって生成された都市風景を示す。 図６は、本発明が有用な、典型的なハードウェアプラットフォームを示す。

Claims (1)

1. アートアセットをランタイムでコンピュータにおいて描画するための最適化されたコードを生成する方法であって、
   アートアセットと、アートアセットに関連付けられた１つ以上の描画メソッドとを、コンパイラのフロントエンドに提供することと、
   アートアセットの断片と、１つ以上の描画メソッドのうちの１つに対する個別の呼び出しとをそれぞれ表す１つ以上のパケットをコンパイラのフロントエンドで生成することと、
   最適化されたコードと、データストリームとを、コンパイラのバックエンドで生成することとを含み、最適化されたコードおよびデータストリームは、アートアセットをランタイムでディスプレイに描画するために用いられる、方法。

Images