ゲームプログラミング/3Dグラフィック

ゲームエンジンとの関係の現状

2000年以降、ソニーのプレステ系ハードの3Dレンダリングエンジンは、実はWindowsのDirectXに合わせて作られてあります。 なぜそれが分かるかというと、ゲーム3Dデザイナー向けの3D-CG技法書を読むと、Direct3Dを中心に解説してあるからです。

だからゲーム業界の3Dデザイナーがモデル制作をする際も、Windows向けの3Dモデリングソフトを用いて、ゲーム用の3Dモデルを作っています。なお、テクスチャなどの画像フォーマットは、プレステ2の場合は「TM2」（ティーエムツー）という（おそらくソニー独自の）画像フォーマットです。

実際にゲームで3D-CGを表示したい場合、現在では海外大手ゲームエンジン（UnityやUnreal Engine など）に、すでに既存の有名3D-CGソフト（Autodeskの製品や、フリーソフトならblenderなど）と互換性のある形式で3Dモデルをよみこめて描画できる方式になっている。

なので、商業の仕事の場合には、それらゲームエンジンを使うことになるのが2020年代の今では主流だろうと思われている。（ゲーム産業の仕事では、人件費も考えて、大手の場合なら、わざわざ自作する事はまず無い。日本企業で海外のゲームエンジンに対抗するのも、非現実的だと思われている。）

ゲームソフト会社やゲーム機会社がノウハウを非公開にしているため推測になってしまうが、ゲーム会社は研究機関ではないので、わざわざ自分の手で3Dエンジンをゼロから作ることは普通はせず（と思われている。実態は不明）、なるべく既存のゲームエンジンの内部に組み込まれている3Dエンジンを買ってくるなどして流用するのだろうと、2020年代では世間的にはゲーム産業はそう思われている。

ゲームエンジンは、個人では無料で使えるものもあるが、しかしフリーソフトではない（自由ソフトではない）。特に3Dゲームエンジンは、オープンソースではない。UnityもUnreal Engine も、ソースコードは非公開である（非オープンソース）。

ゲーム業界にかぎらず、こういった非オープンソースの製品のことを一般に「プロプライエタリ」と言います。たとえば、マイクロソフトのWindowsもOfficeソフトもプロプライエタリです。

ともかく、大企業などが大手ゲームエンジンを使う場合、費用を払う必要が生じることもある。（Unity などの利用規格にも、そういった事が書いてあります。）

なお、3Dモデルのデータ形式（ファイルフォーマット）は規格統一があまり進んでいないのが2020年では現状であり、ファイルフォーマットには .fbx形式、.3ds形式、.dxf形式、.obj形式 など、さまざまな形式がある。

また例外としてオープンソースのblender用の.obj形式を除いて、この分野は非オープンソースである商業ソフトが主流になって普及してきた分野であるので、プログラマー向けの資料などもあまり普及していない（企業秘密なので）。

市販の書籍も、ほとんどがイラストレーターなどのクリエイター向けのものであり、プログラマー向けのものは、ほぼ皆無である。

学術的にも、ファイルフォーマットまでは理論が整理されていない。（学術書に書いてあるのは、三角関数などを用いた3D計算の原理まで。）

いっぽう、もし、既存のゲームエンジンに頼らず3D-CGソフトを自作したい場合などには、原理は下記の節のようになるだろう。あるいは、既存の有名3D-CGソフトで扱っている3Dモデルのデータ形式に不満があって、新しい3Dデータ形式を模索する場合なども、自作することになる。

なお3D-CGの汎用ソフトについては、岩波書店の数学書『可視化の技術と現代幾何学』によると、残念ながら日本は欧米IT企業にソフトウェア技術を頼っているのが現状のようであり、どうやらゲーム産業だけでなくCG映画業界でも3Dアニメ業界でも、使用している汎用ソフトには海外製が多く、輸入しているのが現状のようです。そうだと数学者たちに言われています。

モーションキャプチャ・マシンも、一部ではネット検索では国産を謳っている製品も見つかるものの、しかし数学書『可視化の技術と現代幾何学』によるとモーションキャプチャ・マシンの多くが輸入品のようです。。そうだと数学者たちには言われています。

3Dグラフィック

計算の原理

3D-コンピュータグラフィックの計算の方式は、投影面（スクリーン）の形状（おおまかに2種類）と、平行投影か透視投影かの2種類の違いによって、2×2=4種類程度に分かれる。

投影面

1. 平面投影:
2. 円柱面投影などの非平面投影:

投影の方式

透視投影

1. 透視投影
2. 平行投影

一般的には、平面投影と透視投影の組み合わせが単純なので、よく使われる。

大学の3D-CG学などで単に「投視投影」と言った場合、この平面投影での透視投影の方式のことを言う場合が多い。

投影面

投影面の種類は主に2～3種類、

1. 平面投影: 投影面を平面として考えて、観測者と被写体をむすぶ線分と、投影面との交点を求めて出力画像として表示する方式。
2. 円柱面投影: 投影面を円柱面で考える方式。

くらいである。

このほか、球面投影や、楕円などで考える楕円柱投影や楕円球投影なども理論的にはありうるが、非実用的なので（球面投影に対応した安価な映像デバイスが無い。楕円だと設計のための計算が複雑な割りに、得られる画像も知見もあまり平面投影や円柱投影などと変わらないので）、楕円については考察や説明を除外する。

さて、紹介した平面・円柱の2種の投影面のうち、いちばん単純かつ普及していて実用的な投影面は、平面投影である。

なので、初学者はまず平面投影を中心的に学ぶのが良いだろう。なお、後述する単元での隠面処理のためにカメラの向きの角度計算が必要になるので、円柱投影や球面投影に近い考え方も必要になるので、べつに円柱投影などを学んでしまっても損は無い。

ただし、円柱投影には欠点があり、上下方向と左右方向で透視の縮尺が違うために、視界内で回転する回転体をうまく表現しづらいという致命的な欠点がある。たとえば、回転する音楽レコード盤を見下ろしているとき、円柱投影では、レコードが（工夫しないと）楕円にゆがんでしまう。

球面投影なら、レコードを見ても ゆがんだりしないが、しかし球面投影に適した映写デバイスが存在しない。

なので、結局、ふつうは平面投影で計算することになる。

さて、じつは、平面投影と円柱投影の2つの方式を比べた場合、得られる画像が微妙に異なる。カメラが向きを変えたときに、どのくらい視界内で被写体の位置が変化するかが、それぞれの投影面ごとに変化する。

そして、特に観測者の真横に近い位置になると、特に被写体の動きの変化量の違いが大きくなる。

平面投影の方式の場合、投影面が観測者の視界の向きで、少し前方にあるので、そもそも真横に近い場所にある物体は正投影が無理である。

だが、通常の人間の視界では、真横にある物体には意識が向かないので、なので平面投影でも問題ない。

なお、平面投影の欠点をこう聞くと、てっきり「円柱投影や球面投影のほうが視界にできる領域が広そう」（←誤解）に思われるかもしれないが、しかし実際には数値計算の誤差の理由により、つまり、円柱投影では観測者の真横にある物体は、投影のための数値計算（逆三角関数などの計算）のさいのケタ落ちが大きくなるので、円柱投影でも真横の物体の画像の表示は、不正確な表示になる。

なので、平面投影にしろ円柱投影にしろ、結局どちらとも、観測者の真横にある物体のCG画像表示は、そのままでは不正確な表示になってしまう。

円柱面は、幾何学的には「可展面」（かてんめん）である。トイレットペーパーや巻物を考えれば分かるように、円柱はハサミを入れるなどして展開すれば平面に展開することができる。

しかし球面は可展面ではない。なので、もしも球面投影の方式で3D-CGの投影を考えた場合、地図のメルカトル図法やモルワイデ図法などと同様の問題が起きるので、そういった対策が必要になる。

さて、平面投影は、数学的には単に直線と平面の交点を求めるだけの初等的な方式である。また、2次元で考えた場合の計算式（高校1年あたりで習うような、2点を結ぶ直線と、別の直線との交点を求める計算式）を、比較的に容易に3次元に拡張しやすい。

いっぽうで、円柱投影の場合、長所としては、わざわざ交点を求めなくても、（高校で習うような）三角関数の余弦定理などを使える。だが、球面投影や円柱投影の場合の短所として、その「角度」を算出するのが数学的にやや難しいことと、2次元で考えた結果を3次元に対応するのが難しい。

円柱投影の場合、必要な情報は角度だけなので、円柱の半径または球の半径については無限小であると考えてよい（プログラム上では、半径を書かなくても視界画像を算出できるので）。

すべての投影面で共通する性質

さて、平面投影・円柱投影のどれでも、透視投影ならば共通する性質がある。

それは、もし視界内に複数の点があり、色の異なる点だとして、視界内で観測者の近くにある点によって、観測者の遠くにある点が隠れるとき、それぞれの点の前後関係は、どの投影面でも同じであるという事である。

まず、観測者のカメラ位置を表す点Aと、1つの被写体を代表する点Bを考える。そして、線分ABを延長した無限長の直線Lを考えよう。

そして、直線L上で、仮に点Cが、点Bよりもカメラから遠い位置に（点Cが）あるとしよう。

このような場合で、もし平面投影の場合は、投影面の平面よりも奥にある被写体だけを写すことを考えている。つまり、点A,点Bなは、ともに投影面よりもカメラから遠い位置にある。なので、空間内での２点A,Bの前後関係には、投影面は何の変化も与えない。

このことから原理的には、空間内での前後関係の判定には、単にカメラから放射状に放出される無数の直線を考えて、それぞれの各直線ごとに、その直線上にある複数の点ごとに、カメラからの距離を算出し、カメラから最も近い距離にある点の色だけを視界に表現すれば、前後関係を原理的には簡単に算出できる（Zバッファ法の実装はおそらく、このようになるだろう）。

Zバッファ法は、アルゴリズム的には単純であるが、計算量について難点があり、カメラから放射状に放出する視界計算用の直線（きっと 何百本～何千本・何万本もある）ごとに、それぞれ前後関係を算出しないといけないので、コンピュータの処理速度の高さなどが必要である。

ただし点ごとにZバッファ法で計算すると計算量が膨大になってしまうので、改良法として、面ごとにZバッファ法を計算するという方法もある。

この面ごとのZバッファ法の場合、あくまで近似的なもので、本来なら「面」でなく「点」でないと数学的には正しく前後関係を判定できないので、前後判定される面の大きさとしては、事前になるべく小さな面として　パソコン内では内部処理しておく必要がある。

また、もし一箇所に複数の面があると、うまく前後判定ができない場合の生じることもある。だが普通のゲームでは、そういう一箇所に複数の面が集まる自体はまず無いし、仮に間違った前後判定になっても、事前に面を小さく分割してあれば、間違いの影響も小さくなる。

ただし、面を小さく分割すれば分割するほど、計算量の負担は増えていく。

現在では、GPUなどのグラフィックボードにより、このような面ごとのZバッファ法程度の計算なら、ある程度の新しいパソコンならば、瞬時で可能であろう。

なお、カメラから被写体のあいだの距離のことを「z値」という。Zバッファ法のZとは、そのZ値のことだろう。

Zバッファ法のほかにも「Zソート法」というのがある。「Zソート法」と「Zバッファ法」の違いは、Zバッファ法が各点ごとに計算している一方、「Zソート法」は（点ごと ではなく）大きさをもつ被写体ごとに、奥行きをあらわす値としてZ値を与えておく方式である。

Zソート法は 点ごと ではないので、コンピュータの計算の負担は少ないが、アルゴリズムが複雑化しやすい欠点がある。また、くぼんだ部分のある被写体など、複雑な形状の被写体では、不正確な前後判定になる。

（数値の大きさにもとづいた並べ替え処理はゲームプログラミング/RPG#素早さ順行動のアルゴリズムを参照）

回転などの計算

カメラの向きを変えたり、被写体をどこかを中心軸にして回転したあとの座標を計算したい場合は、

単に、高校数学～大学1年程度の行列の理論の、回転行列の公式をつかえばいい。

なお、四元数でも算出できるが、それは単位、3次元行列または4次元行列の計算を、四元数で置きかえただけの仕組みである。

なお、マイクロソフト社Windowsの3D-CGライブラリのDirectXを使うと4×4行列が出てくるが、これは単に、平行移動も回転行列と一緒に行列であつかえるようにするために、次元を1つ増やしてベクトルを4次元にして、対応する行列を4×4行列にしただけのものである。

数学の教育体系的には、大学1年くらいで習う「行列の同次形（どうじけい）」という理論の応用にすぎない。

行列の同次形とは

回転行列にかぎらず、2×2行列はそれと同内容で一対一に対応する3×3の行列がある。

証明は下記のとおり。（なんと、ネットを検索しても、証明がなかなか、みつからない！　数学書には普通に書いてあるんだが・・・。やはり勉強をする手段は、書物を原則とするにかぎる。）

まず仮に）、2次元の入力ベクトル V を

$V={\begin{pmatrix}v_{1}\\v_{2}\end{pmatrix}}$

とする。（背理法でないので、特に疑わなくていい。）

そして変換行列 A を

$A={\begin{pmatrix}a_{11}&a_{12}\\a_{21}&a_{22}\end{pmatrix}}$

とする。（※ 回転行列でなくてもいいのだが、回転行列を念頭においておくと、次の文の応用がイメージしやすい。）

すると、行列によるベクトルの変換操作は、

$AV={\begin{pmatrix}a_{11}&a_{12}\\a_{21}&a_{22}\end{pmatrix}}{\begin{pmatrix}v_{1}\\v_{2}\end{pmatrix}}={\begin{pmatrix}a_{11}v_{1}+a_{12}v_{2}\\a_{21}v_{1}+a_{22}v_{2}\end{pmatrix}}$

は、こう書ける。（ここまで高校3年のいわゆる「数学C」の範囲。年度により、行列が高校課程から抜けたりする時代もあるが。）

そして、平行移動 をこれに加えるには、単に、平行移動の移動方向に等しいベクトルPを用意して、

$AV+P={\begin{pmatrix}a_{11}&a_{12}\\a_{21}&a_{22}\end{pmatrix}}{\begin{pmatrix}v_{1}\\v_{2}\end{pmatrix}}+{\begin{pmatrix}p_{1}\\p_{2}\end{pmatrix}}={\begin{pmatrix}a_{11}v_{1}+a_{12}v_{2}+p_{1}\\a_{21}v_{1}+a_{22}v_{2}+p_{2}\end{pmatrix}}$

と、ベクトルPを足し算すればいい。

では、上記をもとに、これから行列の「同次形」の概念を説明する。

まず、行列Aとよく似た3次元行列B

$B={\begin{pmatrix}a_{11}&a_{12}&p_{1}\\a_{21}&a_{22}&p_{2}\\0&0&1\end{pmatrix}}$

を用意する。この行列Bが、行列Aの「同次形」である。

そして、入力ベクトルVによく似た、つぎの3次元ベクトルFを用意しよう。

$F={\begin{pmatrix}v_{1}\\v_{2}\\1\end{pmatrix}}$

積AVと同様に、積BFを（数学Cで習うような行列の積の）定義にそって求めてみると、

$BF={\begin{pmatrix}a_{11}&a_{12}&p_{1}\\a_{21}&a_{22}&p_{2}\\0&0&1\end{pmatrix}}{\begin{pmatrix}v_{1}\\v_{2}\\1\end{pmatrix}}={\begin{pmatrix}a_{11}v_{1}+a_{12}v_{2}+p_{1}\\a_{21}v_{1}+a_{22}v_{2}+p_{2}\\1\end{pmatrix}}$

この積BFのベクトルの第1次元と第2次元を見てみると、すでに計算ずみのベクトル AV+P の第1次元と第2次元と同じである。

このように、2次元のベクトルに対する行列変換と平行移動（ベクトル同士の加減算）の合成は、3次元のベクトルに対する行列変換だけに置き換えることができる。

この、上述の行列Bのような形の行列が、「行列の同次形」というものである。ひとことでまとめて、上述のBの形の行列のことを「同次行列」ともいう。次元が変わるのに「同次」というのは奇妙（きみょう）だが、この理由は単に、もとになった英語 Homogeneous を数学者が和訳するときに「同次」と翻訳してしまっただけのことである。 Homogeneous とは「同質」・「同類」のような意味である。

なお、同次行列のことを「斉次」（せいじ）行列ともいう。

3次元ベクトルおよびその変換行列も、同様の計算法により、4次元の同次ベクトルと同次行列とに置き換えることができる。

平面投影の透視投影

原理と公式

一般に平面投影での透視投影では、計算の単純化のため、カメラの向きはZ軸の方向に固定する。

また、カメラの位置は原点に固定する。

カメラを自転させた場合の映像を描写したい場合は、代わりに被写体すべてを反対方向に回転（交点）させることで対応する。

このような仮定は、広く普及している。

この場合、透視投影は、中学レベルの簡単な相似で計算できるので、じつは簡単な比例式で表される。

$x_{s}={\frac {x}{z_{s}/z}}$

$y_{s}={\frac {y}{z_{s}/z}}$

あるいは、式をz関連の変数どうしてまとめて書き換えて、

$x_{s}={\frac {z_{s}}{z}}x$

$y_{s}={\frac {z_{s}}{z}}y$

とも書ける。

ただし、投影面の位置を zs とした。（添字sは「スクリーン」のつもり）

また、 z ＞ zs に位置する被写体だけを描画するものとしている。

なお、この仮定の場合、z軸そのものの座標は x=0、y=0 である。

欠点と対策

このように簡易で表現力の高い平面スクリーン透視投影にも、いくつか欠点がある。

欠点1

欠点のひとつは、観測者のナナメ前方にある被写体が、実際よりも大きく見えてしまうことである。

極端な例をあげると、観測者の真横90度の場所に2メートル離れたところにある被写体は、さきほど紹介した公式に当てはめると無限大に拡大して見える。

このような現象の起きる理由は、遠くの物体の縮小率は、変数zだけによって ${\frac {1}{z}}$倍に縮小するからである。

なので、どんなに真横で何十メートルも離れた位置にいても、真横だとz=0なので倍率は 1/0 = ±∞ となり、被写体は無限大に拡大して見えることになる。

この対策として、真横に近い物体は最初から描画を除外すればいい。

つまり、視界に入る角度を設定しておき、それはたとえば 右60度～左60度 までを視界と定めておき、そこから外れた物体は描画を除外すればいい。

このような処理を可能にさせるために必要な計算として、現在の視界内での被写体の角度 位置を計算する必要がある。その角度の計算のための単純な方法として、単に三角関数 tan タンジェントを使えばいい。

たとえば、 視界内でのx軸方向の角度として$\tan {\frac {x}{z}}$ 、およびy軸方向の角度として $\tan {\frac {x}{z}}$ を計算して、両方のタンジェントとも両方とも一定値の範囲内なら、描画すればいい。

ただし、この方法では、zは一定値以上（たとえばカメラとスクリーンとの距離）でなければならない。

また、近似的な方法だが、三角関数を計算するのではなく、単に、xが一定値の範囲内、yが一定値の範囲内とする方法もある。このx,yを一定値の範囲内とする方法だと遠方にある被写体を描画できないが、そもそもゲームでは遠方にあるキャラクターなどの描画は不要だろう。

ただし、遠方にある山や川などの景色などは、別の方法で描画する必要があろう。

欠点2

平面スクリーンの透視投影では、欠点として、投影スクリーンよりも手前にきた被写体は、根本的に描画できない。

かといって、観測者からスクリーンまでの距離を小さくしすぎると、ゲーム的に不便になる場合がある。

妥協案としては色々あるが、ゲームとして面白ければいいので、一例として、もし被写体がスクリーンよりも手前に来たら、それらの被写体の描画だけ平行投影に切り替えるなどの対策があるだろう。

つまり、ゲーム画面は、（スクリーン幕よりも奥の被写体の）透視投影と（スクリーン手前の被写体の）平行投影との合成になる。

被写体の一部がカメラの裏側に回り込んだら

さて、被写体の一部がカメラの裏側に回り込んだ場合、上記のように単純に、その点の位置だけで描画の有無をきめる場合だと、

たとえば大きな三角形を描画したい場合など、もし、その三角形の3つの頂点のうちの1点だけですらカメラ裏に回り込んだら、もはやその三角形が一部すらも描画できなくなってしまうが（三角形の描画は3点が必要なので）、これは不合理である（一部の頂点が隠れただけなのに、三角形全体が消えてしまうので）。

このような問題への対策は特に決まってはないが一例として、たとえば図形の各頂点などの座標の位置とは別に、さらに代表位置の座標を用意すればよく、つまり代表の位置のx,y,zの座標の変数をそれぞれ用意するのが簡単であろう。

代表の位置は、べつに重心でも垂心でも三点の平均値でも何でもよく、好きなように決めればいい。（べつに面積計算をするわけではないので、重心でなくてもよいだろう）

平面への平行投影

カメラはz軸を向いているとする。

点(x,y,z)を平面スクリーン上に平行投影する場合、単に、zを無視して x,y の値がそのままスクリーンに投影される。

ただし、実際には、奥にある被写体は手前の被写体で隠れるので、zソート法などで隠面処理を考えた描画をする必要はある。

原理を実行したい場合に必要なプログラム環境

もし、（冒頭の章で述べたような）余弦定理による視界の計算をC言語で実行したい場合、

まず、三角関数（逆三角関数も使う）の計算と、平方根の計算が、どうしても必要になる。

C言語で三角関数と平方根を実行させたい場合、標準入出力のヘッダには、これらの数学関数が用意されてないので、

スースコード冒頭にインクルード文

#include <math.h>

で、まず数学関数のヘッダをインクルードする必要がある。

これさえ分かれば、あとは、画面出力の機能のあるプログラム言語を使えば、原理的には3D-CGのプログラムが作れる。

（ただし、国際規格になっている標準C言語 そのものには、画像表示の機能は無い。なので、もしWindowsの場合、たとえば Visual C++ や Visual C# などを使うことになる。本ページではVisual C++ および Visual C# 固有の話題については省略する。）

3D-CGのプログラムは、かならずしもC言語系の言語である必要は無い。

最低限度に必要なのは、画像表示の機能と、逆三角関数と平方根程度の数学計算の標準ライブラリ関数さえ出来ればよい。

ただし、実際には、キーボードなどからの入力の機能なども必要なので、自分の使用したいプログラム言語で、それらのプログラムの方法も調べる必要がある。

なので、原理的にはスクリプト言語でもよく、たとえば JavaScript や python などでも、かまいません。（しかし3D-CGプログラムの場合、商品となるレベルにするには、処理速度の都合で、C言語系でプログラムするのが普通だが。）

もっとも、多くの実用では、自分でC言語でCGプログラムを作ることはしない場合が多く、既成の DirectX や OpenGL などのプログラムを利用するのが一般的です。

それでも、どうしても自作で3D-CG表示プログラムを作ってみたい場合、まず最低限の知識として、上記の逆三角関数、インクルードの方法、キーボード入力機能をもつプログラミングの作成方法、使用するプログラム言語による画面表示の方法、などの知識があることが前提になる。

これらの知識を持たない場合、先にそれらの知識を習得したほうが良い。

なお、C言語にベクトルや行列の機能は無い。なので、もしC言語系のプログラム言語で、ベクトルや行列などに相当する計算をコンピューターにさせる場合は、まず変数をいくつも宣言して、必要なベクトル計算や行列計算のプログラムを作ることになる。

3次元ベクトルを宣言するには、単に、異なる変数を3個、宣言すればいい。

回転行列などの行列は、ここでは単に、座標ベクトルなどのベクトルの変換作業にすぎないから、行列に相当するプログラムを書けばいい。なので、わざわざ行列をつくる必要も無い。（同様に四元数も、わざわざコード中で宣言して作成する必要は無い。）

プログラム例

• ゲームプログラミング/3Dグラフィック/平面スクリーン投影のプログラム例

円柱面投影の透視投影

• ゲームプログラミング/3Dグラフィック/非平面スクリーン投影

で扱う。

なお、自動車運転免許の教習所にあるドライビング・シミュレーターが、 平面ディスプレイをプレイヤー前方の正面・左ナナメ面・右ナナメ面の3面に配置する仕組みになっており、多角柱的な投影面の３面によって擬似的に円柱的・球面的な視界投影面を表現している。

多角柱的な投影面の場合、個々の投影面は平面スクリーン投影に準じるが、投影面全体の関係は円柱スクリーン投影という、やや特殊な事情になる。

ドライビング・シミュレーターのように、コスト的な都合により、ディスプレイそのものを湾曲させることは通常はせず、代わりにディスプレイを複数個配置することで球面的な視界を模擬するのが実際であろう。

原理的にはプラネタリウムなど球面投影も考えられるが、しかしもはやコンピュータ・ゲームの範疇を超えるので、リンク先ではプラネタリウムなどは省略する。上記リンク先では、主に円柱スクリーン投影を扱っているハズである。

中間まとめ

まとめると、平面投影にしろ円柱投影にしろ、

ゲーム映像の場合、原則を透視投影にしても結局、スクリーンよりも手前に来た被写体は、（投資投影でなく）平行投影など別の投影アルゴリズムで描写することになります。

また、スクリーンの奥側でも、真横の方向に近い位置にある被写体は、（アルゴリズムにもよりますが）透視投影ではケタ落ち等が起こりやすいので、平行投影などに切り替える必要があります。

このため、角度または内積を基準として、透視投影の描画の条件を満たした角度位置または内積となる被写体の場合にだけ、被写体を透視投影として描画することになるでしょう。

隠面処理

「隠面処理」とは、隠れた面を表示しない方法のこと。

手前の物体で隠れる部分は、当然、画面に表示されないように工夫する必要がある。

たとえば、ある面Aによって、ある面Bが隠される場合、画面にBは表示させないようにする必要がある。

このための手法はいろいろあるが、共通する原理は、カメラからの向きごとにあるそれぞれの向きごとに、その向きにある複数の被写体（面Aと面B）ごとにカメラから被写体の面の距離（z値）を計算しておき、カメラから遠いほうの面が描かれないようにすればいいのである。

単純なアルゴリズムでこれを行うなら、被写体のそれぞれの面に与える情報としては、Z値のほかにも、カメラからの角度も、面の情報として残しておく必要がある。

カメラからの角度が同じ面どうしで、カメラからの距離を比べるわけである。

カメラから近いほうの物体や面を先に描く方法を、Zバッファ法という。（なお、ほかの方式としては、面ではなく点ごとにカメラから近い物体を書く方法もあるが、しかし計算量が膨大になるために処理速度が悪化する。なので、ゲームのCG手法としては、点ごとのZバッファ法は、あまり普及していない。ただし、（処理速度の必要な）ゲームではなく（映像の緻密さの必要な）商業アニメのプリレンダリングなどの場合ならば、目的・用途に応じて面ではなく点でZバッファするのも良いだろう。目的に応じて手法を使い分ける必要がある。）

被写体が不透明なら、カメラから遠い物体を省略できるので、処理を高速化しやすく、そのため、ゲームにもよく用いられている。

しかし、被写体が透明／半透明な物体の場合に、アルゴリズムが複雑化するという欠点がある。

いっぽう、カメラから遠くから先に描画する場合をZソート法という。被写体に透明の物体を含む場合は、Zソートで描画せざるを得ないだろう。

そもそも論

そもそも論として、かならずしも3D計算を行わなくても、ゲームとして立体的な描画をできる場合があります。

また、既存の商用3Dソフトウェアやフリーソフトなどを使うことにより、自分でプログラムする必要のない場合もあります。

また、そもそも日本のゲーム産業では、3D描画はあまり儲かってなく、儲かってるのはアニメ絵の2次元絵イラストのソーシャルゲームです。ただし、欧米では3D描画が受けることや、アニメ絵風イラストレーターなどもポーズ集がわりに3Dソフトを使ったりするので、そういう事情がある場合にその用途で3Dを使うのはビジネス的に効果的かもしれません。

とりあえず本書では以降、なんらかの理由で3Dの描画を使用したい場合を前提として説明します。

そもそも3Dグラフィックをプログラムする場合とは？

ゲームで、3次元のCG映像を表示する場合、かならずしもプログラミングする必要はありません。

もし、その被写体を見る視点が一方向だけに固定されている場合なら、w:Blenderなどの、あらかじめ一般に流通している3D-CG作成用ソフトウェアで作ったCGモデルを、その視点の方向から見た場合の画像を、ビットマップ画像などとして出力したものを、作成するゲームに追加して表示すれば十分です。どのCGソフトにも、ビットマップ出力の機能はついています。

高速化のための2次元の処理

なるべく単なる2次元画像として処理するほうが、パソコンによる処理も速くなります。

例えば、2次元の横スクロールのアクションゲームのように視点が真横からだけに限定されているゲームの場合なら、たとえ「2次元の横スクロールのアクションゲームだけど、リアルさの表現のために、主人公キャラクターや敵キャラや背景画像は3D-CGで作りたい」場合であっても、Blenderなどの3D-CGソフトで作った主人公キャラなどの形状データをビットマップ画像出力した2次元画像データをゲーム中に表示するだけで十分でしょう。

こういうふうに、あらかじめBlender などの3Dソフトで作成しておいた2次元の画像や2次元の動画などで代用する方式のことを、プリレンダリングといいます。「プリ」とは「前」とか事前とか、そういう意味です。

いっぽう、ゲーム内で画像を表示する直前に3D計算して表示する方式のことをリアルタイムレンダリングといいます。

現在のコンピュータ技術では、映像表現については、ビデオカードやグラフィックカードやGPUなど、映像専用の計算処理デバイスが内蔵されています。

映像の描画は、なるべく2次元ビットマップ画像としてハードディスクやメモリなどに記憶しておいた画像を呼び出すという方式にしたほうが、それらの画像デバイスにより、並列処理的に高速処理できます。

また、ハードディスクやメモリなどの大容量化をするのは、単にハードの枚数を増やせばいいので比較的に容易ですが、いっぽう、CPUを高速化するのは技術的に難しいことが多いのです。

なので、あまり、ゲーム機で描画のたびに毎回3D計算するのではなく(つまり、リアルタイムレンダリングではなく)、ゲーム制作時の3D計算で画像出力しておいた2次元画像データをゲームのたびに呼び出して高速描画するという方式（プリレンダリングの活用）も、ゲームでは処理速度の向上のために必要になります。

2次元画像データで済む事例

真横から見る場合だけにかぎらず、たとえば、RPGで、マップ画面を南の上空から北の地面にむかって斜め45度に見下ろすだけ、とかなら、ビットマップ画像で十分でしょう。

このように、視線が1方向に固定されているなら、たとえ斜め方向の視線であっても、また、どんなに写実的な画像であっても、けっしてゲーム中では3Dプログラミングをする必要はないのです。視点さえ固定されていれば、3Dプログラミングをしなくても単なるビットマップでも表示可能です。

どうしてもゲームソフトでわざわざ3D-CGの処理のプログラムをする場合とは、被写体を見る視点が固定されていない場合で、プレイヤーがゲーム中の映像の視点を360度どの角度にも自由な角度に移動できるような機能を搭載したい場合です。

また、パソコンへの処理時の負荷が、2D画像の表示と比較して3DプログラミングはCPUの計算負荷が大きく、このため、パソコンの性能が不足していると3D画像は処理速度を低下させる原因にもなり、また消費電力も大きくなります。

昨今の携帯ゲームなどでは、消費電力の低減も重要な技術です。

なので、本当に3Dプログラミングをする必要のあるものだけ、3Dプログラミングをするのが好ましいでしょう。

実はゲーム機だけにかぎらず、たとえばパソコンで三角関数や対数関数や平方根などの、小数点以下に無限に桁のつづく数学の関数を使う場合も、実はパソコン内部に三角関数表のような近似値の計算結果があらかじめハードディスクに保存されてあり、関数の使用時には、その数表を呼び出して代入しているだけです。その三角関数の数表を作る場合にだけ、パソコン業者などが超高性能なパソコンを使っているのです。

このように数表などで近似計算しないと、処理速度が遅くなっていまい、使い物にならないのです。携帯用の電卓などの平方根の計算も同様です。電卓では、電力の消費も抑えないといけませんから、そのためにもCPUの負荷を減らすことは必要です。

テクスチャー

テクスチャマッピング

また、市販の3Dゲームでも、実際には、2次元画像と3次元グラフィックとを組み合わせているものも、多くあります。

テクスチャーといって、3次元物体データの指定した面の表面に、画像を貼り付ける技術があります。（w:テクスチャー）

これを使うと、あまりにも複雑な形状を3D的に描きたい場合、大まかな形状だけを3Dで作っておいて、細部は2次元画像で描いて表面に貼り付けたほうが、処理が早くなります。

たとえば、物体表面に描かれた細かな模様などは、いちいち、その細かな模様をすべて3D計算していると、とてつもなく膨大な計算量になってしまうので、普通はそういうことはせず、模様を除いた物体の形状だけを3D計算するのが一般的です。

そして、その物体の3D計算の結果を参考に、画面上での模様の表示位置を算出して、まるで物体に模様を貼り付けるような技術によって、計算量を削減するという技術があります。

このような技術が、テクスチャー技術です。

Windowsアクセサリ「ペイント」などの安価な画像製作ソフトで、テクスチャーとして貼り付けるための二次元画像を製作してビットマップ画像などとして出力しておき、

そのビットマップ画像をBlenderなどで3Dモデルにテクスチャーとして貼り付けておけば、

素人のゲームプレイヤーの目からは、あたかも、ゲーム機内で3D計算をしてるかのように見えます。

なお、プロのゲームグラフィッカーでも、ふつうにSAIとかPhotoshopなどの市販のお絵かき系ソフトで、テクスチャーを作成したりもしており、書籍『ローポリスーパーテクニック』の著者のゲームグラフィッカーの人がそうです。

ISAO 著『キャラクターを作ろう! 3DCG日和』でも、SAIとPhotoshopを用いてテクスチャを書いています。暗黙の前提として、テクスチャの作画には、ペンタブを保有していて、それで描くことを想定しています。

テクスチャーの利点としてテクスチャーにしたほうが処理は速いのはもちろん、副次的なメリットとして、模様の書き換えなどを表示する場合にも、3D部分は共通ですのでプログラム的にもラクに処理できます。

ザラザラした感じの表面なども、普通はテクスチャーでしょう。もしかしたら、高低差のある物体でも、極端に高低差の小さいデコボコなどは、いっそテクスチャとして画像を表現するべきかもしれません。

また、3Dの人間キャラクターの耳の穴とか、鼻の穴とかは、通常のゲームでは、人体の内部から見る機会はほとんどゼロですし、穴の中を近寄って見る機会もほとんどゼロですので、人体のそういう穴は、けっして細部を正確に3Dモデリングする必要は無いのです。せいぜい、鼻や耳の穴の深さ2センチくらいまで3Dデータを作れば十分であり、その深さ2センチの穴の底に、穴っぽい色をした黒色のテクスチャーを貼り付ければ十分でしょう。

なお、かならずしも3D-CGを使ったからって、それだけで、うまく映像的に表現できるわけではありません。たとえば、光源の位置をどうするか、反射の特性をどうするかなど、適切な設計が必要です。

テクスチャーを使う場合、もし作者であるアナタが、あまり上手に映像設計できないなら、ゲームでは、かえってプレイの邪魔になりかえるので、いっそ単純なポリゴン画像に置き換えるか、もしくは、いっそ2次元で絵を書いてしまいましょう。

フィギュア模型の塗装

CG以外でも似たような、テクスチャーと似たようなアイデアは用いられています。

たとえばプラモデルやフィギュア塗装のマニアの業界では、 ガンダム的な巨大ロボットのミニチュアのプラモを塗装する際に、影になりそうな部分に自分で影っぽいくらい色を塗るという表現技法があります。

撮影の際の光の加減の調節では、回折光などの影響により、ミニチュアでは影の部分が明るくなってしまうので、 どうしても影のリアリティを出せないからです。

このテクニックは、たしか1998年ごろにホビージャパンだったかモデルグラフィックスからか出版されたエヴァンゲリオン関連のフィギュア塗装のテクニック本だかホビージャパン特集号かに書かれています。

ntny著『ローポリスーパーテクニック』でも、人物モデルの暗くなる部分は、テクスチャとして、SAIやPhotoshopなどで書いています。

なお色選択のテクニックとして、美少女キャラなどの人体の肌で、影などで暗くなる部分は、単純に明度を下げるのではなく、わずかに赤色を増すように彩度を変えると、キャラの肌の血色が健康的に見えてウケる、というテクニックがこの本の2010年2月の初版第５刷の時点で書籍で語られています。

ただし、実際の市販のゲームの中には、そのまま明度を下げて暗くなる影の部分を表現したりしている作品もあり（たとえばシュタインズゲートなど）、そういう作品でもヒットしています。

なお、アニメ業界でも、キャラではないですが、エヴァンゲリオンのキャラクターデザインの貞本(さだもと)さんという人の1990年代後半の画集（未完作品『オリンピア』の美少女が表紙のヤツのほう）で、美術史の知識として、ゴッホは影には黒ではなく（たしか）緑色を使った、これは彩度を単調にしないため、という美術テクが語られています。なお、画家によっては、緑ではなく紫を使う、という流儀の人もいます。

中学美術で習うような「明度」・「彩度」・「色相」という単語は、こういうふうに20世紀・21世紀のイラスト理論でも使われますので、ちゃんと勉強しておきましょう。

※ 余談ですが、アニメ業界でいう「二次曲線」と、数学でいう「二次曲線」とは、意味が違います。貞本さんの画集の発売当時、なにかの書籍で、貞本さんは、アニメ業界では動画・原画の曲線として「2次曲線は使わない業界」（※ 引用ではなく意訳。手元の書籍が無いので）という話をしたのですが、しかしこれは決して数学でいう「二次曲線」のことではないのです。そうではなく、アニメ業界には、定規を使って曲線を描くという、謎テクニックがあります。定規を回転させながら、定規にそってエンピツで線を書くことで、曲線を書けます。

この定規回転の方法では、書くのが困難な曲線が、アニメ業界でいう「二次曲線」です。　まったくの余談。何かのご参考に。

※ なお、ゲーム専門学校では、高校の数学が苦手な学生のために、授業とは別に高校数学の補習が用意されている場合もあります。このようにゲーム業界では高校レベルの数学は学んでおいたほうが得（トク）です。

※ なお、アニメ業界では、1999年にエヴァンゲリオンの監督の人が、「（高校の）数学3（ 表記は" 数学III "）は科学者・技術者といった理系の人以外は使わねえ」（意訳）みたいなことを何かの書籍のインタビューで答えています。裏を返すと、数学2Bあたりまでは色々な業界で（直接ではないでしょうが）使える可能性がありそうです。エヴァンゲリオンの作中でも「接線グラフ反転」とか「ハーモニクスが（以下略）」とか言って三角関数のCGグラフを出してますし。

思いだしたのでついでに書きますが、その監督は、歴史の年号暗記みたいなのを1年単位でいくつも暗記する能力をようくする受験問題も同インタビューか何かで批判してて、「実社会では誤差3%（5%だったかもしれません）は平気」みたいな事を根拠に言ってた記憶。

なお、誤差3～5%はアニメ業界だけでなく、一般に社会常識として、特に量産するわけでもない低価格で一品モノ（量産品は含みません）の商品・作品の数値などデータには、数％の誤差は含まれます。

（量産品ではない話しかしてませんなので、量産である、世間の食品スーパーの米袋の10kgとかは、もっと厳格かもしれません。詳しい事は知りません。）重量10キログラムを公言する一品モノの商品を買っても、けっしてピッタリと10.00キログラムなわけではなく、たとえば 9.5 ～ 10.5キログラムとかだったりします。

読者は「ゲームとあまり関係ねえじゃねえか」と文句を言いたいかもしれませんが、他にこういう話を語り継ぐ場所が無いので、ご容赦を。小中高の美術教育などでは、こういう大人社会でエンタメ産業とも一般産業とも共通する話は、できないのです。

世間のよくあるシステム・サービスなどの設計では、最初から、数%の誤差が発生することを見越して、余裕のある設計をしています。

マンガやアニメなら、作画アシスタントなども人によって絵柄もクセが微妙に違うという誤差も考慮して、最初から原作者が絵柄を若干の誤差は吸収できるように、少しだけ大げさに身体特徴をデフォルメしたりするわけです。

アニメーションの必要性

コンピュータの環境によっては、入力パッドなどからの入力の受付け反応があまり良くない場合もありますので、もし入力があった場合に画面の変化をして、プレイヤーに入力が行われたことを分からせる必要もあります。

パソコンゲームの場合、作者であるアナタのPC環境と、プレイヤーのPC環境は、パソコンでは一般に違います。また、たとえ商用のゲーム機でも、コントローラーが故障する場合もあります（なので、修理のために取り外せて交換できるようになっている）。

たとえば、主人公キャラが平坦で周囲に何もない大きな平原を歩いていても、プレイヤーがもし（入力コントローラーなどの）移動ボタンを押したなら、移動中は画面が一時的に変わらないとイケマセン。

簡単な方法は、主人公を画面の中央に写し、移動中は主人公が歩いている動画を表示することです。

もし そうしないと、プレイヤーが、はたして移動が正常に行われたのかどうか判別できなくなります。

なお、画像でなく足音のような音を音声出力することで移動表現をする方法もありますし、フリーゲームではそれでも充分でしょうが、しかし世の中には難聴など人もいることを念頭に置いてください。市販の大手企業の販売している商業ゲームでは、そういうバリアフリーもできるだけ考慮されています。なので余裕があれば、やはり画像的に入力反応の分かりやすい画面設計をすべきでしょう。

もし、2次元の横スクロールアクションのゲームなら、入力が正常に行われたら普通は、入力キーの方向に主人公が移動したりしますので、（たとえ主人公が歩く動きをしなくても）判定できます。

しかし、3Dでは、主人公はつねに中央にいるか、そもそも主人公が映らないので、2次元のような判定はできません。3Dにかぎらず、2d-RPGなどでも、もし主人公がつねに画面の中央に表示されるなら、こういう歩き動画の工夫は必要です。

さて、迷路の十字路を、左折または右折したい場合もあります。この場合、曲がり始めの10°〜20°くらいの比較的に小さい回転角での画像が必要です、

もし中割り画像が、真ん中の45°の1枚だけだと、十字路の斜め前方にあった とんがった壁が前方に来た時に、はたして斜め右側にあった壁なのか、それとも斜め左側にあった壁なのか、プレイヤーには不明です。なので、最低でも、曲がり始めの10°〜20°くらいの比較的に小さい回転角での画像が中割りに必要です、

このように、ゲームプレイでは、単に1枚の画像の細かさだけでなく、動画で連続的に動きを表現する必要もあります。

もし、主人公を画面に写さずに、また、移動中も特別な画像を出さないなら、そのゲームでは、もはや、周囲に何もない広大な平原のような空間を出すことは不可能です。

なので、もし、そういう画面設計（主人公を画面に写さない、）のゲームの場合は、そういうふうに、そのゲーム内のマップ（地図）を設計する必要があります。

力学計算は行わない

一般的に流通しているゲームで3D処理のプログラミングを行われている場合、そのようなゲームのほとんどでは、荷重計算や強度計算などの力学の計算は行われていません。

3Dになると映像がリアルなので、てっきり、強度計算などの力学的な計算が行われているように誤解しがちです。

しかし、せいぜい高校物理のレベルの幾何光学の計算しか、行われていません。

こうする理由は、パソコン処理を速くする目的もあります。

荷重計算や強度計算などは、計算を近似しないかぎり、形状がきわめて単純な物体の場合ですら（円柱や立方体や球などですら）、ほとんどの場合は計算に何分～何時間も時間が掛かってしまいます。

しかしゲームでは、なめらかな動画で映像表現する場合などは、画像を1秒間に何十回も描画しなければならない場合もあります。

なので、計算時間の掛かってしまう力学計算は、通常、ゲーム内では行われません。

どうしてもゲーム中で力学的な計算が必要な場合は、近似計算をします。

「ラグドール物理」も参照

たとえば、

高校物理で習う放物線運動のように、質点が運動していると近似したり、

あるいは、伸縮・圧縮する物体なら、内部に、高校物理で習うようなバネが入ってると仮定して近似したり、

あるいは、曲げなどをする物体なら、工業高校などで習う強度計算のように、物体の厚さがうすい金属板のような物だと近似したり、

・・・のように、高校レベルか、せいぜい大学1年レベルで計算を近似します。いわゆる「線形近似」で処理します。

いっぽう、科学者のような、より精密な力学計算は、ゲーム機用のコンピュータでは計算に膨大な時間が掛かってしまいかねず、そのせいで、動画表現に向きません。精密すぎる計算は、ゲームには不適切です。

どうしても、高校物理～大学1年レベルを超えた、力学的にリアルな映像が必要なら、

特撮みたいに、現実世界で模型などをつくってビデオ撮影した動画をゲームに入れるとか、

あるいは空想上の物体なら、

開発中に、ほかの大型コンピュータで力学計算しておいて、その計算にもとづく映像を記録しておいて、その記録映像をゲームに取り入れるとか、（なお、このような手法のことをプリレンダ ムービー という）

そういう工夫が必要です。

書籍『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』によれば、一般にゲームでは、物理学的に正確な流体計算は行わないです。その文献によれば、流体計算では、事前に計算した結果をもとにパターンアニメに落とし込んだり、さらにベクトルデータとして保持するオプティカルフローと言う手法を使うこともあるとのことです。

数学の状況

なお、流体力学の基礎方程式であるナヴィエ・ストークス方程式は、非線型方程式というものの一種です。非線形方程式は、特殊な条件の場合を除いて微分方程式を解くのが数学者でも困難です（まだ解が知られてない方程式すら非線形方程式には多いし、もしかしたら解は無いのかもしれない。解の式があるかないかすら不明）。このため、高校物理のような数式による厳密解を求めるのが、流体演算では原理的に困難です。

一方、光のもとである電磁波の方程式であるマクスウェル方程式は、線型方程式ですので、これは数式でも厳密に表現することができます。このためか、レイ・トレーシングなどの技術は、流体演算と比較すれば比較的に処理は軽いのが現状です。

また、ナヴィエ・ストークス方程式は3次元の場合はまだ方程式の妥当性が証明されておらず、数学上の未解決問題です。（もし証明できたらフィールズ賞です。「フィールズ賞」とは、数学にはノーベル賞はないが、数学においてノーベル賞のような役割の賞がフィールズ賞です。）

つまり、ゲーム機会社が、水面などの流体のCGなどの「リアルタイム レンダリング」などを謳ったデモ映像をプロモーションするかもしれませんが、ああいった映像はすべて、二次元近似のできる場合などやさらに様々な制約・近似を課した特定の事例でしか成り立たない場合だけを想定した近似的なシミュレーション映像です。（もし、そうでなくて三次元の一般的な解によるシミュレーションだとすると、上述のようなフィールズ賞の案件になってしまいます。）

ゲームファンのデマ「最近のゲーム機では流体もリアルタイムレンダで物理学的に（以下略）」（△、おそらくデマ）とかに騙されないように、気を付けましょう。

このデマの原因はおそらく、せいぜい光学計算がリアルタイムレンダリングなのを（マクスウェル方程式は線形方程式なので、正確に計算しても計算量が比較的に少ない）、デマ者はあたかも流体もふくめて全ての演算がリアルタイムかつ精密に物理計算してるのかと勘違いしているだけかと思います。

人類の2020年代の技術で、家庭用ゲーム機程度のコンピュータ資源で精密計算できるのは、せいぜい線型方程式までが限界です。

たとえゲーム業界用語で「物理演算」などの表現が使われていたとしても、流体や（後述の）フリルドレスなどに限定するかぎり非線形的な方程式ですので、物理学的にはあまり正確な計算ではありません。

そしてやはり、数学については、（公式の暗記ではなく、証明を理解するという）深い意味で、数学は勉強するべきです（でないと、デマやハッタリにダマされます）。

また、そもそもポリゴン数が多いと処理が重くなるので、たとえば波しぶきなどの流体のしぶきを一々ポリゴン化していたら、あっというまに描画が停止してしまうので、流体演算はゲームでは、あきらめたほうが良いでしょう。

ディズニーアニメのフリルドレスの事例など

流体演算と同じような計算量の問題は、ゲーム中の巨大生物などの歩行グラフィックにもあります。

たとえば、巨大ムカデのような生物が凹凸のある傾斜を歩くとき、巨大ムカデを地面にメリ込ませたりせずにゲーム速度を維持した描画演算がなかなか難しくなります（少しくらい、地面にメリ込んでいいと妥協するなら可能だろう）。

同様の問題はアニメ映画にも存在します。たとえば2010年くらいの日経サイエンス（サイエンティフィック・アメリカン 日本語版）に紹介されていた事例ですが、アメリカのアニメ映画会社ディズニーでは、3Dアニメ技術の開発においてドレスのフリルの演算に苦慮したといいます。

ドレスのフリルは、フリルどうしがこすれあう接触点が数千個や数万個も膨大にあるので3D演算に膨大な時間が掛かるので、ディズニー社ではスーパーコンピュータを使って、プリレンダ的に描画しているそうです。（なお、日経サイエンスの記事は、ディズニー映画『アナと雪の女王』よりも何年も前の記事です）ディズニー社は、このような計算量の膨大な3D物理演算をなんとか上手く計算するために、科学者を雇用しているほどです。

しかしゲーム産業の場合、プレイヤーにスパコンを用意させることは不可能です。よって、リアルなフリルドレスやリアルな巨大生物など、リアルタイム3D描画はある程度はデフォルメして妥協する必要があり、具体的にはキャラなどが床に少しめり込んだりするのを許容する必要があります。

リアルな女性の長髪なども同様に、スパコン案件になります。この長髪の案件も、ディズニーなどが苦心惨憺して開発していました。ディズニー映画『アナと雪の女王』が映画公開されたころ、例えば子供向けの科学雑誌『子供の科学』で、ディズニーが長髪をバネのようなモデルで近似したことが報じられています。（そのほか、時期は忘れたが日経サイエンスでも似たような解説があった記憶。）

髪は、髪そのものの本数が何万本もあり、しかもその髪どうしが接触しあいます。また、髪の1本自体が曲がります。 このため、もし厳密に計算してしまうと、計算量が膨大になってしまい、計算が事実上は不可能です。

だからディズニーはそのような厳密な方法ではなく、遠隔作用的な反発力で髪の計算を近似しているようです。（※当時にwiki編集者の入手できた科学雑誌ではそれ以上のことが書いてなかったので、詳しくは不明。）

ディズニーは長髪の物理演算の困難のとてつもなさを知っているので、アナ雪に挑戦する前は、トロンという2010年ごろの3D技術を用いたアニメでは、 短い髪で登場人物をデザインしていたほどです。3Dアニメのキャラクターデザインにも、そういう背景があるのです。

どのみちゲームでは、ポリゴン数の問題があるので、長髪のゲーム機でのリアルタイムな物理演算は諦めましょう。

だからファイナルファンタジー8以降の作品が、リアル調な女性の長髪をよく出しますが、おそらくプリレンダ的な処理か何かで、または実写モデルを手本にした3Dモデリングなどで、演算を代用しているハズです。（でないと、もし物理演算そのままだと、スクウェア・エニックス社がディズニーを超える超絶な科学技術力およびスパコンを保有していることになる。）なおディズニーとスクウェアは、『キングダムハーツ』というコラボ作品のゲームを2002年に発売しています。

なお、髪の毛については、そもそもプレイヤーがあまりリアルな髪の動きを普段は求めてはいないという点も、気にする必要があるでしょう。リアルではなく、かわいい動き、かっこいい動きなどを、ゲームやアニメなどの映像の視聴者は求めています。

だいたいゲームに限らずテレビアニメでも漫画でも、登場人物の髪型は、ほぼ、いつも同じ髪型です。また、現実にはありえない髪型のアニメキャラも多くいます。

そもそもアニメやゲームなどの創作物では髪型はキャラクターデザインの時点ですでに、理想的に美しく見える髪形としてデザインされているので、あまりそれを極端に動かす必要も無いのです。 流体のような不定形の物体と違って、髪型には視聴者の好むデザインとの兼ね合いもあります。

だから髪は、アクションシーンや風の強い場合などの場合に、それっぽく髪の毛が動けばいいのです。

たとえば1999年にファイナルファンタジー8が発売されて、CMで3Dキャラ女性の髪の毛がなびくシーンがあったのですが、 それを見た日本の某テレビアニメーターは、「実際の髪の動きとは違う」と言っていましたが（出典は忘れたが、当時のアニメ本であった）、 しかしファイナルファンタジーはそれでも8も8以降の作品も人気の高いままのシリーズです。

ゲーム会社はべつに教育機関ではありませんし、むしろ下手に流体計算などの物理学的事実を勘違いプレイヤーに指摘したせいで、学校の成績に劣等感をもつプレイヤーの屈辱感でも刺激したら反感をもたれてゲームを購入してもらえないでしょうから、ゲーム会社は消費者ターゲット層の勘違いは放置するのでしょう。

やはり、ゲームやアニメなどの娯楽からは、基本的には勉強するのは無理なのです。勉強するには、きちんと国語・数学・理科・社会の教科書を購入して学んでいく方法が適切です。

その他、ゲームに限らず、一般のノートパソコンなどで動作する程度の流体シミュレーターも同様でしょう。流体計算をしているか分かりませんが航空シミュレーターや船舶シミュレーターの類も同様でしょう。だからくれぐれも、「ゲームが駄目なら、航空シミュレーターで代用だ」とかタワゴトを言わないように。

市販パソコンで非線形計算したいなら

どうしても家電量販店で売ってるような市販パソコンで流体計算など非線形したい場合、少ない計算ですら計算結果を求めるのに何十分や何時間も時間が掛かることがあります。

だから、出かける前や自宅なら風呂前や睡眠前などにあらかじめ動作プログラムを起動させておいて、帰宅時や風呂上り後や起床後などに、計算結果を確認するわけです。

理工系の大学生なども、たとえばゼミ前に研究室パソコンでプログラム起動しておいて、ゼミから戻ってきたあとに研究室のパソコンで計算結果を確認するという手順をよく使っています。（特に参考文献の出典はないですが、しかし理系の大学4年生以上の物理系学科や機械工学・電気工学系などでコンピュータシミュレーションを多用する研究をしている研究室では常識的なノウハウですので、疑うなら理系大卒の人たちにでも取材してください。）

教授などは、自分の普段使いのwindowsパソコンあるいはmacパソコンとは別に、オフラインで計算シミュレーション用の Linuxパソコン も研究室に配備していたりするくらいです。

このように流体計算など一部の物理計算シミュレーションは、とても時間が掛かるのです。

こういう計算機活用ノウハウを知っていれば、「ゲーム機でリアルタイムで流体の精密計算」なんて、とても無理な話だと分かるでしょう。

理系の大学でも、スパコンなど使う前にまず、普通のややハイエンド気味程度のパソコンで事前にある程度は検証しておく必要がありますし、バグなどのないことの確認もスパコンより前に必要でしょう。

もちろん、そういった理科系の大学でも、情報科学の学科などでは流体演算を高速計算するアルゴリズムを研究している人もいる大学もあるでしょうし、学園祭・文化祭などの機会があれば、学外の人でも計算結果のデモCG動画を見ることができる場合もあります。

ですが、このデモCGはあくまで特殊な場合の近似例の結果の動画に過ぎず、けっして精密計算ではありませんので細部の精度は期待できません。

世の中には、勘違いして、「頭のいい人はマンガやゲームなど創作物からも学べる」（※これ自体は正しいかも）というのを、

「マンガやゲームに詳しいだけの俺でも頭いいはずだ」（×）と勘違いしてしまって、ロクに普通の国語数学理科社会を勉強していないまま人生を送ってしまっている人もいます。

そういう人の行き着く先は、犯罪者です。偏見ではなく、マンガ出版社である集英社・小学館は、刑務所の教育委託ビジネスを受注しています。

マンガ・アニメ・ゲームだけでなく、テレビのバラエティ番組の類しか見ていなくて普通の国語・数学などの勉強が出来ない人も同様でしょう。

世間には、マンガのキャラが受験勉強を始めたら自分もようやく中学高校の勉強を始めるような人がいますが、しかしマトモな人は、いちいちマンガのキャラが行動を開始しなくても、自分の人生で必要なものを高校くらいの時点で自分から勉強し始めるのです。

まだしも、たとえば「音楽をやってみたかったが親から反対されてその学校に進学できずに経済学部に進学したが、しかし社会人になってカネが溜まったし、 最近のマンガのキャラが音楽を始めたから、俺も帰宅後に音楽を始めてみるか」

とかそういうのなら分かりますが、国語・数学・理科・社会・英語の勉強なんて多くの家庭では反対されないんだから（一部は例外あり）、 普通にさっさと始めるのが普通の人です。

学校の勉強だけでプログラミングは出来るようにならないでしょうが、かといってマンガを読んでもゲームプレイをしてもプログラミングは出来ません。

結局、程度の差はあれ普通のプログラマーと同じように、ゲームプログラミングでも、普通にプログラミングなどを勉強することになります。

普通が一番難しいのです。マンガ『ゴーマニズム宣言』でもそう言ってるし、『行け!稲中卓球部』でも最終回にそう言ってるし、 アニメ業界でもガンダムの富野監督が意訳「あなたの読んでるアニメ雑誌だって、本を運送して書店に届けている（普通の）労働者や道路を舗装工事してくれる人のおかげ」みたいなことを何かのインタビューで言っています。

光学計算

ゲーム中の光学計算ですら、おそらく近似をされたものが使われてるのが普通でしょう。

光の3D計算というのは、正確な光はw:レイトレーシングという、光線の反射経路を追跡していく方法で再現できますが、しかしレイトレーシングには意外と計算量が必要です。

反射した光が別の物体に当たって反射して、　その光が、また別の物体に当たって反射して、　さらにその光が、また別の物体に当たって反射して・・・・・・、

のように、リアルさを追求すると、限度なく、いくらでも無限に計算量が必要になってしまいます。

「反射光の反射光」という現象のように、2次的な反射光があります。

同様に、

反射光の反射光の反射光という3次的な反射光もあり、

反射光の反射光の反射光の反射光という4次的な反射光もあり、

無限に続きます。

なので、ゲーム中での3D計算による反射光の計算では、計算の負担の軽減のため、1次の反射光や、せいぜい2次の反射光くらいで、とめておくべきでしょう。

もしゲーム中で、よりリアルな高次の反射光のような映像を表示をしたいなら、テクスチャーなどを活用すべきでしょう。

つまり、ゲーム機以外の別のコンピュータで高次の反射光を計算して、その計算結果をビットマップ画像などとして出力しておき、その画像をテクスチャーにするわけです。

物理的な光には、反射光のほかにも屈折光や回折光があるということは、

つまりCG的な光の種類の組み合わせにも、例えば

屈折光の反射光とか、

回折光の反射光とか、

回折光の回折光とか、

そういう色々な組み合わせもあります。それら高次の計算をゲーム機で厳密にしてリアルタイム処理するのは、現状のゲーム機の性能では不可能なので、どうしてもテクスチャーのような、なんらかの擬似的な処理が必要になります。

また、反射や、不透明な物体の影の計算では、物体の表面だけが必要ですので、そのような計算の場合には、物体の内部の光学特性データは不要です。

どうしても物体の内部の光学特性データが必要な場合とは、せいぜい、透明な物体に光が差し込んで屈折するような場合くらいです。

そして、ゲームではたいていの場合、せいぜい高校物理で習う屈折の法則のような、屈折率が物体内で均一なものしか、扱いません。

「w:グローバル・イルミネーション」、「w:フォトンマッピング」、および「w:球面調和関数」も参照

環境マッピング

たとえば、中央のオブジェクト（物体）に映りこむ景色を、テクスチャ画像として用意しておけば、環境マッピングになる。

鏡にうつりこむ風景や、金属の光沢などは、正確にシミュレーションして求めるにはレイトレーシングが必要になります。

しかし、レイトレーシングによる計算量は上述のように結構、膨大になります。そのため、アクションゲームなど速度の要求されるゲームでは、あらかじめ制作者が、ゲーム機中の映像について光学計算のシミュレーションをしておき、そのシミュレーション結果にもとづく2次元テクスチャ画像によって光を表現する場合も多くあります。

鏡や光沢のシミュレーションで、上述のようにテクスチャによる代替を行うことについて、「w:環境マッピング」といいます。

しかし、なにも鏡だけにかぎらず、この技術の本質は静的なレイトレーシング結果をテクスチャで置き換えることですので、照明などによる光の明暗のシミュレ－ションも、環境マッピングのようなテクスチャによる代替が可能です。

しかし、環境マッピングの苦手分野として、鏡が移動するような場合や主人公や敵キャラなどのような移動する物体が存在する場合が挙げられます。 そのため別途、移動する物体による鏡面映像などの描画処理を追加する必要がある。

これら「環境マッピング」の技術のように、ゲーム機での光の描画では高速処理のため、あらかじめ基準となる静止物や基準光源などをもとにシミュレーションした2次元画像データをテクスチャなどで作成しておき、もし光源の移動や追加や、移りこむ物体が移動してしまい影が動いてしまったり、鏡に映りこむ風景の変わる等の場合には、追加的に、なんらかの近似的な補正により、基準テキスチャ画像に補正を加えるというような擬似的な方法で、描画を高速処理するという方法も多く用いられる。

1個の平面鏡の中の景色ならレイトレーシングは不要

景色中にある鏡が平面鏡であり、1つしか鏡のない場合、そもそも、鏡のなかの景色を求めるのには、レイトレーシングをする必要は無い。

中学校・高校の理科や数学などで、1個の平面鏡に映る像の見える計算する公式があったのを思い出そう。

鏡に映る像は、平面鏡では、観測者の反対側に、

たとえば、
           鏡
           ↓
人         |

のように、鏡の前に観測者の人が立ってる場合、

           鏡        像
           ↓        ↓
人         |         入

のように、像は、鏡から観測者の距離が等しい。

そして、鏡のなかでは、左右の向きが反対になる。

自分が鏡を見た場合を思い起こせば、右手に持ってたものは、鏡の中の自分は左手にもっている。

つまり、鏡の中の景色は、単に、鏡の外の景色を左右反転したものになる。

さらに、（別章で説明する）「環境マッピング」などの技術と合わせれば、鏡が固定されている場合、移動物体だけを計算すれば済む。

つまり、平面鏡に写る景色を求めるには、移動物体だけについて、鏡の奥の位置に、左右反転した物体を置けばいい。

ただし、この方法ですら、移動物体のポリゴンの計算量が2倍になってしまうので（鏡の外に置くポリゴンと、鏡の中の世界に置くポリゴンとで、2倍のポリゴン計算が必要になる）、ゲーム中の鏡はどうしても計算量を増大させてしまう。

さて、反射をする道具は、鏡だけではない。金属だって反射をするし、水面だって、いちぶの光を反射をする。ガラス表面も、いちぶの光を反射をする。

しかし、ゲーム中の金属や水やガラスなどのすべての反射物体で、移動物体の映り込みの計算を求めてしまうと、計算量が膨大になってしまうので、たいていのゲームでは、ストーリー上では重要でない物体においては、移動計算の写りこみは無視する。

金属や水面の反射では、光沢だけを描画するという簡略化をするゲームも多い。移動物体の写りこみについては、金属や水面の反射では、省略することが普通であろう。

いっぽう、鏡は、ゲーム中のストーリーで重要な意味をもつ場合が多いので、そのような重要な反射物だけ、光沢以外の移動物体の写りこみなどの反射も計算すればいいのである。そして、たいていの鏡は平面鏡であるので、鏡の中の景色は単に外の景色を左右反転すれば済むので、レイトレーシングすら省略できる。

影の描画

影の正確な描画には、レイトレーシング的に光の多く当たったところほど明るく描画するという方法が、いちばん正確である。

しかし、その理想をそのまま実行するには、光の反射や散乱などをたくさん計算しないとならなくなるので、処理が重くなるので、レイトレーシング的な影の描画方法は、ゲームでは、あまり使われない。

そこでゲームでは、よく妥協案として、光源から出たそれぞれの光線ごとに、光源に一番近い物体によって遮られた（光源の）反対側を暗くする、という処理で近似することも多い。例えるなら、隠面処理のZバッファ法を、明暗の表現に応用するような手法である。

まるで影絵のように、光源と遮蔽物の反対側を、暗くすればいいのである。

被写体ごとに、光源に一番近い面だけを明るく描画し、光源に遠い部分を暗くすれば、影の表現になる。

この計算のためには、当然、被写体ごとに光源からの距離を、計算しなければならない。

さて、複数の光源がある場合でも、それぞれの光源の反対側を暗くすればいい。

なお、それぞれの光源による、影と影とが重なったところは、さらに暗くなる。

細かなノウハウ

遠景用のポリゴンデータ

たとえば、カメラの遠くにある物体を、細かく描画しても、無駄になります。

なので、遠くにある物体は、ポリゴン数を減らすという、アイデアもあります。

たとえば、遠くにある建物や地形などを、細かく描画しても、無駄になってしまうでしょう。

なので対策として、ポリゴンデータを2種類用意しておけばいいのです。近景として眺めた場合のポリゴンデータと、遠景として眺めた場合のポリゴンデータの2種類を、制作時に用意しておき、ゲームデータとしてゲーム機に組み込んでおくのです。

近景用では、ポリゴン数を多めにデザインしておくのです（いわゆる「ハイポリ」）。

いっぽう、遠景用では、ポリゴン数を少なめにデザインしておくのです（いわゆる「ローポリ」）。

また、人物でもワキ役のポリゴン数を減らすことは、よく行われます。

技術的な背景として、21世紀のパソコンではハードディスクやメモリに記憶するデータ量と、CPU（またはGPU）の処理速度とのトレードオフとの問題です。

高速化のためには、ハードディスク & メモリの使用量を増やしてでも、CPUやGPUの負荷を減らす必要があるので（現在のハードウェア技術では、それが人類のパソコン設計の限界）、たとえポリゴンモデル設計時の作業負担が増えてでも（※ 設計時にハイポリとローポリの2回のデザイン仕事が必要になるので）、遠景のポリゴンを簡略化することでCPUの負担を減らすという工夫が、市販の3Dゲームなどでも、よくあります。

3Dグラフィックのプログラミング

現代では一般に、3DのグラフィックにはDirectXやOpenGLなどのAPIが利用されます。詳しくはOpenGLなどを参照してください。

しかし、実は、これらのソフトを使わなくても、3Dプログラミングは可能です。

実際、1980年代のマイコンBASICなどのプログラム入門書などを読むと、中学生～高校生向けにワイヤーフレーム式の3Dプログラミングのソースコードが書かれていたりする場合もありました。その程度の初歩的な知識でも、3Dプログラミングは可能です。

もちろん、数学の知識があるのに越したことはないですが、しかし、高校レベルの三角関数に毛が生えた程度の知識でも、3Dプログラミングは可能ですし、1980年代のマイコンBASICのブームの時代から、そういう高校数学レベルで分かる3Dプログラミングの入門書は存在しています。

とはいえ、いまさら3Dソフトをゼロから自作するのは（個人でも不可能ではないが）調べることも多く手間が掛かるので、たいていは、DirectXやOpenGLなど既存のツールを使って、プログラムを作成します。

下記の3Dプログラミングの解説でも、いろいろな数式が出てきますが、数式のひとつひとつは、高校レベルのベクトルや行列、三角関数といった数式です。

行列は、高校の学習指導要領が数年ごとに変わるため、年代によっては高校で習ってない場合もありますが、ここでいう行列とは単に、ベクトルを並べたものです。

行列の計算法について詳しくは高等学校数学C/行列を参照してください。

球体

一般的な3Dソフトでは、球体の3Dは、たくさんのポリゴン面で表現しています。たとえばblenderの球面の表現もそうです。

2Dプログラムだと円や球はプログラム文の1行で書けてしまいますが、しかし3Dの球では何十面もの多くのポリゴン面を使用するという、違いがあります。ご注意ください。

無料3Dソフトで確認したところ、少なくとも blender とメタセコイアはそうです（球面はなん十個ものポリゴン面で表現という仕様）。

数珠（じゅず）とか丸いものが沢山あるゲームは大変。

ゲームではないですが、書籍『キャラクターを作ろう! 3DCG日和』の著者が、書籍中で数珠のポリゴン問題に遭遇しており（大鬼が首輪としてデカい数珠を書けてる3Dモデルが書籍では作成されている）、数珠の球1個を、書籍では粗いポリゴンによってデコボコした多面体のようなもので妥協しています。面が15～20個くらいしか見えない、球のような多面体ですが、しかし数珠だとその球が10個くらい見えてしまうので、10倍の面の数になってしまうので、著者は粗いポリゴンで妥協しています。

blender 入門書では、球オブジェクトを伸ばして、簡単な「ぬいぐるみ」的なモデルの顔や胴体などを作ることも多いですが、しかし頂点数・辺数が多くなるので、「あごをとがらせたい」みたいな一部分だけの変形の際には、操作が難しいなどの理由で、あまり向きません。

じっさい、市販の書籍の後半にある人キャラのモデル例の顔のメッシュを見てみると、球オブジェクトではなく平面オブジェクトを加工して作っています。

ハイポリの場合も最初はローポリで作る

「ハイポリ」と言っても、萌え系の絵柄のモデルの場合、せいぜいメッシュ数はローポリの場合の2倍～3倍くらいまで、です。

あまりにメッシュ数が多くなりすぎると、手作業での修正が困難になります。

なので、ハイポリを作る場合でも、最初にあらめのローポリゴンで大まかな立体を作っておいて、あらめな範囲でヤレル範囲の位置合わせを行って起き、あとから細分化して微調整をします。これが萌え系のハイポリです。

こういった制作工程を知ると、微調整後の3Dモデルのメッシュ修正は困難であり、あとから修正するのは困難だという事が分かります。

比較的ラクに修正できるのは、キャラの向きの修正や、ボーンの向きの修正など、数の限られる要素の修正だけです。

なお、目や瞳は細かくなりがちなので、

• 目のオブジェクトを用意せずに、顔全体オブジェクトに張り付けるテクスチャーの一部で目を表現するか、
• あるいは瞳のオブジェクトを顔の肌の部分とは別オブジェクトの2倍～3倍くらいまでにします。

どちらの流儀にせよ、作り始めはローポリです。

ローポリのモデルでも、土台の形がシッカリしてると、意外となめらかに見えます（※たとえばntny著『ローポリスーパーテクニック』などで紹介されている市販ゲームのポリゴンがローポリで作られてる）。

なので、けっして、見た目の雰囲気のなめらかさに惑わされて、ハイポリでは作り始めないようにしてください。

少なくとも、初心者が作り始めるような普通の3Dゲームでは、作り始めはローポリのはずです。なぜならローポリで作り始めないと、少なくともblenderではメッシュの修正が困難です。

あるいは、もしかしたら、大企業がDirectXで自社開発した自社ソフトの非公開3Dモデリングソフトとか持っているのなら、その会社だけならハイポリでもいきなり作れたり、ハイポリで修正の範囲指定とかグループ指定とかを上手に出来たりできる特殊UIなのかもしれません。しかし、少なくともフリー公開ソフトのblenderを使っている3D初心者には関係ない手法だし、初心者には利用不可な手法です。

※ 余談ですが、こういう事情が分かってくると、（ゲーム業界ではないですが、）アニメ業界の人が背景オブジェクトなどを3Dでよく作る一方でキャラは（3Dではなく）手書きで描きたがるのも、うなづけます。単純に「キャラを手で描くのが好き」というアニメーターが多いという理由もあるでしょうが、それだけではなく、実は動画の使いまわしの頻度が少ないなら手書きのほうが3Dよりも早く作れる場合もある、という場合もあります。

上記のように、細かい萌え絵のキャラ3Dは、作成に手間と時間が掛かるのです。

その他

ゲームエンジン側での3Dデータの編集

ゲームエンジンでも、簡易的には3Dを編集できる場合もあります。

しかし、ゲームエンジンで、あまり高度な編集はできません。仮にゲームエンジンで3Dデータを編集できたとしても、情報不足だったり、難解だったりします。

たとえばボーンの編集などは、ゲームエンジンでは情報不足か困難かもしれません。

なので、3Dモデリングはゲームエンジンに頼らず、blenderなどの3Dモデリングソフトを覚えましょう。

ローポリから始める

ゲーム用に限らず、3Dでは、まず形状のモデリングだけをしても、まったくボーンの設定をしていなければ、なんの3Dアニメーションにも進めません。

なので、形状のモデリングはそこそこにして、さっさとボーンの設定まで進みましょう。

このため、3Dソフトの学習では、ローポリから始めるのが効率的です。

テクスチャなどは、初心者はまだ考えなくてよいです。

市販のプレステなどの3Dゲームのようなポリゴンは、初心者には無理です。あこがれる気持ちは分かりますが、初心者には無理です。

一般的に、初心者は、初代バーチャファイターみたいなカクカクしたポリゴンか、それ以下のもっと粗い極度のポローポリで十分です。

実際、市販の書籍で、初心者むけの入門書にある例も、そういった極度のローポリです。

極度のローポリの３Ｄキャラでいいので、さっさとボーンを入れて、さらにアニメーションをするのが、効率的な学習法でしょう。

また、3Dモデリングソフトで作ったモデルデータを、ゲームエンジンに持ち込む場合には、設定の変更などが必要になる場合もあるのですが、もしその場合にハイポリで作ってしまっていると、各ポリゴン面の設定変更のさいの手作業が多くなって、初心者だと詰む可能性もあります。

たとえば、DirectXはそもそも三角形の面しかサポートしてないですが、しかしblenderは多角形の面をサポートしているので、blenderからゲームエンジンなど他環境への持ち込みなどのさいに設定の変換が必要になったりもあいます。

特にゲーム用途での3Dモデリングの場合、上述のような理由も併せて考えて、ローポリが安全でしょう。

どうしてもハイポリに近づけたゲームを作りたい場合などは、

まずはローポリでいいのでゲームエンジン側に3Dアニメーションを組み込んでみるなど試作品を作ってみて、

ローポリ版のデータも残しつつ、あとから、ハイポリ版に差し替えたゲームを作ってみる、

とするのが、安全かと思います。

Ｔポーズから始める

3D用語で、棒立ちで、腕を左右に伸ばしたポーズを「Tポーズ」と言います。

このポーズでないと、初心者にはモデリングが困難です。

なぜなら、もし腕を組んだポーズなどでモデリング開始してしまうと、たとえばボーンを動かして腕のメッシュ面を下した場合に、腹や胸のメッシュ面まで一緒におりてしまうとか、そういう操作ミスになりやすいのです。

要するに、間接どうしは離したポーズで、モデリングする必要があります。そうしないと、ボーンを動かしたさいに、身体各部のメッシュが意図せぬ動きをするなどします。

このため、Tポーズで、モデリングする必要があります。

また、間接どうしを遠ざける必要もあるので、つまり足も、微妙に離すのがラクです。棒立ちといっても、「気をつけ」ポーズのように足を閉じてしまうと、少しモデリングが面倒です。

人間キャラから始める

ほか、暗黙の前提として、人間以外のイヌやネコなどの４足歩行の動物は、間接の動きが難しいので、初心者は動物は避けましょう。

なお、アニメ業界では、手書きアニメーターですら、イヌなどの動物の動画の練習は後回しです。

動物の１枚イラストの講座はネットを探せばチラホラとありますが、しかしアニメーションの場合は、１枚ではなく動画を何枚も書く必要があるので、間接の動き方を研究しなければなりません。

しかし、ネットには、そこまでの情報はないか、あったとしても初心者には習得が困難でしょう。

3D初心者には、動物の間接の動きの研究・理解までは、無理です。

よって、初心者は、４本足の動物をあきらめましょう。

初心者は、人間キャラをローポリで作りましょう。

どうしても初心者が動物っぽいキャラを作りたい場合、せいぜい、キティちゃんみたいな、デフォルメされた動物っぽい顔のキャラを、２歩足で立たせたもので、ガマンしましょう。

あるいは、動物ではなく、ラジコンカーのような４輪車を簡単なモデルで作って遊ぶ、という方法もあります。

ともかく動物３Dは、間接の動きの勉強が、少し面倒です。後回しに。

Blender3 のアニメーション設定の入門

Blender（ブレンダー）3以降に特有の操作ですが、アニメーションにおける設定をするためのタイムラインなどの表示のためには、画面上部にある「Animation」タブを使います。

画面上部に

レイアウト　モデリング　スカルプト　UV編集　テクスチャペイント　シェーディング　アニメーション　レンダリング　コンポジティング　　　

というのがあるので、そのタブにある「アニメーション」をクリックすることで、アニメーション関連の編集状態にソフトが移動します。

大まかな流れ（Blenderの場合）

1. まず、ローポリで棒人間的な人キャラをモデリング
2. ボーン（アーマチュア）を入れて、ウェイトづけ
3. ポーズモードにして、Rボタンなどで実際にボーンを回転させるなどしてみて、ボーンと一緒にメッシュが動くか試す
4. アニメーションタブでアニメーションに移動。
5. アニメーション編集のタイムライン上で、ポーズモードでボーンを動かし、気に入ったポーズを最初のポーズに登録する。（ポーズモードでないと、以下の動作は失敗する）この例の場合なら、（タイムライン上ではなく）ビュー画面上にマウスカーソルを持ってきてIボタンで「キーフレーム挿入メニュー」を出し「位置・回転」を登録。
6. タイムラインをマウスドラッグで数十フレーム動かし、またポーズ登録。
7. 以下、繰り返す
8. 再生ボタンで、プレビューできる

アニメーションのタイムライン登録時、初心者の場合はボーンは一本ずつ動かすことになります。

なので初心者は、ふつうに腕が２本、足が２本の人間キャラをまずは作りましょう。

もし千手観音とか3Dアニメで作ろうとすると、初心者は過労で死にます。

初心者の場合、キャラの動きは、たとえば腕をグルグル回すだけとか、腕をぶらーんぶらーんと揺らすだけみたいな、非日常で簡単な動作にしましょう。

いっぽう、日常的な基本動作の「歩き」とか「走り」とか「振り返り」とかは、数日前に始めたばかりの初心者には無理です。

手書きアニメーターの初心者ですら、月日を掛けて何枚も練習して、とりあえず「歩き」や「走り」っぽい動きを掛けるように練習していきます。

3dモデリングの場合、ソフトの使い方を学ぶのに時間をとられるので、もはや手書きアニメーターのように「歩き」とかから動きを練習するのは無理です。なので、3dアニメの初心者では、もっと大幅に簡単な、非日常で動きの少ない動きから練習しましょう。

で、ここまでやっても、まだBlenderなど3Dソフト内でのプレビューです。最終的に動画として配布するには、mpegやGIFなどに出力する必要があります。

画面左上のほうに「レンダー」というメニューがあるので、「アニメーションレンダリング」を押せば、ふつうに初期設定に従ったファイル形式での動画用のファイル出力が始まります。

初期設定がどうなってるか、知りません。どこに保存されるかは、元画面側のページで、画面右側の縦に長いアイコン一覧に「出力」プロパティに、出力先のフォルダの表示があるのでそこを見てください。

なお、wiki著者の環境では、出力先フォルダは初期設定ではtmpフォルダでした。

大量のPNGファイルとして、出力されました。

気に入らないファイル形式なら、設定を変更して、再度、レンダリング出力しましょう。

この出力プロパティの下のほうを見続けていくと、「ファイルフォーマット」という項目があって、そこが「PNG」になってました。

これをクリックすると、他の動画形式および静止画像形式（PNGやJPEGなど）にできます。

ファイルフォーマットをffmpegに設定すれば、いわゆるmpeg動画になります。念のため動画コーデックを見ておいて、「H.264」になってれば、たぶん大丈夫でしょう。なぜならH.264がmpegの2020年代以降の代表的な動画コーデックだからです。

しばらく時間が経ってから、出力先のフォルダを見ていって、動画ファイルっぽいのがあれば、たぶん成功です。 あとはそれを動画プレイヤーで実際に視聴できるかテストするだけです。

なお、ffmpeg出力の初期設定のまま試したところ、mkvファイル形式で動画が出力されました。 これをもしmp4形式に変えたければ、「コンテナ」を「MPEG-4」に変えれば済みます。ほかにもoggなど色々なコンテナがあるので、必要な形式に設定して、レンダリングしなおしましょう。

出力先が気に入らなければ、「出力」項目を別のフォルダに指定すれば済みます。ですが、フォルダとして指定する必要があるので、あらかじめ出力用のフォルダを作っておいてください。つまり、外付けUSBや外付けHDDなどに、ファルダ無しでのむき出しで保存しようとしても、失敗するかもしれません。

あれこれ設定をいじる前に、まずは実際にファイル出力してみましょう。

実際にファイル出力してみると、構図や色など、気になる点が見つかるものなので、修正していきましょう。

最初の要修正な出力アニメーションファイルを反面教師にして、もとのモデルの色の修正や、設定などの修正をしていきましょう。

色の修正をするには、右側の縦バーの下から2番目あたりにある「カラープロパティ」で、ベースカラーを目的の色に変えます。これだけだと表示は変わりませんが、zボタンで「マテリアルプレビュー」に表示状態を変えてみると、きちんと色が変わっているのを確認できます。

さらに確認として、動画出力してみて、実際に目的の色になってるか確認してみましょう。

アニメーションタブの時点では、左側のプレビュー画面では色がついていませんが、しかしレンダ出力してみると、きちんと色がついています。

なお、レンダ画面で表示中の静止画1枚だけを保存したい場合、アニメーション出力とは方式がちがいます。

静止画像の出力は、まず

本体側の上部メニュ－バーで「レンダー」＞「画像をレンダリング」

つづけて表示されるウィンドウで、上部のメニューバーにある「画像」＞「名前をつけて保存」　です。

初期設定では、背景が黒、オブジェクト色が灰色で、とても見づらいです。

なので、とりあえず背景用に単なる青空の色の、板状のポリゴン直方体でも作って、キャラの後ろにでも置いときましょう。（なお、カメラ位置によっては、キャラ幅に比べて背景メッシュはかなり横幅が広くなります。ゲーム化の際には、なんらかの対応が必要かもしれませんが、とりあえずゲーム化対応は後回しにします。とにかく、さっさと広い横幅の背景メッシュを追加して、色をつけてしまいましょう。）

そして、アニメーション出力してみて、実際にうまく行くか、試しましょう。

なお、出力動画ファイルは、前回出力したファイルに上書きされます。

さて、出力動画を実際に見てみて、もしうまく行くのを確認できれば、次の工程に移りましょう。

キャラの色をつけていったり、床として草原の緑色の地面とか、あるいは茶色い土色の地面でも、直方体の板のメッシュでも作っておきましょう。

キャラにも、顔や手足の肌色とか、つけていきましょう。

そして動画で出力。

全体的に出力動画の色が暗い場合があるかもしれませんが、画面右の縦メニューアイコンにあるワールドプロパティの設定で解決します。wiki著者の環境の場合、「強さ」を変えて数値を初期値1だったのを4くらいに増やしたら、解決しました。

ほかの可能性としては、ライト設定をしてないから、といく可能性もあります。その場合はライト設定をしましょう。レイアウト画面で、「追加」＞「ライト」で出てくるメニューの中に、光源の種類として「ポイント」とか「サン」とかあるので、初心者は、いちばん設定のラクなサン光源を選ぶとよいでしょう。

こういうふうに、まず動画を出力していって、あとから修正していくのが、3Dアニメの初心者むけの制作手法でしょう。もしかしたら、手書きアニメとは手法が違うかもしれません（どうかは知りません）。

いきなり「最初から設定を理解しきってから制作する」なんて、現代の3Dモデリングソフトでは、もはや無理です。実際に手を動かしていって、それから追加で勉強をすることは、制作中に行き詰ってから、最低限の必要なことだけをネット検索などで調べましょう。

また、3Dアニメではないですが、一般にCGを使ったアニメで言われる制作手法として、「商品になるだけの最低限の品質だけで、さっさと作り終える」というノウハウがあります。『デジタルの「直しすぎ」問題』とも言われます

ゲームの場合、実際のゲーム中での画面で見て問題なければ、それでヨシとします。ntny著『ローポリスーパーテクニック』に、直接は述べられていませんが、そのあたりの事情が下記のように書かれています。

たとえばテクスチャを作画で作る作業などは、制作中の作業では、作業しやすいように拡大して作業するのが普通です。しかし、それだと、実際のゲーム中での表示の大きさとはズレてしまいます。

制作中の拡大画面では上手に作れてると思ったテクスチャが、実際のゲーム画面のサイズに縮小してみると、つぶれたりして見えなかったり、などのミスも初心者にはよくあります。

なので、ntny著『ローポリスーパーテクニック』では、テクスチャの制作中に、実際にゲーム画面のサイズで出力して確認します。

また、ntny著『ローポリスーパーテクニック』では、P.35で、ゲーム中で縮小されているキャラの3Dについて「戦闘中や、街中の会話ではほとんど顔も見えない。そんな中で贅沢なことをやってもしょうがないので、テクスチャ切り替えやモデル切り替えですませてしまっても誰も気付かない」と述べて（※この人の参加したゲームでは、戦闘中や街中の会話では、キャラの3Dが縮小されているらしい）、あまりモーフィングやボーン操作に頼らないことも多い実情を公表しています。

なお、アニメ業界では、修正しすぎないように気を付けつつ、それでも採算の合うように適宜に修正するのがプロです。あるアニメ会社は、あるマスコミのインタビュー記事で「1ドット分の微調整が可能になったというのだ。逆に「やれてしまうので時間をかけすぎる懸念もある」というが、クオリティはやはり向上したという。」と評価されています

メッシュの結合と分離

アニメーションの際、腕メッシュや顔メッシュなど人体のそれぞれのメッシュを結合すると、移動するのに便利なこともある。

結合しないと、移動の際に、身体各部のそれぞれのメッシュを範囲選択しなければならず、やや手間である。

ctrl ＋ J

で結合（join）できる。

問題は「分離」である。

分離は、分離したいパーツを編集モードで選んだあと、右クリックし、「分離」＞「構造的に分離したパ－ツで」で、とりあえず形状だけは分離できる。

しかし、結合の際に、マテリアルプロパティも結合してしまう場合があり（初期設定の無色（灰色）のままだと、マテリアルプロパティの色情報が結合してしまう）、これが上述の「分離コマンド」のあとでも分離しない。このせいの不利益・デメリットは、具体的には、色が独立して変えられない、という事態に陥ることもある。

たとえば、プロパティが結合したままなせいで、顔だけ肌色にしたいのに、服を着ている胴体までも肌色になってしまったりする。

なので、それぞれのマテリアルプロパティをいったん消す必要があり、そのためには、マテリアルプロパティ中にある「×」ボタンを押すと古いプロパティが消えて、その際にプロパティの結合も解除もされるので、新しくそれぞれのプロパティを作り直せばいい。

なお、色をコピーするさい、スポイトやショートカットでは、正確な色のコピーを取れない。よって、色の数値を覚えて手動で調整とか、あるいは、あらかじめカラーパレット登録などをしておく必要がある。

ボーン名とメッシュ名

最低限のメッシュとボーンが作れて、最低限のアニメーションの動画ファイルの出力に成功したなら、

今度はボーン名やメッシュ名などをつけてしまいましょう。

自動生成された名前の Cube.001 とか Cube.005 とかだと、あとから見返したときに意味不明です。

とりあえず、頭 head 、腕 arm_L および arm_R （あるいは arm1とarm2 など） 、足 leg_L や Leg_R など、さっさと命名しましょう。慣習的に、メッシュ名もボーン名も、英語でつけるのが流行です。

あとからより細かい名前に修正しますが（たとえば）、とりあえずはこれで十分です。

初心者の場合、手のひら、足のひらを作るのは後回しで良いでしょう。

ボーン名の命名でよくあるミスが、頭部のボーン名を face にしてしまうミスです。

頭部のボーン名は、face ではなく head です。faceだと頭部の前面しか意味しません。

腕の英語は hand ではなく arm です。

太ももとかスネは、footではなく leg です。footだと、靴をはく部分になってしまいます。

さて、腕の英語は arm でした。

では、上記でとりあえず付けた名前を、用途に合わせて修正していきましょう。

Unityで推奨されている命名の、

UpperArm_L

LowerArm_L

および

UpperArm_R

LowerArm_R

が分かりやすくて実用的かと思います。

Unityで推奨されている命名の、

太ももは UpperLeg_L および UpperLeg_R

スネは LowerLeg_L および LowerLeg_R

が分かりやすいと思います。

英語では thigh とか shin ですが、しかし分かりづらいので、慣習的には使われません。

なお、ボーン名などの末尾にある左右の L および R は、キャラから見た方向です。なので、プログラマー側から見たら逆向きになります。

胴体の命名は、作家やツールによって違いが大きいので、省略。お好きな流儀をお選びください。

修正作業

色付きメッシュの細分化

とりあえず色付きのアニメまで作れたら、あとからメッシュを修正しましょう。

この際、「細分化」が必要です。編集モードで細分化でき、範囲選択でそのメッシュを全体選択します。

しかし、表示モードがマテリアルプレビューだと、すでに色のついているメッシュを細分化できません。

なので、zボタンを押して、表示モードをワイヤーフレームに変えましょう。これで、色のついているメッシュも細分化できるようになります。

なお、周囲に別のメッシュがあると、範囲選択ミスなどのせいで誤動作になります。なので、周囲にメッシュのない場所まで移動するか、周囲のメッシュのほうを移動しましょう。

オブジェクト中のメッシュの一部だけ色付けの方法

メッシュの一部だけを色付けするには、マテリアルプロパティ表示時において画面右側の真ん中あたりにある「＋」ボタンで「マテリアルスロットを追加」

そのマテリアルの色を登録（ふつうの方法と同じ）、

その後、色変えしたいメッシュを選択し、

その後、さきほど登録したマテリアルを「割り当て」で適用。

顔メッシュの作り直し

一通り、動作を確認できたら、オブジェクトを作り直しましょう。既存の細かい球などのオブジェクトを使いまわすよりも、平面メッシュまたは立方体などで作り直しをしたほうが早いです。

少な目のポリゴン数の角柱でバランスを整え、あとからポリゴン数を（２倍程度に）増やして整えていくというのが定石です。

2方向～3方向から見てシルエットがあってれば、この段階では平気です。

よくある構図でのシルエット重視でデザインすべき

※ なお、全身のメッシュについては、正面から見たときの輪郭線（つまり胴体の側面ちかくの線）と、横から見たときの輪郭線（つまり胴体の正面の線。正中線）があってれば平気です。どういう事かというと、カメラから見た場合の前後方向は、たいていのシェーディングでは目立ちません。一方、シルエットは目立ちます。

（※ wiki注）前後方向よりもシルエットのほうが目立つのは、これは3Dに限らずアニメ絵風のイラスト一般でそうです。

ローポリ本でも「シルエット」という用語を用いています。ポリゴン数を減らすために、すべてのポリゴンを細かく作るわけにはいきません。なので、シルエットになるポリゴンだけを重視してデザインするのです。

ゲームでは、キャラが横向きをキープする機会は、じつは少ないです。振り向きや回転などで一瞬だけ横を向くことは多くありますが、しかし横をキープすることは少なく、すぐに正面向き（またはナナメ45度向き）のキープになります。なので、こういったキープの構図での、左右の輪郭線を細かく作ればいいのです。（左右ではなく）前後の立体感は、テクスチャーでカバーするのがコツだという事です。

そもそも論として、『ローポリスーパーテクニック』著者じたいが、横向きをキープしたくないと明言しています。

3Dゲームにおいて、キャラの顔が見える構図で長時間キープされる場合とは、正面またはやや斜め顔の構図です。

ローポリ本では明言されていませんが、どうやら、ゲーム会社のモデラー達、グラフィッカー達が、横向きの構図をキープしたいと思っていないかもしれません。

（※ wiki注）ただし、アニメ産業は異なる。アニメのエンディングの動画などで、しばしば、横向きの歩きのキープ（たとえばドットハック//SIGN のED）、あるいは横向きの走り（たとえばインフィニット・ストラトス 1期のED）のキープの構図のアニメはある。EDでなくとも、たとえばネット検索で「エヴァンゲリオン　横顔」とか「ジブリ　横顔」でググったら、色々とそれらの作品の登場キャラの作中での横顔が出てくるし、その絵の中には作中で長めにキープされていたシーンも多い。

横顔キープの程度は、程度問題で、アニメ業界でも横顔よりも正面・ナナメ顔のほうが頻度が多いだろう。たとえばアニメ雑誌の書きおろしイラストが典型で、アニメ雑誌の書きおろしイラストなどでは圧倒的にナナメ顔が多い（アニメ産業の場合、設定画などを見ないと、なかなか横顔を見れない作品も多い）。ゲームでも、横顔が少ないとはいえ、横顔になるシーンだって存在するという例外もある。

なおゲームの場合、キャラの背中が見える構図も、戦闘シーンなどで存在します。なので、背中の見える構図も、チェックが必要です。多くのアクションゲームやRPGで、プレイヤー後方視点のゲームが多いです。

3Dは色んな視点で見ることに留意

ただし、3Dを作る以上、色んな視点で見ても、破綻しないようにしないといけません。

FGOゲームデザイナーの人の書籍『ゲームデザインプロフェッショナル』によると、3Dのよくあるチェックミスが、「ベストな視点でしかチェックしていない」というものですが、しかしそれだと、ゲームデザインの実務では困るようです。裏から見たら破綻しているとかは困るらしいです。

正面から見たらどうかの確認はもちろん、「真下から見たら？」、「ものすごく近くまで接近して見たら？」など普通のプレイヤーがやらないことまで、ゲームデザイナーはチェックすることもあります。

「ローポリスーパーテクニック」と「ゲームデザインプロフェッショナル」を合わせて考えれば、正面向き（またはやや斜め）・ゲーム画面で表示される向きを基本をしつつも、コスト的に見合う範囲で、他の向きなども破綻のないように作っていくことになるでしょうか。

ISAO 著『キャラクターを作ろう! 3DCG日和』でも、顔ではなくボディですが、とっかかりモデルを直方体の胴、直方の手足で作っておいて 、

ガイドなどのための設定イラストは、初心者では、自分で書くのは不要でしょう。上手い人は自分で下絵の正面画・側面画を描いていますが、しかし初心者には下絵を描く際の勘どころが不明です。下絵を描くのは、もっと3Dを作って慣れてからのほうが良いでしょう。

胴体はさいしょは十数角柱、

手足は八角柱、胴体は十数角柱 で、とっかかりのモデルを作ります。

八角柱よりもさらに少なくても構わず、ローポリスーパーデクニックでは何と最初は腕のメッシュは5角柱です。

なお、ローポリスーパーテクニック本での胴体のとっかかかりの角柱数はあまり明記されておらず不明ですが、初期画像を見ると8～12角柱のていどで胴体を作り始めています。

あとから点を増やしていきます。

そのあと、仕上げのためにその２倍くらいのメッシュにして、胴体なら最終的に二十数角柱で胴体を仕上げ、手足は十数角柱で仕上げています。

けっして、いきなり細部をモデリングせず、ある程度はローポリでとっかかりのモデルを作るのがポイントです。

どうしても球を使いたい場合でも、初期設定の細かい分割の球ではなく、新たに分割の粗い球（縦方向が6～7分割ていど）の球を新規で追加したほうがラクでしょう。

とりあえず、キャラのパーツを上から順に顔から作り直したとしましょう。

たとえば、顔を作る場合、土台となる簡単な立体を作るのが、初心者には把握しやすいかと思います。

たとえば、

簡単な八面体を作る　→　あとから「細分化」などで頂点と辺を挿入していく

のような手順です。

平面を1個つくって、線を選択したあと、 ctrl + F で、面を押し出しできます。

また、線を2つ以上選んで、Fを押すと、その線を通る　折れ面　を作れます。

もし、意図しない奇妙な　折れ面　ができてしまったら、 Ctrl + T で、面を三角形分割できます。

三角形を４角形にしたい場合、不要な対角線を削除 Del で「線を溶解」すれば済みます。

そして、ともかく、とりあえず閉じた顔のような立体の土台を作ります。

あとは、それを「移動」コマンドで、頂点を追加してその位置を移動していって、正面と横から見て形を整えて、顔のような輪郭にしていけば、大体の場合は、そこそこ顔っぽい立体になっています。

鼻のような突起物を足したり、アゴを頭の半分よりも前のほうに移動したり、なんか修正しましょう。

鼻や目の土台の部分の線を書きたい場合、下記のようにアドオンを追加すると便利です。blenderでは、初期設定のままでは、面の上に線を描くことが不可能ですが、しかしアドオンで線を描くことが可能になります。

「編集」＞「プリファレンス」＞「アドオン」で、Snap_Utilites_Line をチェックして有効化すれば可能になります。これを有効化すると、編集モードで左ツールバーに、make line というツールが追加されるので、編集モード時にこのツールで面上に線を描けます。

なお、その際、オブジェクトの透過してる表示設定だと裏側に線を描いてしまったり、線が貫通したりする可能性があるので、透過をオフにしましょう

アドオンのツールボタンは、一度追加しても、blenderを終了すると、ボタンが無くなります。再び使用する際には、またアドオンを有効化しましょう。

make line を使う際、線の基準となる開始点が無いと、なぜか上手く動作しないので、とりあえず細分化などで、耳や鼻の中心線を3～5分割でもして、点を形成しておきましょう。

さて、ローポリなので後頭部とかデコボコしてて見苦しいかもしれませんが、しかしメッシュを増やすのは後回しです。

なお、耳を描く際、make line で横顔に描いた耳の土台の線をそのまま押し出しすると、線の押出になってしまい、立体が形成されません。解決するには、押し出しをする前に、Fボタンで耳の土台の面を形成しましょう。

土台の面を形成後、Eボタンで押し出しします。あとから調整できるので、やや大げさに押し出しをしましょう。

押し出し後、1ボタンや3ボタンを使って、みる方向を変えて、耳っぽい量に調整しましょう。また、細分化で点を増やすなどしましょう。

教本だと一発でうまい位置に耳を押し出せていますが。、しかし初心者では耳の位置や向きをおそらく間違えるでしょう

たとえば、耳の穴のある面は、実は少し上を向いてます。ですが、初心者はこんがらがって耳を下向きにしたりします。

手書きの絵なら、初心者でも顔を描く際には無意識に耳を上向きに書いていても、しかし初心者だと無意識では顔の3Dモデリングには耳の向きが反映されません。やはり、実際に3Dをモデリングする経験が必要です。

比喩的に言うなら、右手でどんなに絵をうまく書けても、左手ではなかなかうまく書けないのと同じです。

やはり初心者には、ガイド用の下絵を練習をするよりも、実際にソフトで3Dモデリングの操作をしてみる経験のほうが必要でしょう。

ともかく、耳を修正しやすいように別オブジェクトに分離しましょう。耳は形状が複雑なので、初心者はオブジェクトを分けないと、顔のホホのメッシュなどと近づいてしまい、修正が困難になります。

まずコピーのため、顔のメッシュ全体をオブジェクトモードで選択し、 ctrl + D でコピーします。

これだと耳を含む顔全体がコピーされてしまっているので、コピー側は耳だけを残して他を削除します。この段階では、まだ別オブジェクトになってません。

耳だけを選択した状態で、右クリックの後、「分離」＞「選択」で、耳が別オブジェクトになります。忘れないうちにオブジェクト名を ear とか mimi （耳） などに変えましょう。

その他、後頭部とかアゴとか修正します。『ローポリスーパーテクニック』の実例の画像を見ると、商業ゲームでも後頭部のメッシュは意外とカクカクしています。頭頂部から後頭部ガワに90度までのリンカク線の数が4個～5個でも、商業ゲームをやれてます。テクスチャーの髪の毛の影の付け方をグラデーションにしてボカすことで、後頭部カクカクをごまかせています。

念のため、時々はナナメなどからも見て、確認しながら修正しましょう。

顔の正しい形が分からない場合、資料を探すことになります。ネットで正しい顔の、いろいろな向きの資料を探す場合、検索ワードに「アニメ」または「イラスト」と入れると資料を探しやすいです。たとえば顔をナナメ上から見下ろす向きで見たい場合「アニメ　見下ろす　ナナメ」みたいに「アニメ」と入れると、希望の構図が出てきやすいです。

写真で探そうとすると、被写体のほうが見下ろしている構図とかが出てくる場合が多く、あまり構図を探すのに役立たない場合が多いです。

人間キャラの耳に関しては、ローポリでもハイポリでも押し出しで作るのが普通です。

顔ばっか作りこんでも胴体が棒だと違和感だらけなので、ある程度の満足いくまで顔を修正したら、続けて胴体を修正しましょう。

ブーリアン

一般に3Dソフトには「ブーリアン」という演算があり、2つのオブジェクトの交差している部分だけを自動で指摘できて、目的として2個のオブジェクトの交差部分だけを残したり、あるいは交差部分だけを除去したりできる。

というか、ブーリアン機能が無いと、精密な3Dモデリング設計では、まったく使い物にならない。3D-CGソフトに限らず、製造業の3D-CAD（3Dキャド）などでもブーリアンという概念を使うので、知らないなら今ここでブーリアンの概念を覚えておこう。

これから紹介する blender のブーリアンの場合、交差部分だけを除去できる。

blenderに限らず3Dモデリング系のソフトでは、ブーリアンによる除去時など演算時に、必要な頂点や線を自動生成してくれるので、とても便利である。（というか、それこそがブーリアンの目的である。もしブーリアンが無いと、いちいち手動でいくつもの点や線を作成せねばならずに、仕事では使い物にならなくなってしまう。）

元ネタの数学の「ブール演算」では、アンド演算（and）とオア演算(or)というのがあって、and演算のほうが交差部分の抽出である。or演算とは、オブジェクトの合体である。しかし3D-CGの場合、合体については別コマンドで対応できるので、慣習的に3D業界では「ブーリアン演算」とは交差部分だけに何らかの演算を適用することを言う。

なお、Boolean とは「ブールの」という意味の形容詞であり、べつにブールのアンド演算という意味ではない。

だが、まあblenderのブーリアンはアンド演算なので、覚えやすい。

• 顔とブーリアン

初心者は、どうせ頭頂部とか後頭部とかアゴ先とか、とんがってモデリングしてるだろうから、そういうのはブーリアンで、それぞれの箇所の頂点・辺を一括で、とんがってない形に整形できる。

なお、実はハゲ頭の人間の頭頂部は、意外と、とんがってる。（裏を返すと、ドラゴンボールの亀仙人とかクリリンとか天津飯のハゲ頭のなめらかな丸みは、じつは骨格的にはウソである。）

だが、実際のとがり気味の頭頂部は、世間では違和感を感じる人が多いので、モデリングの際は坊主キャラであっても頭頂部は丸くしておくのが無難であろう。

• 操作の手順

まず、面から飛び出てる部分を切り抜きたい場合でも、決して平面で切断すべきのではなく、厚みを持った直方体で切断するようにする。

なぜなら、平面で切断しようとしても、平面のどちら側を残すのか、ソフトの挙動が不安定だからである。

いっぽう直方体で切断する場合、blenderでは直方体に含まれる側が除去される仕様である。なので、切り抜いて除去したい部分を立体で覆えばいい。

直方体に限らず、球でも多面体でも閉じた立体であれば、その立体に含まれる側が除去される仕組みである。

本ページでは、この直方体の立体をハサミ側としよう。

ハサミ側の立体を十分に大きくして、切られる側のオブジェクトの外周部を面のひとつに含むようにする。 外周部が横断してないと切断に失敗するので、大き目にしておこう。

その後、「モデファイアプロパティ」　＞　「モデファイアを追加」　＞「ブーリアン」 スポイトで、ハサミ側オブジェクトを選択。

その後、ハサミ立体を非表示にすると（画面の右上のオブジェクト構成欄で目アイコンをクリックで表示を切り替えできる）、たしかに切られてるのが目視できる。

だがまだ適用されてないので、ブーリアンプロパティ上で Ctrl + A のショートカットキーで適用になる。（なお「適用」は英語でapply。）blender3系の場合、ブーリアンプロパティのどこにもapplyボタンが見当たらないので、ショートカットキーで適用を行うことになる。

あとは、空洞になっている切断面を、 Ctrl + F で面を生成し閉じればいい。

このままだと、レンダー時にハサミ側の立体が残るが、画面右上のオブジェクト構成欄の目アイコンの横にレンダーの切り替えアイコンがあるので、それで非表示にできる。

ボーンの作り直し

腕や足などのメッシュを修正したら、そこのボーンの修正も必要になるでしょう。

ボーンの修正時に、構成がよく分からなくなったら、ボーンを消して作り直すのが早いです。ビュー画面でボーンをクリックして、delete ボタンで消すのが早いし分かりやすいです。

あるいは、エラー「ボーンヒートウェイト」とかで手に負えなくなったときも、同様にボーンを消します。

ペアレントしているボーンを delete し切れば、勝手にペアレントしていたメッシュの階層は、元あった階層に戻ります。

ただし、なんか右上の構成バーで残骸が残ってるので、「アーマチュア」とか書いてあるのを右クリックで「削除」して、完全に消します。

そして、また新規でボーンを作り直します。左上の「追加」でアーマチュアを追加です。

そしてペアレントし直しです。

腕は、手のひら指の関節や、指の関節を作るので、なんども作り直しでしょう。

手のひらについて、手首から指の付け根までの関節は、実はあまり曲がりません。初心者は間違えます（この段落のwiki編集者じしんがそう間違えた）。

曲がり量が多いのは、指の付け根のぶぶんの関節です。

いっそのこと、腕と手を別オブジェクトにするのも手かと思いましたが、それだとアニメーション時に手こずりそうです。

ただし、『やわらか3D教室』では画像を見た感じ、腕オブジェクトと、手オブジェクトを、別オブジェクトにしているっぽいです（指は手オブジェクトに含めている）。

腕や足などのメッシュは、胴体メッシュとは別でも構いません。『やわらか3DCG教室』でも、胴体ボーンと手足ボーンとを別々のオブジェクトとして分けています。ボーンも同様、分けても胴体と手足を別オブジェクトに構いません。ボーンは、手ボーン・足ボーンを胴体ボーンとは別々のボーンとして作っても、あとからでも統合できます。

初心者向けのローポリなら、統合なんかせずに別々のボーンのままにしておくのも手かもしれません。『やわらか3DCG教室』のローポリ手本のボーンが書籍の画像を見た感じ、足ボーンを胴体とは接続せずに、別々のボーンの感じです。

なお、このローポリのキャラの手、5本指だけど、そもそもボーンが無い。5本指を書くからってボーンを必ずしも作らなくていい。

『やわらか3DCG教室』では特に名言はしてないですが、手の指はいっそメッシュ側でポーズを直接的に指定してしまうのも策の一つ。

なお、足の指は、どの教本でも素材キャラが靴を履いており、足の指を見せず、よってそもそも足の指はメッシュも無く、指ボーンも無い（「やわらか」本、日和本、ローポリスーパー本、のどれも靴を履いてて、足指のメッシュ自体が無い）。

暗黙の前提だが、服と皮膚は一体のメッシュであり、どの教本でもそうである。

だから、もしキャラが靴を履いてたりして足の指が隠れるなら、足の指のメッシュ自体を作る必要が無い。

なお、『やわらか3DCG教室』本に擬人化の動物キャラの見本（２足歩行のイヌネコっぽい動物の顔の少年）があるので裸足（はだし）なので足の指が出ているが、しかし動物キャラのボーンは5つではなく、文章の説明が無いので不明だが、画像を見た感じ、2～3個のボーンで代用しているようだ。

足の指なんて可動範囲が小さいので、ボーンをいちいち　5本×3関節＝15本　もボーンを作る必要は無い。

『3DCG日和』の鬼キャラは裸足で足が4本指だが、そもそも教本ではボーンを作ってない（鬼は、メッシュの作り方だけ紹介）。

なお、『やわらか3DCG教室』のテクニックとして、文章では語られていませんが、腕の付け根を、胴体メッシュ側に含めています。

解剖学・動物学的には本来なら、腕は動物の前足に対応、足は動物の後ろ脚に対応するので、腕の付け根を胴体メッシュに含めるなら、足の付け根も胴体メッシュに含めるのが解剖学的ですが、しかし『やわらか３D教室』では、後ろ足の付け根は胴体メッシュに含めていません。

※ なお、ネット上にあるイラスト講座（アニメ絵風イラストだとする）の線画の講座でも、よくよく手本の素体イラストを見ると、胴体の練習用の素体はふつう、腕の付け根と、足の付け根とが、胴体の素体の一部として含んでいる形として素体イラストが提示されている場合が多いです。なぜなら、イラスト講座主は明言していませんが、一般に、作画で胴体を書く際に、

もし仮に胴体素体に手足の付け根が無かったとすると（背理法）、

あとで手足の本体の太さを付け足す際に、もし胴体サイドの手足の付け根という土台の太さがミスっていると、胴体ごと書き直しになってしまうので（手足の付け根を胴体サイドで書かなかったせいで）、そのせいで後戻りが大幅に発生してしまうミスになってしまうミスに拡大してしまうのです。

なので、そういった後戻りの防止のための作画テクニックとして、胴体を書く際には早めに手足の付け根を書いてしまう、という作画テクニックがあります。

別の流儀もあります。

メタセコイアなどのように、オブジェクトをさらに分類できるレイヤー機能のあるツールの場合、オブジェクトとしては（頭から足先まで）全身メッシュ、全身ボーンと一体として作りますが（胴体オブジェクトなど個別のオブジェクトは作らない流儀）、しかしレイヤーを胴体、足上部（UpLeg）、足下部（DownLeg）、などと別々に分ける流儀です 、

※ wiki編集者がメタセコイアを使ってないので、勘違いしているかもしれません。詳しい人、手助けを頼みます。

なお、メタセコイアでいうレイヤーに相当するのは、blenderでは「コレクション」という機能です 『【Blender】レイヤーの使い方【移動・表示】』2020.12.27, 2016.06.18, 。

ボーンを作り直したい場合、「リンクの切断」をして、・・・（※ 調査中）

ボーンは生物学的な骨とは違う

初心者レベルでは考えなくていいですが、「ボーン」と言いつつ、これは単に周辺メッシュを代表する軸でしかないので、生物学的には骨の入ってない場所にもボーンは入ります。

具体的に言うと、女性の髪の毛のフサ・タバとか、ボーンが入ります。なんだか触手というか、ギリシア神話の蛇女メデューサみたいで、慣れるまではキモイです。

スカートなど非生物にも、ボーンが入ります。慣れるまで、なかなかキモイです。

要するに、周囲の関節とは別に、独立して動く可能性のあるものは、ボーンが入ります。

たとえばスカートなら、腹の関節や、足の関節とは別に、風が吹いたりとかでスカートが独立して動く可能性があるので、スカートにもボーンが入るのです。

また、ボーンは軸でしかないので、なので顔のボーンも、一本の軸です。位置的に顔ボーンは、なんだか鬼のツノのように見えたりするので、慣れるまではキモイです。

本数もちがう

また、腕の、肘から手首までの骨は、生物学的には2本ですが、しかし3Dソフトのボーンは1本だけです。ボーンは動きを指定するための手段としての軸でしかないので、生物学的な骨の数には対応しません。

おおむね、関節と、次の関節までのあいだがボーン1本ですが、しかし多いぶんには問題がありません。

たとえば、肩甲骨のまわりの動きとか、シミュレーションするのは大変ですので、そういうのはせず（3Dソフトにもそういう機能はない）、腕の付け根のあたりに、（生物学的には関節のない位置なのに）ボーンを1～2本ほど足す場合もあったりします。

足の付け根の、股関節の周囲も同様で、ボーンをいくつか足す場合もあります。

また、肩甲骨とか股関節とかの関節の位置について、腕や足のつけ根のボーンの位置は、対応させる必要はありません。

土台ではない

「骨組み」などの日本語もあるので、ボーンをなんとなく周辺メッシュの土台っぽくイメージしてしまいがちですが、しかしボーンは土台ではなく、ボーンは周辺メッシュを動かすための手段にしか過ぎません。

足の太もものボーンがわかりやすいのですが、生物学的な骨とは、位置がやや違います。

生物学的な太ももの骨は、やや外側によっています。美術解剖学などでも、そう習います。イラスト講座などでも、そう習うかもしれません。

ですが、3Dのボーンは、太ももの真ん中に作ることもよくあります。なぜなら太もものメッシュを動かすためなら、それで十分だし、そのほうが確実に制御しやすい場合もあるあらです。

市販の書籍ではいちいち説明してないですが、しかし書籍にあるボーンの位置を見てみると、生物学的な骨の位置とは微妙にちがっています。

このように、美術解剖学における骨や筋肉などの知識は、残念ながら3Dモデリングには、あまり直接的には使えないのです。少なくとも初心者レベルでは。

とはいえ、プロのレベルだと、美術解剖の専門書を購入して読み込んでいます。書籍『ローポリスーパーテクニック』の著者は、『目で見る筋力トレーニング』（フレデリック・ドラヴィエ著、大修館書店）という筋肉本を進めています。

インストール後の検証と再起動など

ゲームエンジンも3Dモデリングソフトも、インストールするさいの容量が膨大で、何十ギガバイトもあります。

インストールしたら、すぐに使いたいでしょう。学習の手始めとしては、それで良いし、まずは動かして覚えるのが効率的です。

しかし、一見すると正常にインストールされたように見えて、実はまだインストールが正常に完了していないかもしれない可能性があります。

だから、ためしにネットの解説サイトやあるいは市販の解説書を参考に操作してみて、どうしても上手く動作せずに操作が失敗する場合、もしかしたら、単にインストールがまだ正常には完了してない場合もあります。

3Dソフト側のインストールの問題だけではなく、windows側のdirectX関係など関連プログラムのインストールなどが、もしかしたらまだ途中かもしれません。

そのような場合の可能性も考えて、なんだかインストール直後の操作の結果がおかしい場合などは、いったんパソコンを再起動してパソコン全体を更新するなど、してみましょう。

たとえインストール初日の1日目にうまく動作しなくても、3日後や1週間後などにまたチャレンジしてみましょう。なぜか数日後には、前回と同じような操作なのに、こんどは正常に動く場合もあります。

インストール時の表示の「インストールが正常に完了しました！」なんて文言、信用してはいけません。

操作しながら学ぶ

3Dソフトはあまり理論化されておらず、それほど規格統一などもされておらず、よって、操作しながら、使いかたを学ぶ必要があります。

特に blender はショートカット・キーを多用しなければいけない仕様なので、操作を体感的に覚える必要があります。また、ネットでググりながら使い慣れていく必要があります。

けっして、「先に書籍などで情報を覚えてから、ソフトを操作してみる」なんてしないでください。それだと挫折します。

現代では無料の3Dソフトがあるので、書籍を買うより先に、まずソフトを使い慣れてから、そのあと、書籍を読むなどしてください。

あるいは、書籍を買うより先に、YouTubeなどにある講座動画を見るのも良いでしょう。上手い人の操作を見るのも、勉強です。

※ ネットの中には、真逆のことを言う、デタラメな人もいます。つまり、「ソフトの仕様書や規格書類などを読み込んでから、操作方法を勉強しろ」みたいなデタラメを言う人も、実際にいます。この段落のwiki著者がソケット通信の学習時にそういう人にネット上で遭遇しました。

ですが、少なくとも3Dモデリングソフトは、そういう仕様書みたいなのを読み込む学習方法ではなく、最低限の操作マニュアルだけを見てあとは実際に操作をしながら覚えていくものです。

ザッカーバーグいわく、「完璧よりも、早く終わらせろ」という格言もあります。

一つのソフトを集中的に慣れる

3Dソフトはまだ規格統一などされておらず、このため、一つのソフトをまずは集中的に学ぶのが効率的です。

もし、学習中にコロコロと使用ソフトを変えると、基本操作など覚えなおしになってしまい、非効率です。

directXの初期設定

最近の入門事情の難しさ

DirectX プログラミングについて2023年の時点では、書籍やネットによる独学が難しくなってしまっており、なんと出版市場から入門書が無くなってしまってる。

かつて、工学社からDirectXプログラミングの初心者むけのプログラミング教本のシリーズが存在していたが、2015年の『DirectX 11 3Dプログラミング』を最後に、DirectX12以降のバージョンが出ていない。さすがに7年以上も前の教本を使うのは、設定など大きく変わっている可能性があり、初心者には難しいし、そもそもこの教本がOSに想定しているWindows7がサポート切れであるので、活用が困難ある。

なお、DirectXの2023年現在の最新バージョンはDirectX12である。

歴代のDirectXの傾向として、数字がひとつ変わっただけでも、初期設定などは大きく変わる。

工学社以外の他社から分厚い解説書はいくつか出ているが、しかし出ている本はどれも入門的ではなく、入門者には分からない説明がいくつか抜けてしまっている状況である。

しかもネットを調べても、最新のDirectX12のプログラミングの解説サイトは少なく、それどころか一つ前のDirectX11の解説サイトすらネットには少ない。

こういう出版状況になってしまっているので、もし周囲にDirectXプログラミングに詳しい先輩（でなおかつ親切に教えてくれる先輩）などのいない環境の独学者は、就職・自己アピールなどのさいには上述のような出版事情を話して、代わりの勉強として、3DモデリングソフトやDXライブラリなど別の勉強をするしかないだろう。

本文

※ 初期設定の解説がネット上に少ない、説明あっても各所にバラバラで不便なので、まとめる。

内容は調査中.

市販の書籍の中には、要点を押さえてないクソ本も多い。

※ インストール方法については省略。ネットにたくさん転がってるので。

DirectX 単体では、ウィンドウを作れない。DirectX用のウィンドウは別途、windows APIで作る必要がある。

nanodなので、最終的に、

• 「Windows デスクトップ アプリケーション」
• 「追加のオプション」チェックで、「空のプロジェクト」

の２つを作る。

ただし、「追加のオプション」を利用するためには、「windows デスクトップ ウィザード」を利用しないといけない。 なぜならテンプレート選択時のメニュー「windows デスクトップ アプリケーション」だと「追加のアプリケーション」が存在しないので。

このためか、解説サイトなどでは、デスクトップウィザードを用いて設定している

解説サイト大手のWisdomサイトだとバージョンが古いのか名前が違うが、しかし「追加のオプション」のあるテンプレートを選んでいるので。

※ もしかしたら、万が一、ここで「追加のオプション」を忘れても、 「ファイル」＞「新しい追加」＞「新しいプロジェクト」 で「空のプロジェクト」の追加でも行けるかもしれないが（未確認）。しかし、最初から　やり直すのが無難だろう。

さて、プロジェクト画面が表示されたら、これからソリューションエクスプローラーをいじる必要があるので、もし表示されてなかったら、メニュー欄の「表示」＞「ソリューション エクスプローラー」で表示できる。

プロジェクトに、direct3D関連のライブラリを手動で追加しなければならない 。

そのため、メニュー欄の「プロジェクト」＞「プロパティ」によって、プロパティページを開く。

「構成プロパティ」→「リンカー」の先にある、「入力」と「コマンドライン」をそれぞれ設定する必要がある。 「構成プロパティ」→「VC++ディレクトリ」 の設定も必要らしい。

「VC++ディレクトリ」については、閲覧してみて、「インクルード」と「ライブラリ」のディレクトリが、それぞれ

$(VC_IncludePath);$(WindowsSDK_IncludePath);

$(VC_LibraryPath_x64);$(WindowsSDK_LibraryPath_x86)

のようになっていれば問題ない。

なお、この内容は、DirectX SDK と boost のインストール先のパスを指定している。

「構成プロパティ」→「リンカー」→「コマンド ライン」＞で、「追加の依存ファイル」に　directX12の場合は

d3d12.lib;dxgi.lib;%(AdditionalDependencies)

を追加する。

場合によっては、代わりに

d3d12.lib;dxgi.lib;d3dcompiler.lib;%(AdditionalDependencies) を追加する。

さらに工学社本いわく、「構成プロパティ」→「リンカー」→「入力」で、「追加の依存ファイル」に

d3d10.lib d3dx10.lib dxguid.lib dxerr.lib

を追加。ただし工学社本はDirectX10時代のものなので、現代ではライブラリが違うかも。

なお、科学者の水野さんは、バージョン不明だが「追加の依存ファイル」に、

dsound.lib dinput8.lib dxerr9.lib d3d9.lib d3dx9.lib d3dxof.lib dxguid.lib winmm.lib

を追加すべしと言っている。

参考文献

• WisdomSoft
• (pdf) 水野晴規『DirectX プログラミングの準備』 2010/06/12
• ゼロから始めるDirectX11ゲームプログラミング入門 #1「Visual Studioのインストールと新規プロジェクト作成」
• (パワポ) 金子邦彦研究室『DirectX勉強会 第1回』
• 第二 I/O 編集部『DirectX10 3Dプログラミング』、工学社、平成19年(2007年) 7月20日発行

ケーススタディ

カメラの配置

3Dゲームを作るときにはカメラの動作を決める必要があります。2Dの表現ではキャラクタを上から見る、斜め上から見るなどの表現がなされますが、それらはどれも場面をある1方向から見る表現でした。一方、3Dで場面を作るときには、それらはあらゆる方向から見る事が出来るので、見る人の視点によって描画される内容を変更する必要があります。

簡単な表現では、カメラの位置はプレイヤーが動かすキャラクタの場所に固定します。このとき、プレイヤーキャラクタが画面内に映らなくなる表現とカメラをプレイヤーキャラクタの後方に配置して、プレイヤーキャラクタを画面内に含める表現があります。前者の表現はFPS（First-Person shooting: 1人称シューティング）でよく用いられます。

基本的に3Dでの描画を行うには、それぞれの物体に対して座標を与え、それを適切な角度から2Dへの射影を行う事でなされていました。このとき、3Dの描画にOpenGLを使うとすると、各物体の座標の与え方にいくつかの制限が加わります。例えば座標の原点は常にカメラの位置に固定される、画面上方向は常にy座標とする、などです。

幸いにもgluLookAt関数を利用することで、この制限を乗り越えることができます。gluLookAt関数は、カメラの位置、カメラが向いている方向、上方向の3つの3次元ベクトルを用いて指定する関数で、カメラの位置を変更するのと同じ効果をもたらす行列を作成し、現在選択されている行列にかけます。通常の状態ではカメラの位置(0,0,0)、カメラが向いている方向(0,0,-1),上方向(0,1,0)となり、この時かけ算される行列は単位行列に等しくなります。 gluLookAtの行列は次で与えられます。

まず、

${\begin{pmatrix}s[0]&s[1]&s[2]&0\\u[0]&u[1]&u[2]&0\\-f[0]&-f[1]&-f[2]&0\\0&0&0&1\end{pmatrix}}$

で表される行列で、座標の方向を調節します。ただし、

${\vec {F}}={\vec {\textrm {center}}}-{\vec {\textrm {eye}}}$,${\vec {f}}={\vec {F}}/|{\vec {F}}|$, $u'={\vec {\textrm {up}}}/|{\vec {\textrm {up}}}|$, ${\vec {s}}=f\times u'$, ${\vec {u}}={\vec {s}}\times {\vec {f}}$

を用います。更に、カメラの位置を動かす為に、

glTranslated(-eyex, -eyey, -eyez);

を実行します。

ここでは、上の変換のうちで座標の方向を変更する行列について説明します。この行列の導出にはいくつかの前提が必要となります。まず、変換後の座標系ではカメラは-z方向を向いています。またこの時、画面上方向は必ずy方向になります。これらはOpenGLの座標の取り方から来る制限です。ここではもう1つの制限として、gluLookAtで得られる行列が直交行列であることを仮定します。直交行列の各行と列は、お互いに直交する単位ベクトルとなり、直交行列の逆行列は元の行列の転置行列になります。詳しくは線型代数学を参照して下さい。

行列を求める方針として、${\vec {f}}$を$-{\vec {e}}_{z}$に変換し、${\vec {u}}$を${\vec {e}}_{y}$に変換するような行列を探します。このような行列をPとおくと、仮定からPは直交行列なので、

${\vec {e}}_{y}=P{\vec {u}}$

より、

${\vec {u}}={}^{t}P{\vec {e}}_{y}$

が成り立ちます。最後の式は具体的に計算できて、

$(p_{21},p_{22},p_{23})=(u_{1},u_{2},u_{3})$

が得られます。同様にして、

$(p_{31},p_{32},p_{33})=(-f_{1},-f_{2},-f_{3})$

が得られ、求めたい行列のうち6つの要素が得られたことになります。Pが直交行列という仮定を用いると、$(p_{11},p_{12},p_{13})$は、${\vec {u}},{\vec {f}}$に直交する必要があります。このようなベクトルは${\vec {s}}$に比例する必要があります。ここでは右手系の座標系を保つために、

$(p_{11},p_{12},p_{13})={\vec {s}}$

と取ります。これで元の変換行列が得られたことになります。

プレイヤーが動かすキャラクタの位置と向いている方向を表す構造体をcameraとし、その値を次のようにおくと（cはcamera型の変数で、この変数がプレイヤーキャラクタの位置と方向を保持しているものとします）、

typedef struct {
  double x,y,z,dx,dy,dz;
} camera;
camera c;

カメラの位置をプレイヤーキャラクタの位置に変更する方法は次のようになります。

void set_camera(){
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
gluLookAt(c.x,c.y,c.z,c.x+c.dx,c.y+c.dy,c.z+c.dz,0,0,1);
}

ただし、ここでは最後の引数(0,0,1)で、上方向がz方向であると定義しました。

上の変換では、カメラの位置を変更したのですが、これだけだと変更された後の位置を中心として、長さ2で表される立方体の中の物体しか描画されません。これはもともと投影行列が単位行列だった時には、原点を中心として長さ2の立方体内の物体しか描画されないことと対応しています。より遠方の物体を描画するには、glOrtho, glFrustumの両関数を利用することができます。一般的なゲームでは"遠方のものは小さく見える"といった表現がなされるので、ここではglFrustumを用います。glFrustumの引数は状況によりますが、x,y方向に関係する引数を大きく取ると視界が広くなり、z方向の座標を大きく取ると遠くのものまで見えるようになります。ここでは

glFrustum(left,right,bottom,top,near,far);

をgluLookAtの1つ前にいれます。

実際にこの関数を使ってプレイヤーキャラクタが動く様子を書くことができます。処理の様子は、

int main(){
init_gl();
init_camera();
while(1){
  set_camera();
  draw_scene();
  swap_buffers();
  check_fps();
}
return 0;
}

のようになります。set_camera以外の関数は説明していないので、以下で説明します。

1. init_glは、OpenGLの初期化を行う関数です。この関数は使っている環境によりますが、glutInit (GLUT) , SDL_SetVideoMode (SDL) などが対応する関数です。
2. init_cameraは、プレイヤーキャラクタの位置を設定する関数です。cをグローバル変数としておけば、camera型の変数を、引数として渡す必要は無くなります。
3. set_cameraは先程説明した関数です。ここではカメラの位置は定数なのですが、後にカメラの位置を動かす場合も扱うので、ループ内に入れました。
4. draw_sceneは画面に現れる物体を描画する部分です。ここではいくつかの三角錐を配置しました。
5. swap_buffersは、glが描画した内容を画面に表示する関数です。glutSwapBuffers (GLUT) , SDL_SwapBuffers (SDL) などが用いられます。
6. check_fpsは、処理にかかった時間を計算し、画面の書き換えのタイミングと次の処理のタイミングが合うようにする関数です。usleep（環境依存）, SDL_Delay (SDL) などが用いられます。

次の図は、カメラの位置を動かしながら描画を行ったものです。元々遠くに見えていたものが近づくにつれて大きくなる様子がわかります。

具体的には画面中に見える白い物体はそれぞれ三角錐で、中心の座標は(0,0,0),(3,1,0),(3,4,3),(5,-2,1)となっています。更にカメラの位置は(10,0,1)であり、カメラが向いている方向はいずれの場合も-x方向です。

ここで、init_cameraとdraw_sceneの内容を紹介します。init_cameraは、カメラの位置と方向を定める構造体cに、初期値を与える関数です。ここでは次のようにしています。

static void init_camera(){
        c.x = 10;
        c.y = 0;
        c.z = 1;
        c.dx = -1;
        c.dy = 0;
        c.dz = 0;
}

単にカメラの座標を(10,0,1)とし、方向を-x方向に定めているだけです。ここでz座標が0でないのは、FPSでカメラの位置がキャラクタの顔の辺りにおかれることを意識したものです。c.zを0とすると地面を這うような表現になります。

draw_sceneは、次のような関数です。

static void draw_scene(){
        glClear(GL_COLOR_BUFFER_BIT);
        watch_from_camera();
        draw_cone(0,0,0);
        draw_cone(3,1,0);
        draw_cone(3,4,3);
        draw_cone(5,-2,1);
}

glClearは、画面の表示をクリアする関数です。watch_from_cameraとdraw_coneはそれぞれ次のように与えています。

static void watch_from(double x, double y, double z, double dx, double dy, double dz){
        glMatrixMode(GL_PROJECTION);
        glLoadIdentity();
        glFrustum(-1,1,-1,1,0.9,50);
        gluLookAt(x,y,z, x + dx,y+dy,z+dz, 0,0,1);
}
static void watch_from_camera (){
        watch_from(c.x, c.y, c.z, c.dx, c.dy, c.dz);
}

ここで、watch_fromが視点変換を行う関数の本体であり、watch_from_cameraは、引数を与えることを目的とした関数です。ここでは

1. カメラがただ1つであり
2. その名前はcであり
3. それはグローバル変数である

という仮定をおいています。更に、draw_coneは、

#define A (glVertex3f(x,y,z));
#define B (glVertex3f(x+0.5,y,z));
#define C (glVertex3f(x,y+0.5,z));
#define D (glVertex3f(x,y,z+0.5));
static void draw_cone(double x, double y, double z){
        glBegin(GL_TRIANGLES);
        A B C;
        A B D;
        B C D;
        A C D;
        glEnd();
}
#undef A
#undef B
#undef C
#undef D

としています。頂点と面を指定して多角形を書くときには、頂点と面のそれぞれをGLfloat型と、GLint型の2次元配列を使う方が普通です（例えばRed Book3章）。ここでは簡単のためマクロを使いました。

ここまででカメラの位置を指定する方法を解説しました。ここからはカメラの位置を機器の入力を受け付けて変更する方法について述べます。

実際には入力を受けてカメラの位置をどのように動かすかは、例をアクションゲームに限っても、個々のゲームによって変化します。例えば、

1. 常にプレイヤーキャラクタの後ろにつく
2. プレイヤーキャラクタの位置とカメラの位置を別に用意し、それぞれを別に動かせるようにする
3. プレイヤーキャラクタの後ろにつくが、キャラクタが反転したときや移動したときの動作に自由度を残す（即座にキャラクタの後ろに回るわけでないので、キャラクタの正面が見えることがある）
4. 場面毎にカメラの位置を固定する

ここでは簡単のため、1番目の選択肢である"プレイヤーキャラクタの後ろにつく"を採用します。これは、カメラの位置とキャラクタの位置が同一であるか、簡単な変換で導出できる関係にあるためです。

既に2Dのゲームプログラミングを通して、何度か入力機器の取扱いについて見て来ました。ここでは入力機器を扱う方法としてSDLを使います。SDLは入力機器の初期化と、2D,3Dの描画を扱うための簡単なライブラリで、多くの（主に個人製作の）ゲームで利用されています。

SDLでは機器の入力はイベントとして扱われます。イベントを供給する元はシステムによって様々ですが、X（Linux他）や、DirectInput (Windows) が用いられます。SDLがこれらのシステムからイベントを得ている方法を見るには、SDL-x.x.x/src/video以下の各ディレクトリを見ることが必要です。ここでは詳細を追求せずに、SDLの関数を使うことにします。

実際にイベントの監視を行うには、メインループの中で、

while(SDL_PollEvent(&e))
  process_event(&e);

などとします。ここで、eはSDL_Event型の変数で、main関数内で定義します。実際にイベントを扱うのはprocess_event関数で行います。SDLが扱うイベントは、キーボード、マウス、ジョイスティックなどの入力機器からの要請の他に、スクリーンからのexposeイベントやresizeイベントがあります。これらは使っていたウィンドウが他のウィンドウで隠された時や、扱うウィンドウの大きさを変更したときに供給されるイベントです。これらの様々なイベントを扱うため、SDL_Event構造体には、

Uint8 type;

という要素が含まれています。これは各々のイベントの種類を表す要素で、process_event内ではこの値に従って処理を分ける必要があります。具体的には

static void process_event(SDL_Event *e){
  switch(e->type){
    case(SDL_KEYDOWN):
      cb_keydown((SDL_KeyboardEvent *)e);
      break; 
    case(SDL_KEYUP):
      cb_keyup((SDL_KeyboardEvent *)e);
      break; 
    default:
      break; 
  }
}

cb_keydown(up)の関数では実際に押された（離された）キーを取得します。このときにはSDL_KeyboardEvent内の、

e->keysym.sym

要素を利用します。詳しくは、SDLのインストール先から、SDL/SDL_keyboard.hや、SDL/SDL_keysym.hなどを参照してください。cb_keydown(up)内での具体的な処理は対応するpressed関係の変数を書き換えることです。この処理は2Dの時の例と同じなので省略します。

ここまででキーが押されているかどうかを知る事が出来るようになりました。ここからは具体的なカメラの移動を見ていきます。ここではset_camera関数内で、カメラの移動を行います。カメラの位置と方向はc内に記録されているので、この関数ではpressed関係の変数の値を見て、カメラの方向を変更する処理が必要になります。

実際に行う処理は、カメラの位置を変更する処理と、カメラの方向を変更する処理に分かれます。ここではカメラの位置を変更する処理を先に扱います。

FPSでは、カメラとキャラクタの移動は、次のように行われます。

1. "前"を選ぶとキャラクタはカメラが向いている方向に進む
2. "後ろ"を選ぶとキャラクタはカメラが向いている方向と反対に進む

ここでは"前"を表すキーとして上キーを使い、"後ろ"を表すキーとして下キーを用います。具体的なset_cameraは次のようになります。

static void set_camera(){
  if (up_is_pressed()){
    c.x += a*c.dx;
    c.y += a*c.dy;
  } else if (down_is_pressed()){
    c.x -= a*c.dx;
    c.y -= a*c.dy;
  } else if ()
    // 回転のための処理
}

ここで、aはキャラクタの移動速度を調整するための定数です。実際には人間が地面を蹴って移動するとき人間が得るのは力積なので、キャラクタの移動では位置ではなくキャラクタの速度を変更するべきです。ここでは簡単のため移動にかかる時間は無視できるものとしました。力積については高等学校理科 物理Iを参照してください。

次に、キャラクタの方向を変える処理について説明します。ここではカメラの方向を3次元ベクトルで保存しているのですが、説明の都合上、方向をθとφを使って表します。ここで、θは、z軸方向とカメラの方向がなす角、φは、x軸方向と、カメラの方向ベクトルをxy平面に射影したベクトルがなす角とします。

通常キャラクタの方向を変更するときにはφだけを変更します。ただし、キャラクタの視点に立って辺りを見回す表現（主観視点と呼ばれる）では、θも含めて変更する必要があります。ここではφだけを変更します。具体的には左回転をするときには、

phi += b;

右回転では

phi -= b;

とします。ここで、bはキャラクタの回転速度を表す定数です。

キャラクタの方向を表す3次元ベクトルとθ, φは次の三角関数で結ばれています。

$n_{x}=\sin(\theta )\cos(\phi ),n_{y}=\sin(\theta )\sin(\phi ),n_{z}=\cos(\theta )$

逆の変換は

$\tan \theta ={\frac {\sqrt {n_{x}^{2}+n_{y}^{2}}}{n_{z}}},\tan \phi ={\frac {n_{y}}{n_{x}}}$

となります。これらの値を使って3次元ベクトルと方向を表す角の変換を行うことができます。

1度の回転の角度が十分小さいときには、

static void turn_left(){
c.dx -= m*c.dy;
c.dy += m*c.dx;
normalize(c);
}

で左回転を、

static void turn_right(){
c.dx += m*c.dy;
c.dy -= m*c.dx;
normalize();
}

で右回転を表すこともできます。ここで、mは定数であり、normalize関数は、cの方向ベクトルを正規化する関数としました。これは、回転の角度が小さいとき、回転による方向ベクトルの変更を元のベクトルに直交するベクトルで近似できることを利用した変換です。方向角を使わないで回転を表現したい場合に利用するとよいでしょう。

これらの関数を用いると、set_camera内のif - else if文に、

} else if (left_is_pressed()){
  turn_left();
} else if (right_is_pressed()){
  turn_right();
}

を付け加えることになります。

具体的な例:sdl_3d_jump

ここまでで3Dの座標を設定し、定義された物体をプレイヤーキャラクタの視点から観測する方法についてまとめました。例えば3Dのアクションゲームではこれらの手法に加えて重力を与えて、キャラクタが下向きに落下するようにしたり、キャラクタをジャンプさせるという作業が必要になります。しかし、これらの手法は基本的に2Dの場合と変わらないので、ここでは詳しく述べません。

実際には、上で述べたカメラの動かし方と、xjumpなどの2Dアクションの手法を用いて、3Dにおけるxjumpの対応物を作ることができます。ここでは、実際にそれを作成した場合について解説します。

xjumpの対応物を作るために最低限必要な要素は次のようになります。

1. 床を作る
2. キャラクタが空中にいるとき、キャラクタが落下するようにする
3. 床の上にキャラクタがいるときには、キャラクタは落下しない

他に、本来のxjumpでは

1. ジャンプに成功した枚数を表示する
2. キャラクタの状態によって、キャラクタの画像が変化する

などいくつかの要素があります。ここでは簡単のため、

1. 枚数は表示しない
2. キャラクタは三角錐で代用

などとして進めます。

注意

DirectXの場合と違い、OpenGLには3Dのデータを読み込むための関数は存在しません（DirectXにはXファイルと呼ばれるファイル形式がある）。後に、外部ライブラリを用いて3Dデータを読み込む手法について説明します。

ここからは先に述べた3つの要素について解説します。xjumpでは、ジャンプによって飛び移るための床は、乱数を用いて生成していました。ここでは簡単のため床の位置は定数の2次元配列で与えることにします。更に、床の大きさを固定することにすると、各々の床を得るために必要な情報は、床のうちの任意の1点です。ここではx座標とy座標が最も小さい部分とします。これらの情報は、例えば、

double planes [N_PLANES][3] = {{0,0,2},{4,0,4}};

のように与えることができます。

次に、キャラクタが落下する処理については、カメラの位置を動かす処理で、

c.z -= vz;
vz -= g;

などとします。gはここでは下向きの加速度を表す定数です。これらの処理は2Dの場合と同じなので詳しく述べません。

最後に、キャラクタが床の上にいるかを判定するためには、次のような関数を使います。

static int on_the_ground(){
  int i = 0;
  while (i < N_PLANE){
      if (
         (PL_X < planes[i][0] + 9.5) && (PL_X > planes [i][0] +0.5)
          &&(PL_Y < planes[i][1]+6.5) && (PL_Y > planes [i][1]-0.5)
          &&(PL_Z < planes [i][2]+1.0)&&(PL_Z > planes[i][2]-0.5)
      )
     {
         return 1;
     }
         ++i;
}
  ...
}

if文で行っていることはキャラクタの位置（PL_X,PL_Y,PL_Zで与えられる）が各々の床の範囲内にあるかどうかを確かめる作業です。3Dの時の違いは、x座標とy座標の2つについて判定が必要になった点だけです。また、実際にキャラクタが床にいるときに、キャラクタのv_zを0にするなどの処理も行っていますが、2Dの時と変わらないので省略します。

これらの手順で作ったプログラムを仮に3d_xjumpと呼びます。実際に筆者がGLの初期化にSDLを利用してこれを作成してみたところ、300行程度で収まりました。ただし、ここではカメラに回転を行わせず、常にx座標正の方向からキャラクタを見る視点にしました。ここでスクリーンショットをいくつか載せます。

手前に見える三角錐を操って空中のボードに飛び移っていきます。上の方に多くのボードが見えています。

最初の1段に飛び乗った所です。画面中央に次に飛び移れそうなボードが見えています。

ある程度進んでから撮ったショットです。画面奥に見える2枚のボードの間はかなりの距離があり、飛び移るのが難しい難所となっています。

先程見えていた2枚のボードの間に来た場面です。右端に見えているのがこれから飛び移るボードですが、距離を正確に読むのが難しいポイントです。

コースの全景が見えるポイントから撮ったショットです。実際には画面中央上寄りに見えるボードから飛び降りながら撮りました。画面中央奥手に見える2枚のボードが先程の難所で、画面中最も左下に見えるボードが1枚目のボードです。

ここまででキャラクタやカメラの位置を動かす方法について説明しました。ここからは、より複雑な物体を表示する方法について述べます。ただし、複雑な物体を扱うときでもカメラやキャラクタの位置を動かす方法はこれまでと同様です。

物体の表示

ここでは複雑な物体を表示する方法について説明します。既に、OpenGLで頂点を用いた物体の描画について説明しました。また、カメラ配置の例では、三角錐を作成しました。実際にはより複雑な物体を表示することが求められます。例えば後に取り上げるSuperTuxKartでは、カートに乗ったペンギンなどが画面に表示されます。また、それらのカートが走るコースも、表示する必要があります。

これらの描画を行うには、3Dのデータを作成するためのソフトウェアが必要となります。このソフトウェアはモデラと呼ばれ、3Dのゲーム開発をする上で重要なソフトウェアです。モデラ自体はゲームだけでなく、3Dのモデルを作成するときには常に利用されます。

フリーで使用できるモデラとしてはblenderが有名です。このソフトは、Windows, Mac OS, Linuxなど各種のプラットフォーム上で利用できるソフトウェアで、先程のSuperTuxKartでは実際に使用されているようです。ソフトの使い方はblenderなどを参照して下さい。

モデラを使って作成されたデータは、3Dデータとして保存されます。これは頂点の位置や、面を塗る色などを指定しており、これを読み取ることでモデラで作ったデータを画面上に表示する事が出来ます。

残念ながらこれらのデータには、標準化されたものがなく、データ形式はモデラごとに変化します。各種の形式を読み取るためにはそれらに対応するライブラリを使うのが簡単です。SuperTuxKartでは、PLIBを使っています。PLIBは、Windows, Mac OS, Linuxなどで動作する3Dプログラミングの為のライブラリです。SuperTuxKartではデータの受渡しに.acファイルを使っていますが、このファイル形式はblenderとPLIBの双方でサポートされています。

注意

最近3Dデータの共通フォーマットとしてCOLLADAがSCEから提唱されたようです。

実際にはPLIBを利用して、カメラの配置など3Dプログラミングに必要な作業を行う事も出来ます。しかし、ここではPLIBの機能には深入りせず、与えられた3Dモデルのファイルを表示するプログラムを作成するに留めます。このプログラムは、PLIBのサンプルであるplib_example( )の、src/ssg/tux/tux_example.cxxとほぼ同じ内容です。

注意

ここではOpenGLを用いるためにGLUTを利用しますが、PLIB自身もOpenGLの設定を行う機能を持っている様です。

#include <plib/ssg.h>
#include <GL/glut.h>
ssgRoot *root = NULL;
static void display(){
  glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
  ssgCullAndDraw(root);
  glutSwapBuffers();
}
int main(int argc, char **argv){
  glutInit(&argc, argv);
  glutInitDisplayMode(GLUT_DEPTH);
  glutCreateWindow("aaa");
  glEnable(GL_DEPTH_TEST);
  data_init();
  camera_init();
  glutDisplayFunc(display);
  glutMainLoop();
}

ここまでが、PLIBとGLUTを用いるときの基本的な描画を行う部分です。今までと違うのは、物体の描画にssgCullAndDraw関数を用いていることです。PLIBは3DモデルのデータをssgRootクラスを用いて管理します。ssgCullAndDraw関数は3Dモデルのデータを実際に描画する関数です。ここでは描画する3Dモデルに対するポインタをrootとしました。実際にデータをrootに与える部分はdata_init関数としており、次のように与えられます。

static void data_init(){
  root = new ssgRoot;
  ssgEntity *snowman = ssgLoadAC("snowman.ac");
  root->addKid(snowman);
}

ただし、ここでは"snowman.ac"というACファイルが同じディレクトリ内にあるものとしました。ここまでで物体の描画は行われますが、物体が実際に見えている事を知るために、カメラの位置を動かす必要があります。その作業はcamera_init関数で行います。

static void camera_init(){
  sgCoord campos;
  sgSetCoord(&campos, 0, -10,0,0,1,0);
  ssgSetCamera(&campos);
}

ここではカメラの位置を(0,-10,0)とし、カメラの向きを(0,1,0)としました。何も設定しないとファイルから読み出された物体の位置は(0,0,0)となるので、これで設定は完了です。

ここで作成したacファイルは球と円柱だけを用いた物です。より複雑な物体を作るにはblenderなどを参照して下さい。

具体的な例

glTron

w:en:GLtron

Neverball

w:en:Neverball

SuperTuxKart

http://supertuxkart.berlios.de/

手書きアニメ調の3D

• ゲームプログラミング/3Dグラフィック/手書きアニメ調の3D

ローポリ制作手法的なこと

ローポリのポリゴン数には、特に基準はないのですが、慣習的に人物キャラクター1体あたり3000ポリゴンがとりあえずの目安になることが多いです。

一般的に、3D-CGの分野では、顔や手足などの注目される部分はポリゴン数が多く分配されますが、腕などはポリゴン数が少なめです。書籍『ローポリスーパーテクニック』や、別著者の『3DCG日和』（著者 ISAO、出版: BNN、）でも、（著者は特に明言していないが）書籍中のポリゴンデザインはそのように、顔が多めで、腕がスカスカになっています。

これは別にゲームやアニメに限ったことではなく、アメリカの3Dアニメ映画などでも同様であり、たしか岩波書店が90年代後半～2005年ぐらいに出した情報科学書か、あるいか別の数学者（微分幾何学の研究者）が2005～2010年ぐらいに書いた本だったかで、そう書かれていたような記憶があります。

若山正人 編『可視化の技術と現代幾何学』、岩波書店、2010年3月26日 第1刷発行 、を確認したら、その本にはポリゴンの密度の方よりの話題は無かった内容なので、たぶんそれより前の時代の別の数学書に書かれていたと思います。

CG用語で「特徴点」という用語があるのですが、顔はほかの身体パーツと比べて特頂点が多いので、アメリカのハリウッド業界などで使われている3D-CG製作ソフトでもモジュールが顔とそれ以外とでは分かれていると、その科学者は古いほうの岩波の書籍で述べていました。

アマチュア・初心者向けの3D-CGソフトでは、あらかじめ特徴点が設定されているのが普通です。

3Dゲーム業界では、「リギング」と言って、ポリゴンとジョイントを関連づける作業もあり、一般に3Dモデラーがリギングも担当します。

※ ネット検索で探すなら、「特徴点」で探すよりも「リギング」で探したほうが3D-CGの情報が見つかりやすいかもしれません（試してみた）。

あと、現代では3D作品では、作品にも寄りますが、イラストを描く人と、そのイラストをポリゴンにアレンジして3Dデザインをする人とは別の人です。

2Dイラストレーターに先にデザインを出してもらい、それをもとに3Dグラフィッカーがポリゴン用に3Dデータを作り直します。

これは、ゲーム『シャイビングフォース・イクサ』などの「3Dデザイナー」（参考文献中の表記）職である ntny（※著者名）著『ローポリスーパーテクニック』（ソフトバンク出版）にそう書かれています。

2Dイラストレーターのデザインでは3D的な整合性を意図的に考えずに自由な発想でデザインをしてもらう仕事を依頼するので、整合性など不自由な部分への対応については3Dグラフィッカーが（整合性を）補うと書籍に書かれています。書籍『ローポリスーパーテクニック』中にも

「 間違っても、イラストレーターに、「整合をとったイラスト」を注文してはいけない 」

と書かれています。「それを上げるのは、理詰めで作るデザイナーだけでよい。」（※「デザイナー」とは、書籍の文脈では3Dグラフィッカーのこと）と書籍にあります。

だから、ゲーム業界では（アニメ業界とは異なり、）三面図がない場合もあります。

キャラの前後の2枚の設定画さえあればいい、とのことです。

（この点、アニメ産業とは異なります。また、こういったゲーム文化とアニメ文化の違いにより、アニメ版権モノの作品のゲーム化では、例外的にアニメ文化に合わせて、膨大な設定資料をもとにゲーム制作することにもなったりすると、ローポリスーパー本のnyuuさんは述べています。）

テクスチャを描くのは、3Dデザイナーです。なので、3Dデザイナーにも2Dイラスト力が必要です。

多くのゲームの場合、ゲームで最も負荷が掛かるのは、RPGなら戦闘、アクションゲームならアクションシーンです。

シーン全体で使えるポリゴン数に上限があり、たとえば上限が30000〜35000万（秒間30フレーム）だったりするので、そこから逆算して各オブジェクトの制限ポリゴン数の仕様が決まったりします。

背景や戦闘エフェクトなどにもポリゴン数が配分されるので、それだけでポリゴン数の半分くらいを占めてしまうこともあり、キャラクターと敵のポリゴンは残り半分くらいしか使えません。そういった諸々が上司などに考慮されて、キャラクターのポリゴン数が1体あたり3000くらい、と決まったりするようです。

敵モンスターのポリゴン数はそれより少ない場合も多く、モンスター1体あたり1500ポリゴンだったりする場合もあります。おそらくですが、キャラクターをウリにするゲームの場合、キャラクター以外のポリゴン数は犠牲になるのでしょう。

実は、イベントシーンなどの上半身のアップでは、イベント用の別ポリゴンモデルを使っている場合もあります。

※ アニメ業界でも似たような手法があります。極端な顔アップや目アップなど、実はキャラ設定画とは別の設定画が存在する場合もあります。調べやすい例だと、アニメ『新世紀エヴァンゲリオン』テレビ版（1995〜96年版）の設定画がそうです。このアニメの設定資料では極端な目アップの設定画がありますが、実は全身の設定画の絵にある目の絵とくらべると、目アップと全身画の目には線の本数や位置が違います。目アップの設定画を単純に縮小コピーしても、まったく全身の設定画の目にはなりません。

その他の例では、書籍『ゲームクリエイターの仕事』によれば、カメラから遠くて小さいキャラクターの場合には、ポリゴン数の少ないものに切り替えるという手法もあり、このような手法を LOD (Level Of Detail) と言います。

一般的に、キャラクターに表情をつけさせる場合、「特徴点」（とくちょうてん）と言われるモデル中の各パーツを代表する（パーツ1つあたり）数個程度の頂点を移動します。

目の両端および中央、まゆの左右および中央、鼻の左右および中央や鼻頭、口の左右および中央、こめかみ、あご、などに、それぞれ特徴点がいくつか当てられています。その特徴点を、望みの表情になるように移動することで、表情をつけます。

関節などにも特徴点があります。

重要なことは、「こめかみ」にも特徴点があることです。（別セクションで紹介した岩波書店だか微分幾何学者の本にも、特徴点のひとつとして「こめかみ」が書いてありました。）

子供の描くような平面的な顔の絵と、立体的な顔のデザインのコツは、こめかみを意識した絵を描けるかどうかです。子供の遊びの「福笑い」だと、こめかみを意識する事が無いので、なかなか「こめかみ」のデザインには意識が回りません。

正面顔での「こめかみ」の位置は、実は、目の瞳の下の位置です。（世間では、勘違いして、輪郭の位置だと思ってる人が多い。）自分の顔で試してください。鏡の前で、正面を向いた状態のまま「こめかみ」の頂上に指を当てて、指を上に動かして、目の手前に来るまで上に動かしてください。誰の顔でも、指先は目じりの下のほうに到着します。

しかし世間の人の多くは勘違いしており、「こめかみの頂上は輪郭上にある」（×）と錯覚しています。

ローポリスーパーテクニックの著者は、「こめかみ」のこの世間の勘違いを「こめかみトラップ」と呼んでいます。

この「こめかみ」のデザインのコツは、一般のイラスト技法書を見ても、なかなか解説書が見つかりません。アニメーターさんとか立体的な絵を書けるのでアニメーターは感覚的には絶対に分かっているハズなんですが、しかしアニメーター教本でも、なかなか「こめかみ」の説明を見つけるのが難しいです。

やはり、CGソフトをイジって、こめかみのポリゴンを実際にいじっているプロの人だと、目のつけどころが違います。やはり、絵の勉強において、色々な映像クリエイターの人の意見を技法書で読むのは勉強になります。

いろいろとローポリ本の解説をしてしまいましたが、実は「ローポリにセオリーはない！」ともローポリ本の著者は述べています。なぜそうなるかというと、ゲームで使われるポリゴンモデル自体が、ゲームの仕様から逆算されて決められるからです。

よく整形手術の広告か何かで、「ほお骨を削ってスリムな顔に」とか言ってるのを見掛けると、こういう「特徴点」の存在を知ってる人は、整形広告がバカバカしく思えるでしょう。ああいう広告を真に受ける層な時点で、「わたしは観察力すらない馬鹿で〜す。正真正銘の馬鹿でーす」と自己紹介しているようなもんです。観察力さえあれば小学生ですら、ほお骨の共通性に気づけるわけです。ほお骨の位置関係なんて、人種が同じなら、ほぼ共通なわけですが、しかし馬鹿は観察力が無いので気づきません。 馬鹿は、目の前の現実よりも、先入観を重視します。そのくせ「自分は先入観にとらわれない（から、私は頭いい！）」とか思っています。

そのくせ、馬鹿ほど「自分は観察力がある」と思って自惚れて（うぬぼれて）います。マンガ『行け！稲中卓球部』で、文脈は違いますが「馬鹿のくせに自分は頭がいいと思ってるタチの悪い馬鹿」という表現がありますが、まさにそれピッタリです。

その整形後の写真か何かを見て（CG加工してない保証すらないですが）、「美人だ」とか言ってる人もまた馬鹿の自己紹介です。馬鹿は馬鹿同士で褒め合います。関わらないようにしましょう。

アニメ作品だと、ジブリのアニメの宮崎駿のキャラクターデザインや、カラー社『新世紀エヴァンゲリオン』のキャラクターデザインだと、ほお骨がけっこうハッキリとしています。ロボットアニメだと、パイロットを斜め下にあるカメラから見上げる構図もあるので、けっこうホオ骨が目立つ構図もあります。イラスト趣味では「どういう絵柄を好きになるか？」の時点ですでに、自分の観察力アピールが始まるのです。

さて、ローポリ本の著者は述べていませんが、「こめかみ」他にも忘れやすいパーツとしては、目の白目（しろめ）も忘れやすいです。目のデザインを描くときも、瞳の中のハイライトばかりに意識が向きがちなので、白目の部分に意識がむかず、そのため極端に白目の少ない目をデザインしてしまうと、お猿さんやお馬さんのような動物的なつぶらな目になってしまいがちです。それが好きならそれでも構いませんが。

ともかく、ローポリの場合、特徴点を動かして表情をつけるので、なのでポリゴン数も限られてきます。（「ローポリスーパーテクニック」では「頂点情報」と言ってるが本ページではCG学の用語にならって「特徴点」とした。岩波本だかにも「特徴点」で「表情」という表現があったので。岩波本などによると、特徴点を編集して表情をつくるという作業の流れは、けっして日本のアニメやゲームだけでなく、アメリカなどのハリウッド映画やディズニー映画などもそうだと言ってました。）

だからともかく、3Dゲームのキャラクター表情の場合、特徴点以外はなるべくテクスチャーで処理することになるでしょう。

一応、複数の一体化したポリゴン複数セットのうちの代表点の1つだけを特徴点とする方法を使えば、もっと多くのポリゴンをCGソフトで操作できるかもしれませんが、ゲームではローポリ化する必要あるので不要でしょう。（もしかしたらハリウッド映画のリアルCGなどだと、ポリゴン複数セットの代表点の方式のほうが良いかもしれません（推測です。現在の版のwiki編集者はよく知りません）。）

その他

ローポリに限りませんが、一画面中で表示可能なポリゴン数に制限がありますので、実は現在のゲームで一画面中に表示できるキャラクターやモンスターなオブジェクトの個数には、限りがあることになるハズです（特に参考文献はありませんが）。

ファミコン時代の昔のゲームは、画面中の描画処理の限界のため一画面中のキャラ数に限界がありましたのでマップ配置が実はそういう制限を受けていたでしょうが、実は現代の3Dゲームでもポリゴン数の制限で似たような問題が生じてしまいます。

とにかく現代では、一画面中で表示可能なポリゴン数に制限がありますので、だから物陰に隠れて見えないはずのオブジェクトは、いちいち表示をオフにするプログラムを組まないといけません。

一方これが映画、アニメ用の3D-CGだったら、そんなことせずともZバッファ法で手前のオブジェクトで上書きするだけで奥のオブジェクトは隠れますし、最終的に動画ファイルにエンコードするので問題ないです。ポリゴン数が多くても、単にエンコード中の時間が掛かったりするだけで、最終的にエンコードされた動画の速度には関係ありませんので。単に作り手側だけ、エンコード時間が掛かるだけであり、視聴者側は何もエンコードしないからです。

しかし、ゲームのリアルタイムレンダリングでは、そうはいかないのです。ポリゴン数が多いことは、プレイヤーにとって操作中の処理落ち、またはプレイの操作速度の低下などにつながり、プレイヤーの快適性を著しく下げます。

だから、いちいち、非表示のオブジェクトの非表示プログラムを組まないといけません。また、前提としてそのような都合のいい壁などによる目隠しが必要です。

だから現代ゲームでも、実はマップの配置は、昔のファミコンゲームと同様に、処理落ちをさせないように、プレイヤーの視界に入る敵の配置をうまく分散することができるようなマップ配置になっているハズです。