リアルタイム 3D 映像の開発まとめ。まだ未確認のものが多く、間違いが含まれている可能性があります。

• blog に戻る

• SxS = Side by Side, T&B = Top and Bottom, FS= Frame Sequential, R/G R/B B/A R/C = Anaglyph
• 結局 裸眼立体視できると便利なことが多い。
• 逆に 3D モニタで左右の効果の差を確認する場合は、片目で交互に見て確認。目が疲れた場合も片目が有効。
• Interlace でラスタが逆の場合、偏光メガネを左右逆に付けるときちんと見える。

参考リンク

• ヘッド位置はコンテンツによって制限される。ほぼ全部が水平視差なので位置や頭を傾けると視差方向が一致しなくなる。また視差の幅はモニタサイズとスクリーンからの距離を決める。
  • 方式によるヘッド位置が自由であるメリットは、自分で動いてコンテンツに合わせて最適な視聴位置を調整できること。どのコンテンツでも好きな位置で正しく見えるわけではない。

• Parallax Barrier
  • 裸眼。レンチキュラーに近い。横解像度が半分。明るさ半減だが 3D としては明るい。チラツキなし。
• Interlace + polarization
  • 安価な偏光メガネのみ。インターレースは縦解像度が半分。チラツキなし。
• Frame sequential + active shutter
  • 高価なアクティブシャッターメガネが要る。左右で半減するだけでなくシャッターでも暗くなる。解像度そのままで時分割。室内照明の影響を受けてちらつきが生じることがある。

• PS3 の 3D 出力は原則 HDMI のみ。高品質だが対応モニタでないと描画できない。従来のモニタ向けに HDMI 以外でも SxS 出力が欲しい。
• アクティブシャッターメガネは互換性が無い。１万以上する高価なものなので、互換性を保証して欲しい。
• ZALMAN の偏光メガネは安価だが、さらに Real-D でもらえる偏光メガネも使える。
• コンテンツ側が圧縮 SxS なら何で再生しても Wrap で見ることができる。
• ZALMAN のインターレース変換はアプリで行えば何でも描画できるはずだけどまだためしてない。

気がついたことなど

左右の目に、視差のずれた映像をそれぞれ映すだけです。ステレオの音声とよく似ています。

立体視の視差は視聴時の実空間で認識します。 映像の中のカメラは実空間と異なっているので映像に違和感を感じることがあります。 左右の映像をどれだけずらせば良いのか、見かけのずれ幅はモニタサイズと視聴位置の影響を受けます。

プリレンダリングされたムービーや静止画の場合、コンテンツ制作時にカメラが固定されるため視聴環境に応じた調整ができません。 リアルタイムの 3D CG は、描画時にモニタに合わせたカメラ設定が可能なので立体視との相性が良くなります。

視差による立体視は擬似的な表現であるため、厳密に実空間と連続でなくても立体に見えます。 ただしサラウンドの 3D 効果と同じように個人差があります。 前後の視聴位置である程度調整が可能です。

おそらく表示方法や、モニタが対応しているフォーマット等によって出力の仕方は異なってくるものと思われます。 基本的には 1フレームで左右 2枚分の絵をレンダリングします。

iWarp 310 のように単純な圧縮 SxS の場合は、左右の絵を 1枚の画像としてレンダリングします。 仮に出力が 640×480 と仮定すると、320×480 のサイズで左右の絵をレンダリングすることになります。 この場合それぞれ縦長の潰れた絵になります。

裸眼立体視用 (平行、交差) の場合はアスペクト比を保つ必要があるのでそのまま 640×480 と同じ比率で 2枚。 交差法の場合は SxS と左右が反転。

Zalman などのインターレース (ライン インターリーブ) の場合は、SxS とは逆に縦に潰れた解像度で 2枚です。 あとでラスタ毎に交互に合成する必要があります。

カメラの位置で左右の視差を作りますが、レンダリング時は同一のフレームに収める必要があります。 できるだけ違和感がないように左右それぞれビューポートの調整が必要です。 カメラを注視点方向に toe-in する方法と、View Frustum をせん断変形させる方法の二通りのやり方があるようです。 Maya にはさらに平行シフトのみの Parallel があります。

注視点への toe-in は問題が生じることが多いので、View Frustum の変形が基本となります。 カメラは回転させずに角度をつけません。 よって描画時は View Matrix だけでなく Projection Matrix も置き換えます。

立体視で Parallel 以外のアルゴリズムを使うと 3D の左右の視線が交差する位置が生じます。 この距離に描画された物体は、レンダリング時に左右の描画のずれがなくなるため TV の枠と同じ位置にあるように見えます。

2D のウィンドウや文字などを、左右の視差ずれ無しで描画した場合も同様です。 テレビ枠と全く同じ位置に固定されたように見えます。 (画面についた汚れや埃もこの位置に固定される。)

この距離がゼロ視差位置となります。 これより奥の物体は引っ込んで見え、逆に手前の物体が飛び出て見えます。 立体視の宣伝では飛び出して見えることを強調することがありますが、 手前への描画はフレーム枠にかかることが多いためクロストークが生じやすくなります。 飛び出し表現は安易に使用できません。

3D の奥行きは左右のずれ幅で表現します。 よって厳密な Z 位置はピクセルサイズの影響を受けます。 例えば高速化のために低解像度でレンダリングした場合、横解像度の 1pixel サイズより細かい精度で Z 位置を特定することができません。

網目のような単独のピクセルが目立つような描画は、エイリアシングにより Z 位置が同一平面に固定されず、でこぼこにみえることがあります。 ピクセルがボケるとこのような問題は起こりません。

何が問題なのかは明らかです。

カメラ空間とスクリーン空間に影響される描画は原則として描画負荷が 2倍となります。 圧縮 Side by Side やインターレースなど、ピクセル面積が半分になる場合はこの限りではありません。 ポストエフェクトも左右それぞれ個別に生成する必要があります。 マルチパスの場合はそれもすべて 2回描画します。

カメラ空間に無縁な描画が含まれている場合は 2倍の負荷となりません。 例えば ShadowBuffer はライト空間でレンダリングされるため、左右分けて 2回分レンダリングする必要がありません。 PSM の場合も代表となるセンターカメラを使えば良いので、律儀に左右のカメラでレンダリングしなくても良いわけです。

また DirectX10 (Direct3D10) 以降は、CubeMap 生成のために GeometryShader でレンダリング先の View を選択することが可能となっています。 これは MRT とはまた別の機能です。 SV_RenderTargetArrayIndex 及び SV_ViewportArrayIndex 。 同時に GeometryShader で描画ポリゴンを複製できるので、この機能を使えば一度の描画で左右 2面分のレンダリングが可能となり負荷を軽減できると考えられます。 (未確認)

基本的には 2枚のずれた絵を左右の目に個別に映すだけです。音声のステレオと同じです。 そのため立体感の強弱は基本的には表示方式に影響されません。 同じモニタサイズ、同じ視聴位置で同じ映像ソースを見た場合は、フレームシーケンシャルのアクティブシャッター TV だろうと偏光板式のモニタだろうと 同じ立体感で見えると考えられます。 違いを作っているのはおそらく次の原因によるものではないでしょうか。

• 映像ソースに含まれている画角やカメラのずらし位置(視差)と、現実の視聴環境の関係
• 左右の絵がどれだけ綺麗に分離されているか。クロストークの少なさ
• 細部の左右の違いがきちんと見えているかどうか。暗くなって細部が潰れたりぼけて違いがはっきりしなかったり。
• 個人差を解消できているかどうか。映像ソースの許容範囲と視聴時の制限。
• 表示方式が想定しているモニタサイズ、モニタとの距離、位置、頭の角度で見ているかどうか。