4,3　VRMLの表示が遅くなる理由

　これまでVRMLを紹介してきたが、3D立体画像になれば確かによりリアルに表現は出来る。が、まだこれまで一般的にはあまり広まっていないのが現実である。

　特に、Netscapeでは立ち上げるとJavaを起動してしまうし、表示をするのに時間がかかる。

　では、なぜそうなのか。立体を表示するのに時間がかかる理由を検討してみる。VRMLには次の4つのサブシステムがある。

  1. User Interface
    2. 　描画するVRMLコンテンツのレイアウトを制御するサブシステム。VRMLブラウザのボタンやメニュー、描画エリアの位置決めなどを行い、ビジターがいずれかのボタンをクリックしたり、メニューからアイテムを選んだり、描画エリア上のモデル上にマウスを動かしたりすると反応する。

  2. World loader
    3. 　VRMLコンテンツ内のテキスチャ・イメージや音声、スクリプトのローディングを行うサブシステム。また、読みこんだVRMLファイルに記述ミスなどがないかどうか調べるのも、このサブシステムの役割でもある。

  3. World management
    4. 　ビジターの視点や行動の特徴を随時追跡したり、管理したりするサブシステム。例えば、ビジターがVRMLコンテンツ内にあるモデルと衝突したりすると、ビジターに対して衝突したことが伝わるように対処する。さらに、センサーやスクリプト、音声、イベント伝達回路の状態を管理するのがこのサブシステムである。

  4. World drawing
    5. 　「World management」サブシステムと連携して、モデルをディスプレイ上に表示できるように変換するサブシステム。ビジターによって何か変化したり、アニメーションが変更になったりする度にロードされたコンテンツの情報を再スキャンしてモデルの再構築を行う。

　ここでは、4番目のWorld drowingでピクセルで画像を用いるシステムについて次のように述べてみた。

　3次元をブラウザ上で表示するのに一連のプロセスがある。(下図)　高度に最適化されたVRMLコンテンツでは、3次元モデルの情報はVRMLを表示するのにスムーズにいくが、最適化がうまく行かないと流れがうまくすすまなくなってしまう。
　このプロセスはアニメーションをかけたりすると、はじめからプロセスする、


図1　Cubeノードでの3角形の分割
　立体画像の表示は全部3角形で構成されている。箱、円錐、球のノードは左図のように3角形の構成となっている。

　なぜこういうことを述べたか言うと、それぞれの形は左図のように3角形に分割して送っているからである。各ステージの働きを下の表にあらわした。

ステージ
主なデータ
の種類
主なノード・タイプ
Transform
頂点座標、座標変換マトリクス
Geometry, Billboard, Transform, Viewpoint
Backface cull
頂点座標
Geometry
Compute lighting
頂点座標、
色値、光度
Geometry, Appearance, Color, DirectionalLight, Fog, Material, Pointlight, SpotLight
Texture transform
イメージ座標、
イメージ変換マトリックス
Geometry, TextureTransfor
View cull and clip
頂点座標、
イメージ座標
Geometry
View project
頂点座標
Geometry, Viewpoint
Rastarize
頂点座標、
色値、
イメージ座標、
ピクセル値
Geometry, Background, Imagetexture, MovieTexture, PixelTexture

図2　Sphereノードでの3角形の分割

図1　Coneノードでの3角形の分割

　それぞれの各プロセスを説明すると、
  • Transform
    • 　3角形のそれぞれの頂点座標を、並行移動や回転、スケーリング等を用いて、ビジターを中心として特別な座標へ変換する。

  • Backface cull
    • 　受け取った3角形が見ている人に接してる面をさぐる。モデルの背面側と内側は表示する必要がないので、表面に値する部分を次のプロセスに持って行く。

  • Compute lighting
    • 　分割した3角形に対して、光の強度を計算する。これにより立体表示を計算している。

  • Texture transform
    • 　3角形にテキスチャ・イメージ（jpg, gif等の画像ファイルと考えていいだろう）をマッピングするときの座標地を計算するときに用いる。3角形がテキスチャ・マッピングと関係なければ、次のプロセスに進むことができる。
    　3角形がテキスチャ・マッピングと対応していれば、そのイメージの座標に対して、平行移動や回転、スケーリングを行い、その後はイメージの座標値は、3角形の3つの角に合致するように計算される。

  • View cull and clip
    • 　このプロセスには、3角形が見ている人に視界に入っているかどうかチェックし、視界に入っていなければそれは排除され、視界に入っていれば次のプロセスに進む。
    　もし一部であれば、視界でない部分を切り取り、次のプロセスへ送る。

  • View project
    • 　それぞれの3角形を2次元の平面状に投影する。

  • Rasterize
    • 　3角形をピクセル・データに変換し、ディスプレイに表示する。それぞれの3角形に色をつけるのもここの機能に入っている。

　3角形の数がたくさんある物体
　3角形の数が少ない物体
　上の2つは何がわかるかというと、アニメーションをさせてみると、それぞれの動きの滑らかさが違うと思う。
　おそらくここでは、左の画像では3角形に直すとその数が多く、処理が複雑なため、アニメーションの動きがぎこちなくなっているが、右の図では3角形に直すと数が少ないため、動きも早く見せることができる。

　プロセスを進むと、例えば表示が遅いときは、データがそのどこかのプロセスにおいて詰まっていると言える。そのゲインとして次の3つが挙げられる。ちなみにその詰まってることを束縛状態と呼んでるが、それは”bound＝束縛する”ということだから、そういう風に用いた。

  • coordinate-bound
    • 　座標データの演算処理が原因で起こる束縛状態。

  • pixel-bound
    • 　ピクセル・データを生成するために必要となる演算処理が原因で起こる束縛状態。「Rasterize」が発生元。

  • texture-bound
    • 　テキスチャ・マッピングに関する演算処理が原因で起こる束縛状態。「Texture transform」が発生元。

　coordinate-boundはおそらくCPUに関して言えることだから、演算処理には問題はない。一番問題となるのRasterizeだと思う。例えば、ペイントを用いて1000ピクセルぐらいの大きさで絵を書いてしまうと、当然ファイルサイズもでかいし、表示するのにも時間がかかる。これか3Dに影響するのは当たり前だと思う。

　この例は、例えばブラウザの中にはるか遠くに見える惑星があり、その惑星に複雑な地形が表示してあれば、遠くにある分ピクセルで表示するのはあまり時間はかからないが、演算処理がそれよりも時間がかかるだろう。
　そして、その地形を拡大（接近すること）すると画面が大きくなる分、ピクセルデータも多大になり、演算処理よりも遅くなってしまう。

←BACK　↑TOP　NEXT→