graphics.hatenablog.com

テクニカルアーティストの技術を書き殴るためのメモ帳

テクニカルアーティストのためのデータベース入門 (4) 「エンティティ」と「リレーション」

f:id:hal1932:20160929224613j:plain

graphics.hatenablog.com

アセットの要素分解

冒頭の図を「ER図(Entity Relation Diagram)」と呼ぶ。
詳しい書き方は省略するが、要するにアセットの設計図だ。

ER図自体は本来DBの設計などに使われるグラフだが、よく似た図を、TAなら何度も見たことがあるはずだ。例えばMayaのノードグラフとか。実際のところ、(それが有用かどうかはさておき)Mayaのノードグラフは、MySQLなどのDBにそのまま落とし込むことができる。というか、ノードグラフとはMayaが構築しているデータベースであると、自分なんかは考える。

エンティティ

実際にアーティストがデータを制作するときの手順を考える。

Mayaでモデリングをして、「モデル」を作成する。作成したモデルは、「ファイル」として保存される。Photoshopで「テクスチャ」を描く。描いたテクスチャは、「ファイル」として保存される。Mayaに戻って、作成したテクスチャを読みこんで、モデルに貼り付ける。このとき、これを制作したアーティストは、「成果物としてのモデル」「モデルが参照するテクスチャ」「それらが保存されたファイル」を管理することになる。これらの管理対象のことを、エンティティと呼ぶ。

ノードグラフの「ノード」と考えてしまって差し支えない。

モデリングについて詳しくみてみる。以下は、キューブの1面をエクストルードしたもの。これをつくった人は、「元のモデル」「モデルを押し出すという操作」「出来上がったモデル」の3種類を管理しているはずだ。なので、これら3つをエンティティとして考えることもできる。
f:id:hal1932:20161002053712j:plain

リレーション

冒頭の図にある Model / Texture / File の関係性を整理してみると、だいたいこんな感じになると思う。

  • 1つの Model は、複数の Texture が設定される可能性がある
    • 「0枚以上の Texture が設定される」と言い換えることもできる
  • 1つの Model は、1つの File として保存される
  • 1つの Texture は、1つの File として保存される

ここでは「設定」という言葉を使ったけど、実際には、モデルがテクスチャを参照するのか、テクスチャがモデルを参照するのかはケースバイケースになると思う。1つのモデルやテクスチャは、基本的には1つのファイルとしてファイルシステム上に表現される、ということにしておく。

この、「ModelとTextureとの関係性」や「TextureとFileとの関係性」を、リレーションと呼ぶ。

ノードグラフの「エッジ」と考えてしまって差し支えない。

ふつうのアセット制作の場合、だいたい以下4つのリレーションを押さえておけば事足りると思う。ネーミングは適当なので、人やチームによって変わるかもしれない。

  • 参照(依存)
    • モデルはテクスチャを参照する
    • ジオメトリキャッシュはアニメの計算結果に依存する
  • 構成(細分化)
    • テクスチャアトラスAは、テクスチャB、テクスチャC、テクスチャDから構成される
    • ワークフロー全体は、モデリング、テクスチャリング、アニメーション、レンダリングの4段階に細分化される
  • 表現形式
    • テクスチャの実体はファイルとして表現される
    • 制作進行ステータス(「開始」「レビュー」「完了」など)はステータスIDとして表現される
  • 状態
    • モデルAは「制作中」という状態である
    • キャラBは武器Cを装備している状態である

リレーションというのはあくまで概念なので、実際にDB上でどう表現されるかは場合によって異なる。例えば、「モデルはテクスチャを参照する」というのは、「modelsテーブルにtexture_idが保存される」かもしれないし、「texturesテーブルにmodel_idが保存される」かもしれないし、「model_texture_mapsテーブルにmodel_idとtexture_idの組み合わせが保存される」かもしれない。他のやり方ももちろんある。

アセットのER表現

つまり、管理すべきアセットとそれらのアセット同士の関係性を整理する、アセット全体をノードグラフとして表現する、TAが扱うDBというのはそういうものになることが多いと思う。