<HEAD>
<TITLE>OpenGL...</TITLE>
</HEAD>

<BODY BACKGROUND="../Image/Back2.GIF"
	TEXT="#E0E0E0"
	BGCOLOR="#191919"
	LINK="#90D0FF"
	VLINK="#4080D0"
	ALINK="#0000FF">

<BASEFONT SIZE="3" FACE="ＭＳ Ｐ明朝">

<BR>
<CENTER>
<FONT SIZE="7" COLOR="80FF80"><I>OpenGL...</I></FONT>
<P>
<P>
</CENTER>

<CENTER>
<IMG SRC="../Image/Bar2.gif" ALT "-------------------------------------------" width=100% height="8">
</CENTER>
<P>

<P>
<DL>
<DT>
<FONT SIZE="3" COLOR="#FFFF80"><B><I>98/06/17（水）　</I></B></FONT>
<FONT SIZE="4"><B>− OpenGL... − OpenGL に欲しい機能など</B></FONT>
<P>
<DD>
　<FONT COLOR ="#FF9090">OpenGL</FONT>は、実質3DCGの標準と言えるAPIである。
そして、その機能は<FONT COLOR ="#FF9090">CAD/CAM</FONT>向きで
極めて高性能などと言われている。
確かに高性能ではある。
しかし、その仕様は、<FONT COLOR ="#FF9090">洗練されるまでAPIに追加されない</FONT>。
OpenGLは、<FONT COLOR ="#FF9090">ARB（Architecture Review Board）</FONT>と
呼ばれる委員会が新しい機能の提案や承認、新規リリースの承認、
適合性テストなどを行っている。
ARBメンバは<FONT COLOR ="#FF9090">複数の企業</FONT>から公平に成り立っているため、
Direct3Dのように、Microsoft一社のみの意向で
簡単に仕様の変更／追加がなされることがないのである。
そのため、<FONT COLOR ="#FF9090">Direct3Dで実装されつつあるような新しい機能</FONT>はもっていない。
<BR>
　逆に、Direct3Dはどんどん新しいバージョンがリリースされている。
そして、特にゲームで利用価値が高くなるような、つまり、
<FONT COLOR ="#FF9090">「速度をあまり低下させずに
画質の向上を目指す」</FONT>ことに関しては、
力の入れ方が違うのをひしひしと感じる。
とにかく使えそうな機能はどんどん追加するわけだ。
近い内にリリースされるDirectX6も、興味深い新機能がメジロ押しである。
もちろん、APIはその都度複雑になり、ごちゃごちゃになり、
わけわかめ状態になるという欠点があるのは事実なため、
手放しで喜べる訳でもないのだが。
<BR>
　私は、今はOpenGLを使っている。
そうなると、
<FONT COLOR ="#FF9090">Direct3Dで使えるがOpenGLでは使えない機能</FONT>
が気になってくる。
ここで、Direct3Dにあるかどうかは別として、私が極めて私的に
<FONT COLOR ="#FF9090">OpenGLに欲しいと思っている機能</FONT>についてまとめよう。
<P>
<FONT COLOR ="#FF90FF">
●各行列での頂点変換（ジオメトリ演算）の有効／無効スイッチ。
</FONT>
<BR>
　つまりは、Direct3Dのような頂点形式の選択である。
OpenGLでは、<FONT COLOR ="#FF9090">全ての描画にはジオメトリ演算が付きまとう。
たとえ二次元の描画でもだ。</FONT>
Direct3Dのように、ジオメトリ演算は自分のプログラムで行うといった
ことはできないため、二次元だろうが三次元だろうが無関係に、
描画にはジオメトリ演算が付きまとうのである。
無用な演算は速度の低下を招く。
<BR>
　そこで、<FONT COLOR ="#FF9090">
各行列の頂点への演算処理の適用の ON／OFF を選択する
機能</FONT>が是非欲しいところなのである。
<P>
<FONT COLOR ="#FF90FF">
●屈折マッピングおよび法線環境マッピング
</FONT>
<BR>
　OpenGLには、<FONT COLOR ="#FF9090">
動的にテクスチャ座標を生成してくれる機能</FONT>がある。
この機能に、<FONT COLOR ="#FF9090">
屈折マッピングおよび法線環境マッピング</FONT>が欲しいのである。
<BR>
<FONT COLOR ="#FF9090">
　屈折マッピング</FONT>は前に少し書いたように、
基本的には環境マッピングと同じような考え方である。
ただ、<FONT COLOR ="#FF9090">
視線ベクトルを頂点表面で反射させるのではなく、屈折させる方法</FONT>である。
<BR>
　さて、<FONT COLOR ="#FF9090">法線環境マッピング</FONT>とは、
ここで私が勝手に言っている言葉である。
だいたいは環境マッピングと同じ方法なのだが、
<FONT COLOR ="#FF9090">
反射した視線ベクトルからテクスチャ座標を計算するのではなく、
法線ベクトルから直接テクスチャ座標を計算する</FONT>のである。
なんでそんなのが必要かというと、
実はこのマッピング方法と環境マッピングがあれば、
<FONT COLOR ="#FF9090">
シェーディング計算を一切行わずにライティングが可能</FONT>なのである。
しかも<FONT COLOR ="#FF9090">
光源を何十個付けようがパフォーマンスは全く変わらない</FONT>。
さらにDirectX6のように
<FONT COLOR ="#FF9090">
マルチテクスチャ機能</FONT>まであると、パフォーマンスもかなり向上するだろう。
<BR>
　まあ、しかしこれもあまり必要性は感じられないだろうから、実装されることは
<FONT COLOR ="#FF9090">
ない</FONT>だろう...。
一回試してみたいという願望はあるのだが...。
<P>
<FONT COLOR ="#FF90FF">
●マルチテクスチャ
</FONT>
<BR>
　そして、先程も述べた<FONT COLOR ="#FF9090">マルチテクスチャ機能</FONT>である。
これは、<FONT COLOR ="#FF9090">ポリゴン一回の描画で複数のテクスチャを指定でき、
それらをアルファブレンディングなどで混合しながらラスタライズできる
機能</FONT>である。
これができると、<FONT COLOR ="#FF9090">
テクスチャマッピング＋環境マップハイライト</FONT>を、
<FONT COLOR ="#FF9090">
一回の描画処理で実行できてしまう</FONT>のだ。
ハードウェアがサポートすればパフォーマンスは大幅に向上するし、
たとえAPIレベルの実装だけでも、かなり無駄は減ることになる。
<P>
<FONT COLOR ="#FF90FF">
●ハイライトの計算モデルをBlinnに
</FONT>
<BR>
　OpenGLやDirect3Dで使われているスペキュラー要素によるハイライトの計算は、
<FONT COLOR ="#FF9090">「Phongのモデル」</FONT>と呼ばれる
アルゴリズムを用いている。
このPhongのモデル、実は強引である。また、それによる不具合も少しある。
<BR>
　<FONT COLOR ="#FF9090">
「Blinnのモデル」</FONT>とは、Phongが
<FONT COLOR ="#FF9090">経験的</FONT>に導入した式を少し変更し、
<FONT COLOR ="#FF9090">もっと物理的根拠から説明できる形にしたもの</FONT>である。
<FONT COLOR ="#FF9090">
「Phongのモデル」</FONT>では、
<FONT COLOR ="#FF9090">視線の方向と、光線が物体表面で正反射した方向</FONT>が
<FONT COLOR ="#FF9090">
どれだけ近いか（つまりはその内積）で計算する</FONT>モデルである。
ただ、これだけでは一般的な素材のハイライトには鈍すぎるため、
内積の値（<FONT COLOR ="#FF9090">マイナスは
ゼロとみなし、0.0〜1.0の範囲</FONT>）を<FONT COLOR ="#FF9090">べき乗</FONT>し、
<FONT COLOR ="#FF9090">鋭さを出す</FONT>。
<FONT COLOR ="#FF9090">
鋭いハイライトを表現する</FONT>ためには、通常数十から
百数十程度のべき乗が必要</FONT>である。
このべき乗はあくまで<FONT COLOR ="#FF9090">経験則</FONT>であり、
物理的な根拠は実はあまりない。
<BR>
　<FONT COLOR ="#FF9090">「Blinnのモデル」</FONT>は、
もっと<FONT COLOR ="#FF9090">物理的な根拠から説明のできるモデル</FONT>である。
計算方法は、まず<FONT COLOR ="#FF9090">
視線ベクトルと光線ベクトルの二等分ベクトル</FONT>を求める。
さらにこの<FONT COLOR ="#FF9090">ベクトルの逆ベクトル</FONT>と、
<FONT COLOR ="#FF9090">物体表面の法線ベクトル</FONT>から
<FONT COLOR ="#FF9090">輝度（明るさ、つまり表面の色）</FONT>
を計算するのである。
<BR>
　しっかし、<FONT COLOR ="#FF9090">
「視線ベクトルと光線ベクトルの二等分ベクトルの逆ベクトル」</FONT>って
一体何のことだろうか？
もっと分かりやすく書くと、<FONT COLOR ="#FF9090">光線が正反射した時、
ちょうどカメラに向かって反射する</FONT>ような
<FONT COLOR ="#FF9090">法線ベクトル</FONT>のことである。
実はこれ、実に理にかなった計算方法なのだ。
何故こんな計算の仕方になるのか説明しよう。
<BR>
　<FONT COLOR ="#FF9090">ハイライトがぼやける（ぼやけない場合は
光源が完全に映り込む）</FONT>のは、
物体表面に細かいレベルの<FONT COLOR ="#FF9090">凹凸が存在する</FONT>からだ。
この<FONT COLOR ="#FF9090">細かな凹凸が光線をそれぞれ鏡面反射させる</FONT>ため、
光源が完全に映り込むのではなく、ぼやけたハイライトになるのである。
通常の素材では、<FONT COLOR ="#FF9090">細かな凹凸（微平面）の向きはほとんどが
物体表面の法線に近い方向を向いている。</FONT>
しかし量は少ないながらも、
<FONT COLOR ="#FF9090">物体表面の向きとはかなり違った向きの微平面も少しは存在する</FONT>。
なんとなく、<FONT COLOR ="#FF9090">物体表面に近い向きの
微平面ほど、全体に占める量が多い</FONT>ことは理解できるだろう。
<BR>
　Blinnのモデルを使う時、最も簡単な方法は、
<FONT COLOR ="#FF9090">微平面の法線ベクトル</FONT>
（二等分ベクトルの逆ベクトル)と<FONT COLOR ="#FF9090">物体表面の
法線ベクトル</FONT>の
<FONT COLOR ="#FF9090">内積</FONT>をとり、これをPhongのモデル同様
<FONT COLOR ="#FF9090">べき乗する</FONT>ものである。
これは言いかえるなら、<FONT COLOR ="#FF9090">
「微平面の量は、物体表面の向きから離れれば離れるほど、
その角度のcosのべき乗に比例して減衰する」</FONT>
という考え方に基づいている。
<FONT COLOR ="#FF9090">鋭いハイライトをもつ表面は、角度が
開くと極端に減衰するため、
べき乗の値を大きく取るとよい</FONT>ことになる。
先程も述べたが、この減衰の仕方は<FONT COLOR ="#FF9090">
もっとも単純な計算方法</FONT>である。
さらに物理的に考えられた方法（例えば凹凸によって遮られる光の割合も
考慮した計算方法など）もあり、これらを使うとさらにリアルなハイライトを
表現することができる。
しかし、リアルタイムレンダリングで使うなら、ここまで考慮する必要はないだろう。
<FONT COLOR ="#FF9090">内積のべき乗だけで充分</FONT>である。
<BR>
　Blinnのモデルを利用すると、計算負荷はほぼ同じだが、ハイライトの減衰が
Phongのモデルよりも少しリアルになる。
例えば、Phongではその計算上、<FONT COLOR ="#FF9090">
光線の反射ベクトルと視線ベクトルの角度差が
90度以上に開く</FONT>と、<FONT COLOR ="#FF9090">ハイライトは
完全にゼロになってしまう</FONT>が、
Blinnでは、<FONT COLOR ="#FF9090">光が裏から当たる角度まで滑らかに減衰する</FONT>。
<BR>
　それからもうひとつ、Blinnのモデルだと<FONT COLOR ="#FF9090">
面白い表現</FONT>ができる。
これも法線環境マッピング同様、個人的にちょっと試してみたい方法なのだが、
......これはちょっと説明しにくいので、またの機会にしよう。
また考えがまとまったらその時点で紹介することにする。
<BR>
　OpenGLでは<FONT COLOR ="#FF9090">
過去の実装が破棄される</FONT>ようなことはまずあり得ないため、
<FONT COLOR ="#FF9090">Phongのモデルが無くなることは考えられない</FONT>。
だが、せいぜいPhongのモデルとの<FONT COLOR ="#FF9090">選
択の余地</FONT>ができてくれると、
非常にイカすんだよなあぁ。
<P>
　以上が、とりあえず<FONT COLOR ="#FF9090">個人的に
「OpenGLで欲しいなぁ」</FONT>と思っている機能である。
考えてみると、あんまり実現の可能性はないなぁ。
でもまあ、<FONT COLOR ="#FF9090">マルチテクスチャや屈折マッピング</FONT>
などは、将来的には実装される可能性はあるだろう...。
あぁ、でも<FONT COLOR ="#FF9090">屈折マッピングは、屈折率とかのデータも必要になる</FONT>し....
やっぱ無理かなぁ..(^^;;
</DL>

<!-- Signature -->
<FONT SIZE="3" FACE="ＭＳ Ｐ明朝">

<CENTER>
<IMG SRC="../Image/Bar2.gif" ALT "-------------------------------------------" width=90% height="16">
</CENTER>

<UL>
	<A HREF="index.html"><B><I>Masa's Column</I></B>に戻る</A>

	<TABLE>
	<TR>
	<TD>
	<A HREF="../index.html"><IMG SRC="../Image/MasaPlate.gif" BORDER="0" WIDTH="112" HEIGHT="48"></A>
	</TD>
	<TD><A HREF="../index.html">ホームページに戻る</A></TD>
	</TR>
	</TABLE>

	本ページの御意見・御感想は<BR>
<B>
<ADDRESS>
	<A HREF="mailto:masa@daionet.gr.jp">
		<I>E-Mail: masa@daionet.gr.jp</I></A>
</ADDRESS>
</B></UL>

</FONT>
<!-- Signature -->

</BODY>
