Blender アニメーションプロジェクトの進捗について

2023年6月26日から30日にかけてBlender HQで行われたBlenderのアニメーションとリギングモジュールのワークショップについてのブログ記事の紹介です。これはAnimation 2025プロジェクトの一環で、昨年10月に行われたワークショップの続編となっています。

このワークショップの目的は、手作業によるデータ管理を減らすことで、アニメーター（およびアニメーション・データを扱う他の人々）をスピードアップさせることです。

Action は20年以上もの間、Blender の主要なアニメーションデータコンテナでした。このブログ記事では、最終的にアニメーションデータのメインコンテナとして Action に取って代わる ‘Animation’ という新しいデータブロックが提案されています。

新しいシステムに対する要望
提案されているモデルの詳細
ノンリニア編集機能の追加
データモデルの技術的な詳細
設計すべきこと
グリースペンシルのコラボレーション – ゴースト
オペレーション／可能性／将来のアイデア
大まかなスケジュール
まとめ

新しいシステムに対する要望

どのようなデータモデルを作るにせよ、それは2022年10月のワークショップの大きなアイデアの基礎となるものである必要があります。ワークショップの最初には、以下のような新しいシステムに対する要望が挙げられました。

徐々にアニメーションを作り上げていく。
別のテイクを試す。
他の人のアニメーション（あるいは1週間後に自分のアニメーション）を調整。
プロジェクトアニメーションシステムを持つ。
USDファイルやゲームコントローラーなど、他のソースからアニメーションをストリームイン。
そして、そのすべてを手動でアニメーションを作成。

このことから、アニメーションレイヤーを導入する必要があること。

さらに、関連するものをまとめてアニメーションできるように、つまり、1つのアニメーションで複数のデータブロックをアニメーションできるようにする必要があると考えられました。これによって、例えば、大人が赤ちゃんを抱いているアニメーションを1つのAnimationデータブロックに入れることができます。

最後に、すべてのアニメーションをブレンドファイル間でリンク可能にしたいという要望がありました。これはActionデータブロックで既に可能ですが、NLAデータはアニメーションオブジェクトの上に直接置かれるので、オブジェクト自体をリンクしなければリンクできません。さらに、各オブジェクトは独立したNLAデータを持っているので、複数のオブジェクトで同時にノンリニアアニメーションを行うのは面倒です。このことにより、NLA機能はアニメーションに移すべきだと結論づけられました。

■Animation Layers（アニメーションレイヤー）

現在、Blenderでレイヤーアニメーションを扱うことは技術的に可能です。それにはNLAを使い、レイヤーごとにActionを作成し、それらを別々のトラックに配置する必要があります。技術的には可能ですが、作業は楽ではありません。これはたくさんの異なるActionを作るだけでなく、例えばリタイミングするときなど、レイヤーをまたいで編集を行うことを非常に難しくします。

NLAデータはアクションのように別の「もの（things）」としてリンクすることができないため、これらのレイヤー化されたアニメーションを制作パイプラインでさらに進めていくことは困難です。

新しいアニメーションレイヤーシステムの目標は以下の通りです：

すべてのレイヤーを含む1つのデータブロック。
異なるデータブロックにまたがる複数のFカーブのキーを編集できるドープシートのような、レイヤーをまたいだ編集のためのツール。
Fカーブ以外のデータをレイヤーに置くことができるように。モディファイアのように下のレイヤーのアニメーションをフィルタリング／操作したり、シミュレーションのように新しいアニメーションデータを導入したりできます。
Fカーブ以外のレイヤーの上でアニメーションできるように。

■マルチデータブロックアニメーション

「1つのキャラクター」は多くのデータブロックで構成されており、アニメートされるときには、すべてのデータブロックがそれぞれのアクションを取得します。これはしばしば、ボーンやArmature上のカスタムプロパティからすべてを動かすことで回避されます。これは可能ですが、不便で、セットアップが難しいことがあります。

提案されているAnimation data-blockは、アニメーションを “user “ごとにグループ化しておくことができます。

同じシステムを通して、複数のキャラクターをアニメーションさせることも可能です

提案されているモデルの詳細

このセクションでは、上記のアイデアを詳しく見ていきます。

■アニメーションレイヤー

各レイヤーはアクションのデータブロックと見なすことができます。レイヤーは、Fカーブやその他のアニメーションデータを含むことができ、下から上に評価されます。

アニメーションレイヤーは、もちろん、異なる内容を持つことができ、異なるフレームをキーにすることができます。

各レイヤーがその下のレイヤーとどのようにブレンドするかは、レイヤーごとに設定できます。

これは、ブレンドモードがストリップごとに設定できるBlenderの現在のNLAシステムとは異なります。レイヤーごとにこの設定を持つことで、管理がよりシンプルになり、レイヤーをマージするのがより簡単になります。各レイヤーは、混合モード（置換、結合、加算、減算、乗算）と影響度（0-100%）を持っています。

レイヤーは入れ子にすることもできます。

ネストされたレイヤーがどのように動作するかは、親レイヤーの「子モード（child mode）」設定によって決まります。

Mix：子レイヤーを最上位レイヤーと同じように結合します。
Choice：一度にひとつの子レイヤーのみをアクティブにします。これは、異なる選択肢を切り替えるために使用できます。

レイヤーがそれ自身と子レイヤーの両方のデータを持つことができるかどうかは、まだ未解決の問題です。今のところ、物事をシンプルに保ち、どちらか一方だけを許可することになりそうと言われています。

■マルチターゲットアニメーション

Actionsとは逆に、レイヤーは複数のデータブロックのアニメーションを含むことができます。これは、出力システムによって行われます。アニメーションデータにはさまざまな出力があり、それぞれにデータブロックを差し込むことができます。

上の例では、2つの出力があり、1つはEinar用、もう1つはTheo用です。それぞれに独立したFカーブのセットがあります。

これをユーザーインターフェースでどのように表現するかは、まだ設計中ですが、接続された出力には、接続されたデータブロックの名前が表示されることになりそうなようです。

ノンリニア編集機能の追加

レイヤーのアニメーションデータは、実際にはレイヤー上のストリップに含まれています。デフォルトでは、ストリップは1つしかなく、それは無限（とそれ以上）に広がっています。上の画像でそのストリップを表示しなかったのはこのためです。

必要であれば、ストリップに境界線を与えることができ、それはよりNLAストリップのように動作します。時間内で左右に移動させたり、繰り返したり、同じレイヤーや他のレイヤーから参照したりすることができます。

アニメーションデータを常にストリップ内に置くことで、データは統一された方法で扱われます。これによって、NLAを使うために今しなければならないような大きな切り替えを避けることができるようになります。また、ツールもより統一され、アドオンの作成者もより簡単になるとされています。

■ストリップタイプ

すべてのレイヤーは同じですが、それらのストリップはさまざまなタイプにすることができます。

これらのストリップタイプの名前は、今後の設計作業の過程で変更される可能性があります。

Keyframe Strip はアクションと似ていますが、マルチデータブロックアニメーション機能を備えています。
Reference Strip は、同じAnimationデータブロック内の別のストリップを参照します。また、データを別の出力にリマップしたり（例えば、Cube.001アニメーションをCube.002に使用）、別のデータパスにリマップすることもできます（ボーンの名前を変更した後、FCurvesを新しい名前にリマップ）。
Anim Strip は、Reference Stripと似ていますが、別のストリップを指すのではなく、別のAnimationデータブロック全体を指す点が異なります。
Meta Strip　には、ネストされたレイヤーのセットが含まれており、独自のストリップもメタストリップにすることができるため、任意のネストが可能です。事実上、これは埋め込まれたアニメーションデータブロックです。

他の種類のストリップについてもアイデアがあります。これらを適切に具体化するにはさらに作業が必要です。今のところ、これらは大まかなアイデアですが、依然として全体的なデザインの中核であるとされています。

Simulation Strip は、筋肉、布地、その他のものをシミュレートします。もちろん、その上で別のレイヤーでアニメーション化します。ただし、シミュレーション時間とアニメーション時間は異なるクロックを使用している可能性があるため、アニメーションシステムだけでなく、Blender でさらに多くの作業が必要になります。
Procedural Animation Strip には、下にあるアニメーションレイヤーの結果を処理するノードシステムがあります。これはデータの評価をいくつかの部分（アニメーションレイヤー→他のコードによる処理→さらなるアニメーションレイヤー）に分割することになり、Blenderの他の領域でのサポートが必要になります。
Universal Scene Description (USD)、Alembic ファイル、モーションキャプチャファイルなど、他のソースから受信するストリーミングデータ。これには、おそらく#68933: Collections for Import/Exportと組み合わせて、そのようなファイルを扱う現在のアプローチを変更する必要もあります。

データモデルの技術的な詳細

Developer Blog のなので、開発者向けの内容も説明されています。ここではデータモデルの技術的な詳細について紹介したいと思います。下記のデータモデル図にある緑色のノードは、すべてAnimationデータブロックの中に埋め込まれているものです。

Animation は ID なので、他のブレンドファイルからリンクしたり、追加したりできます。

他の IDは、現在 Action指しているのと同じように、影響を受けている Animation を指すことができます。

各 Animation は、レイヤーとアウトプットのリストを持ちます。

それぞれの Output にはIDポインタがあり、そのOutputがアニメートするデータブロックを決定します。label は自動的にデータブロックの名前に設定されるので、ポインタがなくなっても、ラベルで出力を識別して再マップすることができます。 id_type は、MeshデータブロックにMaterialアクションを割り当てることができないように、異なるデータブロックタイプを混在させることができないようにします。

図では、 ID が Animationを指し、Outputが ID を指しています。以前のデザインにはこの2つ目のポインターはありませんでした。その代わり、各出力には名前があり、IDはアニメーション化される出力の名前を宣言していました。しかし、このような名前ベースのアプローチは壊れやすく、管理が難しいことがわかったため、代わりにポインタを使うことになりました。

■ストリップタイプ

上の図と同じように、緑色のノードはすべてAnimationデータブロック自体の中に含まれています。

Keyframe ストリップは、各出力に対してアニメーションチャンネルの配列を定義します。

出力がストリップによってどのように参照されるかは、設計上の未解決の問題です。単純に出力インデックスを使用することを検討していますが、これには脆弱性があります。ポインターを使うこともできますが、アニメーションのコピーが作成されるたびにリマッピングが必要になります。これはアンドゥ・システムでも起こることなので、当初考えられていたほど珍しいことではありません。

参照型の ReferenceStrip と AnimStrip は2種類のリマッピングが可能です。

Remapping Outputs: あるデータブロックのアニメーションを別のデータブロックに適用します。例えば、 Cube.001 のアニメーションが Cube.002 に適用されます。
Remapping Data Paths:あるプロパティのアニメーションを別のプロパティに適用します。例えば、 pose.bones["clavicle_left"].… のすべてのアニメーションは、 pose.bones["clavicle_L"].…にマッピングされます。これは接頭辞ベースで行われるため、リマップされた接頭辞で始まるデータパス（Blender内部では「RNAパス」と呼ばれます）はすべてこの変更の対象となります。

■チャンネルタイプ

新しいアニメーションモデルは、Fカーブのキーフレーム以外にも適用できるはずです。具体的な例を挙げると、これにより、グリースペンシルアニメーションとの緊密な統合が可能になります。

さらに、アクティブなシーン・カメラを設定するためにカメラ・マーカーを使用する現在のシステムは、システムがこの特定の用途のみに限定されているという意味で、少しハックです。「フレームX以降でYを使用する」という形のアニメーションをもっと一般化したほうが良いと考えられています。このような理由から、KeyframeStrip は、異なるアニメーションチャンネルタイプを含むことができます。

FMap は、フレーム番号から配列のインデックスへのマッピングです。FCurveのように、すべての時点に対して値を持つのではなく、FMap は「穴（hole）」を持つことができます。これはグリースペンシルのためのもので、どのフレームにどの絵を表示するかを定義するためのものです。

IDChooser は現在のカメラマーカーを一般化したものです。基本的には、「フレームX以降でYを選択する」ということです。すべてのデータブロックの関係をアニメーション化するのに、これを適用できる可能性は低く、まずは、この方法でアニメートできるプロパティをいくつか選び、その使い方と影響について経験を積むことになるとされています。

設計すべきこと

このシステムを実用的なものにするためには、まだ設計しなければならないことが多くあり、以下の項目が挙げられています。

ビヘイビアとツールのリンク：あるファイルから他のファイルへアニメーションデータをリンクすることはよくあることです。基本的なフローはうまく機能し、新しいツールを使えば、より複雑なワークフローが可能になるはずです。
シミュレーションレイヤー：アニメーションとシミュレーションは、同じタイムソースを使用することもできますが、異なるクロックを使用することも可能です。
プロシージャルアニメーション：様々なものが「プロシージャル・アニメーション」の下に分類されます。これは、本格的なノードベースのアニメーション生成とミキシングシステムであったり、レイヤーレベルでのFカーブモディファイアのような単純なものであったりします。
アニメーションシステムのアニメーション：レイヤーの影響やさまざまなストリップ・パラメーターなどをアニメーションさせることができるはずです。
リグノード（Rig Nodes）： 2022年10月のワークショップの大きな成果の1つは、「slappable rigs」で、異なるフレーム範囲でアクティブにできるコントロール・リグ・システムでした。Rig Nodesはそのプロトタイプです。このようなシステムが、より大きなアニメーションシステムとどのように統合されるかは、設計する必要があります。

グリースペンシルのコラボレーション – ゴースト

Grease Pencilチーム（代表：Falk David氏とAmélie Fondevilla氏）とのコラボレーションでは、ゴーストについて議論がされました。これは2Dアニメーションの世界ではオニオンスキニング（onion skinning）とも呼ばれますが、3Dアニメーションやゲーム、その他の分野ではより広く使われているようなので、Blenderではゴースト（ghosting）という言葉が選ばれました。

ChristophとFalkは共同でプロトタイプを作成し、こちらのビデオで紹介しています。

■目標

ゴースティングシステムの目標は次のとおりです。

さまざまな時点のデータを、現在のビューに重ねて表示すること。
すべてのオブジェクトタイプで機能する統合システム。
編集可能なゴースト：ゴーストを編集するために、必ずしもシーンフレームを移動する必要はありません。
移動可能なゴースト：移動してトレースしたり、逆に間隔をあけて動きの全体像を把握したりできます。
Blender の残りの部分に対してノンブロッキング：再生やスクラブがゴーストシステムによって遅くならないこと。

■機能

以下の機能がこのシステムにとって重要だと考えられています。

ゴーストするオブジェクト、またはそのサブセット（その瞬間にアニメートしている手だけなど）を定義する。
ゴーストの時間を、現在の時間に対して相対的に、または絶対フレームとして定義する。
ゴーストをクリックすると、そのフレームにジャンプします。
スクリーンとワールド空間でゴーストをオフセット。
ゴーストは更新されないようロックすることができます。これは、さまざまなアニメーションテイクを探索するためのリファレンスを保持するのに役立ちます。

■技術的な課題

以下のような解決すべきさまざまな技術的課題があります。

現在、選択はすでに厄介なものになっています。例えば、2つのオブジェクトが同じアーマチュアを共有し、両方がポーズモードであるとき、選択はそれらの間で同期されます。異なる時点での選択は、おそらくデータのより多くのコピーを必要とし、それはBlenderが爆発しないように管理される必要があります。
依存関係グラフは、複数の時点が並行して評価されることを考慮して更新する必要があります。これにより、’completion’ ステートもフレーム単位になり、現在のシーンフレームがゴーストが評価される前に’ evaluated completely（完全に評価された）’とマークされるようになりそうです。
最後に、システムのスピードをどう確保するかという問題があります。このためにキャッシュを使用する場合、そのキャッシュをどのように無効にするかという問題が常にあります。

オペレーション／可能性／将来のアイデア

このワークショップでは、データモデルに焦点が当てられ、このモデルをサポートするための操作にはあまり焦点が当てられませんでしたが、以下の操作について簡単に議論し、含めるかどうかが検討されました。これは網羅的なリストではないことにご注意ください。

選択による分割：選択されたFCカーブは別のレイヤーに移動し、残りは現在のレイヤーに残ります。
キーイングセットとして機能する、レイヤーごとの設定可能な「プロパティセット（property set）」：キーを挿入すると、これらのプロパティは常にそのレイヤーでキーイングされます。複数のレイヤーがそれぞれ「プロパティセット」を持つことができます。例: ‘body animation’ レイヤーと ‘face animation’ レイヤーがあり、Blender は自動的にキーを正しい位置に配置します。
周波数分離 (Frequency Separation)：Fカーブは低周波（つまり大まかな動き）と高周波（細かい動き）に分割され、それらがブレンドされて同じアニメーションになります。これらのアニメーションは、別々に編集することができます。このようなワークフローは、写真や音楽の編集ではすでに一般的であり、アニメーションにおいても非常にパワフルです。
ストリーミングと録画：あるシステムからアニメーションをストリーミングし、例えばライブモーションキャプチャーシステムからFカーブとして録画します。
アニメーションチャンネルの組み合わせ：クオータニオン（常に4つの値）、あるいはトランスフォーム全体（位置＋回転＋スケール）が常に完全にキー設定されるようにすることで、興味深い新しい作業方法が開けます。すべてのフレームがすべてのキーを持っていることをBlenderが「知っている」とき、パワフルで使いやすいアニメーションをもたらすことができます。