クイックドロー3D

QuickDraw 3D（略してQD3D ）は、 1995年にApple Inc. （当時はApple Computer, Inc.）が開発した3Dグラフィックス APIで、も​​ともとはMacintoshコンピュータ向けに開発されたが、クロスプラットフォームシステムとして提供された。^[1]

QD3Dは2つのレイヤーに分かれていました。RAVE（Rendering Acceleration Virtual Engine）と呼ばれる低レベルのシステムは、Direct3DやMiniGLのようなOpenGLの簡易版に似た機能を持つハードウェア抽象化レイヤーを提供しました。その上に、オブジェクト指向のシーングラフシステムであるQD3Dがあり、 OpenGL++と同様のレベルでモデルの読み込みと操作を処理しました。^[2]このシステムは、ファイル形式変換用の高レベルユーティリティと、Mac OS用の標準ビューアアプリケーションも提供しました。

QD3D は、1990 年代半ばの Apple の苦境と、3D ハードウェア市場の将来的な変化について設計チームが下したいくつかの重大な決定が実現しなかったことの両方の結果として、コンピュータ市場にほとんど影響を与えませんでした。Apple は、 1998 年にSteve Jobsが引き継いだ後、QD3D の作業を放棄し、Mac OS での将来の 3D サポートはOpenGLに基づくと発表しました。

1990 年代の標準的な 3D API は OpenGL でした。これはSGIによって作成され、当初はハードウェア抽象化レイヤーとして動作し、ワークステーションシステムの機能にほぼ一致していました。OpenGL API は、ペイントの色やカメラの位置などの描画モードを設定するための状態設定命令と、通常は三角形のメッシュとしてジオメトリをシステムに送信するシステムから主に構成されていました。これらの命令の組み合わせはディスプレイ リストに保存され、その後レンダリングされて出力が生成されました。

OpenGL には、完全な 3D プログラムを作成するために必要な多くの機能が欠けていました。ジオメトリ データの保存と読み込み、そのデータのグループへの収集によるモデル オブジェクトの作成、状態の制御はすべてプログラマーに任されていました。パフォーマンスが制限されていた時代には、これは利点であると考えられており、こうした種類の機能を直接制御することがパフォーマンス向上の手段でした。

しかし、この高レベル機能の欠如により、単純なプログラムを素早く書くことが難しくなり、相互運用性も欠如するようになりました。OpenGL++ や (後の) Fahrenheitなど、ファイルからジオメトリをロードしてディスプレイを提供するなど、より一般的な簿記タスクの多くを処理する、標準化された高レベル API を提供するための取り組みがいくつか開始されました。これらの標準化されたシーン グラフシステムにより、プログラマーはプログラムの GUI を提供するだけで済みました。

OpenGL は主に低レベルですが、実際には SGI システムでのみ使用される高レベルの概念もいくつか含まれています。このため、一般的なハードウェアで実装しやすくするためにこれらの機能を削除した別の一連の API が生まれました。これらの中で最もよく知られているのはMiniGLです。これは独立した API ではなく、すべてのハードウェアでサポートされることが保証されている OpenGL の関数のリストに過ぎず、そのため、これらの呼び出しに限定されたプログラムが最大のパフォーマンスで実行されることが保証されます。

QD3D は、ワークステーションよりもかなり低消費電力のコンピュータで動作するように最初から設計されました。このため、API の上位層と下位層をきれいに分離する共同作業が行われ、下位層の RAVE システムは最初から MiniGL に近いものになりました。これにより、異なるハードウェアに簡単に移植できる、クリーンで最小限の API を提供できるという利点がありました。

RAVE のみを移植すればよかったため、上位層の API は必要に応じて複雑にすることができ、QD3D システムには完全なシーン グラフ、標準化されたモデル ファイル形式、3DMF、さらにはそれらを利用する基本的な GUI オブジェクトも含まれていました。QD3D で簡単なアプリケーションを書くには、プログラマーはいくつかのライブラリを組み込み、ResEditなどのツールを使用してプログラムに GUI 要素を配置するだけで済みました。

追加機能には「プラグイン」レンダリング システムがあり、アプリケーションはさまざまなスタイルでシーンをレンダリングできます。開発者はモデルやコードを変更することなく、同じシーンをインタラクティブにレンダリングしたり、適切なプラグインを使用してレイ トレーシングやフォン シェーディングなどの方法を使用してレンダリングしたりできます。

QD3D API は、純粋なCコードに基づくオブジェクトのようなシステムでした。さまざまな構造体は、他の重要なオブジェクトへのポインターを含むように注意深く構築されました。オブジェクトは必要な描画状態をすべて認識しているため、OpenGL で開発するときに通常必要となるコードが不要になりました。

欠点としては、QD3D のレイヤー化によってパフォーマンスの問題が生じました。たとえば、システムは描画前にすべてのオブジェクトの状態を保存し、自動的に設定しました。これにより開発ははるかに簡単になりましたが、開発者が直接制御できない方法でパフォーマンスが低下しました。プログラミングの容易さよりもパフォーマンスを重視するアプリケーションでは、代わりに RAVE レイヤーを直接使用することもできます。

もう 1 つの懸念事項は、シーン グラフがビューから隠されていることです。グラフを注意深く「カリング」してビューにないオブジェクトを削除することで、レンダリング パフォーマンスを大幅に向上できます。QD3D の後のリリースでは、シーン グラフ内のオブジェクトのグループ化に基づいて可視性カリングを自動的に実行する機能が追加されましたが、OpenGL ではこの機能がサポートされていないため、通常、開発者は最初からこの機能を実装する必要がありました。

低レベルの 3D パフォーマンスを良好にするには、プログラマーが効率的なモデルを提供するだけでなく、ハードウェア用の高品質のドライバーも必要です。RAVE はクロスプラットフォームとして設計されていましたが、Mac をサポートするハードウェア開発者 ( ATI、NVIDIA、3dfx ) のみが RAVE 用のドライバーを作成しました。このため、QD3D と代替 API の比較は一方的なものとなり、Mac 以外では QD3D はソフトウェア RAVE 実装にフォールバックせざるを得ませんでした。

OpenGL が Windows 上で普及するにつれ ( D3D よりも API を擁護したid Softwareの功績とされることが多い)、ハードウェア開発者は Microsoft の D3D 用に計画された将来の機能セットを基準に将来のハードウェアを設計するようになりました。OpenGL は拡張メカニズムを通じてこれらの変更を比較的簡単に追跡できましたが、RAVE の機能セットは比較的固定されたままでした。

1999 年 1 月のMacworld Expoで、Apple は QuickDraw 3D も RAVE もMac OS Xには含まれないことを発表しました。同社は 1999 年 6 月に開発スタッフを解雇し^[要出典]、Conix Enterprises から Mac 実装と主要スタッフを購入した後、社内技術を OpenGL に置き換えました。

AppleがQD3Dのサポートを撤回した後、QD3D APIのオープンソース実装が外部で開発されました。Quesaとして知られるこの実装は、QD3Dの高レベルの概念とOpenGLレンダラーを組み合わせたものです。このライブラリは、クロスプラットフォームのハードウェアアクセラレーションだけでなく、Appleがサポートしたことのないプラットフォーム（Linuxなど）でもQD3D APIを使用することもできます。最新のアップデートは2023年のものです。^[3]

RAVE を採用して公開されている数百のアプリケーションの中には、次のようなものがあります。

• 1990年代のグラフ電卓。すべてのPower Macintoshに同梱されていた。
• 地震
• ディセント II
• アンリアル
• カーマゲドン2
• 未来の警官：LAPD
• ウォーターレース
• ストラタビジョン3D
• インフィニD
• バグダム

• クイックドロー
• オープンGL
• ダイレクトX
• 3dfx

• QuickDraw 3D 1.5.4 を使用した 3D グラフィックス プログラミング — QD3D マニュアル (アーカイブ)
• QuickDraw 3D: Macintosh グラフィックスの新しい次元 — プレリリース記事、1995 年 6 月
• QuickDraw 3D: 質問と回答
• Quesaプロジェクトのホームページ
• Pomme プロジェクトのホームページ — Pangea Software のゲームを最新のプラットフォームに移植するために使用される Quesa フォーク。