はじめましての人ははじめまして。そうでない人はこんにちは。日本CGサービス（JCGS）の痴山紘史です。今回から、「痴山紘史の日本CG見聞録」と称して私が気になった技術的なトピックをご紹介していくことになりました。
TEXT_痴山紘史 / Hiroshi Chiyama（日本CGサービス）
EDIT＿尾形美幸 / Miyuki Ogata（CGWORLD）
言い出しっぺの法則
この連載を始めるきっかけになったのは、呑み会の席でCGWORLD編集部の尾形（美幸）さんに「CGプロダクションに近いエンジニアが技術的な情報交換をする場がないんですよね」というお話をしたことでした。「プロジェクトでTAやTDとして¨こういうツールをつくりました¨というお話はたくさんあるのですが、もうちょっと深掘りして、技術的な議論を中心に据えた記事がほしいんです」というお話をしたところ、「じゃあやりましょう」となったのです（言い出しっぺの法則！！）。
そのような経緯で始まった連載のため、月刊『CGWORLD』やCGWORLD.jpでは普段あまり扱われないテーマを、これまでターゲットとしていなかった方に読んでいただく内容がメインになります（そもそもそんな奇特な読者がいるのか.........？という不安感もありますが）。そのようなちがいがあるため、第1回目はこの連載がどのような立ち位置で、何をしていきたいかをご説明していきます。「前口上長いよ！！」とお思いでしょうが、ちょっとだけお付き合いください。
本連載のトリセツ
本連載はエンジニアに対して技術的な内容をご提供していくことを目的としています。その中でも、論文紹介のようなものよりも、プロダクションで働くエンジニアが日々触れるような、現場よりの技術紹介を中心にしていきます。
私も可能な限り内容に間違いがないよう努力しますが、時には内容が間違っていたり誤解してしまっていることもあるかと思います。技術的な内容を議論する場合には年齢や立場は関係なく、正しいものは正しい、間違っているものは間違っていると明確にしてより良い知見を得ることが大事です。CGWORLDで主に扱われる「作品」というものは何が正しくて何が間違っているのか判断することが難しく、言ったもの勝ちになりがちなことが多いですが、技術的に間違っていることは間違っているので、そこは気兼ねなくドシドシ突っ込みをおねがいします。記事中の内容で間違いなどありましたら CGWORLD編集部（cgw@cgworld.jp）や私のTwitterアカウント（@chiyama）までご連絡いただけるととてもありがたいです。また、ネタのご提供をいただける方も（切実に！！！）募集しています。
どこまで解説して、どこを省くか？
このような連載を始めるにあたって悩ましいのが、どこまでを基本的な知識として説明を省くかということです。本来ならLinuxの使い方やバージョン管理システムの解説といったところから順番に進めていくべきなのでしょうが、それをやっているといくら紙面があっても足りないですし、エンジニアにとっては当たり前でつまらない内容になってしまいます。また、世の中には私が書くよりも格段に良質なドキュメントが揃っているので基礎的な内容はそちらにお任せすることにして、私の独断と偏見でここまでの内容なら想定読者なら知っているだろうというラインで線引きをすることにしました。
具体例を上げると、Linuxの操作やバージョン管理システムの概念、gitの使い方といった一般的なコンピュータの使い方は前提知識としてもっているだろうということにします。ただし、基礎的な知識であっても映像業界特有のものであったり、ある程度新しめのものについては随時説明を入れるように心がけていきます。たとえばOSの仮想化は知っているだろうという前提ですが、Dockerのようなコンテナ技術は比較的新しめなものなので軽いご紹介くらいはした方がいいかなと思っています。Linux上でのMayaなどのアプリケーション環境の構築は業界特有の内容なので、ハマりどころがあったら解説を入れるようにします。
これまでの日本や海外での似たような動き
まずは、技術的な情報交換としてどのような活動が行われてきたかを振り返ってみます。
日本で技術的な情報交換の場というと、CEDECを真っ先に思い浮かべる方が多いでしょう。ただ、CEDECはゲーム開発者向けのカンファレンスなのでプロダクションで働くエンジニアがほしい情報とはちょっとポイントがずれている感じがします。それでもとても勉強になることも多いので貴重な場ですけどね。
日本のプロダクションで働いているエンジニアが情報交換をする場としてはCGWORLDクリエイティブカンファレンスの「CGスタジオのエンジニアがシステムをできる限り公開！2017∼良い作品を作るための¨あの手この手のやりくり¨を紹介∼」というセッションや、CEDECで行われているTA Bootcampなどがありました。また、プロジェクト内でのツール開発事例は月刊『CGWORLD』の記事の中でも取り上げられています。ただ、これらで今ひとつ不満に思っていたのが、個別のスタジオやプロジェクト内での具体的な事例がメインとなるため、どうしても単発的な内容になってしまいがちなことでした。
いずれにしても、現場で使用している技術や日々行なっていることを普遍的な内容まで落とし込んで、発展性をもって語られることが少ないなぁというのが私の印象です。
海外ではSIGGRAPHが大きな役割を果たしてきたことは間違いないです。また、コミュニティとしてはスタジオのシステム管理者が集まるStudio Sysadminsで日々情報交換が行われていますし、パイプライン関係者が集まって議論をする「Global VFX Pipelines」がSIGGRAPHのA Birds of a Feather（BOF）として開かれていて、日常的に集会もあるようです。また、Visual Effects Society（VES）にも Technology Committeeがあり、テクノロジー関連の議論や規格の策定が行われています。このように、草の根活動もありつつ組織的な交流が行われている印象を受けます。
また、プロダクションが開発したプログラムをオープンソースソフトウェアとして公開する事例も増えています。Industrial Light & Magic（ILM）のOpenEXR やPixar Animation StudiosのUSDはとても有名ですし、Image EngineはGafferを公開しています。また、Animal LogicもGitHubにリポジトリを公開しています。日本ではポリゴン・ピクチュアズの子会社だった（※1）J CUBEがMultiverseを公開しています。これ以外にも、海外有名プロダクション名+GitHubやOpenSourceで検索すると必ずと言っていいほど公開されている技術を見つけることができます。
※1 J Cubeは2017年にポリゴン・ピクチュアズから独立したというご指摘をいただきました。ご指摘ありがとうございます。
日本と海外の事例で大きく異なるのは、プロダクション独自の秘伝のタレを煮詰めていくのではなく、社外と技術を共有しながら、（CG／VFX業界に限らず）世界とつながった形で技術開発を行なっていく姿勢だと感じます。この姿勢は本連載でも学んでいきたいところです。
想定環境
この連載で想定する環境を決めていきます。
現在、多くのスタジオでLinux導入が進んでいます。海外大手プロダクションではほかに選択肢はありませんし、日本でも既に普通になってきています。一部Windowsを使用しているスタジオもありますが、前述のような実績のあるオープンソースソフトウェア（OSS）を含めたインフラ、システムの管理コスト、人材集めなど多くの点でデメリットの方が大きく、主流とは言えません。
.........と言うのはさすがに煽りすぎですね。でも、開発者はLinuxないしはMac OSXベースで開発を行うのが普通ですし、世界中にあるOSSもWindows対応は二の次もしくはそもそも対応していないということが多いです。そのような状況の中Windowsを使うメリットはないので、本連載ではLinux環境をベースにお話を進めていきます。エンジニア向けの連載だからこれでいいのです :-)
Linuxにも多くのディストリビューションがあります。ざっと眺めたところ、VFXスタジオではCentOS6/7ないしはRedHat優勢な感じかなという印象です。そして、Ubuntuに徐々にシフトしてきている感じもします。感覚的には、VFX スタジオ向けのOSSは「CentOSやRedHatなら自分たちは使ってるよ、そしてUbuntuもサポートしているよ（でも動かないかもねテヘッ♪）」という感じが多い気がします。そこで、本連載では特に問題がなければCentOS7をメインで、使用するソフトウェアによってはUbuntuも使っていくことにします。
次回予告
以上で長い前口上は終わりです。やっと次回から本題に入っていきます。
まずは、グローバルスタンダードな環境を手元につくってみることから始めましょう。スタジオで運用する環境を構築する際、使用するコンパイラや各種ライブラリのバージョンがある程度揃っていないと、ソフトウェアベンダーもユーザーも勝手な環境をつくって管理が煩雑になってしまいます。それを避けるため、先ほども少し触れたVESのTechnology ComitteeがVFX Reference Platformを策定しています。現在の最新はCY2018ですが、公開されているOSSの様子から類推するに、現場で使用されている環境はCY2016が主流なようです（こういう情報もGitHubを眺めるとなんとなく透けて見えてきます）。とは言ってもずっとCY2016のままいくわけではなくプロジェクトの開始やシステムの更新に合わせてアップグレードされていくことでしょう。
VFX Reference Platformで議論されている内容や仕様を見ると、今後どのようなながれで環境がバージョンアップしていくかを知ることができます。ひとつ大きなトピックとしては、次に策定されるCY2019でPython3が推奨されるかもしれないということです。皆さん、Python3対応していますか∼？（ああ、ブーメランが.........）（※2）
※2 脱稿後にCY2019 DRAFTが発表され、Python3はいくつかの技術的問題から正式対応はCY2020に持ち越しになりました。ただ、かなり強い調子で Python3への移行の準備をするように警告されています。
VFX Reference Platformは使用するディストリビューションまでは指定していません。また、インストーラなども用意されていないので環境構築はスタジオごとに行う必要があります。メーリングリストを見ていると、要望は上がっているようですがあまり乗り気ではないようです。
一度でもVFX関連のツールの自前ビルドを試したことがある人ならわかるかと思いますが、VFX Reference Platformで上げられているライブラリのいくつかは本当にビルドのハードルが高く、がんばって何とかしようとするものの心がポッキリ折れるというものが結構あります。そ・し・て、gccやglibcのバージョンがディストリビューション標準のものと異なるので、全て自前でビルドを行う必要があります。実際に私もこの記事のためにCentOSで環境構築を試したのですが、PySide2で早々にエラーが出て天を仰ぐことになりました.........。
そのような、本職のプログラマやシステムエンジニアでも骨が折れるCY2018環境の構築をどのように行なっていくか、次回順を追って解説していきます。それでは皆さん、本連載をよろしくおねがいします！！
今回は以上です。次回もぜひお付き合いください。
（第2回の公開は、2018年7月を予定しております）
プロフィール
