UDN
Search public documentation:

UnrealModelingJP
English Translation
한국어

Interested in the Unreal Engine?
Visit the Unreal Technology site.

Looking for jobs and company info?
Check out the Epic games site.

Questions about support via UDN?
Contact the UDN Staff

Unrealモデリング ガイド

ドキュメントの概要:ここでは、Unrealのモデリングにふさわしいいくつかのデザイン例、さらにレベルやキャラクターに使うポリゴン数の推奨値をご紹介します。Unreal Engineで初めてモデリングを行う方を対象としています。

ドキュメントの変更ログ:最終更新者Michiel Hendriksにより細部変更。前回修正者Tom Lin (DemiurgeStudios?)により概要文の変更。原文作成者はTom Lin (DemiurgeStudios?)。

Unreal Engineでモデルを作る

Unreal Engineのモデリング手順の流れは、他の一般的モデリングとほぼ同じです。そこで、Unreal Engine特有の機能の他、ゲーム固有のモデリング事情についてもご紹介します。アニメーションのあるプレーヤモデルについて特に詳しくご説明します。

モデルの設計プラン

モデリングの最も初歩的な部分でありながら、限りなく重要なのがこの設計プランです。モデリングの第一歩はこれから作るモデルの持つ動作能力を決定することで、その動作を軸にモデルを作成します。例えば、モデルが「登る・持ち上げる・投げる」といった動作を頻繁に行う場合、モデルの滑らかな動きを実現するためにモデルの肩付近により多くのポリゴンを設定することになります。また、三人称視点カメラをキャラクターの後ろに配置することが多いなら、モデルの顔部分に集中してポリゴンを使うのではなく、後姿に多くのポリゴンを使うようにします。また、ユーザが最もよく見るモデルの部位はどこなのか検討します。例えば、FPS(一人称シューティング)では全体的にキャラクターの動作が速く、距離もあります。この場合、アップになったり静止したりすることはほとんど無いため、顔に多くのポリゴンを費やす必要はありません。むしろ、ポリゴンを均一に広げた方が良いのです。 もちろん、キャラクター以外のモデルについても同様です。例えば車なら、ドアの開閉、窓から中が見えること、さらには車がひっくり返ることなどの必要性を検討します。各部の重要性を検討し、それに応じて適当なポリゴン数で作成します。

スムースメッシュ

Unreal Engineでは通常、スムーススキンを貼り付けたメッシュでキャラクターモデルを作成します。つまりモデルは、複数ピースの集まりではなく一体もののサーフェスで出来ています。このため、複数パーツの集合体であるモデルとは違い、骨格構造に基づいてモデルが変形するようになります。このシームレスな外観が特にふさわしいのは肘、膝、そして指などの関節部で、これらはスムーススキンでないとモデルの継ぎ目を「滑らかに」する手段がテクスチャに無くて困ることが多いものです。モデルの影もスムーススキン モデルの方が理にかなった動きをします。 サイボーグ、ロボット、そしてカナダ人など、関節が硬くスムース変形を必要としないキャラクターの場合は、完全にスムーススキン化せずにモデルを作成することもあります。防弾チョッキを着たSWATのチームメンバーを例に考えてみましょう。肩関節をスムーススキンから切り離すと、動画時に出来てしまう肩のシワが緩和されるという利点もあります。 しかし、ほとんどの場合はスムーススキンで処理するのが最もよいでしょう。

特殊関節

飛んだり跳ねたりするだけのビデオゲームで満足する時代はもう終わりを告げようとしています。瞬き、視線、舌の動き、身振り手振りなどは、新たなモデルに着手するにあたって必ず検討すべき項目です。こういった動作がモデルの可能性をグッと広げますが、犠牲も伴います。アルファチャンネルを使ったテクスチャ、多ポリゴン、複雑なリギングや活発な動作の追加などが、落とし穴となってしまう場合もあるのです。 こうした属性の作成に役立つヒントをいくつかご紹介します。

動く目

この手順では、アニメーションメッシュでアルファチャンネルを利用します。

モデルの眼は、眼球を模したテクスチャを貼った球体を眼球孔に配置するのが唯一最善の方法だという人もいるかもしれません。しかし、アルファチャンネルやマスクをテクスチャに適用すれば、もっと効果的な手法が使えます。眼球を作ってしまうのではなく、眼を白目と虹彩の二つの部位として分割して考えるのです。白目をスムーススキン化した顔の一部(固定要素)として作成し、虹彩を一枚のポリゴン上にフロートさせると、「眼球」のサーフェスに沿って虹彩のみを動かすことが出来ます。これは眼球に便利なシミュレーションでUT2003およびUT2004でも使われています。

eye.jpg

まぶた

まぶたには、キャラクタースタジオにデフォルトにない顔の骨格構造が必要です。

まぶたはスムーススキンによってある程度模造できます。まぶたの簡単な作り方は、上下に単純回転する頂点列に単一ボーンをバインドし、そのままポリゴンシートを張った目の上でスキンをドラッグするというものです。モデリングの観点から言えば、安全にストレッチできる頂点列を利用すれば、あまりにもたくさんの顔ジオメトリを編集せずに済むのだと覚えておいてください。

eyelid.jpg

舌には、キャラクタースタジオにデフォルトにない顔の骨格構造が必要です。

舌は、動きの必要度にはよりますが、ほとんど説明の必要はないでしょう。もしも、舌を誰かに向かって突き出す、唇をなめる、などのように口から舌をかなり出す場合は、少し変則的な骨格構造を用いる必要があります。Unrealでは、ボーンを時間の経過に伴い伸張させる機能をサポート*していません*。ボーンの情報は方向と位置のみとなっています。舌の動作に最も良い方法は、ボーンを折り返す方法でしょう。既存のボーンを伸張するのは不可能なので、アコーディオンのように折ったり展開したりします。

tonguebone.jpg

モデリング上の観点から言えば、通常の舌ならこの処理で十分です。舌は口のかなり奥に置かれるため、外へと伸ばし出してもほとんどの部分はずっと口の中にあるということを覚えておいてください。

+++ 参照ポーズ(Refpose)

Unreal Engineのモデリングで常に意識すべき重要なコンセプトの一つに、参照ポーズ(Refpose)とアニメーションの区別があります。拡張子「.PSK」のファイルに出力される参照ポーズ(Refpose)にはモデルとボーンの情報がありますが、アニメーション情報はありません。ここはボーンの効果を設定する場所で、エンベロープやロックによってグループ化された頂点にボーンが及ぼす作用を設定します。一方、アニメーション情報は拡張子「.PSA」のファイルに格納されますが、骨格構造の動きに関する情報のみで、ウェイトの情報はありません。というのも、参照ポーズ(Refpose)とは基本的に、モデリングをすすめるにあたってリギングを簡単かつ快適に行えるようなスタンスに設定したキャラクターなのです。 ActorXはこれらのファイルを生成するプラグインですが、詳細説明については「ActorXMax Tutorial(ActorXMaxチュートリアル)」もしくは「ActorXMaya Tutorial(ActorXMayaチュートリアル)」をご覧ください。 腕を両サイドへピンと伸ばし、足を外に開いて立つスタンダードな参照ポーズ(Refpose)のキャラクターを使ってモデリングを始める方が多いと思います。筆者は最近、腕の角度を45度にしたキャラクターからモデリングを始めるようになりました。腕は少なくとも半分は下ろした状態なので、モデルが腕を休ませた状態の見栄えは、(姿勢としては非常に不自然な)ピンと伸ばした状態よりもかえって重要なのです。リギングのシェーディングは重たくなってしまいますが、肩の変形が少なくなるので試してみてください。

refpose.jpg

+++ スムージング グループ スムージング グループによってスムージングした静的メッシュなら、快適に操作できます。まさしくスムースです。

骨格(キャラクター)モデルにスムージングは 正式には サポートされていませんが、モデルを読み込むとスムージンググループごとに階層分割され、スムージンググループ機能が有効となります。一体どういうことでしょうか。これはActorXが、スムースエッジに沿って頂点を分割した分割ピースごとのスムージングにより、スムージング処理を代行しているということです。つまり擬似スムージングですが、実行後モデルのスムースエッジ上に存在する頂点数は倍増してしまいます。分割頂点ごとにメモリ占有量やレンダリング負荷がどんどん積み上がってしまうので、骨格モデルをグループ分割することはお奨めしません。 それでもこのスムージング処理を行いたいという場合は、ActorXパネルで[bake smoothing group](スムージンググループのベイク)のボックスをチェックしてください。

bakesmoothing.jpg

+++ ゲーム内のパースペクティブ

広範囲に稼動するカメラは、ゲーム用モデリング特有の機能です。しかし、これがアーティスト泣かせとなる場合もあります。カメラが様々な距離や視点からモデルを捕らえるので、うまく作ったはずのモデルも変形して台無しになってしまうことがあります。例えば、モデルが足元をまっすぐ見下ろすと、脚は床に向かって徐々に細くなり、足がとても小さく見えます。一方、同じモデルを50ヤード離れた所から見てみると、今度はバランスよく見えます。この作用に対し、カメラが足元に近づくにつれて脚の幅を少しずつ均等に広げてゆきたい人もいるでしょう。実例をご覧になりたい場合は「UnrealDemoModels(Unrealデモモデル?)」をご覧ください。 ここでは必ず守るべき規則などはありません。モデルの描画状態をよく検証して、適切な処理を判断しましょう。 もう一つ覚えておきたい事項は、見かけのモデルサイズです。多くの場合、スクリーン上のキャラクターに利用するピクセル数はテクスチャマップよりも少なくなります。複数モデルを作成する場合は、離れていてもどのモデルか区別がつくように、しっかり特徴づけるよう心がけます。 当然ながら、UT2003のように複数プレーヤやチームでプレイするゲームでは特に重要になります。

+++ Unreal Engineのヒント

作業を快適にし、モデルを格好よくする、とっておきのヒントをいくつかご紹介します。

クリッピング ポリゴン

互いに直接クリップさせたスムーススキン モデルのポリゴンは見栄えが悪くなりやすいのですが、スムースエリアとの継ぎ目を隠すディテールを後で追加する場合、クリッピング ポリゴンはいたずらにトライアングルを増やさずに済むよい手法です。シート上に眼(虹彩)を作成する前述のヒントと、このクリッピング ポリゴンを併用すればより効果的です。クリッピング ポリゴンは[UnrealEd]で完璧に作動します。

eye clipping

眼を見ると、眼球の虹彩部分はほぼ正方形のポリゴンシート上にあるように見えます。テクスチャのアルファチャンネルには、Unrealで虹彩が円形にみえるようにする透明度の情報が入っています。

eye alpha texture

一つだけクリッピング トライアングルが問題になるケースがありますが、それは二つのトライアングルに割り当てたマテリアルがテクスチャのアルファチャンネルを使用する場合です。これは同でもよい問題ではなく、何かが損傷していることは明らかです。

眼に関しては、虹彩だけがアルファ情報を持つので順調に機能します。クリップ先(周辺の眼ソケット)がアルファチャンネルを使用しないので、描画優先順位がバッティングしないのです。従って、モデルプランニングの初期段階ではモデルのどこでアルファを利用するのかを識別し、二つのアルファ トライアングルが交差しないことを確認することが大切です。万一、交差の可能性がある場合(例えば毛髪など)は、フェース同士が限りなく平行に近くなるように徹底的に角度を落とし、トライアングルが接触する角度を可能な限り最小化します。この角度が垂直となるのは最悪のケースです。

clipping illustration

片面ポリゴン

[UnrealEd]で両面テクスチャを有効にする代わりに、片面ポリゴンを利用すると時間短縮の有効な手段となります。モデリング上の追加作業は何もなく、単にモデルの裏面をオープンにしておくだけです。旗などの物体に適しています。 ここでも、目が良い実例になります。フロートする虹彩は片面ポリゴンシートです。

スムースキン メッシュ作成用のサーフェスは、完全に閉じている必要がありません。ポリゴン数を抑えたいエリアでは、場合によりあえて不完全なメッシュにしておくこともできます。もちろん、何かの拍子にサーフェスのギャップがカメラの真正面にならないかは確認しておきましょう。また、サーフェスに空けられた穴もそのままにしておいて、モデルの後ろをブロックするようにポリゴンを配置して穴を「埋める」方法もあります。

eye hole

繰り返しますが、眼はこの技法の優れた実例です。ピンクの部分は実は大きなトライアングルで、頭の中のかなり後方に配置してあります。これによって、白で埋めなければならないギャップが顔にないか確認する必要がなくなります。

eye inside

+++ ディテールレベルの比較

ディテールのレベルについては、プロの処理方法を参考にしましょう。このセクションではUT2003、Unreal IIおよびオリジナル版Unreal Tournamentのポリゴン数を比較します。このデータを読むにあたり、ポリゴンの概数がそのまま実際のレベル稼動速度を示すものではないこと、各トライアングルに施した効果の影響も大きいことを留意しておいてください。

UnrealⅡ

UnrealⅡは2003年2月にリリースされました。全般に超多ポリゴンとなっており、開始レベルの各パーツは2万~8万5千ポリゴンです。一般に屋外セクションが比較的多ポリゴンで平均4万5千~6万です。室内やトレーニングエリアの平均は3万5千~3万8千です。これらのレベルでは敵のモデルが登場しないので、ディテール度の高い描画を追求できます。 作戦のメインベースとなる船はディテールがより詳しく描画されます。ここは空間が狭く、その分各エリアに詰め込めるポリゴン数が比較的多くなっています。ポリゴン総数は4万~10万の間で、平均数は約6万です。 中心プレーヤと敵のモデルが登場する第一レベルでのポリゴン数は1万5千~7万5千程度です。戦闘中のポリゴン数は敵を含めて約2万5千~3万です。当然、重たくなる戦闘エリアをデザインする場合は、ジオメトリ密度を下げなければなりません。第3レベルでは、画面上に各部の同時描画ポリゴンは(開始時の外装で)1万5千~1万6千にのぼります。一方、中心プレーヤのほとんどは5万~8万ポリゴンで処理されます。 敵や味方のプレーヤモデルに使うポリゴン数にはかなり幅があります。モデルSkaaryはおよそ2,500ポリゴン、ヘビーSkaaryは3,450ポリゴンです。ポリゴンが最も小さいモデルはAraknidで870ですが、ヘビーバージョンになると2,500ポリゴンです。プレーヤと共に戦う海兵隊員は2,000~2,600ポリゴンです。最多ポリゴンは、仲間の乗組員Aidaが達した4,900ポリゴンです。Aidaは母船に幽閉されていてかなり狭い環境にいるため、モデルにかなり複雑な細工を施すことができます。 カットシーンでは、全体的に高いディテール レベルを設定できるはずです。オープニングのカットシーンは1万5000~5万ポリゴン、その後のカットシーンでは、1万4000~1万5000ポリゴンになります。

UT2003

2002年9月、UnrealⅡに4ヶ月先立ってUnreal Tournament 2003がリリースされました。予想通り、両ゲームのポリゴン総数はほぼ同レベルです。実際、レベルによりディテールのポリゴン数にはかなりの差がありますが、それぞれのサイズや推奨するプレーヤ装備の違いを考えれば納得できると思います。 UT2003のプレーヤ モデルは2,100~3,300ポリゴンですが、そのほとんどは約2,600ポリゴンに絞られています。レベルの総ポリゴン数にこれらの数値はまだ加算していないのでご注意ください。

_Antalus_の推奨プレーヤ数は4~6人です。ポリゴン数は2万5,000~7万5,000にわたり、平均3万5,000ポリゴンです。

_Plunge_の推奨プレーヤ数は3~12人です。人数に幅がある分、同時描画ポリゴン総数も1万~10万となります。プランジにテレイン トライアングルが無いようですが、多ポリゴンを実現できるのはこのためです。レベルのデザインとは、低ポリゴンや多ポリゴンだけに注目してその間の数値をあまり見ないので、本当の意味での「標準」ポリゴン数を断定するのは難しいことです。

_Inferno_(2~6人用)は_Plunge_同様、幅広いポリゴン数です。やはり総数は1万~10万ポリゴンにわたりますが、マップが_Plunge_の約半数のプレーヤを対象としている分、軽くなります。同時描画のレベル平均は4万~6万ポリゴンです。

_Tokara Forest_(8~16人用)はプレーヤ数にかなり幅があります。レベルは同時描画で1万~8万ポリゴン、平均が3万~4万ポリゴンです。

Unreal Tournament

1999年11月にリリースされたこのゲームは、技術面で言うと生きた化石のようなものですが、驚いたことにこれが、かなりの低ポリゴンで目を見張るほど美しい環境を作り上げられるまでに素晴らしく成長しました。

UTのプレーヤキャラクタは300~400ポリゴンです。

_Orion's Barricade_(6~12人用)は、1シーンにつき300~800ポリゴン、平均400~500ポリゴンです。

_Curse II_(4~12人用)は、1シーンにつき220~450ポリゴンで、平均400ポリゴンです。

_Oblivion_(2~3人用)は、少し多めの200~900ポリゴンです。ただし、戦闘エリアでの平均は400ポリゴンに納まっています。

_Gothic_(6~16人用)は200~700ポリゴンで、平均は400ポリゴンです。