OLM R&D祭2022 10/21 "MANIAC" CODE：ソースコードからツール化まで

研究開発といえばプログラミング。プログラミングといえば、ソースコードです。R&Dのスタッフも増え、中・大規模プロジェクト開発も増えてきました。そのためにコード管理をどのようにすべきか？コンパイルまわりから結合テストまで裏の裏の話をさせていただきます。

Transcript

1. "MANIAC" CODE ソースコードからツール化まで Marc Salvati © OLM Digital, Inc. 1
2. R&Dとは © OLM Digital, Inc. 2 将来 管理 技術 ネットワーク・マシン・ソフト 要望・ソースコード プログラミング・情報工学 CG・数学・物理学 プラグイン・ツール 新たな映像表現・長期企画・研究
3. R&Dとは © OLM Digital, Inc. 3 将来 管理 技術 ネットワーク・マシン・ソフト プログラミング・情報工学 CG・数学・物理学 プラグイン・ツール 新たな映像表現・長期企画・研究 要望・ソースコード
4. 2008年のOLMのR&D • リード一人 • 研究プロジェクト – 研究者二人 – アニメーション – アセット管理、パイプライン • SI二人 • 開発一人 © OLM Digital, Inc. 4
5. コンパイル 開発 ソースコードからツールまで © OLM Digital, Inc. 5 ソースファイル スクリプト プラグイン ライブラリ/SDK インストール スクリプト プラグイン 要望・アイデア 自動化 新しい表現
6. コンパイル 開発 ソースコードからツールまで © OLM Digital, Inc. 6 ソースファイル スクリプト プラグイン ライブラリ/SDK インストール スクリプト プラグイン 要望・アイデア 自動化 新しい表現 シンプルです！ VC++ コピー
7. コンパイル 開発 ソースコードからツールまで © OLM Digital, Inc. 7 ソースファイル スクリプト プラグイン ライブラリ/SDK インストール スクリプト プラグイン 要望・アイデア 自動化 新しい表現 シンプルです！ VC++ コピー
8. 開発環境とコンパイル数が多い • プロジェクトが多い • プロジェクト⇒DCCバージョン⇒コンパイラー • 開発環境 – コンパイラー依存 – OS依存 • WindowsとLinux • 昔は32/64ビット • 再コンパイルが発生 – DCCの新バージョン – Arnoldは一年に3-4回 – ツールの改善 • 要望 • バグ発見 © OLM Digital, Inc. 8 プロジェクトA Maya 2019 MtoA 3.2.1 プロジェクトB Maya 2020 MtoA 4.0.0 VC 2015 VC 2017 GCC 6.3.1 GCC 6.3.1
9. インストールが多い • 再コンパイル⇒再インストール – 人数分 – プロジェクト分 – レンダーファーム分 • 共存インストールが必須 – 同時に複数のプロジェクト関わる作業者 – 異なったツールバージョンで作業 – 異なったDCCバージョンで作業 © OLM Digital, Inc. 9 プロジェクトA Maya 2019 MtoA 3.2.1 プロジェクトB Maya 2020 MtoA 4.0.0
10. 自動化と管理が必要 © OLM Digital, Inc. 10 自動コンパイル 開発環境の自動構築 ソースファイル スクリプト プラグイン ライブラリ/SDK 自動インストール スクリプト プラグイン 要望・アイデアの管理 自動化 新しい表現
11. 概要 • ミスを防ぐ・効率的な開発環境 – 要望とアイデアの管理 – ソースコードのバージョン管理 – 自動コンパイル・開発環境の自動構築 – 結合テスト – バージョン番号の決め方 – 自動インストール • まとめ © OLM Digital, Inc. 11
12. 要望とアイデアの管理 © OLM Digital, Inc. 12 コンパイル 開発 ソースファイル スクリプト プラグイン ライブラリ/SDK インストール スクリプト プラグイン アイデア 自動化 新しい表現
13. 要望とアイデアの管理 • 忘れないようにTrelloで管理 • チケット管理 – Pending – Todo – Doing – Done – Released © OLM Digital, Inc. 13
14. 要望とアイデアの管理 • Pending – 開発者にアサインしたい • Todo – 開発者決定 – まもなく開発開始 • Doing – 開発中 • Done – 開発が終わった – アーティストには渡していない • Released – フィードバック待ち • Archive – フィードバックが終わり – 必要なチケット発行してから © OLM Digital, Inc. 14 リード 開発者 リード
15. ソースコードのバージョン管理 © OLM Digital, Inc. 15 コンパイル 開発 ソースファイル スクリプト プラグイン ライブラリ/SDK インストール スクリプト プラグイン アイデア 自動化 新しい表現
16. ソースコードが多数 • 12人 – パイプライン（～3.5人） • 自動化・効率化 • データ・アセット管理ツール • スクリプト系と単独アプリが多い – 開発（～8.5人） • 画像処理、シェーダーなどの一般CG開発 • C++でのDCCのプラグイン開発が多い • 数百万ラインのコード © OLM Digital, Inc. 16
17. バージョン管理無しの運用 © OLM Digital, Inc. 17 プロジェクトB OLM Toon OLM Toon OLM Toon 機能追加リリース無し プロジェクト開始 更新のタイミング OLM Toonを使っているプロジェクトが 全部終わっている プロジェクトA OLM Toon プロジェクトC 新OLM Toon 制作 開発
18. バージョン管理ありの運用 © OLM Digital, Inc. 18 プロジェクトB OLM Toon 2.0 OLM Toon 2.0 OLM Toon 2.1（機能追加） プロジェクト開始 更新のタイミング 必要に応じて プロジェクトA OLM Toon 2.0 プロジェクトB OLM Toon 2.1 プロジェクトC OLM Toon 2.1 制作 開発
19. ソースコードの管理 • ツールのバージョン管理のため • R&Dの資産 – ソースコードはなくしてはならない – 取り消し・やり直しがしたい • 共有したい – 共同開発のため – コードレビューのため – ライブラリの共有 ⇒ソースコードのバージョン管理が必須！ © OLM Digital, Inc. 19
20. 共有するサーバー SVNで管理 © OLM Digital, Inc. 20 ツール1.0 ツールtrunk 最新のソースコード リリースされた ツール1.0のソースコード
21. 共有するサーバー SVNの仕組み © OLM Digital, Inc. 21 ツール1.0 ツールtrunk 開発者1 ツールtrunk ツール1.0 開発の開始前に サーバーから 最新のソースコードをダウンロード チェックアウト
22. 共有するサーバー SVNの仕組み © OLM Digital, Inc. 22 ツール1.0 ツールtrunk 開発者1 ツールtrunk ツール1.0 最新のコードを修正
23. 共有するサーバー SVNの仕組み © OLM Digital, Inc. 23 ツール1.0 ツールtrunk 開発者1 ツールtrunk ツール1.0 最新バージョンから 新たなバージョンを作る ツール2.0
24. 共有するサーバー SVNの仕組み © OLM Digital, Inc. 24 ツール1.0 ツールtrunk 開発者1 ツールtrunk ツール1.0 新たに作ったツールバージョンを 共有サーバーにアップロード ツール2.0 ツール2.0 コミット
25. 共有するサーバー SVNの仕組み © OLM Digital, Inc. 25 ツール1.0 ツール2.0 ツールtrunk 開発者1 開発者2 ツールtrunk ツール1.0 ツール1.0 ツールtrunk ツール2.0 ツール2.0 ツール3.0 ツール3.0 コミット チェックアウト もう一人の開発者が 簡単に 開発を進められる
26. SVNリポジトリーの構成 © OLM Digital, Inc. 26 共有 個人 AE Maya Nuke olm_lib SConstruct OLM Smoother ae_lib 1.0 1.2 trunk src vc SConscript
27. AE Maya Nuke olm_lib SConstruct SVNリポジトリーの構成 © OLM Digital, Inc. 27 共有 個人 OLM Smoother ae_lib 1.0 1.2 trunk src vc SConscript OLMのライブラリ
28. AE Maya Nuke olm_lib SConstruct SVNリポジトリーの構成 © OLM Digital, Inc. 28 共有 個人 OLM Smoother ae_lib 1.0 1.2 trunk src vc SConscript 自動コンパイル周り（Scons）
29. 共有ができるからコードレビュー • 他の開発者のコードを見る – バグ発見 – ルールを守る – ディスカッションする – 勉強になる • OLMでは – 2-3週間ごとに2人が提出、7-8人が見る • レビューするところを自由に選ぶ – ミーティングでディスカッション © OLM Digital, Inc. 29
30. 今後 • アーティストのコード管理 – ソース管理にあまり馴染みがない • Gitに移動 – Gitがスタンダード – リモートの時代なので • Git対応のクラウドサービスが多い – 開発プロジェクトの規模が大きくなってきている – 開発者が増えている – 課題 • SVNと違ってモノリシックなコードベースではない • 運用ルールが必要 © OLM Digital, Inc. 30
31. 自動コンパイルと開発環境の自動構築 © OLM Digital, Inc. 31 コンパイル 開発 ソースファイル スクリプト プラグイン ライブラリ/SDK インストール スクリプト プラグイン アイデア 自動化 新しい表現
32. コンパイルが多い：例 • MtoAを更新 • サポートされているMayaのバージョン • WindowsとLinuxコンパイル – レンダーファームがLinux – アーティストのパソコンはWindows • シェーダー数 © OLM Digital, Inc. 32 Ｘ 3-4 20 2 Ｘ 120-160コンパイル数
33. Sconsで自動コンパイル • Pythonで書く – わかりやすい – メンテしやすい • ツールごとにコンパイルファイル一個 – Sconscript • コマンドライン – ツール名・バージョン – DCC名・バージョン © OLM Digital, Inc. 33
34. SConscriptファイルがシンプルに！ Import("env") import sconsUtil.source_library as source_library import sconsUtil.library as library sourceFiles= Glob("src/*.cpp") sharedFiles = source_library.SourceRequest.get(LIB_NAME, LIB_VERSION, env, SOURCE_FILES) libRequests=[library.LibraryRequest(LIB_NAME, LIB_VERSION, LIB_FILES)] output = env.compileElement.build(env, sourceFiles, sharedFiles, libRequests) Return('output') © OLM Digital, Inc. 34 コンパイルされる ソースコードのファイル OLMの共有ソースコード ライブラリ コンパイルされている ライブラリ
35. MayaのOLM Noise DeformerのSconscript Import("env") import sconsUtil.source_library as source_library sourceFiles= Glob("src/*.cpp") sharedFiles = source_library.SourceRequest.get("olm_maya_util", "2.0.1", env, [ "MAYA_General.cpp"]) output = env.compileElement.build(env, sourceFiles, sharedFiles, []) Return('output') © OLM Digital, Inc. 35 コンパイルされる ソースコードのファイル OLMの共有ソースコード ライブラリ MayaのSDK、バージョンなど書いていない Mayaのバージョン変えても使える
36. Sconsのライブラリ • DCCのコンパイル手続き – バージョンに合わせて • コンパイラー • コンパイルオプション – 特殊ケースの対応（AEのPiplなど） • ライブラリの自動設定 – OLMの共有コード • ソースコードの自動追加 – DCCのSDKライブラリ – 外部ライブラリ © OLM Digital, Inc. 36
37. Sconsの実行 • コマンドライン – LinuxとWindowsで可能 – それぞれのログインが必要 • 処理 – SVNの更新 – サーバーから前のプラグインを削除 – 前のコンパイル結果削除 – コンパイル – 自動インストールの準備 • サーバーへのコピー • 一つのツールのコンパイル可能 – 複数のツールバージョン – DCC複数 © OLM Digital, Inc. 37
38. JenkinsでSconsラッピング • コンパイルを一括化 – 複数のツールの一括コンパイル – WindowsとLinux両方コンパイル – ウェブＵＩから実行 • コンパイル結果とログの共有 • 結合テスト実行 © OLM Digital, Inc. 38
39. コンパイルフローのまとめ © OLM Digital, Inc. 39 Visual C++で設定 Visual Studio Code Notepad++ PyCharm Visual C++でコンパイル Visual C++で修正・作成 ソースファイル スクリプト プラグイン ライブラリ/SDK DCCで試す スクリプト プラグイン サーバー スクリプト プラグイン SVN ソースファイル サーバー ライブラリ/SDK Scons/Jenkins 自動コンパイル プラグイン スクリプト スクリプト 開発者のコンパイル 自動コンパイル SConscript Visual C++ ファイル
40. コンパイルフローのまとめ © OLM Digital, Inc. 40 Visual C++で設定 Visual Studio Code Notepad++ PyCharm Visual C++でコンパイル Visual C++で修正・作成 ソースファイル スクリプト プラグイン ライブラリ/SDK DCCで試す スクリプト プラグイン サーバー スクリプト プラグイン SVN ソースファイル サーバー ライブラリ/SDK Scons/Jenkins 自動コンパイル プラグイン スクリプト スクリプト 開発者のコンパイル 自動コンパイル SConscript Visual C++ ファイル
41. 自動コンパイルと開発環境の自動構築 © OLM Digital, Inc. 41 Visual C++で設定 Visual Studio Code Notepad++ PyCharm Visual C++でコンパイル Visual C++で修正・作成 ソースファイル スクリプト プラグイン ライブラリ/SDK SVN ソースファイル サーバー ライブラリ/SDK スクリプト 開発者のコンパイル CMakeで自動構築 Visual C++ ファイル DCCで試す スクリプト プラグイン サーバー スクリプト プラグイン Jenkins 自動コンパイル プラグイン スクリプト 自動コンパイル
42. なぜCMake？ © OLM Digital, Inc. 42
43. CMake • 長い歴史 – オプションとライブラリの場所指定 – コンパイルができる開発環境生成 • Makeファイル • VC++ファイル • 2017年からCppConでモダンCMakeが話題 – チュートリアルとドキュメントが多い – 使用者が増えた © OLM Digital, Inc. 43
44. モダンCMake • CMake 3からモダン – 以前はHeaderとライブラリのInclude、フラグのリスト – 今はターゲットベース • ライブラリの再利用中心 • フラグはユーザーに © OLM Digital, Inc. 44 外部からライブラリを 見つける ライブラリとリンク
45. モダンCMake • CMake 3からモダン – 以前はHeaderとライブラリのInclude、フラグのリスト – 今はターゲットベース • ライブラリの再利用に中心 • フラグはユーザーに © OLM Digital, Inc. 45 共有ソースコードをライブラリ化に DCCバージョンで決まる ライブラリとリンク 外部からライブラリを 見つける
46. AEのコンパイル設定のライブラリ化 © OLM Digital, Inc. 46
47. AEプラグインのコンパイル手続き © OLM Digital, Inc. 47
48. まとめ • 自動コンパイル – DCCのバージョンアップがしやすい – ツールの配布がしやすい • 自動インストールを楽にする • Cmakeへの移行 – 開発環境の自動構築 • 開発者と自動コンパイル環境の統一 • コンパイル設定の一貫性の改善 – Sconsよりもちょっとファイルが長い – まだ勉強中 © OLM Digital, Inc. 48
49. 結合テスト © OLM Digital, Inc. 49 コンパイル 開発 ソースファイル スクリプト プラグイン ライブラリ/SDK インストール スクリプト プラグイン アイデア 自動化 新しい表現
50. なぜ？ • ツールが思う通りに動いているか？チェックが必要 – DCCバージョン毎 – LinuxとWindows – DCC毎のチェックが違う • Mayaの例：Maya+Arnoldの組み合わせ • AEの例：8/16/32ビット、解像度・マスク付きなど • 手動では無理！ • 自動化が必要！ © OLM Digital, Inc. 50
51. 確認したいこと • 動作 – ロードができるか – UIが動いているか – それぞれの機能が動いているか • レンダリング – 今までの出力結果と同じ – 時間 • DCCのバージョンでの互換性 © OLM Digital, Inc. 51
52. レンダリングベースのテスト • レンダリング結果の比較で分かる – ピクセルが一緒なら • プラグインのロードができて • レンダリングの互換性 • 機能の動作が正常 – レンダリング時間の比較も可能 • シンプル – DCC毎に同じアプローチ可能 – 自動化しやすい © OLM Digital, Inc. 52 リファレンス シーン DCC V1 テスト シーン DCC V3 テスト シーン DCC V2 レンダリング 結果 DCC V1 レンダリング 結果 DCC V2 レンダリング 結果 DCC V3 レンダリング レンダリング レンダリング ピクセルごとの比較と報告
53. AEの例：チェックする項目 • AEのスクリプトで自動生成 – コンポよりも大きいレイヤーに適用 – レイヤーよりも小さいマスクの適用 – ガウシアンブラー適用後のエフェクト適用 – 四角でないピクセルの適用 – 8/16/32ビット – フル解像度、半分の解像度 • 連番レンダリング – 可逆圧縮LZW圧縮のTiff © OLM Digital, Inc. 53 レンダリング数＝AEバージョン数ｘツールバージョン数ｘコンポ数ｘ3 X 2 フル・半分 解像度 8・16・32 ビット
54. AEの例：自動レンダリングと比較 • Pythonスクリプト • レンダーファームに投げる – Deadline – AEライセンスのあるマシンに • 比較 – 画像の比較 – ピクセルの差があるファイル数を出力 • 差が＜1％、＜10％、＞10％ • ImageMagick?遅すぎました • LibTiffのtiffcmp.cのカスタム版 • Jenkinsで実行 – リファレンスのレンダリング – テストのレンダリングと比較 © OLM Digital, Inc. 54
55. 今後 • リファレンスの更新のやり方、自動化 • AE – それぞれのAEプラグインのリファレンス作成 • Maya – シェーダー、リグ、デフォーマーはレンダリングで – GPUレンダリングはPlayblast? – 自動化のスクリプト系は？ • その他のDCCも – Nuke – Houdini – Photoshop・・・ © OLM Digital, Inc. 55
56. バージョン番号の決め方 © OLM Digital, Inc. 56 コンパイル 開発 ソースファイル スクリプト プラグイン ライブラリ/SDK インストール スクリプト プラグイン アイデア 自動化 新しい表現
57. 概要 • プロジェクトごとの運用 – 開始時は最新 – 必要に応じて途中でバージョンアップ • クラッシュ問題 • 必要になった機能 ‐ アセット ↔ ツールバージョン の管理が必要になる！ • 見てバージョンアップ可能か知りたい © OLM Digital, Inc. 57
58. セマンティックバージョニング © OLM Digital, Inc. 58 X.X.X マイナー メジャー パッチ
59. セマンティックバージョニング © OLM Digital, Inc. 59 後方互換性がある 機能を追加した場 合 APIの変更に互換性 のない場合 後方互換性を伴うバ グ修正をした場合 ライブラリのために 作られたルール X.X.X
60. セマンティックバージョニング © OLM Digital, Inc. 60 互換性がある 機能性 互換性がない 互換性を伴う バグ X.X.X
61. 映像制作でのバージョニング • バグと機能の違いは大事じゃない • 使えるかどうかが大事 – エラーなくシーンを開ける？ – 思ったような画像になる？ • バージョンを見て更新するかどうか判断したい © OLM Digital, Inc. 61
62. 映像制作でのバージョニング © OLM Digital, Inc. 62 出力結果が 変わった 前のシーンを開けない まだプロダクションでは使 えないのは0 その他 出力結果も構造も変わらない • 機能追加 • バグ修正 出力 構造 互換性 X.X.X
63. 映像制作でのバージョニング © OLM Digital, Inc. 63 出力結果が 変わった その他 出力結果も構造も変わらない • 機能追加 • バグ修正 出力 構造 互換性 X.X.X (.X) パッチ 前のシーンを開けない まだプロダクションでは使 えないのは0
64. パッチってなに？ Wikipediaから 「パッチ（英: patch）とは、コンピュータにおいてプログラムの一部分を更新し てバグ修正や機能変更を行うためのデータのこと。「修正プログラム」や「アッ プデート（プログラム）」などとも呼ばれる。」 小さいバージョンアップ OLMでは 一時的にバージョンアップ © OLM Digital, Inc. 64
65. パッチってなに？ © OLM Digital, Inc. 65 プロジェクトB OLM Toon 2.0 引き続き、パッチ OLM Toon 2.0.0.1 OLM Toon 2.0 OLM Toon 2.1 機能修正 OLM Toon 3.0 大幅機能追加 OLM Toon 2.1.1 クラッシュ修正 バージョンアップ OLM Toon 2.1.1 OLM Toon 2.0.0.1 2.0+2.1.1クラッシュ修正 プロジェクト開始 2.0でクラッシュが 起きるのを発見 プロジェクト終了 プロジェクトD OLM Toon 2.0 プロジェクトA OLM Toon 2.0 プロジェクトC OLM Toon 2.0 プロジェクト OLM Toon 3.0 パッチ 無しの 運用 パッチ ありの 運用
66. まとめ • バージョン番号のルールが大事 – 管理が必須 • バージョンは分かりやすい – 見て使えるか分かる – 開発者が決めやすい • リリースノートもしっかり – どう互換性がなくなったのか – 画像がどう変わったか – どういう機能を追加したのか © OLM Digital, Inc. 66 出力 構造 互換性 X.X.X (.X) パッチ
67. 自動インストール © OLM Digital, Inc. 67 コンパイル 開発 ソースファイル スクリプト プラグイン ライブラリ/SDK インストール スクリプト プラグイン アイデア 自動化 新しい表現
68. なぜ自動インストール • ツールを使ってもらいたい – 使えるようにインストールしたい – DCC毎に設定が違う • いくつかのプロジェクトを平行で作業する – DCCの起動時ツールのバージョンを選びたい • 自動化が必要 © OLM Digital, Inc. 68
69. OLM Setup • ツールリストからツールの設定 – コピー – DCC内で使えるように • DCCを起動 • バッチで実行 • 最近OLM Setup Launcherでバッチ実行 © OLM Digital, Inc. 69
70. OLM Setup Launcher © OLM Digital, Inc. 70 DCC 環境：プロダクション、テスト、開発 プロジェクト名 プロファイル名
71. • プロダクション環境 – 制作する環境 – 安定したもの – バージョン固定 • テスト環境は制作に使わない約束 環境とは？ © OLM Digital, Inc. 71 開発 プロダクション OLM Toon 1.0.1 OLM Toon 1.0.1 開発中 OLM Toon 1.1 リリース バージョン固定 OLM Toon 1.0 テスト
72. プロファイルとは • XMLファイル • プロジェクトが使うツールのリスト – DCCのバージョン – ツールのバージョン – MtoA・Bifrostのバージョン • 外部のツールも扱う – OpenVDB – Golaem – Yeti • 同じプロファイル＝再現可能 © OLM Digital, Inc. 72
73. OLMSetupのフォルダー構成 • コンパイル後、ファイルサーバーへ – 構成ルール • ツールのフォルダーの構成はDCCによる – DCC個別の設定が必要 © OLM Digital, Inc. 73 olmsetup production test dev tools ae maya nuke houdini ps toonboom olm others ツール名 バージョン
74. ツール名 バージョン 例：Mayaフォルダー構成 © OLM Digital, Inc. 74 plugins 64 Mayaバージョン windows ツール名.mll linux arnold_shader 64 Arnoldバージョン windows ツール名.dll linux scripts ツール名.so ツール名.so extensions header pythonTemplates Mayaバージョン 64 windows linux ツール名.dll ツール名.so ツール名.mtd ノード名Template.py mel ogsfx python xml olm_uis_ツール名.mel AEノード名Template.mel *.mel *.ogsfx *.py *.xml
75. ツール名 バージョン 例：Mayaフォルダー構成 © OLM Digital, Inc. 75 bin bifrost config.json *.exe *.dll *.pyd icons module *.png Mayaのモジュール構成。省略。 mental_ray_shader もう使わない。省略。 <USER_HOME>¥olmsetup dev test production プロフィル名 ツール名 ツールバージョン maya plugins arnold_shader …
76. Mayaの設定 • 実行する前にコピー • 実行する前に環境変数を設定 – MAYA_PLUG_IN_PATH：プラグインフォルダー – MAYA_MODULE_PATH：モジュール – MAYA_SCRIPT_PATH：MELスクリプトフォルダー – PYTHONPATH：Pythonスクリプト – XBMLANGPATH：アイコンフォルダー – MI_CUSTOM_SHADER_PATH：MentalRayシェーダー – BIFROST_LIB_CONFIG_FILES：BifrostのCompound – ARNOLD_PLUGIN_PATH：Arnoldのプロシジャー – MTOA_EXTENSIONS_PATH：ArnoldのTranslatorなど – MAYA_RENDER_DESC_PATH：レンダラー – MAYA_COLOR_MANAGEMENT_POLICY_FILE：カラーマネジメント用 – MAYA_UI_LANGUAGE：英語・日本語の切替 – ADSKFLEX_LICENSE_FILE：ライセンスサーバーの指定 – コマンドライン用 • LD_LIBRARY_PATH：コマンドラインツールの実行 • PATH：コマンドラインツールの実行 © OLM Digital, Inc. 76 プラグイン用 Arnold用
77. まとめ © OLM Digital, Inc. 77
78. ルールが大事 • ルール無し＝自動化無し • ルールとは – 決める（管理） – 守る（自動） – 使う（自動） • 柔軟な対応が可能なルール – さまざまなDCCの対応 • OLMではPhotoshop, After Effects, Maya, Nuke, Houdini, Arnold, … – さまざまな環境（OS・リモート・・・） © OLM Digital, Inc. 78
79. 開発の世界 自動化と管理 © OLM Digital, Inc. 79 自動コンパイル 自動結合テスト 自動開発環境構築 コードレビュー バージョン管理 ソースファイル スクリプト プラグイン ライブラリ/SDK 自動インストール バージョン管理 スクリプト プラグイン 情報管理 アイデア 要望 リクエスト
80. 結論 • 管理がないと将来の道がない – 人数が多いほど大事 • 自動化・仕組みが必要 – 技術の進化に伴い更新 • 管理の幅が広い – コード – ツール – 要望 – 人 © OLM Digital, Inc. 80 将来 管理 技術