Javaでの3Dグラフィックプログラミング、パート3:OpenGL

Javaでの3Dグラフィックスプログラミングに関するこのシリーズの前回の記事からしばらく経ちました(これについては、このコラムの最後で詳しく説明します)。これが、私たちが最後に話し合ったことと、中断したところについての簡単な復習です。

前の2つの列(「参考文献」を参照)では、Java3Dについて説明しました。静的コンテンツと小さなシーンについて説明した後、大きなシーングラフを使用して、いくつかの基本的な3Dワールドにインタラクティブ機能を組み込みました。

Java 3Dの使用について少し理解したところで、3DグラフィックスへのJava 3Dアプローチを、主要なグラフィックスAPIの候補であるOpenGLと比較対照します。

この記事はもともとコードを多用することを目的としていましたが、Magicianバインディング(以下を参照)に関するArcane Technologiesによる最新の決定により、コード例を削除する必要があったことに注意してください。この記事の内容が、OpenGLコンソーシアムからまだ入手できない将来のJava-OpenGLバインディングに適合できることを願っています。

いずれにせよ、私はこのコラムの最後にある「参考文献」に、関連性のある有用なOpenGL関連の参照とURLをすべて提供するように努めました。Java-OpenGLをさらに掘り下げたい場合は、これらのリファレンスを確認することを強くお勧めします。

Java-OpenGLとJava3Dの比較

Java 3Dに関する以前の記事では、グラフィックスアプリケーションにJava3Dを使用することの長所と短所のリストを提供しました。そのリストを繰り返してみましょうが、Java3DベースのソリューションではなくJava-OpenGLベースのソリューションの長所と短所を見てください。

OpenGLを使用することの強み(および、拡張により、特にJava-OpenGLバインディング):

  • OpenGLは、グラフィックの手続き型モデルを提供します

    これは、グラフィックプログラマーがこれまで使用してきたアルゴリズムや方法の多くと密接に一致しています。手続き型モデルは、多くの熟練した3Dグラフィックス愛好家にとって、直感的でわかりやすいものです。

  • OpenGLは、レンダリングパイプラインへの直接アクセスを提供します

    これは、ほとんどのJavaバインディングを含む、さまざまな言語バインディングのいずれにも当てはまります。OpenGLを使用すると、プログラマーはグラフィックのレンダリング方法を直接指定できます。Java 3Dのようにヒントを与え要求するだけでなく、規定します。

  • OpenGLは考えられるあらゆる方法で最適化されています

    OpenGLは、ハードウェアとソフトウェア、および最も安価なPCやゲームコンソールから最もハイエンドのグラフィックススーパーコンピューターに至るまでの対象プラットフォームで最適化されています。

  • あらゆる種類の3Dグラフィックス関連ハードウェアのベンダーがOpenGLをサポートしています

    OpenGLは

    インクルード

    ハードウェアベンダーがグラフィックステクノロジーを測定する基準。Microsoftが華氏イニシアチブでSGIに参加するにつれて、これが事実上、OpenGLが2Dおよび3DグラフィックスのAPI戦争に勝ったというMicrosoftの間接的な承認であることが多くの人に明らかになりました。

一方で、完璧なものはありません。OpenGL、そして確かにJava-OpenGLバインディングには、いくつかの重大な欠点があります。

  • グラフィックプログラミングへの手続き型アプローチの長所は、同時に多くのJavaプログラマーにとっての短所です。

    オブジェクト指向の方法論を使用してJavaで最初の正式なプログラミング命令を受け取った可能性のある比較的新しいプログラマーにとって、OpenGLの手続き型メソッドは、オブジェクト指向のアプローチや優れたエンジニアリング手法とうまく調和していません。

  • 多くのベンダーのOpenGL最適化は、ハードウェアの選択を減らすことを目的としています

    独自の拡張機能を構築し、独自の最適化を行って独自のハードウェアをより多く販売することは、各ベンダーの最大の利益になります。すべてのハードウェア最適化と同様に、1つのプラットフォームの各最適化が他のいくつかのプラットフォームの移植性とパフォーマンスを低下させることを理解した上で、アクセラレータ固有のOpenGL最適化を使用する必要があります。Java 3Dのより汎用的な最適化は、主にJava3Dアプリケーションの移植性を最大化することを目的としています。

  • OpenGLへのCインターフェースは至る所にありますが、Javaインターフェースはまだ標準化されておらず、広く利用可能ではありません。

    Arcane TechnologiesのMagician製品は、最近までこの移植性の問題を変えるために市場に出回っていましたが、その終焉とともに、少なくとも現時点では、Java-OpenGLのクロスプラットフォームの話の多くが進んでいます。これについては、以下で詳しく説明します。

  • OpenGLがレンダリングプロセスの内部の詳細を公開すると、単純な3Dグラフィックプログラムが大幅に複雑になる可能性があります。

    パワーと柔軟性は複雑さを犠牲にしてもたらされます。今日のテクノロジーの世界の急速な開発サイクルでは、複雑さ自体が可能な限り回避されるべきものです。バグに関する古い格言は真実です。コード行が多いほど、(一般的に)バグも多くなります。

OpenGLベースのアプローチの長所と短所からわかるように、Java-OpenGLは、Java3Dが弱い多くの分野で強力です。OpenGLは、Java 3Dが明示的に回避するレンダリングプロセスへの低レベルのアクセスをプログラマーに提供します。OpenGLは現在、Java 3Dよりもはるかに多くのプラットフォームで利用できます(Magicianは別として)。しかし、この柔軟性には潜在的な代償が伴います。プログラマーには最適化する余地がたくさんあります。つまり、逆に、物事を台無しにする余地がたくさんあるということです。Java 3Dには、より多くの組み込みの最適化とより簡単なプログラミングモデルがあり、Java、3Dグラフィックス作業、またはネットワーク化され分散されたグラフィックスプログラミングに不慣れなプログラマーにとって特に便利です。