ゲームプログラミング/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種類程度に分かれる。
3Dグラフィック

投影面
3Dグラフィック

投影の方式
3Dグラフィック

一般的には、平面投影と透視投影の組み合わせが単純なので、よく使われる。
3Dグラフィック

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

投影面の種類は主に2~3種類、
3Dグラフィック

くらいである。
3Dグラフィック

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

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

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

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

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

なので、結局、ふつうは平面投影で計算することになる。
3Dグラフィック

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

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

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

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

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

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

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

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

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

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

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

さて、平面投影・円柱投影のどれでも、透視投影ならば共通する性質がある。
3Dグラフィック

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

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

そして、直線L上で、仮に点Cが、点Bよりもカメラから遠い位置に(点Cが)あるとしよう。
3Dグラフィック

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

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

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

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

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

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

ただし、面を小さく分割すれば分割するほど、計算量の負担は増えていく。
3Dグラフィック

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

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

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

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

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

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

単に、高校数学~大学1年程度の行列の理論の、回転行列の公式をつかえばいい。
3Dグラフィック

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

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

数学の教育体系的には、大学1年くらいで習う「行列の同次形(どうじけい)」という理論の応用にすぎない。
3Dグラフィック

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

証明は下記のとおり。(なんと、ネットを検索しても、証明がなかなか、みつからない! 数学書には普通に書いてあるんだが・・・。やはり勉強をする手段は、書物を原則とするにかぎる。)
3Dグラフィック

まず仮に)、2次元の入力ベクトル V を
3Dグラフィック

とする。(背理法でないので、特に疑わなくていい。)
3Dグラフィック

そして変換行列 A を
3Dグラフィック

とする。(※ 回転行列でなくてもいいのだが、回転行列を念頭においておくと、次の文の応用がイメージしやすい。)
3Dグラフィック

すると、行列によるベクトルの変換操作は、
3Dグラフィック

は、こう書ける。(ここまで高校3年のいわゆる「数学C」の範囲。年度により、行列が高校課程から抜けたりする時代もあるが。)
3Dグラフィック

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

と、ベクトルPを足し算すればいい。
3Dグラフィック

では、上記をもとに、これから行列の「同次形」の概念を説明する。
3Dグラフィック

まず、行列Aとよく似た3次元行列B
3Dグラフィック

を用意する。この行列Bが、行列Aの「同次形」である。
3Dグラフィック

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

積AVと同様に、積BFを(数学Cで習うような行列の積の)定義にそって求めてみると、
3Dグラフィック

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

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

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

なお、同次行列のことを「斉次」(せいじ)行列ともいう。
3Dグラフィック

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

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

また、カメラの位置は原点に固定する。
3Dグラフィック

カメラを自転させた場合の映像を描写したい場合は、代わりに被写体すべてを反対方向に回転(交点)させることで対応する。
3Dグラフィック

このような仮定は、広く普及している。
3Dグラフィック

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

あるいは、式をz関連の変数どうしてまとめて書き換えて、
3Dグラフィック

とも書ける。
3Dグラフィック

ただし、投影面の位置を zs とした。(添字sは「スクリーン」のつもり)
3Dグラフィック

また、 z > zs に位置する被写体だけを描画するものとしている。
3Dグラフィック

なお、この仮定の場合、z軸そのものの座標は x=0、y=0 である。
3Dグラフィック

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

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

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

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

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

この対策として、真横に近い物体は最初から描画を除外すればいい。
3Dグラフィック

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

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

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

ただし、この方法では、zは一定値以上(たとえばカメラとスクリーンとの距離)でなければならない。
3Dグラフィック

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

ただし、遠方にある山や川などの景色などは、別の方法で描画する必要があろう。
3Dグラフィック

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

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

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

つまり、ゲーム画面は、(スクリーン幕よりも奥の被写体の)透視投影と(スクリーン手前の被写体の)平行投影との合成になる。
3Dグラフィック

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

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

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

代表の位置は、べつに重心でも垂心でも三点の平均値でも何でもよく、好きなように決めればいい。(べつに面積計算をするわけではないので、重心でなくてもよいだろう)
3Dグラフィック

カメラはz軸を向いているとする。
3Dグラフィック

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

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

もし、(冒頭の章で述べたような)余弦定理による視界の計算をC言語で実行したい場合、
3Dグラフィック

まず、三角関数(逆三角関数も使う)の計算と、平方根の計算が、どうしても必要になる。
3Dグラフィック

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

スースコード冒頭にインクルード文
3Dグラフィック

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

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

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

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

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

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

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

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

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

これらの知識を持たない場合、先にそれらの知識を習得したほうが良い。
3Dグラフィック

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

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

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

で扱う。
3Dグラフィック

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

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

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

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

まとめると、平面投影にしろ円柱投影にしろ、
3Dグラフィック

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

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

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

「隠面処理」とは、隠れた面を表示しない方法のこと。
3Dグラフィック

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

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

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

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

カメラからの角度が同じ面どうしで、カメラからの距離を比べるわけである。
3Dグラフィック

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

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

しかし、被写体が透明/半透明な物体の場合に、アルゴリズムが複雑化するという欠点がある。
3Dグラフィック

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

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

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

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

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

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

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

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

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

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

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

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

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

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

なので、あまり、ゲーム機で描画のたびに毎回3D計算するのではなく(つまり、リアルタイムレンダリングではなく)、ゲーム制作時の3D計算で画像出力しておいた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次元で絵を書いてしまいましょう。
そもそも論

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

たとえば、
そもそも論

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

同様に、
そもそも論

無限に続きます。
そもそも論

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

高速化のためには、ハードディスク & メモリの使用量を増やしてでも、CPUやGPUの負荷を減らす必要があるので(現在のハードウェア技術では、それが人類のパソコン設計の限界)、たとえポリゴンモデル設計時の作業負担が増えてでも(※ 設計時にハイポリとローポリの2回のデザイン仕事が必要になるので)、遠景のポリゴンを簡略化することでCPUの負担を減らすという工夫が、市販の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モデルのメッシュ修正は困難であり、あとから修正するのは困難だという事が分かります。
そもそも論

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

画面上部に
そもそも論

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

大まかな流れ(Blenderの場合)
そもそも論

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

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

もし千手観音とか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で推奨されている命名の、
そもそも論

および
そもそも論

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

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

が分かりやすいと思います。
そもそも論

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

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

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

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

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

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

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

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

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

そのマテリアルの色を登録(ふつうの方法と同じ)、
そもそも論

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

たとえば、
そもそも論

のような手順です。
そもそも論

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まずコピーのため、顔のメッシュ全体をオブジェクトモードで選択し、 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教室』本に擬人化の動物キャラの見本(2足歩行のイヌネコっぽい動物の顔の少年)があるので裸足(はだし)なので足の指が出ているが、しかし動物キャラのボーンは5つではなく、文章の説明が無いので不明だが、画像を見た感じ、2~3個のボーンで代用しているようだ。
そもそも論

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

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

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

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

別の流儀もあります。
そもそも論

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

なお、メタセコイアでいうレイヤーに相当するのは、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などにある講座動画を見るのも良いでしょう。上手い人の操作を見るのも、勉強です。
そもそも論

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

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

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

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

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

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

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

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

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

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

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

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

nanodなので、最終的に、
directXの初期設定

の2つを作る。
directXの初期設定

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

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

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

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

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

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

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

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

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

のようになっていれば問題ない。
directXの初期設定

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

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

d3d12.lib;dxgi.lib;%(AdditionalDependencies)
directXの初期設定

を追加する。
directXの初期設定

場合によっては、代わりに
directXの初期設定

d3d12.lib;dxgi.lib;d3dcompiler.lib;%(AdditionalDependencies) を追加する。
directXの初期設定

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

d3d10.lib d3dx10.lib dxguid.lib dxerr.lib
directXの初期設定

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

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

dsound.lib dinput8.lib dxerr9.lib d3d9.lib d3dx9.lib d3dxof.lib dxguid.lib winmm.lib
directXの初期設定

を追加すべしと言っている。
ケーススタディ

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の行列は次で与えられます。
ケーススタディ

まず、
ケーススタディ

で表される行列で、座標の方向を調節します。ただし、
ケーススタディ

F → = center → − eye → {\displaystyle {\vec {F}}={\vec {\textrm {center}}}-{\vec {\textrm {eye}}}} , f → = F → / | F → | {\displaystyle {\vec {f}}={\vec {F}}/|{\vec {F}}|} , u ′ = up → / | up → | {\displaystyle u'={\vec {\textrm {up}}}/|{\vec {\textrm {up}}}|} , s → = f × u ′ {\displaystyle {\vec {s}}=f\times u'} , u → = s → × f → {\displaystyle {\vec {u}}={\vec {s}}\times {\vec {f}}}
ケーススタディ

を用います。更に、カメラの位置を動かす為に、
ケーススタディ

を実行します。
ケーススタディ

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

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

より、
ケーススタディ

が成り立ちます。最後の式は具体的に計算できて、
ケーススタディ

が得られます。同様にして、
ケーススタディ

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

と取ります。これで元の変換行列が得られたことになります。
ケーススタディ

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

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

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

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

をgluLookAtの1つ前にいれます。
ケーススタディ

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

のようになります。set_camera以外の関数は説明していないので、以下で説明します。
ケーススタディ

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

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

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

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

draw_sceneは、次のような関数です。
ケーススタディ

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

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

という仮定をおいています。更に、draw_coneは、
ケーススタディ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

右回転では
ケーススタディ

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

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

逆の変換は
ケーススタディ

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

1度の回転の角度が十分小さいときには、
ケーススタディ

で左回転を、
ケーススタディ

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

これらの関数を用いると、set_camera内のif - else if文に、
ケーススタディ

を付け加えることになります。
ケーススタディ

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

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

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

他に、本来のxjumpでは
ケーススタディ

などいくつかの要素があります。ここでは簡単のため、
ケーススタディ

などとして進めます。
ケーススタディ

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

のように与えることができます。
ケーススタディ

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

などとします。gはここでは下向きの加速度を表す定数です。これらの処理は2Dの場合と同じなので詳しく述べません。
ケーススタディ

最後に、キャラクタが床の上にいるかを判定するためには、次のような関数を使います。
ケーススタディ

if文で行っていることはキャラクタの位置(PL_X,PL_Y,PL_Zで与えられる)が各々の床の範囲内にあるかどうかを確かめる作業です。3Dの時の違いは、x座標とy座標の2つについて判定が必要になった点だけです。また、実際にキャラクタが床にいるときに、キャラクタのv_zを0にするなどの処理も行っていますが、2Dの時と変わらないので省略します。
ケーススタディ

これらの手順で作ったプログラムを仮に3d_xjumpと呼びます。実際に筆者がGLの初期化にSDLを利用してこれを作成してみたところ、300行程度で収まりました。ただし、ここではカメラに回転を行わせず、常にx座標正の方向からキャラクタを見る視点にしました。ここでスクリーンショットをいくつか載せます。
ケーススタディ

ここまででキャラクタやカメラの位置を動かす方法について説明しました。ここからは、より複雑な物体を表示する方法について述べます。ただし、複雑な物体を扱うときでもカメラやキャラクタの位置を動かす方法はこれまでと同様です。
ケーススタディ

ここでは複雑な物体を表示する方法について説明します。既に、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の双方でサポートされています。
ケーススタディ

実際にはPLIBを利用して、カメラの配置など3Dプログラミングに必要な作業を行う事も出来ます。しかし、ここではPLIBの機能には深入りせず、与えられた3Dモデルのファイルを表示するプログラムを作成するに留めます。このプログラムは、PLIBのサンプルであるplib_example( )の、src/ssg/tux/tux_example.cxxとほぼ同じ内容です。
ケーススタディ

ここまでが、PLIBとGLUTを用いるときの基本的な描画を行う部分です。今までと違うのは、物体の描画にssgCullAndDraw関数を用いていることです。PLIBは3DモデルのデータをssgRootクラスを用いて管理します。ssgCullAndDraw関数は3Dモデルのデータを実際に描画する関数です。ここでは描画する3Dモデルに対するポインタをrootとしました。実際にデータをrootに与える部分はdata_init関数としており、次のように与えられます。
ケーススタディ

ただし、ここでは"snowman.ac"というACファイルが同じディレクトリ内にあるものとしました。ここまでで物体の描画は行われますが、物体が実際に見えている事を知るために、カメラの位置を動かす必要があります。その作業はcamera_init関数で行います。
ケーススタディ

ここではカメラの位置を(0,-10,0)とし、カメラの向きを(0,1,0)としました。何も設定しないとファイルから読み出された物体の位置は(0,0,0)となるので、これで設定は完了です。
ケーススタディ

ここで作成したacファイルは球と円柱だけを用いた物です。より複雑な物体を作るにはblenderなどを参照して下さい。
ケーススタディ

w:en:GLtron
ケーススタディ

w:en:Neverball
ケーススタディ

http://supertuxkart.berlios.de/
ローポリ制作手法的なこと

ローポリのポリゴン数には、特に基準はないのですが、慣習的に人物キャラクター1体あたり3000ポリゴンがとりあえずの目安になることが多いです。
ローポリ制作手法的なこと

一般的に、3D-CGの分野では、顔や手足などの注目される部分はポリゴン数が多く分配されますが、腕などはポリゴン数が少なめです。書籍『ローポリスーパーテクニック』や、別著者の『3DCG日和』(著者 ISAO、出版: BNN、)でも、(著者は特に明言していないが)書籍中のポリゴンデザインはそのように、顔が多めで、腕がスカスカになっています。
ローポリ制作手法的なこと

これは別にゲームやアニメに限ったことではなく、アメリカの3Dアニメ映画などでも同様であり、たしか岩波書店が90年代後半~2005年ぐらいに出した情報科学書か、あるいか別の数学者(微分幾何学の研究者)が2005~2010年ぐらいに書いた本だったかで、そう書かれていたような記憶があります。
ローポリ制作手法的なこと

若山正人 編『可視化の技術と現代幾何学』、岩波書店、2010年3月26日 第1刷発行 、を確認したら、その本にはポリゴンの密度の方よりの話題は無かった内容なので、たぶんそれより前の時代の別の数学書に書かれていたと思います。
ローポリ制作手法的なこと

CG用語で「特徴点」という用語があるのですが、顔はほかの身体パーツと比べて特頂点が多いので、アメリカのハリウッド業界などで使われている3D-CG製作ソフトでもモジュールが顔とそれ以外とでは分かれていると、その科学者は古いほうの岩波の書籍で述べていました。
ローポリ制作手法的なこと

アマチュア・初心者向けの3D-CGソフトでは、あらかじめ特徴点が設定されているのが普通です。
ローポリ制作手法的なこと

3Dゲーム業界では、「リギング」と言って、ポリゴンとジョイントを関連づける作業もあり、一般に3Dモデラーがリギングも担当します。
ローポリ制作手法的なこと

あと、現代では3D作品では、作品にも寄りますが、イラストを描く人と、そのイラストをポリゴンにアレンジして3Dデザインをする人とは別の人です。
ローポリ制作手法的なこと

2Dイラストレーターに先にデザインを出してもらい、それをもとに3Dグラフィッカーがポリゴン用に3Dデータを作り直します。
ローポリ制作手法的なこと

これは、ゲーム『シャイビングフォース・イクサ』などの「3Dデザイナー」(参考文献中の表記)職である ntny(※著者名)著『ローポリスーパーテクニック』(ソフトバンク出版)にそう書かれています。
ローポリ制作手法的なこと

2Dイラストレーターのデザインでは3D的な整合性を意図的に考えずに自由な発想でデザインをしてもらう仕事を依頼するので、整合性など不自由な部分への対応については3Dグラフィッカーが(整合性を)補うと書籍に書かれています。書籍『ローポリスーパーテクニック』中にも
ローポリ制作手法的なこと

と書かれています。「それを上げるのは、理詰めで作るデザイナーだけでよい。」(※「デザイナー」とは、書籍の文脈では3Dグラフィッカーのこと)と書籍にあります。
ローポリ制作手法的なこと

だから、ゲーム業界では(アニメ業界とは異なり、)三面図がない場合もあります。
ローポリ制作手法的なこと

キャラの前後の2枚の設定画さえあればいい、とのことです。
ローポリ制作手法的なこと

(この点、アニメ産業とは異なります。また、こういったゲーム文化とアニメ文化の違いにより、アニメ版権モノの作品のゲーム化では、例外的にアニメ文化に合わせて、膨大な設定資料をもとにゲーム制作することにもなったりすると、ローポリスーパー本のnyuuさんは述べています。)
ローポリ制作手法的なこと

テクスチャを描くのは、3Dデザイナーです。なので、3Dデザイナーにも2Dイラスト力が必要です。
ローポリ制作手法的なこと

多くのゲームの場合、ゲームで最も負荷が掛かるのは、RPGなら戦闘、アクションゲームならアクションシーンです。
ローポリ制作手法的なこと

シーン全体で使えるポリゴン数に上限があり、たとえば上限が30000〜35000万(秒間30フレーム)だったりするので、そこから逆算して各オブジェクトの制限ポリゴン数の仕様が決まったりします。
ローポリ制作手法的なこと

背景や戦闘エフェクトなどにもポリゴン数が配分されるので、それだけでポリゴン数の半分くらいを占めてしまうこともあり、キャラクターと敵のポリゴンは残り半分くらいしか使えません。そういった諸々が上司などに考慮されて、キャラクターのポリゴン数が1体あたり3000くらい、と決まったりするようです。
ローポリ制作手法的なこと

敵モンスターのポリゴン数はそれより少ない場合も多く、モンスター1体あたり1500ポリゴンだったりする場合もあります。おそらくですが、キャラクターをウリにするゲームの場合、キャラクター以外のポリゴン数は犠牲になるのでしょう。
ローポリ制作手法的なこと

実は、イベントシーンなどの上半身のアップでは、イベント用の別ポリゴンモデルを使っている場合もあります。
ローポリ制作手法的なこと

その他の例では、書籍『ゲームクリエイターの仕事』によれば、カメラから遠くて小さいキャラクターの場合には、ポリゴン数の少ないものに切り替えるという手法もあり、このような手法を LOD (Level Of Detail) と言います。
ローポリ制作手法的なこと

一般的に、キャラクターに表情をつけさせる場合、「特徴点」(とくちょうてん)と言われるモデル中の各パーツを代表する(パーツ1つあたり)数個程度の頂点を移動します。
ローポリ制作手法的なこと

目の両端および中央、まゆの左右および中央、鼻の左右および中央や鼻頭、口の左右および中央、こめかみ、あご、などに、それぞれ特徴点がいくつか当てられています。その特徴点を、望みの表情になるように移動することで、表情をつけます。
ローポリ制作手法的なこと

関節などにも特徴点があります。
ローポリ制作手法的なこと

重要なことは、「こめかみ」にも特徴点があることです。(別セクションで紹介した岩波書店だか微分幾何学者の本にも、特徴点のひとつとして「こめかみ」が書いてありました。)
ローポリ制作手法的なこと

子供の描くような平面的な顔の絵と、立体的な顔のデザインのコツは、こめかみを意識した絵を描けるかどうかです。子供の遊びの「福笑い」だと、こめかみを意識する事が無いので、なかなか「こめかみ」のデザインには意識が回りません。
ローポリ制作手法的なこと

正面顔での「こめかみ」の位置は、実は、目の瞳の下の位置です。(世間では、勘違いして、輪郭の位置だと思ってる人が多い。)自分の顔で試してください。鏡の前で、正面を向いた状態のまま「こめかみ」の頂上に指を当てて、指を上に動かして、目の手前に来るまで上に動かしてください。誰の顔でも、指先は目じりの下のほうに到着します。
ローポリ制作手法的なこと

しかし世間の人の多くは勘違いしており、「こめかみの頂上は輪郭上にある」(×)と錯覚しています。
ローポリ制作手法的なこと

ローポリスーパーテクニックの著者は、「こめかみ」のこの世間の勘違いを「こめかみトラップ」と呼んでいます。
ローポリ制作手法的なこと

この「こめかみ」のデザインのコツは、一般のイラスト技法書を見ても、なかなか解説書が見つかりません。アニメーターさんとか立体的な絵を書けるのでアニメーターは感覚的には絶対に分かっているハズなんですが、しかしアニメーター教本でも、なかなか「こめかみ」の説明を見つけるのが難しいです。
ローポリ制作手法的なこと

やはり、CGソフトをイジって、こめかみのポリゴンを実際にいじっているプロの人だと、目のつけどころが違います。やはり、絵の勉強において、色々な映像クリエイターの人の意見を技法書で読むのは勉強になります。
ローポリ制作手法的なこと

いろいろとローポリ本の解説をしてしまいましたが、実は「ローポリにセオリーはない!」ともローポリ本の著者は述べています。なぜそうなるかというと、ゲームで使われるポリゴンモデル自体が、ゲームの仕様から逆算されて決められるからです。
ローポリ制作手法的なこと

よく整形手術の広告か何かで、「ほお骨を削ってスリムな顔に」とか言ってるのを見掛けると、こういう「特徴点」の存在を知ってる人は、整形広告がバカバカしく思えるでしょう。ああいう広告を真に受ける層な時点で、「わたしは観察力すらない馬鹿で〜す。正真正銘の馬鹿でーす」と自己紹介しているようなもんです。観察力さえあれば小学生ですら、ほお骨の共通性に気づけるわけです。ほお骨の位置関係なんて、人種が同じなら、ほぼ共通なわけですが、しかし馬鹿は観察力が無いので気づきません。 馬鹿は、目の前の現実よりも、先入観を重視します。そのくせ「自分は先入観にとらわれない(から、私は頭いい!)」とか思っています。
ローポリ制作手法的なこと

そのくせ、馬鹿ほど「自分は観察力がある」と思って自惚れて(うぬぼれて)います。マンガ『行け!稲中卓球部』で、文脈は違いますが「馬鹿のくせに自分は頭がいいと思ってるタチの悪い馬鹿」という表現がありますが、まさにそれピッタリです。
ローポリ制作手法的なこと

その整形後の写真か何かを見て(CG加工してない保証すらないですが)、「美人だ」とか言ってる人もまた馬鹿の自己紹介です。馬鹿は馬鹿同士で褒め合います。関わらないようにしましょう。
ローポリ制作手法的なこと

アニメ作品だと、ジブリのアニメの宮崎駿のキャラクターデザインや、カラー社『新世紀エヴァンゲリオン』のキャラクターデザインだと、ほお骨がけっこうハッキリとしています。ロボットアニメだと、パイロットを斜め下にあるカメラから見上げる構図もあるので、けっこうホオ骨が目立つ構図もあります。イラスト趣味では「どういう絵柄を好きになるか?」の時点ですでに、自分の観察力アピールが始まるのです。
ローポリ制作手法的なこと

さて、ローポリ本の著者は述べていませんが、「こめかみ」他にも忘れやすいパーツとしては、目の白目(しろめ)も忘れやすいです。目のデザインを描くときも、瞳の中のハイライトばかりに意識が向きがちなので、白目の部分に意識がむかず、そのため極端に白目の少ない目をデザインしてしまうと、お猿さんやお馬さんのような動物的なつぶらな目になってしまいがちです。それが好きならそれでも構いませんが。
ローポリ制作手法的なこと

ともかく、ローポリの場合、特徴点を動かして表情をつけるので、なのでポリゴン数も限られてきます。(「ローポリスーパーテクニック」では「頂点情報」と言ってるが本ページではCG学の用語にならって「特徴点」とした。岩波本だかにも「特徴点」で「表情」という表現があったので。岩波本などによると、特徴点を編集して表情をつくるという作業の流れは、けっして日本のアニメやゲームだけでなく、アメリカなどのハリウッド映画やディズニー映画などもそうだと言ってました。)
ローポリ制作手法的なこと

だからともかく、3Dゲームのキャラクター表情の場合、特徴点以外はなるべくテクスチャーで処理することになるでしょう。
ローポリ制作手法的なこと

一応、複数の一体化したポリゴン複数セットのうちの代表点の1つだけを特徴点とする方法を使えば、もっと多くのポリゴンをCGソフトで操作できるかもしれませんが、ゲームではローポリ化する必要あるので不要でしょう。(もしかしたらハリウッド映画のリアルCGなどだと、ポリゴン複数セットの代表点の方式のほうが良いかもしれません(推測です。現在の版のwiki編集者はよく知りません)。)
ローポリ制作手法的なこと

ローポリに限りませんが、一画面中で表示可能なポリゴン数に制限がありますので、実は現在のゲームで一画面中に表示できるキャラクターやモンスターなオブジェクトの個数には、限りがあることになるハズです(特に参考文献はありませんが)。
ローポリ制作手法的なこと

ファミコン時代の昔のゲームは、画面中の描画処理の限界のため一画面中のキャラ数に限界がありましたのでマップ配置が実はそういう制限を受けていたでしょうが、実は現代の3Dゲームでもポリゴン数の制限で似たような問題が生じてしまいます。
ローポリ制作手法的なこと

とにかく現代では、一画面中で表示可能なポリゴン数に制限がありますので、だから物陰に隠れて見えないはずのオブジェクトは、いちいち表示をオフにするプログラムを組まないといけません。
ローポリ制作手法的なこと

一方これが映画、アニメ用の3D-CGだったら、そんなことせずともZバッファ法で手前のオブジェクトで上書きするだけで奥のオブジェクトは隠れますし、最終的に動画ファイルにエンコードするので問題ないです。ポリゴン数が多くても、単にエンコード中の時間が掛かったりするだけで、最終的にエンコードされた動画の速度には関係ありませんので。単に作り手側だけ、エンコード時間が掛かるだけであり、視聴者側は何もエンコードしないからです。
ローポリ制作手法的なこと

しかし、ゲームのリアルタイムレンダリングでは、そうはいかないのです。ポリゴン数が多いことは、プレイヤーにとって操作中の処理落ち、またはプレイの操作速度の低下などにつながり、プレイヤーの快適性を著しく下げます。
ローポリ制作手法的なこと

だから、いちいち、非表示のオブジェクトの非表示プログラムを組まないといけません。また、前提としてそのような都合のいい壁などによる目隠しが必要です。
ローポリ制作手法的なこと

だから現代ゲームでも、実はマップの配置は、昔のファミコンゲームと同様に、処理落ちをさせないように、プレイヤーの視界に入る敵の配置をうまく分散することができるようなマップ配置になっているハズです。