データストア

概要

GNsDockではアーティストが作成したデータをストアと呼ばれる管理されたデータ領域に保存する事で共有します。
ストアは構造や命名規則が事前定義されており、共有データはルールに乗っ取って規則正しく格納されます。もし管理構造を全く別にしたい場合は複数のストアを定義する事も出来ます。
データの保存、呼び出しも規格化されており同じストア階層への保存、呼び出しは誰がどのスタジオで行っても同じ結果になるようになります。
ストアを利用する事で仕様書作成と申し送りから解放される事を願います。

ストアの構造

ストアは幾つも用意する事が出来ますが、全てのストアは同じフレームワークから派生します。
フレームワークはディレクトリ構造のひな型を提供します。
ひな型は管理上必要な階層が固定されており派生したストアでは変更可能な階層を編集する事で独自のディレクトリ構造を定義する事になります。
ストアの階層を紹介します。

階層	名前	変更	役割
1	Root	×	ルートとなる固定階層です。ストア定義時に固定値として設定されます。 ストア名がディレクトリ名となります。
2	Dynamic Category	〇	データをカテゴリーで分別するための階層です。 設定した命名規則の範囲でディレクトリを任意に作成する事が出来ます。 次のFixedCategory階層の拡張領域としての役割を持ち任意の数の階層をプロジェクトごとに追加する事が出来ます。
3	Fixed Category	×	データをカテゴリーで分別するための固定階層の末端です。 設定した命名規則の範囲でディレクトリを任意に作成する事が出来ます。
4	Phase	×	データを工程で分別するための固定階層です。 設定した命名規則の範囲でディレクトリを任意に作成する事が出来ます。
5	Variation	×	データをデータの種別で分別するための固定階層です。 設定した命名規則の範囲でディレクトリを任意に作成する事が出来ます。
6	Revision	×	データの履歴を保持する固定階層です。 データが保存または更新される場合、ストアはこの階層に日付のディレクトリを作成してデータを保存します。 日付は16桁のUTC(標準時)エポック秒になります。
7	Contents	×	データの実体を格納するための固定階層です。 データ保存時にシステムがcontentsという名前のディレクトリを作成します。

例としてデジタルアセットを格納するassetsというストアを定義してみます。
階層を「root/type/name/phase/variation/revision/contents」とします。
typeがDynamicCategory、nameがFixedCategoryです。
それぞれ次のようなディレクトリを作ってデータを保存していく事が想定できます。

root	type	name	phase	variation	revision	contents
assets	character prop background vehicle	human cat dog car	model rig shader textrue	mayaAscii psd image	1234567891234567 1234567891234568 1234567892345678	contents

データ同期

ストアの階層情報やストアに保存されているデータをリモートを介して同期する事が出来ます。
同期の基本仕様はこちらを参照してください。
アップロードはパブリッシュと同時もしくは同期ツールによって一括で行う事ができます。
ダウンロードも同じく個別または一括で行う事が出来ます。

ストアのディレクトリ

ストアはしばしば実際のディレクトリ構造の内容とは異なった情報を返します。
例えば、ストア上は存在しているように見えるがディレクトリが存在しない。逆に存在するディレクトリなのにストア上からは閲覧できない。などです。
これはストアのディレクトリ構造がデータベースで管理されており、実際のファイルシステムを見ていないからです。
次にストアを操作した時のストアとファイルシステムの挙動を紹介します。

アクション	ストア	ファイルシステム
作成	同一のディレクトリがファイルシステムに無い場合、データベースに登録 データ同期を行っている場合はリモートの書き込み権限が必要です。	何もしない
削除	データベースから削除 データ同期を行っている場合はリモートの削除権限が必要です。	削除出来れば削除する
一覧	データベースからリストを作成	何もしない
存在の確認	データベースに登録を確認、登録されていればファイルシステムを確認	データベースに存在する場合のみ確認
データ保存	何もしない	保存先までのディレクトリを作成

ストアがデータベースを作成する理由はデータ同期のためです。
データベースはsqliteで作成されており、プロジェクトを共有するスタジオ全てで同期されます。
ストアには時には数十テラを超える制作データが保存されるため全てを同期するのは困難なため構成情報だけを同期する仕様になっています。
これによりどのスタジオでストアの階層に変更が加えられても素早く同期できるというわけです。
またストアのデータを全てダウンロードできない個人環境などの場合は必要なデータのみダウンロードを行う事が出来るようになります。

パブリッシュ

ストアにデータを保存する事をパブリッシュ(Publish)と呼びます。
パブリッシュを行う場合、パブリッシャー(Publisher)と呼ばれる保存を担当するクラスがデータの検証、加工、ファイル生成を行います。
パブリッシャーは複数用意されており、実行中のアプリケーションとストアの保存先（パス）を基準に選択されます。
具体的には実行アプリケーションと保存先のroot階層、 phase階層、variation階層を見てパブリッシャーを選択しています。

データフロー

GNsDockではストアに工程ごとのデータ保存領域を確保し、対応したパブリッシャーとローダーを設置する事でデータフローが構築されます。
ただし、GNsDockには決まったデータフローは無く、提供されるフレームワークを使ってスタジオまたはプロジェクトのワークフローに沿った構成を構築していく必要があります。

例としてモデリング工程とリギング工程のフローの一例を紹介します。
次のような要件を持ちます。

• アプリケーションはMayaとphotoshopを使用する。
• モデルはディテールの異なるレイアウト用、アニメーション用、レンダリング用を用意する。
• モデルに使用しているテクスチャーはモデルデータとペアで管理する。
• テクスチャーは修正対応のためソースとなるPSDもストアに保存しておく。
• リギング工程ではそれぞれの用途のキャラクターを作成する。

上記の要件を実現するために次のようなパブリッシャーとローダーを用意します。

アクション	名前	機能
publish	mayaScenePublisher	mayaのシーンファイルをストアに保存します。 保存の際にテクスチャーなどの参照ファイルを収集してパスを置換します。
publish	filePublisher	単純にファイルをストアにコピーします。
load	mayaSceneLoader	mayaのシーンファイルをmayaのシーンにネームスペースなしのインポートでロードします。

図にすると次のようになります。

次にもう少し複雑な例を紹介します。
リギング工程で作成されたキャラクターを使ってアニメーションを作成してレンダリング用のキャラクターとアニメーションをライティング固定とエフェクト工程で使用するフローです。
次のような要件を持ちます。

• アニメーション工程はmayaを使う。
• アニメーション工程ではアニメーション用のキャラクターまたは軽量化されたブロックモデルを使用する。
• アニメーション工程はアウトプットとしてカメラ、アニメーションカーブ、alembicを出力する。
• ライティング工程はmayaを使う。
• ライティング工程はレンダリング用のキャラクター、カメラとアニメーションカーブをリファレンスして使う。
• エフェクト工程はhoudiniを使う。
• エフェクト工程はalembicとカメラをhoudiniにロードして使う。

上記の要件を実現するために次のようなパブリッシャーとローダーを用意します。

アクション	名前	機能
publish	mayaScenePublisher	mayaのシーンファイルをストアに保存します。 保存の際にテクスチャーなどの参照ファイルを収集してパスを置換します。
publish	mayaCameraPublisher	mayaのカメラだけをストアに保存します。 次の形式で複数のファイルを同時にパブリッシュします。 ・カメラをそのままmayaAsciiで保存 ・アニメーションをベイクしたカメラをmayaAsciiで保存 ・アニメーションをベイクしたカメラをfbxで保存 ・アニメーションをベイクしたカメラをalembicで保存 ・アニメーションをベイクしたカメラをnkで保存
publish	mayaAnimPublisher	mayaのシーン内のアニメーションカーブをストアに保存します。
publish	mayaAbcPublisher	mayaのシーンをalembicに変換してストアに保存します。 変換前にシーンに読み込んでいるキャラクターをレンダリング用に入れ替えます。
load	mayaRigLoader	ストアに保存されたキャラクターをネームスペース付きでリファレンスします。
load	mayaCameraLoader	ストアに保存されたカメラをネームスペース付きでmayaにリファレンスします。
load	mayaAnimLoader	ストアに保存されたアニメーションをネームスペース付きでリファレンスして、キャラクターと接続します。
load	houdiniCameraLoader	ストアに保存されたカメラをhoudiniに読み込みます。
load	houdiniAbcLoader	ストアに保存されたalembicをhoudiniに読み込みます。

図にすると次のようになります。

このように工程、パブリッシャー、ローダー、ストアを組み合わせる事でデータフローが構築されます。
ちょうどmayaやnukeのノードをコネクションでつないでヒストリーを作成するのに似ています。
この例では分かりやすくするためにシンプルな構成にしましたが実際にはもっと多くの工程があり、更に複雑なデータフローになるはずです。

GNsStore

ストアにアクセスするためにはGNsStoreを使います。
GNsStoreはスタンドアローン版とアプリケーション版が用意されておりアプリケーション版はそれぞれアプリケーション内のサブウインドウとして動作するようになっています。
GNsStoreはスタンドアローン版はGNsLauncherから、アプリケーション版はそれぞれアプリケーションのGNsDockメニューからGNsStoreを実行する事で起動できます。

ウインドウ上段はストアの階層を選択するためのセレクターです。
下段は選択したストア階層に対して行うアクションを選択します。アクションはタブで分けられており、パブリッシュや読み込みなどがそれぞれタブになっています。

アクションタブ内は選択しているストアの情報とアクションを実行するためのオプションと実行ボタンが表示されます。
表示されるオプションはストアとアクションの選択状態、プラグインの有無によって変化します。