ID:58703さん

<h3>概要</h3> 日本のアニメーション製作におけるコンポジット作業で使用する After Effect 用のプラグインの提案・開発 <h3>担当</h3> 小規模な開発なので仕様の決定から開発までを基本的に一人で担当した。 <h3>使用言語・ライブラリ</h3> C++, OpenCV, Eigen, Qt <h3>課題</h3> 日本のアニメーション製作の最終工程であるコンポジット作業では、コンポジット用のソフトウェア（主にAfter Effect）を用いてエフェクトの付与とコンポジットが行われる。 しかし、AEなどのソフトのデフォルトのエフェクト（ブラーなど）は、2Dアニメに使用することを想定したものではないため、余計な手間が必要になったりそもそもアニメ特有の表現の作成が難しかったりする問題がある。 <h3>取り組み</h3> <ul> <li> コンポジターから課題を聞き出し、現場で求められている機能の具体的な形の提案・決定を行った。 </li> <li> 要求機能を実現するためのアルゴリズムの選定を行った。既存のもので難しい場合は新しいアルゴリズムを考案した。テスト実装の間は Qt と OpenCV を使用して GUI を作成した。 </li> <li> C++ で After Effect 用のプラグインを作成した。メモリ管理が独特なので外部のライブラリを手軽に使用することはできないが、必要に応じて OpenCV や Eigen などを使用した。 </li> </ul> <h3>プラグインにより実現した機能・表現の具体例</h3> <ul> <li>アニメ調のブラー（おばけブラー </li> <li>カーブの法線方向へのグラデーションの生成 </li> <li>AE上で完結する単純な流体シミュレーション </li> </ul> <h3>工夫した点</h3> <ul> <li> アニメは自然画像と異なり境界がはっきりとしているため、ブラー処理などで境界部分の変化がより目立ってしまうという問題がある。なので、特殊なアルファの扱い方をする新しいブラーのアルゴリズムを考案した。これにより、境界部分のディテールをある程度残したままブラーをかけるおばけブラーのような効果を実現できた。 </li> <li> コンポジット作業では多数のエフェクトを順次適用していくため、単体のエフェクトは極力軽い方がよい。一方でエフェクトの適用は直列であるため、一つのエフェクトで多くのスレッドを使用することは問題がない。なので、並列化が可能なものに関してはOpenMP, SIMDなどを用いて極力並列化をし、作業効率の最大化を図った。 </li> </ul> <h3>効果</h3> 作製したプラグインの内特にアニメ専用ブラーのプラグインはコンポジターにも好評であり、社内の作業で常に使われるようなものとなった。また、ほとんどのプラグインは実際の映像制作で使われており、作業の効率化・表現の拡張という目的を十分に果たすことができた。 個人的にはコンポジターとのやりとりを通して、ユーザーの要望を形にしていくプロセスを学べたのが大きな経験であると思う。

<h3>概要</h3> 映像制作（主に2D/CGアニメーション）のためのパイプライン及び作業補助のための周辺ツール作成・運用 <h3>担当</h3> パイプラインの設計・開発及び運用 <h3>使用言語・ライブラリ</h3> python, mel, JavaScript, Qt (PySide2) <h3>課題</h3> <ul> 現在の映像制作は、モデリング・アニメーション・エフェクト・ライティングなどの工程の分業が進んでおり、セクション内でのデータの管理、セクション間でのデータの受け渡しを簡単に行えるパイプラインを敷くことが重要になっている。社内に既存のパイプラインは存在するが、改良・変更を施していき、デザイナーが本質的な作業に集中できるように変化していく必要がある。 <h3>取り組み</h3> <ul> <li> 既存の Pipeline の保守・改良を行った。使用言語は主に Python で、GUI が必要な場合は Qt (PySide2)を用いた。一例として以下のようなことを行った。 <br> <ul> <li> セクションをまたぐ出荷作業の高速化。Maya のシーンファイルをテキストとして読んで編集する機能が存在したが、一括読み込み一括書き出しで、バッファも適切に使用していないため IOに時間がかかっていた。読み込みをバイナリモードに変更・ライトバッファを余裕を持たせて設定・逐次読み込みの変更を施すことで、およそ10倍速にすることができた。 </li> <br> <li> アニメーションデータ出荷作業の高速・安定化。アセットのアニメーションを出力するときに、従来はシーンのすべてのデータを読み込んでいたため、重いシーンの場合開くだけで数時間かかり、場合によってはメモリが足りずに処理落ちしてしまうことがあった。処理をレンダーファーム上で並列化して、単体の処理では必要なデータだけを読み込むようにすることで、数日かかっていた処理を1時間程度で終わらせるられるようになり、処理落ちもしなくなった。 </li> <br> <li> Maya の作業シーンの軽量化。大きなシーンになると、開くだけで数十分、オペレーションを挟むと数分止まってしまうものが多かった。そのため、Maya の GPU キャッシュや Alembic キャッシュ・ASS などのキャッシュと実データとの入れ替え機能を作ることで、作業シーンを軽くする取り組みを進めた。 </li> <br> <li> 共用 Python モジュールの整備。レンダーファームへのジョブの投入、前セクションから出荷されたデータの場所の検索など、DCCツール（Maya, Houdini, Nuke など）間で共通のロジックが必要になることが多いため、それらの Python モジュールを整備した。従来はツールごとにハードコードされていたものを整備することで、コーディング時間の削減・保守の手間の削減に寄与した。 </li> </ul> </li> <br> <li> 映像制作管理データベースであるShotGrid（旧Shotgun）を導入する際に、その Python API の調査及びパイプラインへの組み込みを行った。また、社内に立てた Centos のサーバー上で特定のデータベースの変更に対してアクションを hook する機能を整えた（hookの機能自体は提供されている）。この機能はCentos の Service として動かしており、サーバーの再起動時にも自動で起動するようにした。また、サーバーが落ちている際のデータベースの変化に対して、hook を起動するべきものを取捨選択するようにし、誤作動を防ぐようにした。 </li> <br> <li> Photoshop のブラシ・プリセットの切り替えを簡易にするために Adobe CEP の機能を使って JacaScript で専用の切り替えツールを作成した。 </li> </ul> <h3>効果</h3> データ処理の高速化はデザイナーの作業のストレスを軽減し、高評価をいただいた。また、Photoshop のブラシ・プリセット切り替えツールも非常に好評を博しており、社内の作業で常時使われている。ShotgGrid に関しても、hook による自動化が可能であるという認識を社内で共有することができ、それを前提として一連のデータ変更が行われるようになっているため、ShotGrid の有効な活用に寄与していると思う。